I've been tinkering with KiCad lately on "upgrading" my current build. I currently run the W65C02 at 2MHz and have the standard 32K RAM and 32K ROM, but also have an RTC with 2K NVRAM. My I/O space is mapped at 2K, which leaves me with 28K RAM. My glue logic is ATF22V10. I have a WDC ACIA which I've bypassed the bug by software. And also have a VIA that connects a 40x4 display, and an ATMEGA328P that acts as a PS2 interface that works perfectly. I even programmed it to accept CTRL-ALT-DEL to do a soft reset.

Since I can easily do it with PLDs, I want to reduce my IO space to 256 bytes, just because I can. I also want to add further functionality to the current MCU and adding i²C as well as a serial interface (Rx/Tx). On top of that, I'd add a second MCU to get SPI. Why microcontrollers? I want to offload the heavy lifting from the CPU by not having to bit-bang all these protocols. But I wonder if it's the best or most elegant solution? Plus, I have no idea if it's going to work properly I've glanced over Daryl's 65SPI CPLD, and my eyes glazed over when I tried to understand the CUPL listing. I'd love to implement this, and luckily, Atmel makes a 40 pin DIP version, perfect for breadboard. I guess a lot of reading is in order.

Anyway, I eventually want to build a PCB out of it. All that is missing is the TMS9918A (which works on my breadboard), and a pair of PSGs (that still illudes me) that will be daughter-boarded later. All my connectors lined up together will add up to exactly 63 pins, the same amount as on standard breadboards.

Anyway, here is my design so far. Maybe it's overdesigned? Also, a picture of my current build. Any thoughts?

_________________
Fred Segard
A.K.A. The Micro Hobbyist
https://6502sbc.blogspot.com/

That's amazing! That's like my dream build.

Your cables run far nicer than my work

_________________
No simulation survives contact with reality!

Looks great!

Just one suggestion - You could probably run both ATmegas of a single 16Mhz can oscillator rather than use 2 crystals and associated capacitors. (I was running both the 65C02 and ATmega off the same can osc. for a while on my early boards).

As for IO mapping - might it be easier to put it up at the top, say $FExx ? Just thinking of saving all that "precious" RAM down below...

Cheers,

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

Good idea, I didn't think that was possible. So far, I've never seen a dual configuration MCU, let alone sharing a single can. I guess you have to program one of the fuses to accept cans instead of oscillators. I'll have to investigate... or is it as simple as only using one of the pins? Of course, I'm being lazy and programming the MCU on a UNO, then removing the chip each time.


That's a great idea, I really didn't think of that one. I would have thought of using $8000 and .org at $8100. But with a PLD, it's easy enough to do.

_________________
Fred Segard
A.K.A. The Micro Hobbyist
https://6502sbc.blogspot.com/

Yes, as simple as using one pin. (osc1) but yes, I'd have to check, but I think the fuses are different. I almost always use an USB->SPI programmer, but weigh up the convenience of using the internal bootloader (via an Uno board) vs. sticking an ICSP socket (or 2!) on your board. Good use of the ATmegas though - I use one on my Ruby boards and am using 2nd on the expansion board...


That's a great idea, I really didn't think of that one. I would have thought of using $8000 and .org at $8100. But with a PLD, it's easy enough to do.[/quote]

Only suggesting $FExx as that's what I'm doing on my Ruby boards and the decode was easy in a GAL not sure if enough pins on a 22v10 to decode all the other chips you're after, but a 2nd GAL certainly makes life easy... (I also use a GAL to combine IRQs but it looks like you're doing just that in your 16v8 too)

I think my take comes from using the early 6502 systems like the Apple II and BBC Micro where just just had RAM all the way from 0 upwards and ease of using a can osc. than 3 separate components, even though the can might actually work out more expensive in the long run... But for small hobby use? I often find convenience wins over price (for smallish values of price!)

Cheers,

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

First, system looks really nice, congrats!

I also use page $FE for I/O on my systems... been doing that since the 80's. I also use an ATF22V10 PLD for glue logic. I would suggest that you extend your I/O range from 16-bytes to 32-bytes. This gives you more flexibility for additional I/O, not to mention that you can support a pair of 65C22 VIAs with one chip select (if 32-bytes wide). You can check out the WinCUPL files on my Github page for the C02 Pocket SBC. My PLD config has selects for RAM, ROM and 5-I/O selects (at 32 bytes wide) and provides phase 2 clock qualified Read and Write signals for RAM/ROM and non 65xx I/O devices (like the NXP UARTs).

Lastly, I would be inclined to lose the W65C51 (the xmit bug) and use a NXP UART instead. You can get use a PLCC version and socket that with a standard through-hole socket.

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

My own thoughts on that would be to lose the W65C51 and use the serial port on one of the ATmegas - since you're using that for some IO (I2C and SPI) anyway, but it's an increase in coding time just to save one chip - especially if you've already conquered the Tx bug issue.

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

True, using your implementation would save a chip, and I would think there's plenty of resources left in the ATmega to handle serial I/O. Depending on the intended use of the serial port, I still think it better to drop the W65C51 and use something else. I use the serial port as a console and also for Xmodem-CRC upload and download to the SBC. Using the older SCC2691 at 115.2K baud rate, data transfers are very quick, not to mention you get a 16-bit timer that can easily be configured as a jiffy clock that's not affected by the CPU clock rate.

One last thing (looking at his schematic again) would be to add an additional DS1813 with a momentary switch on the NMI line. This would provide a "Panic" or "Debug" trigger for helping isolate system crashes, etc.

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

If you're going to put one or two ATmega devices on there, you could lose the reset circuit and use the ATmega's POR and brownout detector to generate the system reset signal. You could also lose the 28C256 and use one of the ATmegas to load code into RAM. If you get an ATmega with 32K or 48K of flash there should be plenty of room for the 6502 ROM code in there, plus you can make it in-circuit reprogrammable. It should also be faster because you usually need wait states to access flash if the CPU is running at or near it's maximum clock frequency, whereas RAM doesn't need them.

That's beginning to sound a lot like my Ruby project!

I think it's good to see other peoples ideas though - saves us all from the monotony of the beige boxes!

Cheers,

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

Since you are already using PLD and interested in CPLD, another system approach is a tightly integrated design centers around a 64 to 128 macrocell CPLD (ATF1504 or ATF1508). CPLD can replace many of the 65xx peripherals so you can significantly reduce the part count to a core design of just 6502, RAM, and CPLD that has serial console, mass storage, bootROM, and serial/parallel peripheral interface. Another advantage is speed; many members already able to achieve 20MHz 6502 system with TTL logic; with CPLD that's easily done and if you fancy a walk on the wild side, you can shoot for 30Mhz+ 6502 system.
Bill

You could also potentially generate the CPU clock from one of the ATMega328 chips as a background task, provided one of the OCx pins is available. Example Arduino code;

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

Woohaa! Mind blown!

Of course, I wouldn't know where to start. But I'll try. I have just acquired two ATF2500C-20PU CPLDs. It was the only DIP package version available (breadboard friendly).

_________________
Fred Segard
A.K.A. The Micro Hobbyist
https://6502sbc.blogspot.com/