Emulating ROM with a one-chip ARM

[BigEd]

Chromatix wrote:

The main impediment to building the bootstrap module is actually a shortage of binary-to-hex 7-segment drivers - BCD decoders are still available, but the hex ones have inexplicably been discontinued. I may need to settle for 16-way demultiplexers and a less friendly display, so as to avoid relying on a GAL for that purpose.

(See the new thread over here for more on this.)

[gbm]

An STM32 microcontroler can emulate the full logic of a ROM by itself at at least 600 kHz, without external buffers or logic gates. The main problem which must be solved is tristating the data bus on strobe deactivation. This may be handled with timer inputs and DMA. In case of F4 and F7 series only DMA2 (not DMA1) module may be used, which creates some troubles. That's why I don't use F4 nor F7/H7 in my SDC design.
On L4 series, tristating the bus takes about 100 ns. Should be significantly faster on L4+ and L5. It is also faster on F4, provided you have a proper timer triggering DMA2 requests.

[Druzyek]

Quote:

I did this as well using an Atmega324 to directly become ROM in a VIC-20.

This is a cool idea! Did you ever consider using the Atmega to write to an SRAM at startup and then using that as pseudo ROM?

[drogon]

Druzyek wrote:

Quote:

I did this as well using an Atmega324 to directly become ROM in a VIC-20.

This is a cool idea! Did you ever consider using the Atmega to write to an SRAM at startup and then using that as pseudo ROM?

I can't answer for the above poster, but this is what I've done in my little experimental 6502 (Ruby 6502 as it's now called). My system is completely ROMless - the ATmega pokes the bootloader into the top 256 bytes of RAM then takes the 6502 out of reset and off it goes. You just need enough pins spare on a microcontroller. As well as the reset line the ATmega is also controlling the Rdy and BE pins too. I did consider doing the full address-bus, but that would need another 8 pins on the ATmega but I wanted them for other stuff. (It's an ATmega 1284p - 40 pin DIP)

-Gordon

[Dr Jefyll]

drogon wrote:

You just need enough pins spare on a microcontroller.

Yup. If you have lots of pins available then you can take over both the 65xx address and data buses, plus a few control signals. It's a very simple scheme to get working but you need to have plenty of microcontroller pins available. In some circumstances it's not easy to provide that many pins, so FWIW I'll quickly mention two alternative solutions that trade off the extreme simplicity for something that's more physically compact and involves less wiring.

This scheme takes over only the 65xx data bus, plus a few control signals -- ie; not the address bus. Lots of people have come up with this idea, and in many cases it'll be the best tradeoff. The 65xx CPU participates in the bootup by running a simple program which appears to reside in memory but is actually generated by the microcontroller.

This scheme only takes over three control signals. Again, the 65xx CPU runs code which appears to reside in memory but is actually generated by the microcontroller. Even a tiny 8-pin device is more than sufficient (and as a bonus it manages Reset, too).

-- Jeff

[drogon]

Dr Jefyll wrote:

drogon wrote:

You just need enough pins spare on a microcontroller.

Yup. If you have lots of pins available then you can take over both the 65xx address and data buses, plus a few control signals. It's a very simple scheme to get working but you need to have plenty of microcontroller pins available. In some circumstances it's not easy to provide that many pins, so FWIW I'll quickly mention two alternative solutions that trade off the extreme simplicity for something that's more physically compact and involves less wiring.

This scheme takes over only the 65xx data bus, plus a few control signals -- ie; not the address bus. Lots of people have come up with this idea, and in many cases it'll be the best tradeoff. The 65xx CPU participates in the bootup by running a simple program which appears to reside in memory but is actually generated by the microcontroller.

This scheme only takes over three control signals. Again, the 65xx CPU runs code which appears to reside in memory but is actually generated by the microcontroller. Even a tiny 8-pin device is more than sufficient (and as a bonus it manages Reset, too).

-- Jeff

Those are pretty nifty ideas to reduce the number of wires into the 6502. For my system, I did think about clocking the 6502 from the Atmega - initially one pulse at a time and just using the data bus - matched to the clock pulses to send the boot vector then the minimal boot code LDA/STA as in your first link above, however I also wanted a way for the 6502 to communicate back to the Atmega, so opted for a 256-byte shared RAM approach - the ATmega in my system is the UART and Video and keyboard controller (and soon the SD card controller too)

It's working very well for me in a minimal configuration so-far and I'll carry it over when I build the 65c816 system.

-Gordon

[Oneironaut]

Almost forgot about this small project I did...

viewtopic.php?f=4&t=4351&start=60

One ATmega1284 feeds the 6502 as SRAM and also does color VGA.

I later improved it vastly using an XMega384 overclocked to 64MHz, but never bothered to document it!
The result was almost a C64, but using only 2 chips... 65C02 and XMega384.

Brad