My very first 6502 SBC, more simulation than machine, is back from the board house, built up and works.

It's a 3-chip system with a real 6502 and two AVRs simulating the address space. The DIP40 AVR ran out of pins necessitating the twin-AVR solution. The system features:

• An Admin UART to control ( single step, trace bus state, upload ROM, reset) the system from a laptop. There is some funky potential such as simulating ( really slowly) bus devices over the Admin UART, or running tests on the 6502 by controlling the system like a puppet
• Simulated bus devices:
  
  • Up to 15K of RAM. The ATmega128 has 16K but needs some for itself. I currently have this as 8K of RAM at $0000 and 4K of "ROM" at $f000
  • Up to 128K ( minus the size of the master AVR firmware) of ROM ( simulated from program memory - not implemented yet because I haven't finalised my ROM)
  • 4K of EEPROM ( not implemented yet)
  • SPI ( The register file is 65SPI compatible except for the slave select register)
  • UART ( simulated on the ATtiny2313 complete with a 16-byte RX queue)
  • Timers ( not implemented yet. Timers on the master would need an SPI exchange to interrupt since the slave drives IRQB. Timers on the slave will have unusual periods because of the UART-friendly 18M432 system clock)
  • Blitter ( not implemented yet - the master AVR could copy around chunks of RAM must faster than the 6502)
  • The ATmega128 has a hardware multiply that could be made available as a bus device

Because all 16 bits of the address bus and 8 bits of the data bus are decoded by the master AVR, few pins remain. PHI2, RWB, MOSI, MISO, SCK, RX and TX for the Admin UART and the /SS for the slave AVR account for the rest. The slave AVR is in control of RESB, IRQB, the SS* lines on the SPI bus and the 6502-driven UART.

Here's the bus trace after powering up:


The simulated ROM contains:

..and the RESB vector is $f000 just to prevent the 6502 running amok before a ROM is uploaded via the Admin UART and these things can be seen in the trace above. Also above, the WDC65C02S does seem to access the stack just prior to the RESB vector but doesn't write at any point.

When I'm developing the ROM, the workflow is:

• Press F9 in my editor, which runs "make", which assembles the ROM to /tmp/ROM.prg
• A daemon that I call "dude" after avrdude notices that /tmp/ROM.prg has been changed and uploads the ROM via the Admin UART. The .prg format allows me to place the ROM where I like
• "dude" then resets the system via the Admin UART, the ROM runs and happy boot messages come from the 6502 via the slave UART
• I can then interact with the 6502 via the slave UART like it's a real system!

This is what the system looks like so far:



The system is very slow ( I guess about 250 kHz) although it's fast enough to feel nice and responsive using the monitor over the serial port.

I feel like a bit of a heretic next to you lot with your crystal oscillators and address decode logic but this system is more capable than I expected and I'm having a lot of fun writing a machine-code monitor for it. I'll also be able to develop SPI peripherals and write 6502 drivers for them that will work on "real" machines later on.

I like it!

Very nice, Neil.

Dave Cheney experienced similar performance issues when sharing Arduino memory and I/O with a 65C02 which he described in his Make your own Apple 1 replica blog article. Dave was using a 16-MHz AVR (Tcy = 62.5-nS) so you have an advantage with your 20-MHz AVR (Tcy = 50.0-nS). Basically, if you're trying to achieve a 1-MHz 65C02 clock rate, you have 20 AVR instruction cycles to work with for each 65C02 clock cycle while Dave only has 16 instruction cycles to work with. I'm not familiar with AVR, but, using every trick I know of, I have been able to share memory and I/O in 16 cycles (Tcy = 62.5-nS) on a PIC.

Cheerful regards, Mike

Nice accomplishment Neil!

As long as you are learning something and having fun, the clock speed does NOT matter.

Keep us informed on your progress!

Daryl

_________________
Please visit my website -> https://sbc.rictor.org/

On a first project, speed is always secondary to functionality. The important thing is that it works and none of that nasty smoke leaked out. Good job!

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