-
Updated 2023-07-12: Hello, Guest! Welcome back, and be sure to check out this follow-up post about our outage a week or so ago.
Another IIci ROM hack
- Thread starter dougg3
- Start date
Dennis Nedry
Well-known member
8 MB is the limit of the ROM slot, after that you have to start adding clips for more address lines, if it can work that way. Each clip would double the max ROM if the memory controller allows this.
Max ROM SIMM = 8 MB * 2 ^ (# of clips)
We also talked about using some sort of large flash drive/CF/SD card, but this presents a problem because they are serial and the Mac expects parallel ROM. It would be difficult to convert serial to parallel fast enough for that to work.
Max ROM SIMM = 8 MB * 2 ^ (# of clips)
We also talked about using some sort of large flash drive/CF/SD card, but this presents a problem because they are serial and the Mac expects parallel ROM. It would be difficult to convert serial to parallel fast enough for that to work.
I've thought about it, but there are a couple of problems:
The ROM SIMM slot pinout only provides for 8 MB of space, so you'd have to do extra hardware hacks to get more address lines. Might be better to do a PDS type card instead because of that.
You have to get the data off the CF card and onto the data bus fast enough. It's going to require some kind of controller/FPGA/whatever in between to read from the CF card and stick it on the bus fast enough, or use RAM or . I think on the past couple of pages people were discussing ways to make it happen -- but that 8 MB limit is still a problem.
I was thinking if a ROM disk was the main reason we wanted to use the extra space, a ROM disk driver could change between different 7.5-MB pages by writing to a register (which would be handled by the FPGA) to pick the selected page. This is how 16-bit microcontrollers handle addressing more than 64 KB of space, for example. So you'd still only need the 8 MB of address lines in that case. It would be pretty complicated to get working though. I believe this is also how Nintendo games were able to address larger amounts of program space as well.
Edit: What Dennis Nedry said.
Edit2: I forgot the "write" line doesn't come out to the SIMM. It would have to be something like what bbraun described. Maybe a read from a specific address followed by another read to select a bank or command or something?
The ROM SIMM slot pinout only provides for 8 MB of space, so you'd have to do extra hardware hacks to get more address lines. Might be better to do a PDS type card instead because of that.
You have to get the data off the CF card and onto the data bus fast enough. It's going to require some kind of controller/FPGA/whatever in between to read from the CF card and stick it on the bus fast enough, or use RAM or . I think on the past couple of pages people were discussing ways to make it happen -- but that 8 MB limit is still a problem.
I was thinking if a ROM disk was the main reason we wanted to use the extra space, a ROM disk driver could change between different 7.5-MB pages by writing to a register (which would be handled by the FPGA) to pick the selected page. This is how 16-bit microcontrollers handle addressing more than 64 KB of space, for example. So you'd still only need the 8 MB of address lines in that case. It would be pretty complicated to get working though. I believe this is also how Nintendo games were able to address larger amounts of program space as well.
Edit: What Dennis Nedry said.
Edit2: I forgot the "write" line doesn't come out to the SIMM. It would have to be something like what bbraun described. Maybe a read from a specific address followed by another read to select a bank or command or something?
Last edited by a moderator:
One could still use the ROM slot for more storage though. Put some registers somewhere in the 8MB addressable space, and a device driver (we're already using one as it stands) could access an arbitrarily large backing store through polled access of those registers. It'd work more efficiently through an interface that had an interrupt line, but still seems doable just through the ROM slot. And of course it doesn't necessarily even need to be accessing storage, it could be accessing a USB device, or network, or even another processor.
As far as what can be put in the ROM, in theory anything can. It's only software, right?
When I typically use the term 'device driver' on Mac OS, I'm referring to resources of type 'DRVR'. Those conform to a specific interface and can be manipulated by system API. The only thing that's required for those to work in the ROM is they be added to the resource section of the ROM, and some code somewhere needs to call _Open with the device driver's name (in theory). My ROM Disk driver does this by replacing the unused .netBOOT driver in the resource section of the ROM, and the ROM already has code to call _Open on that driver, so all of that happens for "free".
There's only so many unused entries in the ROM resource section to be repurposed. Eventually, it may be necessary to move the entire resource section past the end of the regular ROM so it has room to grow. The resources within the ROM should be self referential (as in, not have relative offsets to other parts of the ROM outside themselves), so moving the entire thing is probably going to be safer than trying to grow it in place and move code that comes after it, which is definitely being referenced through relative offsets from elsewhere in the ROM.
But, resources of type 'DRVR' are only a specific set. Extensions are things that have resources of type 'INIT', which is a code resource that gets run at specific times during OS boot. That all gets a little more tricky, especially since the 'INIT' code typically loads other resources within the extension file, like icons to display at boot time, or just to load and run 'DRVR' drivers. Those might be evaluated on a case by case basis, I think.
Anyway, the gist of the whole thing is: maybe?
Specific instances can be investigated on a case by case basis, I think.
When I typically use the term 'device driver' on Mac OS, I'm referring to resources of type 'DRVR'. Those conform to a specific interface and can be manipulated by system API. The only thing that's required for those to work in the ROM is they be added to the resource section of the ROM, and some code somewhere needs to call _Open with the device driver's name (in theory). My ROM Disk driver does this by replacing the unused .netBOOT driver in the resource section of the ROM, and the ROM already has code to call _Open on that driver, so all of that happens for "free".
There's only so many unused entries in the ROM resource section to be repurposed. Eventually, it may be necessary to move the entire resource section past the end of the regular ROM so it has room to grow. The resources within the ROM should be self referential (as in, not have relative offsets to other parts of the ROM outside themselves), so moving the entire thing is probably going to be safer than trying to grow it in place and move code that comes after it, which is definitely being referenced through relative offsets from elsewhere in the ROM.
But, resources of type 'DRVR' are only a specific set. Extensions are things that have resources of type 'INIT', which is a code resource that gets run at specific times during OS boot. That all gets a little more tricky, especially since the 'INIT' code typically loads other resources within the extension file, like icons to display at boot time, or just to load and run 'DRVR' drivers. Those might be evaluated on a case by case basis, I think.
Anyway, the gist of the whole thing is: maybe?
Specific instances can be investigated on a case by case basis, I think.
Just brainstorming here after pondering Dennis Nedry and bbraun's replies...
How about leaving the first 4 MB of ROM SIMM space as regular ROM? It is still connected directly to a flash chip, so no problems booting at all -- it's already all parallelized and ready to go right off the bat. Connect the SIMM /OE pin and the appropriate SIMM address pin to an AND gate's input, and connect the AND gate's output to the ROM chips' /OE pins -- I think that would be sufficient to disable the ROM chips' outputs in the second half of the ROM SIMM space. Maybe not an AND gate, but whatever gate is appropriate (too lazy to think about it right now).
Then, drivers patched into that ROM space read from various locations in the second 4 MB of ROM SIMM space to do things. To "write" to it, you could read from a certain address inside that space, followed by four consecutive reads from a 256-byte space to specify the address, and another four consecutive reads to specify the data. Example:
I want to write $12345678 to $ABCDEF00 (which might be a register I've created in the FPGA for something--a memory page selection register or an SD card controller register or whatever). The "begin write" register is at $40C00000, and the "write address/data" registers are from $40C00100 to $40C001FF.
So I start by reading from $40C00000. The FPGA notices this and starts listening for reads from the "write address/data registers" registers. Next, I read from $40C001AB, $40C001CD, $40C001EF, and $40C00100, in that order. Now the FPGA knows I want to write to the address $ABCDEF00, and waits for 4 more read cycles to figure out the data to write. So I read from $40C00112, $40C00134, $40C00156, and $40C00178. Now the FPGA knows both the address and the data I wanted to write, so it does the write. Finally, there could be some kind of a status register to poll to determine completion of the write (if necessary).
Obviously, this is slow because it takes 9 read cycles to do a single "write cycle". Is that a big problem? For faster performance, I could reserve a 64K space rather than a 256-byte space and do two bytes at a time. That would only require 5 read cycles. I could probably cut it down to 4 read cycles by combining the first $40C00000 read cycle with the first "write address" read cycle, perhaps in a new 64K space so I still have sync information to know when a read begins.
Using this technique, I'm pretty sure we could do *anything* we want with the ROM SIMM slot, no extra hardware mods required. Map a huge CF card, SD card, or any other peripheral like bbraun pointed out.
Of course, routing the board would be tricky, but it could probably be done...may need 4 layers to fit the FPGA/sockets/etc. on the board though.
Wow...I think my mind is about to explode now.
How about leaving the first 4 MB of ROM SIMM space as regular ROM? It is still connected directly to a flash chip, so no problems booting at all -- it's already all parallelized and ready to go right off the bat. Connect the SIMM /OE pin and the appropriate SIMM address pin to an AND gate's input, and connect the AND gate's output to the ROM chips' /OE pins -- I think that would be sufficient to disable the ROM chips' outputs in the second half of the ROM SIMM space. Maybe not an AND gate, but whatever gate is appropriate (too lazy to think about it right now).
Then, drivers patched into that ROM space read from various locations in the second 4 MB of ROM SIMM space to do things. To "write" to it, you could read from a certain address inside that space, followed by four consecutive reads from a 256-byte space to specify the address, and another four consecutive reads to specify the data. Example:
I want to write $12345678 to $ABCDEF00 (which might be a register I've created in the FPGA for something--a memory page selection register or an SD card controller register or whatever). The "begin write" register is at $40C00000, and the "write address/data" registers are from $40C00100 to $40C001FF.
So I start by reading from $40C00000. The FPGA notices this and starts listening for reads from the "write address/data registers" registers. Next, I read from $40C001AB, $40C001CD, $40C001EF, and $40C00100, in that order. Now the FPGA knows I want to write to the address $ABCDEF00, and waits for 4 more read cycles to figure out the data to write. So I read from $40C00112, $40C00134, $40C00156, and $40C00178. Now the FPGA knows both the address and the data I wanted to write, so it does the write. Finally, there could be some kind of a status register to poll to determine completion of the write (if necessary).
Obviously, this is slow because it takes 9 read cycles to do a single "write cycle". Is that a big problem? For faster performance, I could reserve a 64K space rather than a 256-byte space and do two bytes at a time. That would only require 5 read cycles. I could probably cut it down to 4 read cycles by combining the first $40C00000 read cycle with the first "write address" read cycle, perhaps in a new 64K space so I still have sync information to know when a read begins.
Using this technique, I'm pretty sure we could do *anything* we want with the ROM SIMM slot, no extra hardware mods required. Map a huge CF card, SD card, or any other peripheral like bbraun pointed out.
Of course, routing the board would be tricky, but it could probably be done...may need 4 layers to fit the FPGA/sockets/etc. on the board though.
Wow...I think my mind is about to explode now.
tt
Well-known member
Haha, mine too! Clever idea. I was thinking of using SLC flash chips to make an SSD on ROM SIMM. If it were done that way, and everything can keep up, you could get an order of magnitude of speed over native SCSI for most of the compatible machines (15-20MB/s according to GTTMFH).
I don't foresee any particular problems with that approach from the software side as long as there are synchronization registers to know that the results of any particular command are ready.
Worst case, the driver would be called from an interrupt handler, but I'm not seeing anything particularly problematic. This is a really simple interface, which makes it safe in a variety of situations.
I'm up for a driver.
The ROM SIMM interface will be slower than PDS, but it'd certainly work on more machines. That seems like a plus to me.
For the specifics of the access pattern, it would be easiest and fastest from the driver perspective to do as much as possible on the FPGA side, reducing what needs to be done by the host processor. Plus it's pretty much guaranteed the FPGA is going to be faster than the host processor anyway. But, the tradeoff there is making the access pattern application specific vs. generic and modular.
For both size constraints and modularity, would it be reasonable to put the FPGA on the SIMM, and have a connector and separate board for the components the FPGA exposed (microSD/CF/whatever)? My thinking is that CF probably won't fit within the size constraints of the current ROM SIMM, and there are quite a few different ideas of what could be exposed.
Anyway, just some thoughts.
Worst case, the driver would be called from an interrupt handler, but I'm not seeing anything particularly problematic. This is a really simple interface, which makes it safe in a variety of situations.
I'm up for a driver.
The ROM SIMM interface will be slower than PDS, but it'd certainly work on more machines. That seems like a plus to me.
For the specifics of the access pattern, it would be easiest and fastest from the driver perspective to do as much as possible on the FPGA side, reducing what needs to be done by the host processor. Plus it's pretty much guaranteed the FPGA is going to be faster than the host processor anyway. But, the tradeoff there is making the access pattern application specific vs. generic and modular.
For both size constraints and modularity, would it be reasonable to put the FPGA on the SIMM, and have a connector and separate board for the components the FPGA exposed (microSD/CF/whatever)? My thinking is that CF probably won't fit within the size constraints of the current ROM SIMM, and there are quite a few different ideas of what could be exposed.
Anyway, just some thoughts.
Trash80toHP_Mini
NIGHT STALKER
On the hardware size limitations/design front, it looks to me like it's time to just add a microprocessor to your ROM SIMM, DQ. :
Breaking the rest of the circuitry out to a header cable (USB?) leading to a daughtercard stand-off'd inside an FDD Chassis seems a no-brainer to me. That's your prototyping area with physical I/O accessed through the Floppy Slot, probably from a second prototyping board. This physical I/O form factor is common to every FDD era Mac and conveniently positioned as well. [] ]'>
Dunno, maybe the cable from the SIMM should be designed from the start as a DaughterCard headered to a square prototyping board with pads for four I/O connector combination choices to be aimed at the floppy slot from its standoffs, in said standardized sheet metal expansion bay housings?
Dunno, I'm just piping into the brainstorming session where I can at this point, my head already exploded a few pages back! 8-o
Breaking the rest of the circuitry out to a header cable (USB?) leading to a daughtercard stand-off'd inside an FDD Chassis seems a no-brainer to me. That's your prototyping area with physical I/O accessed through the Floppy Slot, probably from a second prototyping board. This physical I/O form factor is common to every FDD era Mac and conveniently positioned as well. [
] ]'>Dunno, maybe the cable from the SIMM should be designed from the start as a DaughterCard headered to a square prototyping board with pads for four I/O connector combination choices to be aimed at the floppy slot from its standoffs, in said standardized sheet metal expansion bay housings?
Dunno, I'm just piping into the brainstorming session where I can at this point, my head already exploded a few pages back! 8-o
Trash80toHP_Mini
NIGHT STALKER
@ tt & bb,
You two might want to take a look at the practicality of doing an NuBus/PDS end run around the ROM SIMM's speed limitations as a parallel project, there looks like a lot of crossover betwixt the three approaches.
Having the Killy Klip hack come back into the picture for 68000 I/O hacking might be an interesting avenue of approach for consideration at as well.
The Portable and PB100 might fit into the picture along with the Compacts by this avenue of approach as well. :approve:
edit:
EEK! p.35! 8-o
You two might want to take a look at the practicality of doing an NuBus/PDS end run around the ROM SIMM's speed limitations as a parallel project, there looks like a lot of crossover betwixt the three approaches.
Having the Killy Klip hack come back into the picture for 68000 I/O hacking might be an interesting avenue of approach for consideration at as well.
The Portable and PB100 might fit into the picture along with the Compacts by this avenue of approach as well. :approve:
edit:
EEK! p.35! 8-o
Dennis Nedry
Well-known member
If information is available directly on the address/data bus, that is the fastest possible access. But it seems like there would be a lot of overhead when connecting this with serial flash memory, in at least these ways:
- Extracting/converting serial data to parallel
- More complicated driver, more instructions/jumps/waiting for ROM ready per read
- probably others
When we consider this overhead, we should compare it to the overhead of using NuBus which was originally designed for this purpose. If we hack the friggin' crap out of NuBus, we could make a mass storage card similar to a SCSI card but direct from NuBus, through a fast microcontroller, to SD/Compact Flash/IDE/USB flash drive/etc.
I have always been one to dream of packing multiple purposes into one card for Macs that can only take one card, so if a fancy enough microcontroller is selected, it seems like a reasonable community project to begin adding 10/100k ethernet, 16-bit 44kHz stereo audio in/out, etc. and rigging up some crazy breakout cable. These are not overnight projects, but they are just the sort of putzy things that we like to chip away at and chat about.
Direct access has the highest potential and can be made to work with ALL Macs, but considering the bottlenecks involved with the cheap massive flash memory we have available, We should at least think about NuBus.
- Extracting/converting serial data to parallel
- More complicated driver, more instructions/jumps/waiting for ROM ready per read
- probably others
When we consider this overhead, we should compare it to the overhead of using NuBus which was originally designed for this purpose. If we hack the friggin' crap out of NuBus, we could make a mass storage card similar to a SCSI card but direct from NuBus, through a fast microcontroller, to SD/Compact Flash/IDE/USB flash drive/etc.
I have always been one to dream of packing multiple purposes into one card for Macs that can only take one card, so if a fancy enough microcontroller is selected, it seems like a reasonable community project to begin adding 10/100k ethernet, 16-bit 44kHz stereo audio in/out, etc. and rigging up some crazy breakout cable. These are not overnight projects, but they are just the sort of putzy things that we like to chip away at and chat about.
Direct access has the highest potential and can be made to work with ALL Macs, but considering the bottlenecks involved with the cheap massive flash memory we have available, We should at least think about NuBus.
I've tossed around the idea of doing a PDS card, to the point of trying a basic schematic in Eagle. I'm a software guy, and I'm kind of starting from scratch on this side of things. Eagle licensing isn't terribly practical for 030 PDS connector sized PCBs. I tried KiCAD and FreePCB, they didn't have the 030 PDS connector in their library and I got bored with manually setting up 120 pin connectors. Wire wrap prototype just confused me, trying to keep straight ~70 little wires all the same color. So, I just don't see myself getting anywhere on a PDS card anytime soon, especially with an ever increasing todo backlog. Maybe someday.
The ROM SIMM approach will always work in more machines, I had just tossed around the PDS idea as a personal learning project because it seemed a stretch, but attainable with my current level of understanding. But again, at this point I just don't see it getting anywhere in the near future. Plus, declaration roms are a different type of challenge from the system rom.
If someone else were so inclined and wanted to make something, I'd be excited to help out, and would be all about the software side. I've got some fundamental infrastructure to create declroms now that I've been creating them from scratch and just throwing them into Asante NICs' 27C256 EPROMs.
olePigeon
Well-known member
It would be neet, but I wouldn't want to sacrifice my 040 card for it. What about a NuBUS card, or would that be even slower? The SIMM seems really, really fast to me. Maybe it's just because it's solid state. I just think that it's cool that the SIMM slot is also used for storage, saves you a slot.
Yeah--if we needed to call the driver from an interrupt handler, I suppose we could just disable interrupts during any writes to the SIMM to force it to be atomic. Maybe there's a better solution too with the help of the FPGA...I'm not sure.
Great! Now we just need to find people who are up for PCB design and FPGA programmingI'm up for a driver.
It's beyond my current knowledge level. I want to learn (and I have some FPGA dev boards), but I have a lot to learn about it before I'm anywhere near proficient for sure.I agree completely and I think it's feasible. The SIMM has to fit within an SE/30 which doesn't have much clearance above the existing SIMM, and it'll be hard to fit extra connectors. It's probably going to be hard enough fitting an FPGA on it. It would be wonderful to make it some kind of generic card that could be reused for tons of different purposes. I agree that the FPGA would have to stay on the SIMM (otherwise there are over 50 wires that would have to go through a cable to the FPGA, not counting ground wires...probably not going to happen, but I'd love to be proven wrong).
Yep -- although I'm not sure a microprocessor is the right choice -- an FPGA is probably the way to go. I suppose a microcontroller could set up an interrupt to occur whenever the output enable/chip select lines toggle to determine when to read/write to the address bus (and when to set the data lines as inputs rather than outputs), but I think an FPGA is more suited for the task. For parts of it that do need a microcontroller, possibly an FPGA paired with a microcontroller or a softcore inside the FPGA could do the trick.On the hardware size limitations/design front, it looks to me like it's time to just add a microprocessor to your ROM SIMM, DQ. :
We also have to keep in mind that it's going to be hard to find 5V FPGAs. I think it will require level shifting (and a voltage regulator to generate 3.3V from the 5V), which is definitely possible, but annoying. Also, do we know how much current the power pins in the SIMM socket can supply? Same with all of the data/address pins...we'd have to make sure we're not trying to draw too much from any of them. Considering it was really only designed to power four flash chips, I always have to wonder. Some of these questions make me wonder if one of the other sockets *is* a better idea.
Very true, although we will need to hack the ROM anyway to get it to boot off of such a NuBus card (or does the Mac ROM have a mechanism in place to boot from a NuBus card?)
I really like the idea of a community project as Dennis Nedry pointed out. I don't want to be the only one designing the hardware on this project (and now that we're moving toward more complicated things, I will need help). I'd recommend if we do it this way to use something like KiCad so that everyone has easy access to the PCB files. Like bbraun said, Eagle's usefulness starts to break down as soon as you need bigger boards. I'm not the biggest fan of KiCad, but maybe it's just because I don't fully understand it yet. I remember feeling similar things about Eagle initially too.
In conclusion, I have no idea where to go next
But I think the consensus is that there is definitely a next step to bring high-speed modern storage, among other things, to these Macs. If we can somehow bypass the slow secondary storage mechanisms of the computers of this era (slow SCSI drives) by hooking modern secondary storage mechanisms (CF, SD, SSD, whatever) into a faster primary storage interface, we can really do some cool things, as evidenced by bbraun's ROM disk driver.
Trash80toHP_Mini
NIGHT STALKER
Again, I'll suggest breaking out from the ROMM SIMM interface into the FDD expansion bay/slot and powering the additional circuitry from the FDD or HDD connectors on a standard issue Y-Cable. That's the place to do any voltage step-down and feed it back to the ROM SIMM over the interface cable.
Methinks you're at the point where bringing in a microcontroller specialist (tt,techknight, perchance?) for the interface to your ROM SIMM might be the correct avenue of approach to keep things as simple in the ROM SIMM Slot and flexible as possible overall.
edit: sorry, I didn't grok you point at first. Why would you want to boot from a NuBus Card? You're still booting from system ROM and then polling each of the physical slots for a DeclROM on NuBus or PDS to interface with the Slot Manager. Any drivers or software can be loaded from either card type from the Declaration ROM, IIRC.
Methinks you're at the point where bringing in a microcontroller specialist (tt,techknight, perchance?) for the interface to your ROM SIMM might be the correct avenue of approach to keep things as simple in the ROM SIMM Slot and flexible as possible overall.
Yep, it's called the Slot Manager and I think every Mac since the II and SE use a form of it, supported in ROM.
edit: sorry, I didn't grok you point at first. Why would you want to boot from a NuBus Card? You're still booting from system ROM and then polling each of the physical slots for a DeclROM on NuBus or PDS to interface with the Slot Manager. Any drivers or software can be loaded from either card type from the Declaration ROM, IIRC.
That's what the declaration ROM is for. You can put boot code into the declaration ROM, and the system ROM will boot from it. But... It's a little limited. The system ROM will *only* boot from a Slot (nubus or PDS) if it is set as the boot device in PRAM. So it's not really the same use case as the ROMDisk, and could be seen as complementary. The ROMDisk as the recovery volume, the Slot based device as the regular boot drive.
That limitation is why I went with the hacked up system ROM in the first place. I had the ROM Disk driver loading and booting from a modified Asante NIC's declaration ROM, but the 1.5MB ROM disk was really only practical as a recovery volume, and needing the PRAM value already set wasn't terribly useful as a recovery volume.
However... That's not to say it can't be done. Before boot selection happens, the Slot Manager runs a Primary Init routine from the declaration ROM, if one exists, regardless of what the boot device is. This is when Slot based video devices draw the checkered screen at power on, for example. So, once the card can load and execute code, all sorts of possibilities open up.
Yeah, that's a good idea! Is it feasible/safe/reliable to take all of the parallel ROM SIMM signals directly from there to the expansion bay/slot? That would be pretty slick if so and would remove all of the bandwidth limitations. Heck, I (or someone else) could probably get a prototype working with a bare ROM SIMM PCB and some ribbon cable.
I'm glad you brought this up because I'm very curious what the other microcontroller gurus think about this. I'm thinking it's going to need an FPGA/CPLD involved. I'm pretty good with microcontrollers too, and I'm just not convinced that a microcontroller alone is the right approach for talking with the bus signals. A microcontroller that interfaces with an FPGA to do work that's easier in software than hardware is fine, but the actual bus interface screams to me as something that should be handled in hardware rather than software because of the fast timings.
Let's do some math: GttMFH says that the ROM access rate on the SE/30 is 15.67 MB/sec. Each ROM access reads 4 bytes, so it's really only a 3.9175 MB/sec access rate. This means every 255 nanoseconds, another ROM access might occur. (Luckily, the ROM chips I'm using in the 8 MB SIMM have a 55 ns access time, so they're plenty fast enough). A 100 MHz processor has a clock cycle every 10 nanoseconds. So if a 100 MHz processor is monitoring the address bus, basically that leaves us around 25 clock cycles for the microcontroller program to do something before it has to be ready for the next ROM read cycle. Even with tightly optimized assembly code, 25 cycles isn't a whole lot of processor time.
The IIfx apparently has a ROM access rate of 64 MB/sec (equivalently, a real read speed of 16 MB/sec). At 16 MB/sec, there's a read every 62.5 nanoseconds. The 8 MB chips are still fast enough...in fact, the older 2 MB SIMM chips might be breaking timing guidelines on the IIfx if my math is correct because I think the other chips I'm using have a minimum access time of 70 nanoseconds. This example is actually making me doubt my math -- anyone want to double check to make sure I'm not full of crap? Anyway, at 62.5 nanoseconds, a 100 MHz processor will only have 6 cycles available between ROM accesses.
Judging by these numbers, in order to accurately sample the address lines correctly after the output enable line and chip enable lines have gone low, and provide a good readback to the Mac within ample time, it's going to take something with faster timing than a 100 MHz processor. And 100 MHz is pretty fast for a microcontroller--for example my SIMM programmer runs at 16 MHz. That's why I'm thinking the logic for handling the reads, signaling to the Mac that an operation has completed (with the polling register), etc. will have to go into an FPGA/CPLD. Then, it could signal to a microcontroller through an interrupt line or whatever to do actual work and let it know when it's complete, finally signaling the Mac through the polling register that the operation has really completed. I don't have a ton of experience with FPGAs though -- is my math coming out OK, is this still feasible in an FPGA at these speeds, and/or am I missing something big here?
Whew, sorry for the rambling! More fried brain for me tonight...
Ah, thanks for clearing that up. I guess I didn't totally understand what the DeclROMs were capable of.
Similar threads
