My 6502 Roadmap - Comments, Advice and Suggestions Requested

[Shawn Odekirk]

floobydust wrote:

First, congrats on getting your system up and running, that always feels good... having success!

Thanks!

floobydust wrote:

- Look at the TI7705B as a reset chip. It will give you positive and negative reset lines.

I've studied your design and saw that you were using this chip. I should have considered switching to this chip before purchasing additional DS1813s. It's hard to justify paying more in shipping than for the parts themselves, so this will probably have to wait until the next revision.

floobydust wrote:

- You can use the DS1813 for a NMI trigger (panic button).

Has this feature proven useful? I think in most cases a hard reset would be sufficient for my needs.

floobydust wrote:

- WDC also make a W65C22 with an open collector IRQ output.

Again, I wish I had realized using the W65C22N would simplify my design before purchasing additional W65C22S chips. Ordering a couple W65C22N chips would certainly help offset the shipping costs, but then I'd be stuck with unused W65C22S chips. Again, something for the next revision.

floobydust wrote:

- I'm guessing you're using one of the serial lines for a console. In most cases, a Serial-to-USB adapter is used, as most current systems don't have serial ports anymore. If this is the case, you could swap out one of the DB-9 connectors with a FTDI adapter... mounts in the DB-9 format and can connect directly to the SC28L92 without any level changes.

I guess I really fell short when doing my homework. I thought that these provided a physical DB9 connector and that a USB-to-Serial adaptor would still be required, but looking at them more closely it looks like they provide a physical USB mini B connector. They're a little pricy, but considering they replace the level shifter and the physical DB9 connector, the cost is closer. One more thing to consider for the next revision.

I'm still running V1.4 of your monitor and have consulted your C02BIOS V2 source for help getting the NXP UART working. Your code has been a huge help. Thanks!

Shawn

[Shawn Odekirk]

BigDumbDinosaur wrote:

I'm not seeing anything in your layout that takes care of power and ground. Is this a four-layer board?

Yes, it is a four-layer board.

BigDumbDinosaur wrote:

Also, there are some places where traces are needlessly being "wound around" pins. Some massaging should produce shorter and more direct paths.

I will try to work on that.

BigDumbDinosaur wrote:

Pay attention to the board house's design rules with regard to spacing of different board features. It looks as though you're pretty tight in a couple of locations

I think I've configured KiCad to match the board house's capabilities, but I am a newbie and could have missed something.

BigDumbDinosaur wrote:

it's hard to estimate anything with the layouts in PDFs.

Is there a better format I could use? Since not everyone uses KiCad I thought PDFs would be the best.
I did remember to output them in monochrome!

Shawn

[GARTHWILSON]

Shawn Odekirk wrote:

I wish I had realized using the W65C22N would simplify my design before purchasing additional W65C22S chips. Ordering a couple W65C22N chips would certainly help offset the shipping costs, but then I'd be stuck with unused W65C22S chips. Again, something for the next revision.

Note that there are more differences than that. From WDC's website:

Quote:

W65C22S/W65C22N Differences

• The W65C22S is lower power, faster and direct drive outputs with no current limiting resistors on outputs ports.
• The W65C22N is plug replacement of NMOS 6522 devices with current limiting resistors on output ports.
• The W65C22N does not have bus holding devices on the input, IO pins.
• The W65C22N IRQB is an open drain output that CAN be Wire-ORd, unlike the totem-pole output of the W65C22S (some customers have had to use a diode in series with the IRQB output when using the W65C22S in their systems that had Wire-ORd interrupts).

The 22S's port outputs are much, much stronger than the data sheet lets on; and unlike the N version, the S version can run down to 1.8V. I would definitely recommend the S version for all new designs.

[Shawn Odekirk]

BigDumbDinosaur wrote:

Shawn Odekirk wrote:

I've been away from the forum for a while...I went back and rebuilt my breadboard version following the schematic. While rebuilding the breadboard version I think I figured out that the problem I was having with the SC28L92 was due to noise on the RESET line.

