6502.org

Well my first 6502 build is rather strange. It's going to get put in a display case in my ECE Department for people to see. My plan is to have it just send the SL train animation to a terminal over UART. SL is actually written in C, so I'm not going to be running that, or porting it to 6502 assembly. What I have done is captured the output using putty session logging so that I have the series ascii commands that produce it. At full screen width on a monitor the size/resolution that I'll be running this on, and after cleaning up the couple of bash command lines from it, it is 53kB. This means I'm going to have a rather ROM heavy build. The plan is that I'll store that as an array in ROM, then just write the minimal code to set up the 6551, and loop through the array, sending it out the UART to a raspberry pi connected to a monitor. I could use the raspberry pi's build in UART, or use a FTDI USB cable on the pi. Then just let the old 6502 just loop that all day long.

The memory map I have planned out is:
ROM: 0x1000 to 0xffff
6551: 0x0800 to 0x08ff......really i think it ends up going to 0x09ff, but it doesn't matter
RAM: 0x0000 to 0x07ff

This is about 60kB of ROM, so that should fit the 53kB of data, and leave me 7kB of program space, and vectors, which should be way more than I need for such a simple application.

It's probably just going to run on a solderless breadboad from a 1mhz clock. The 6551 will have the 1.8... clock that the baud rate generator requests in the datasheet. I plan to run the baud rate at 19200. So the bug in the wdc 6551 has. Since I'm not going to have a 6522, that T2 work around isn't going to be practical for me. Should I rig up something with a decade counter? Or should I just put in some wait states in my loop, and try to tune it for as little waiting without losing bytes? Can I connect the baud rate oscillator to the RxC pin, and set the control register to 0000, and get 115,200 baud? I'm thinking the faster I can get the UART going, the better/smoother the animation will be.

For memory decoding, as you can see from the map, if any of pins a12-a15 are high, then the ROM need to be enabled. An the RAM and 6551 also have to be aware of that as well. A 4-input NOR gate is super convenient for this on a12-a15, then using its output to enable/disable the ROM, as well as a 3-8 decoder. The 74AC138 has 3 enables, one of which is active high, so I can use that. If I use a 2-4 74AC139 it has only 2 enables, and they are both active low, so I would need to add an inverter in between the NOR gate and the decoder. The 138 and 139 otherwise have the same propagation delays, so I figure why not just use the 138 so I can skip adding another layer of propagation in the form of an inverter. But the real time hog here is that you cannot buy fast 4 input NOR gates. The only one I can find is a CD4002B, and its propagation delay is 125-250ns. I'm going to run my clock slow (1MHz), and it will always be enabled, so I don't think it'll be a problem for this application. The problem is my weird memory map for this build. I have so many address pins that will indicate ROM. Do you think this will be a problem with this particular application? If I really have to, I can just do a CPLD to decode the whole thing. Part of what drew me into the build was that it was going to be so strange.

Just to be clear, the 6502 is not going to be reading anything from the UART. This is just going to be outputting the train animation with no user interaction. Later if this computer generates any excitement, and I come up with another idea for this, I may remap the memory, rebuild the machine a bit different, and do something else.

Welcome! An interesting project: very much an appliance. In this case, I see no problem with using a software timing loop to keep the UART happy. You'll probably get advice to use a different UART, and take various decisions which increase flexibility, but if you're sure you know what this machine needs to do, you should be able to just get on with it.

Do keep us updated with progress!

I did consider a lot of other UART options. The older 6551 chips that don't have the bug, but they are kinda pricey used chips that take a month to ship from a recycling yard in china. I considered that DUART board that is on one of the hobby pages, and maybe putting an xbee on one of the UARTs. I thought about using a 6522, and an SPI MAX3100. But being that this is just going to be an appliance on a solder-less breadboard for now, all these options just seem to add unnecessary complexity that the project doesn't need, and I maybe don't need to have on my first build. The memory map is already bizarre enough.

Do I need to use a MAX232 or something to do a level shifting on the 6551's UART output? The FTDI USB cable I have is 5v tolerant, and since I won't be sending anything nothing will need to read the 3.3v logic the cable will send with. I'm assuming that the 6551 is producing 5V logic. Is this correct?

This is my cable. I've used it on both 5v and 3.3v logic many times without problems.
https://www.adafruit.com/product/70

Right. The '51 has no RS-232 line drivers or receivers onboard. You mention the MAX3100, which I like. I've been using the MC145406 (same thing as the SN75C1406) triple line driver and receiver in a 16-pin DIP which takes significantly less board space than the same number of channels in charge-pump-type ICs; but the MAX3110 (note the extra 1 replacing a 0) has onboard line drivers and receivers, using charge pumps. The 145406 needs the ±12V power supplies (or ±10V, whatever—it's not critical at all) which I always have for other things anyway, like my onboard D/A converter, audio amplifier, and LCD backplane; so why not use it. The MC145407 does have charge pumps, but has more pins to connect their capacitors.

Will there be enough performance for the job you have in mind for it to do if you spend the time in timing loops? (You could subtract from the loop delay for other things the processor needs to be doing, as long as you don't overshoot and get done early and write the next byte too soon.)

I was thinking that maybe I could connect the FTDI USB cable directly to the '51 since I don't need to go all the way up to RS-232 voltages for this build. Would that work? I'm assuming the '51 is going to put out 5v logic levels, which the FTDI cable will tolerate despite being a 3.3v device.

That should work just fine. Unless you have some old "real" terminals or old PCs/Laptops with real serial ports, I'd not bother with the MAX devices at all. I use TTL serial for almost all my stuff these days and when I need to connect to proper retro computers with real RS232/EIA voltage levels then I use Startech USB adapters.

-Gordon

Yes, second that: serial at TTL levels is the usual story for hobbyists, where distances are often a few inches (or cm).

For serial connections I've been using the HC-05 and HC-06 Bluetooth modules lately. Readily available, easy to set up, no wires!!!

Thanks for the replies. That's what I thought about just being able to connect the ftdi cable right to the 6551, but then I started to doubt myself when I saw a youtube video full of errors.

Hi!
Then, you don't need an UART, you can simply shift the bits via software.

In fact, being a little clever, you don't even need RAM, and can use the R/W line to simply latch a data bit as the serial output. Without RAM you can't do subroutines, but you can use X and Y registers as counters and do a simple loop like:
Note that for decoding the output bytes, you only need a D flip-flop clocked by ( RW NOR Phi2 ), then you have 8 output lines that change on any write.

Wow, dmsc! It takes a very clever and slightly twisted mind to imagine a useful 65xx device with no RAM! I'm not qualified to comment on its feasibility, but I'm impressed just the same.