Hi guys

This is my (hopefully) completed 6502GPD v2.5 design. I'm designing the PCB layout at the moment, but want to get some expert opinions before I get it fab'd (if you guys are happy to do this?).
I'm not going to wire-wrap it as it'd probably cost me less to just get to made (mostly due to the cost of wire wrap sockets).

Over all description
It's a general purpose 65c02 board with as much I/O as possible exposed for experimentation and with expanded memory mapping.
Here are the features:
- 65c02s CPU running at 8MHz (dependant on the max speed of the design, especially the memory banking)
- 16 banks of RAM, each bank is 64KB. Not all is used - see banking below
- 24KB ROM - see banking below
- I/O: 2 channel Serial, TTL level, additional general I/O pins available
- I/O: System VIA
- I/O: User VIA
- I/O: 4 bit banking latch

Memor map
The system allows for 16 banks of memory to be selected. Each bank is 64KB in size.
Certain memory ranges may not be "banked" and will always map to a specific memory bank or device.
The following is adjustable in the ATF1504 CPLD
$0000-$0FFF : Zero page, stack, some non-bank OS/user space. This will always map to bank 0 no matter the selected bank
$1000-$8FFF : Main RAM, fully bank switchable.
$9000-$90FF : (no device selected)
$9100-$91FF : I/O / Serial/ACIA, always mapped irresepctive of bank selected
$9200-$92FF : I/O / User VIA, always mapped irresepctive of bank selected
$9300-$93FF : I/O / System VIA, always mapped irresepctive of bank selected
$9400-$9EFF : (no device selected - I may map this to RAM in future)
$9F00-$9FFF : Bank latch
$A000-$DFFF : If in bank 0 then OS ROM selected , otherwise the same as $1000-$8FFF
$E000-$FFFF : OS ROM

Total of accessble RAM:
Bank 0 : 36KB >> ($0000-$8FFF)
Banks 1-15 : 48KB each (48KB x 15 = 720KB) >> ($1000-$8FFF, $A000-$DFFF)
Total : 36KB + 720KB = 756KB

I/O
ACIA/Serial: This was originally going to be a WDC 65C51 but due to a bug in that chip I've gone for a SC28L92. This IC allows 2 serial channels and some general I/O ports.
The serial channels map to 2 headers which provide for TXD, RXD, CTS, RTS and GND, don't use a line driving IC but utilise TTL levels. A TTL to RS232 module map be used with this.
6 outputs pins and 5 input puts are available for user use (OP2-7, IP2-6) and are routed to pin headers.
User VIA: This VIA is dedicated completely to user programs. The pin headers for ports both A & B include their own +5V and GND pins.
System VIA: This is for the OS to use. It gives access to a pin header for 44780 LCD (in 4 bit mode), 4 banks of 128KLB I2C EEPROM and a real time clock (RTC).
Bank latch: Selects the memory bank (0-15). Read/writable. The bank number is the lower 4 bits, the top 4 bits are discarded/set to 0.

User input/output
The user display/keyboard is going to be from an attached PC via serial channel A. An LCD port may be attached to the appropriate System VIA pins. Additionally, a PS2 keyboard could be mapped to the System VIA (Port B pins 2-7 and CB1 are free and route to a pin header).

Diag/expansion
The following signals are routed to pin headers for diag/expansion purposes:
Address bus (16 bits)
Data bus (8 bits)
65C02 signals: IRQB, NMIB, RESB, RWB
IRQ open drain
PHI2 clock
/RD and /RW from the CPLD (used with non-65xx devices)
4 GND pin headers are dotted around the board for use with 'scope probe ground
Reset button and NMI buttons provided.

Device addressing
The ATF1504AS does all device addressing (ACIA, VIAs, RAM, ROM, bank latch)

IRQ arbistration
The ATF1504AS does all IRQ arbitration (ACIA (open drain) and VIAs)

RAM
The RAM consists of two bricklaid SRAM ICs with all pins except the /CE enabled pins soldered together.
The bottom most IC /CE pin is soldered directly to the PCB, where-as the top-most IC /CE pin is connected to a nearby single pin header. This has been done to conserve PCB real estate.
Each IC is 512KB - each seen as 8 banks of 64KB - for a total of 1MB. The bottom-most IC covers banks 0-7 and the top one covers banks 8-15.
The top-most IC can be omitted (and the associated /CE pin header), reducing the memory to 8 banks of 64KB.

Clock
The main PHI2 clock is generated via a crystal oscillator can routed through a D type flip flop. This gives a square-wave signal with a 50/50 duty cycle.