What is controlling the 28L92's reset line that would generate noise?

When I was first adding the 28L92 I experienced occasional corrupted characters in the serial output. Trying to determine if the 6502 was writing corrupted characters to the 28L92, I decided to use the General Purpose register (1100 - $C) in the 28L92 to test whether I could write and then read back what I had written consistently. I'm not sure why, but at higher clock speeds I could sometimes read back what I had written to the General Purpose register, but at 1 MHz I always read $0F. The datasheet indicates that the General Purpose register is initialized to $0F on hardware reset. Probing the RESET signal with my oscilloscope showed a lot of noise.

Originally my reset circuit looked like this. I've removed a lot of the signals that don't apply to this discussion.

Original Reset Circuit

You previously commented that using the 22V10 as a simple inverter for the RESET signal was wasteful of the GAL's limited resources, but at the time I had a few unused pins on the 22V10 and decided to use them rather than add an additional IC just to generate the active-high RESET signal.
Notice that the PHI2O pin is next to the RESB pin on the 6502. On a solderless breadboard the PHI2O output induces a lot of noise on neighboring breadboard rows. In an effort to completely isolate the RESET signal I created the following circuit.

Updated Reset Circuit

After switching to the new reset circuit I have not had any problems with the 28L92.
My theory about where the noise on the RESET line was coming from may be totally incorrect. It may not have been induced from the PHI2O output, it may not have been propagating through the 22V10, and it may not have been a problem at all on a wire-wrap board or PCB. However, the change has eliminated my problems with the 28L92.

Shawn

[Shawn Odekirk]

GARTHWILSON wrote:

I would definitely recommend the S version for all new designs.

Thanks for the info!
I will still consider using a diode rather than a logic gate to OR my interrupts together in a future revision.

Shawn

[Shawn Odekirk]

Chromatix wrote:

It strikes me that the signals from the 22V10 all go a long way across the board. It might be a better idea to move it nearer to the devices it connects to. Displacing the 7400 and the UART crystal would be a relatively minor and inconsequential sacrifice.

Yes, I agree. It should be no problem to swap the positions of the 22V10 and 7400.

Chromatix wrote:

the JEDEC memory pinout is a complete shambles

Are you referring to the 22V10 pin assignments? I have some flexibility in that area. I could re-assign the pins so that they line up better with the pins on the 6502.

Chromatix wrote:

Conversely, keeping the two memory devices side by side, as they are now, is a good idea since they essentially connect pin to pin. The signals from there to the CPU and other devices are the ones that get tangled up, because the JEDEC memory pinout is a complete shambles. Consider rotating the pair of them together, in 90° increments, to see which way routes the address and data lines least messily.

I was trying to keep the ICs all oriented the same way, but I suspect this is like the rule of thirds in photography, meant to be broken when appropriate. I see that floobydust and BigDumbDinosaur have both bent this rule where appropriate.

Shawn

[drogon]

Shawn Odekirk wrote:

Chromatix wrote:

the JEDEC memory pinout is a complete shambles

Are you referring to the 22V10 pin assignments? I have some flexibility in that area. I could re-assign the pins so that they line up better with the pins on the 6502.

Chromatix wrote:

Conversely, keeping the two memory devices side by side, as they are now, is a good idea since they essentially connect pin to pin. The signals from there to the CPU and other devices are the ones that get tangled up, because the JEDEC memory pinout is a complete shambles. Consider rotating the pair of them together, in 90° increments, to see which way routes the address and data lines least messily.

I was trying to keep the ICs all oriented the same way, but I suspect this is like the rule of thirds in photography, meant to be broken when appropriate. I see that floobydust and BigDumbDinosaur have both bent this rule where appropriate.

Shawn

Another option might be to stack them vertically... But you still need to work out the optimal positioning for one, then solder the other(s) on-top but bring out their /CE pins to separate headers on the PCB.

This is a very old technique, but I used it relatively recently for 2 x 32KB chips on my Ruby 6502 boards and 2 x 512KB chips on the 816 boards.

