About a week ago I posted this thread where I asked if anyone had considered using a microcontroller to add some modern functionality to a 6502 SBC. By the replies, I'm guessing no one had, so tried to figure out how to do this.

For this project, I'm using a ATMega32u4 microcontroller, a relatively cheap part that's much less expensive than the parts it will be replacing (a 6850 and MAX232). There are two distinct design goals for this project:

A USB serial port, as I can't think of a new computer that comes with an RS232 port. This will be implemented with LUFA on the microcontroller. Incidentally, LUFA is able to use just about EVERY USB class, from virtual COM ports to MIDI and HID hosts and devices. If you want a 6502 SBC to receive data from a USB keyboard, that's possible with this setup.

In-system ROM programming to allow for rapid development of new software. Basically, I'm stealing the idea from this project. It's just a pair of shift registers attached to the address bus with a few pins on the microcontroller for the ROM /OE /CE and /WE. I had originally thought about using the Bus Enable pin on a WDC 6502, but realized giving the uC control of the CPU reset pin would also be required (to soft boot the machine) and also has the same effect.

In use, the microcontroller will function as a virtual COM port, translating the data bus on the SBC to the serial port. The virtual COM port on the uC is mapped to $A000 -$BFFF. One interesting aspect of this setup is the ability to use the SPI port on the microcontroller for an SD card. This would require a little more address decoding for the microcontroller, but the fact that we have a microcontroller running twenty times faster than the 6502 means some *very* interesting stuff can happen. I2C and SPI devices are extremely easy to implement now. Hell, even WiFi wouldn't be that much of a stretch.

There are still a few issues with the schematic, but nothing really major. One consideration for this prototype is breaking out the address, data, and ROM control pins out onto 0.1" headers, just for testing purposes. I expect that requirement to go away in a future version of this hardware allowing for a significant reduction in size, even though it's only 80mm x 80mm (3.125" square). I've posted the two sheets and an extremely preliminary board below. If the schematics are illegible, here's an album of all the pics.

Sheet A, showing the ATmega32u4 and shift register ROM writer:



Sheet B, showing the rest of the SBC:



And a totally incomplete board layout:



EDIT: In the hour or so since I posted this, I realized how dumb my address decoding was. Now I'm selecting the ROM with a 3-input NAND on A13, A14, and A15. I've also replaced the direct addressing of the microcontroller with the other two gates in a 74ls10. This gives me two microcontroller chip select lines, meaning it's even easier for the uC to function as a serial output and an SD card.

I just bought this FTDI USB-to-RS232 converter from Mouser for $19, but I have not set it up yet.




So you're talking about a microcontroller running at several hundred MHz? (I2C and SPI are very easy to bit-bang with a 6522 anyway though.) Can you make the schematics clickable to enlarge. There's not enough resolution as it is to see much.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

No, his 6502 is running at 1 MHz.

PL2303(HX) modules are a cheaper option. They go for a few pounds/dollars on eBay.

_________________
Andrew Jacobs
6502 & PIC Stuff - http://www.obelisk.me.uk/
Cross-Platform 6502/65C02/65816 Macro Assembler - http://www.obelisk.me.uk/dev65/
Open Source Projects - https://github.com/andrew-jacobs

Regarding the clock, I recommend replacing the crystal oscillator circuit with a canned oscillator. Or possibly deriving the clock from a microcontroller pin, which would allow easy single stepping/debugging.

You can also use a USB-serial-TTL adapter. With this, the MAX232 is not needed anymore.
http://www.ebay.de/itm/USB-2-0-to-TTL-U ... 3a7a450c8f
This one is about 5$.

_________________
How should I know what I think, until I hear what I've said.

Interesting....

I had a similar idea, as a means to add I2C to my 6809 setup. I never got as far as to do any actual experiments though. The question is, is a ATMega fast enough to get itself off the data bus after the host CPU does a read? It sounds quite natty, implementing in software the control signal logic for a traditional piece of hardware like a UART. Is this possible? I assume it is. But still, it sounds almost alien....

Other uses for AVRs and the like I can think of:

