my goal is to make a SCSI system like they did back then with 128K ROM. but i am going to code an Atmega128 to emulate the 5380 SCSI controller and the SCSI drive interface, so i could use a USB flash drive, or SD memory, or for simpler reasons, ATA CF card. or basically like a SCSI --> USB mass storage
Heck i could even do an ATmega256 and put the ROM in the flash with everything else to minimize chip count down to a mere 1. so everything is all on 1 chip. problem with that though is the number of pins to address full ROM to the 68K CPU.

Click to expand...

That is a very cool idea.

Regarding the pin problem, if you are willing to add one more chip you can mostly eliminate your pin problem, I think. It might require a few more components...

Generally, these interfaces have an address bus and a data bus. If you're going parallel to parallel, as you are when going CPU to SCSI, the data doesn't really change. So, if you're a little creative, you can just tie the address and control lines to your microcontroller and use it to control where the data lines go by changing the state of multiplexers and/or bus switches. You may need to latch the data however, which is another component, unless you can find it combined with the multiplexer or bus switch, which you might, because TI makes a logic chip for just about every function a person could imagine....

So the address/control lines and the microcontroller do all the "thinking" about where the data should go, but the data doesn't pass through the microcontroller, it is routed to the appropriate destination by the microcontroller.

Now, if your plan is to use a microcontroller with a built-in USB bus, for example, this idea does not work so well, since the data probably needs to go into the microcontroller in order to come out of the microcontroller's USB pins. But for many interface translations, this microcontroller as traffic cop idea is applicable.

So in the above (ROM, not mass storage) case, the one chip you would add would be a Flash or EEPROM. Something with 4 Mb or even 8 Mb is cheap these days. Then you just use the microcontroller to translate the address the Mac is supplying to whatever address you want to actually access on the EEPROM.

And that also brings up another thing. i could make a small little lightweight app you could run that would set the hardware to boot from the 64k rom or 128k rom.
because if i use an ATmega256, i could fit both ROMs in just the flash area. and use a control byte written into its eeprom to decide which one to boot from. simple enough, i would just have to give that control byte its own address space on the macintosh buss. just write a $01 or a $02 into that address space will determine which ROM to boot from.

Click to expand...

Why not use an address in PRAM? I bet there's an unused one you could hijack. Then you'd just need a way for the ATmega256 to read the PRAM contents at boot up without interference from the 68000. I think there's a pin that will hold the 68000 inactive while the ATmega256 sneaks around behind its back.

Of course, if you follow this road to its conclusion, you'll figure out how to emulate the whole Mac in hardware, and simply build a replacement for all the slow hardware sitting in a microcontroller. But one thing at a time.

You might also want to take a look at the MCF522xx cold fire chips. The demo and development boards cost a bit ($99 & $300 respectively) but individually, the raw chips are cheap and the controllers are very capable.