Also remember (if it's not already been mentioned here) that you don't need to connect D0 from the CPU to the D0 pin on the memory device. You can similarly 'scramble' the address lines too.

-Gordon

[Shawn Odekirk]

drogon wrote:

Another option might be to stack them vertically... But you still need to work out the optimal positioning for one, then solder the other(s) on-top but bring out their /CE pins to separate headers on the PCB.

This is a very old technique, but I used it relatively recently for 2 x 32KB chips on my Ruby 6502 boards and 2 x 512KB chips on the 816 boards.

Once, a very long time ago, I worked on an old Macintosh (128 or 512) that someone had stacked additional RAM chips to upgrade the memory. I almost broke it because the motherboard no longer slid out of the case the way it normally did, and I banged the stacked RAM against the case frame a few times before I realized I would have to pry the motherboard out.

drogon wrote:

Also remember (if it's not already been mentioned here) that you don't need to connect D0 from the CPU to the D0 pin on the memory device. You can similarly 'scramble' the address lines too.

I don't think it's been mentioned in this thread, but I am aware that it is possible. If I connected the address and data lines to the ROM in a "creative" way, I'd have to write a program to translate the ROM image before burning it. Not impossible, but probably more work than I'd like to do. You wouldn't have this problem with Ruby though.

Shawn

[Chromatix]

I mean the JEDEC-standard pinout of memory devices. It evolved from early EPROMs in the 16Kx8 range, with successively larger devices having the extra address lines added first to redundant pins halfway down one side, then as extra pins all on one end, completely out of sequence with the existing address and control lines. The intent was to retain socket compatibility between different sizes of device, important for EPROM programmers if little else. SRAMs inherited the pinout via NVRAMs, which could substitute for EPROMs but were essentially an SRAM with a built-in battery.

And yes, you can connect the address and data lines to your CPU in a different order if you like. But you also have to program the ROM according to that shuffling, otherwise the contents will appear nonsensical. It is logistically easier to use the correct pinout in most cases. An exception would be if you have a way to bootstrap the board and perform in-circuit programming, which is feasible with recent Flash EEPROMs, but you then have to translate the write protection release commands (which are based on address patterns) and still make sure enough low-order address lines are the right way around to match the device's page size.

I think it's quite common to rotate memory devices relative to the rest of the logic devices. It really can help with dealing with the pinout.

[GARTHWILSON]

or you could just make a hardware programming adapter for the EPROM. Use a DIP header that goes into the EPROM programmer's socket, and wire it as necessary to a ZIF socket to put the EPROM in. I have one I did in 1994. I'll come back and put of picture of it here if I find it again.

[floobydust]

Shawn Odekirk wrote:

floobydust wrote:

First, congrats on getting your system up and running, that always feels good... having success!

Thanks!

floobydust wrote:

- Look at the TI7705B as a reset chip. It will give you positive and negative reset lines.

I've studied your design and saw that you were using this chip. I should have considered switching to this chip before purchasing additional DS1813s. It's hard to justify paying more in shipping than for the parts themselves, so this will probably have to wait until the next revision.

floobydust wrote:

- You can use the DS1813 for a NMI trigger (panic button).

Has this feature proven useful? I think in most cases a hard reset would be sufficient for my needs.

floobydust wrote:

- WDC also make a W65C22 with an open collector IRQ output.

Again, I wish I had realized using the W65C22N would simplify my design before purchasing additional W65C22S chips. Ordering a couple W65C22N chips would certainly help offset the shipping costs, but then I'd be stuck with unused W65C22S chips. Again, something for the next revision.

floobydust wrote:

- I'm guessing you're using one of the serial lines for a console. In most cases, a Serial-to-USB adapter is used, as most current systems don't have serial ports anymore. If this is the case, you could swap out one of the DB-9 connectors with a FTDI adapter... mounts in the DB-9 format and can connect directly to the SC28L92 without any level changes.

I guess I really fell short when doing my homework. I thought that these provided a physical DB9 connector and that a USB-to-Serial adaptor would still be required, but looking at them more closely it looks like they provide a physical USB mini B connector. They're a little pricy, but considering they replace the level shifter and the physical DB9 connector, the cost is closer. One more thing to consider for the next revision.

I'm still running V1.4 of your monitor and have consulted your C02BIOS V2 source for help getting the NXP UART working. Your code has been a huge help. Thanks!

Shawn

Hi Shawn,

Yes, the FTDI device I linked (the one I use on my C02 Pocket SBC) is very nice to have... you just connect it directly to one channel of the UART (TxD, RxD, CTS, RTS) and you have a full console via USB... no guess work. Another similar interface I've used is the FTDI LC234X... these are a small board with a newer chip...and a micro-USB connector. There's a jumper for interface levels (3.3v and 5.0v) and they also have the +5V power available so you can power your SBC from the USB port.

NMI Panic switch. I think it's useful... I've used it quite a bit when debugging stuff. My C02BIOS V2 versions show the supporting code under the Panic routine. It only clears/resets the console port and it's page zero pointers, then jumps to the Monitor warm start vector. It also save the registers and the first four pages of memory to the next four pages... so you can see what was going on when things went south. It's a cheap addition: a DS-1813, momentary switch and a bypass cap for the DS-1813 power.... and a bit of code.

I opted for the TL7705B so I could have an open collector positive going reset which is on the expansion connector. It allows me to add other devices with a positive going reset if needed and you can drive it high without worrying about shorting the output from a gate output (74HC00).

Last... if you've been able to pattern your BIOS with the same JUMP table as my V2 BIOS, I would recommend switching to the later V2 Monitor version as well. It's better code... has it's own JUMP table and has some additional features/functions as well. Xmodem-CRC upload and download are supported and there's a fix on the S-Record download support... and likely some other fixes as well... one in the disassembler IIRC.

I stopped working on the V1.x code a couple years ago... and am working on V3 (BIOS and Monitor) which is supporting a Maxim DS1511Y Realtime Clock and a 50-pin Compact Flash Card for block storage. Keep posting updates!

[Shawn Odekirk]

Chromatix wrote:

because the JEDEC memory pinout is a complete shambles

I thought you were referring to something I had done poorly, like the 22V10 pin assignments. I've been bummed all weekend because I felt like a new parent showing off his newborn baby and someone says "that's an ugly baby."

Chromatix wrote:

I mean the JEDEC-standard pinout of memory devices.

After re-reading your message several more times and while composing my reply to you I started to understand that is what you were referring to.

Chromatix wrote:

I think it's quite common to rotate memory devices relative to the rest of the logic devices. It really can help with dealing with the pinout.

I will give it a try.

Thanks,
Shawn

[Chromatix]

GARTHWILSON wrote:

or you could just make a hardware programming adapter for the EPROM. Use a DIP header that goes into the EPROM programmer's socket, and wire it as necessary to a ZIF socket to put the EPROM in. I have one I did in 1994. I'll come back and put of picture of it here if I find it again.

That would work fine for an old-style EPROM with UV erase and requiring high Vpp to program. The newer EEPROMs can be rewritten with neither of those, so they have write protection algorithms to avoid accidents. Maybe read some recent datasheets to see how they work and would be affected by address pin swaps.

[BigDumbDinosaur]

GARTHWILSON wrote:

Note that there are more differences than that. From WDC's website...

Something else to consider is the S version of the WDC 65C22 is assembled with a 0.6µ TSMC die that has been qualified at 20 MHz during manufacturing.

[BigDumbDinosaur]

drogon wrote:

Also remember (if it's not already been mentioned here) that you don't need to connect D0 from the CPU to the D0 pin on the memory device. You can similarly 'scramble' the address lines too.

I elected to not do that in any of my POC units. I concluded after trying such a layout in CAD that it really wouldn't do much for me other than save on a few via. POC 1.2 connects the MPU's address and data buses pin-for-pin to RAM and ROM, and is stable at 20 MHz. Draw your own conclusions about the value of "scrambling" the address and data buses.