* "side loading" RAM from an SD card while the CPU is halted, presumably replacing the traditional [EEP]ROM completely if necessary
* IO expander (VIA type stuff) when interfaced with the hosts databus, or (a poor second) over a UART

Assuming it is possible to have an AVR sit on a 6502/other 8 bit bus, there are indeed some interesting possibilities.

Lawrence

_________________
8 bit fun and games: https://www.aslak.net/

This is what I'm trying to figure out. Just from the speed alone - 16 or 20 MHz on the AVR - it should be possible. There's also the fact that right now, I'm not considering pushing data *from* the uC to the 6502; the atmega is only grabbing data from the data bus.

Of course, with all the potential for really cool stuff like Ethernet and SD cards, pushing data on to the data bus with the uC would be ideal. I'm gonna have to send off some emails to people much smarter than me.

That would be a big limitation for the USB/serial interface if the 6502 cannot receive any data.

Oh wow I'm a moron.

At least I have some experiments to do.

I've been using the pictured FTDI USB/Serial device for months, either assignd to a Win7 VM under fusion, native under Windows, OSX or Linux and either Putty (Win or Linux) and Terminal/Screen under OSX. A more integrated device is available in the form of a DB-9 mounting shell which has a mini-USB on the plug side is the RS-232 signals on the pin mounting. You can order with RS-232 voltage levels or a 3.3V or 5V version and skip the RS-232 level conversion, i.e., direct to the onboard 6551 or whatever you use for a console serial port on your SBC.

http://www.mouser.com/ProductDetail/FTD ... yVDNan4%3d

One of these will be on my next SBC layout for a console.

_________________
Regards, KM
https://github.com/floobydust

Even with this kind of speed the AVR would not be fast enough unless it is doing nothing else (handling the parallel bus) and I guess that is not an option. The AVR simply has no hardware to latch or tristate a parallel port by means of an external signal. Software would be far too slow to accomplish this unless it just sits there and waits to do it.

Daryl shows how to do it with the help of an extra latch stearing the RDY input of the 6502 (I think that works only for a read). http://sbc.rictor.org/vid3.html The other option also shown is to buffer data to the AVR with an octal latch.

_________________
6502 sources on GitHub: https://github.com/Klaus2m5

I have one of these stuck into my breadboad - works lovely. You can even tap the 5V line. You do have to use a USB extension lead if you do it that way though.

Lawrence

_________________
8 bit fun and games: https://www.aslak.net/

Some model PICs have a peripheral called a 'Parallel Slave Port' (PSP) that lets them do this. The peripheral allows PORT D to be connected to an 8-bit data bus while PORT E has read, write and chip select control signals (e.g. /RD, /WR and /CS). The firmware loads a value into the port latch to provide data if the chip is read and will latch external data if it is writen. An interrupt fires after each read and write to allow the port to be serviced and made ready for the next access. I don't know if AVRs have the same capability.

Doing this in software would require several instructions. You would need to monitor the control signals and decide when to make the port an output with a value on the rising edge of combined signal CS & RD or latch an input on the falling edge of CS & WR. The microcontroller would need to be executing much faster than the host CPU to be sure of catching the transistions within the hosts timing limits.

Some of 24F/33F devices have an extended slave port with two address lines so you can make the PIC appear at four consecutive memory addresses but these are 3V3 devices.

I've been working on a design for a minimal ROM-less 65C02 system (65C02 + 65C22 + 128K RAM + PIC + 2x GAL) where this peripheral is used to turn a PIC into a UART after it has loaded a boot ROM image into the RAM.

_________________
Andrew Jacobs
6502 & PIC Stuff - http://www.obelisk.me.uk/
Cross-Platform 6502/65C02/65816 Macro Assembler - http://www.obelisk.me.uk/dev65/
Open Source Projects - https://github.com/andrew-jacobs

Right now I have the uC 'CS' pins on the 0th and 1st hardware interrupts. You have a point, but most AVR instructions are one or two clock cycles. Maybe if I clock the 6502 at a few hundred kHz, it might work with some very clever coding.