Power
The board has one main power input which expects 5V (reverse polarity protected)
2x Aux +5V power out headers are provided. These don't have any protection (for now).
3x 33uF tantalum capacitors are dotted around the board for power smoothing
Each IC has a 100nF ceramic capacitor across the power pins for smoothing

Circuit Diagram:


Please let me know what you think .

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Nice machine - I see you have set aside space for an OS. Do you already have ideas for the OS? (I'm perhaps thinking especially of memory management, as you have lots of memory and a banking system, but the memory is in 32k and 16k chunks.)

(I admit, this isn't a question about the hardware design!)

A good suggestion. I'll make the change and (for now) route the freed pin to a pin header. Cheers!

I was thinking of implementing a version of BASIC, although I'm not sure which so happy to take on recommendations. Perhaps a modified version of 6502 Basic. An alternative is to write my own, but that will require a lot more time.
Ideally, I would have liked to get all of the RAM together in a single block as I think many languages don't deal with multiple blocks well (which is what I think you might be referring to), but it means I lose ROM space to I/O. I might still do that. Perhaps:
$0000-$1FFF : 8KB, Non-banked RAM, always maps to bank 0
$2000-$C9FF : 42.75KB, Banked RAM (banks 0-15)
$CA00-$CAFF : Not used
$CB00-$CBFF : System VIA, always mapped irrespective of bank
$CC00-$CCFF : User VIA, always mapped irrespective of bank
$CD00-$CDFF : System VIA, always mapped irrespective of bank
$CE00-$CEFF : Latch, always mapped irrespective of bank
$CF00-$CFFF : Offboard device / not used
$D000-$FFFF : 12KB, ROM

RAM size:
Bank 0 : 50.75KB
Banks 1-15 : 42.75KB each = 642.25KB
Total: 692.25KB

The added bonus to the above map is that it might speed of the glue logic a bit in the CPLD as I won't need to deal with the RAM/ROM overlay.

Beyond what others have already noted:

1- I/O decoding... seems an awful of space wasted for I/O selects. I use a PLD for this and break out page $FE into 32-byte wide I/O selects.

2- RAM setup... why not use a single 1MBx8 SRAM instead? Personally, I don't like piggybacking them, unless it's a modification for testing. But again, that's up to you.

3- ROM usage... as you're using a CPLD, you should be able to bank that if needed as well, and by relocating the I/O upwards, you could easily make a 56KB RAM and 8KB ROM mapping with less than 256 bytes used for I/O.

4- Pull-up/down resistors... I've noticed quite a few of these on signals like /RD and /WR and some other signals. Have you found this necessary?

5- ROM signals... why not use the /RD signal to drive /OE and keep the /CS select separate? If you use an EEPROM, you could also wire the /WR to the EEPROM (via a jumper) and provide insitu programming.

6- Reset signals... I'm using a TL7705B which provides open collector outputs for both negative and positive going reset signals... just a thought.

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

Hi flooby

Thanks for responding. I've listed my responses as numbered ones just to keep things easier:

1. Indeed. I did it that way as I was trying to keep the decoding in one CPLD (I mostly succeeded - only an extra NAND chip is used on top). This was partly to keep the number of ICs down and also I was told a long while ago about possible timing issues if I used multiple GALs & CPLDs. I could possibly use an 22v10 GAL to decode the IO into a single page?
2. I looked at 8Mbit (1MB x8) RAM. Most of the ones I checked at the time were slower running at 45ns or slower, where-as the CYC1049GN runs at 10ns. I planned to use a circuit to slow down the CPU when the 45ns ROM is accessed, but go faster when accessing RAM. Due to space constraints I dumped that later on in the design process.
3. I was trying to keep some of the ROM always available to cut down in the need for bank switching. I could make it bankable I supposed, but prefer to keep access always available. I did the same with the I/O for the same reason.
4. It was recommended that I add pull-up resistors on the CPLD outputs as the ATF1504AS has TTL level outputs (just about 4v for a 'high'). I was going to leave these off the board if it turned out that they were not needed.
5. No reason not to. However, the CPLD only allows the ROM to be selected in conjunction with RWB being high so there's no problem having it that way and means I don't need to route another line to the ROM.
With regards programming: I'm going to be using a Winbond W27C512-45Z which uses +14V for erasing and +12V for programming. I only have 5v available on the board so not really an option.
6. I did have a look at the TL7705B previously and am still thinking on it - thanks for the suggestion.

One thing issue I've noticed is that most SRAMs which have TTL compliant inputs (needed for the ATF1504AS CPLD) also output using TTL levels and I don't think the w65c02s databus is TTL compliant? I had a very quick look through the datasheet this evening but couldn't find anything which mentioned TTL, but some googling seemed to indicated WDC had dropped the TTL level compatibility. I could be wrong and will check again.
As such, I might need to add a pull-up bus resistor on the databus...

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Fantastic! Thanks for confirming that BDD . It means I can get away with using an 8mbit SRAM (if I want to put up with 55ns - which isn't a major issue now). Out of interest: Do you know if there are issues with the w65c02s being better, the same, or worse at driving the databus? I watched a video recently in which someone was using using a w65c02s in place of an NMOS part and had an adapter board with a '245 bus transceiver on the databus. The designer apparently had concerns that there might be issues with load driving or (as I did) with TTL levels.

Speaking of the PET 8032 - I have one sitting here in bits being cleaned. Only down side it has very corroded edge connectors so might have to see if I can get around that by retinning them, using copper tape or feeding of custom connector an adapter which then has edge connectors.

Finally, Merry Christmas to all .

CY62158E (datasheet) MoBL looks interesting. 45ns, TTL compatible I/O, although it says that it's not compatible with CPUs which expect CMOS input levels - which should be fine given the discussion above.
The only downside I can see is that it'=s a fairly large IC: 44-pin TSOP Z44-II.

Can you be more specific, please, BDD? Did they tell you WDC 'C02 inputs are just as TTL compatible as Rockwell 'C02 inputs?

Seems to me you're intent on giving us a yes-no answer to the TTL compatibility question, but things aren't quite so clear cut. For example, I think it's terrific you got your WDC-based POC projects to work. But the fact they work doesn't prove WDC chips satisfy the generally accepted meaning of "TTL compatible." Rockwell's C02's do. They adhere to a spec that guarantees optimal reliability for transactions with RAM's etc that that don't produce a good, solid (ie, 5 volt-ish) logic high. Using those same Ram's with a WDC chip means noise immunity will be significantly compromised. That doesn't mean the design will fail, but it does shrink the realm of circumstances in which one can expect it to operate reliably.

In other words, you are operating in a second tier of TTL "compatibility," one that's less robust; ie, more reliant on circumstances. A lot of the time it may be adequate... and I've been know to bend the rules myself occasionally ... but it's a lesser degree of compatibility than that offered by Rockwell. Please let's not equate the two.

-- Jeff

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

I've got the PCB routed finally. I think I've developed an aversion to routing PLCC ICs . Just doing some tidying up, etc. now.

He's a picy of a graphical representaion of the PCB. I'm using EagleCAD (not the Autodesk one) with a PCB limit of 160mm x 100mm so have had to crush everything in a bit:
Top:


Bottom:


One thing which I'd like to implement is video and keyboard. To this end I've routed the following signals (via pin headers) to the right side of the PCB (opposite side of I/O) for potential daughter board(s). Each such daughter board will have pass through headers so more than one can be used:

A0-A19 (65c02 A0-15, A16-19 derived from CPLD used by RAM banking)
D0-D7 (65c02)
NMIB (65c02)
RESB (65c02)
BE (65c02)
RDY (65c02)
PHI2
/PHI2 (inverted version of PHI2)
RWB (65c02)
/RD (active low read, only enabled when PHI2 is high)
/WR (active low write, only enabled when PHI2 is high)
SPARE (spare i/o pin on the decoding/irq CPLD)
IRQ _OD (open drain input to the decoding/irq CPLD)
+5V
GND

PCB looks good... agreed on routing around PLCC devices. I probably should have mentioned this before, however....

The 5-pin connectors used for your TTL Serial outputs. You might want to use a 6-pin header with a pin-out that matches one of the FTDI USB-to-Serial interfaces. I've used several of these over the years... one that could be useful for your SBC is the LC-234X (datasheet attached). You don't need to use the power pin, but possibly a jumper in case you decide to run the board from USB power.



Also, have you found some good pass-thru headers/connectors for stacking the I/O board(s)?

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

A good idea. I could probably make a custom cable, but there's no reason not to make things easier at the design stage .

Here's the redesign. JP26 represents my original pin header and JP25 represents my new one. The pinout from the datasheet you linked can be found beneath:



Header-wise: I have seen a few solutions, but if it really comes down to it I'll use pin header sockets on the underside of the daughterboards and offset pin headers on the top side.

And here's the above on the PCB :