-
Hello MLAers! We've re-enabled auto-approval for accounts. If you are still waiting on account approval, please check this thread for more information.
Another IIci ROM hack
- Thread starter dougg3
- Start date
After more research I'm pretty sure it will require a firmware update to use the new 8 megabyte SIMM. This PDF is for Spansion devices, but it's all JEDEC standard stuff from what I can tell.
It's because the flash chip always looks at its A0 through A10 pins for the address to enter unlock mode, even in byte mode where there's an extra address pin (A-1) which goes before A0. I correctly have it wired up so A-1 is the lowest address pin (A-1 is wired to what I call A0 on the SIMM programmer side, A0 is wired to what I call A1, and so on...), but because the chip looks at A0 instead of A-1 for the lowest bit for unlock addresses, the unlock addresses have to be shifted over one bit. It kind of sucks because now the firmware will have to know which type of SIMM you're using, but I'm not too concerned about it -- if you pick a capacity bigger than 2 MB in the control software, it'll just automatically switch the firmware over to the other addressing scheme. I'll have to add something in the firmware so the control software can tell the programmer board what type of SIMM it should be talking with, but that will be simple to add to the communication protocol.
Whatever the case is, it should still work fine
And the existing programmer board firmware is really easy to update -- the update process is fail-safe.
It's because the flash chip always looks at its A0 through A10 pins for the address to enter unlock mode, even in byte mode where there's an extra address pin (A-1) which goes before A0. I correctly have it wired up so A-1 is the lowest address pin (A-1 is wired to what I call A0 on the SIMM programmer side, A0 is wired to what I call A1, and so on...), but because the chip looks at A0 instead of A-1 for the lowest bit for unlock addresses, the unlock addresses have to be shifted over one bit. It kind of sucks because now the firmware will have to know which type of SIMM you're using, but I'm not too concerned about it -- if you pick a capacity bigger than 2 MB in the control software, it'll just automatically switch the firmware over to the other addressing scheme. I'll have to add something in the firmware so the control software can tell the programmer board what type of SIMM it should be talking with, but that will be simple to add to the communication protocol.
Whatever the case is, it should still work fine
And the existing programmer board firmware is really easy to update -- the update process is fail-safe.
It should be possible to stay backwards compatible with the older SIMMs and not have to keep reflashing the programmer for different SIMM revs. Here are some ideas:
Mod Programmer firmware only:
- Trial and error both unlock methods, and continue on with the one that worked
- Find some other difference that you can detect between the boards / ROM chips
With programmer application involved:
- Make a SIMM rev. selector in the programmer application, and send a message to the programmer board to select the right unlock method
Mod Programmer firmware only:
- Trial and error both unlock methods, and continue on with the one that worked
- Find some other difference that you can detect between the boards / ROM chips
With programmer application involved:
- Make a SIMM rev. selector in the programmer application, and send a message to the programmer board to select the right unlock method
That's the plan! And in your case, it's really necessary because the DayStar card takes up 512 KB of the available ROM space. Without this bigger SIMM you would only have 1 MB of space available for the Disk Tools disk.
I have made all necessary changes to the firmware and control software already...I just have to wait for the PCBs and chips to arrive!
I have made all necessary changes to the firmware and control software already...I just have to wait for the PCBs and chips to arrive!
And you were worried about the cost of flash, dougg3!
This seems to be a pretty cost insensitive item if people are wanting to pay more for PCB color!
There are a couple ideas that crossed my mind on this, particularly since reading your other thread about the AV ROM.
1) An AV ROM SIMM would be neat, although probably low volume due to needing to solder a new connector on most of our motherboards. I'd be up for it, my Q630 also has pads for a ROM SIMM.
2) With the 8MB SIMM, new possibilities open up, including running newer, larger ROMs. The IIsi ROM was mainly chosen for the current round of hacking because it had space and was 512KB, which left a pretty usable 1.5MB. But with 8MB, it becomes reasonable to run all the way up to a 2MB AV ROM. That's burning a lot of mostly unnecessary space for the II series machines, but might be worthwhile. The remaining 6MB is still pretty usable, and there are lots of benefits. Some of them being: SCSIMgr4.3, and the EDisk driver. The EDisk driver is quite versatile, including the builtin support for a ROM disk *and* being able to find the ROM disk image inside the ROM. The EDisk driver is both the RAM disk driver and the Classic's ROM disk driver. Which pretty much obsoletes most of the work I've done so far (with the exception of the ROM mapping tables, and disabling both the ROM checksum and the memory test), but such is technology. It'd be interesting to see if SCSIMgr4.3 in the AV ROMs helps the Q900's dual SCSI bus limitations (and the Q900 has the SIMM slot, same as the 700).
This seems to be a pretty cost insensitive item if people are wanting to pay more for PCB color!
There are a couple ideas that crossed my mind on this, particularly since reading your other thread about the AV ROM.
1) An AV ROM SIMM would be neat, although probably low volume due to needing to solder a new connector on most of our motherboards. I'd be up for it, my Q630 also has pads for a ROM SIMM.
2) With the 8MB SIMM, new possibilities open up, including running newer, larger ROMs. The IIsi ROM was mainly chosen for the current round of hacking because it had space and was 512KB, which left a pretty usable 1.5MB. But with 8MB, it becomes reasonable to run all the way up to a 2MB AV ROM. That's burning a lot of mostly unnecessary space for the II series machines, but might be worthwhile. The remaining 6MB is still pretty usable, and there are lots of benefits. Some of them being: SCSIMgr4.3, and the EDisk driver. The EDisk driver is quite versatile, including the builtin support for a ROM disk *and* being able to find the ROM disk image inside the ROM. The EDisk driver is both the RAM disk driver and the Classic's ROM disk driver. Which pretty much obsoletes most of the work I've done so far (with the exception of the ROM mapping tables, and disabling both the ROM checksum and the memory test), but such is technology. It'd be interesting to see if SCSIMgr4.3 in the AV ROMs helps the Q900's dual SCSI bus limitations (and the Q900 has the SIMM slot, same as the 700).
for large ROM space, isnt there a possibility of using a small scale micro-FPGA? using such with a serial flash and a RAM IC thats large enough to handle everything?
For example, soon as power hits the SIMM, the FPGA copies/decompresses the SPI flash into the RAM IC and everything runs from the RAM IC in a parallel state, whilst the FPGA is managing the RAS/CAS of the RAM to keep it refreshed. There are open source FPGA code out there for VHDL on controlling all RAM up to DDR3. FPGA would be used as the buffer, a read request comes from the ROM space, so the FPGA fetches it from RAM and puts it on the bus.
For example, soon as power hits the SIMM, the FPGA copies/decompresses the SPI flash into the RAM IC and everything runs from the RAM IC in a parallel state, whilst the FPGA is managing the RAS/CAS of the RAM to keep it refreshed. There are open source FPGA code out there for VHDL on controlling all RAM up to DDR3. FPGA would be used as the buffer, a read request comes from the ROM space, so the FPGA fetches it from RAM and puts it on the bus.
Last edited by a moderator:
Yes -- I have some of the work done on it already. All the chips are tied together with their control lines, but I can just send the wrong data bytes to the other chips (if present) during the unlock sequence to skip erasing/programming them. The code is there -- I just have to add it to the communication protocol and add capabilities to the control software to activate it.
Yeah...it's weird! But yeah, something like blue or black sounds great to me.
Sorry!Purple!
*Edit
laaame]
Haha...well if that's the case, let's find a manufacturer who can do silkscreen in orange or something awesome like that!
Yeah, the lack of soldered sockets is a problem with making ROM SIMMs for other models. I have a ton of 64-pin SIMM sockets thanks to olePigeon, but it's a pain in the butt to add the sockets to the motherboard. For that reason I'm not sure that I really want to create one. Honestly, it's similar enough that I could probably just reuse the existing SIMM PCB and just add a switch or something for "program mode" vs. "in-Mac mode" that sets the chip select line as needed.
I wonder if the Q630's ROM SIMM uses the same pinout? I think I have a Performa 630 here somewhere, I could check it out with a multimeter. Or maybe the dev notes for it say the pinout...I'm too lazy to check now.
The EDisk driver seems like a really interesting idea. Does it work in the same conditions as the things you've had to work around, such as the "only 1 MB of ROM space available in 24-bit addressing" problem?
BTW, I've flashed an AV ROM onto my SIMM and tried to boot my IIci with it -- it doesn't work
But it would be AWESOME if we could figure out why it doesn't work and make it work. That would be great to get everything up and running on the latest 68k Mac ROM.---
Latest update: the chips have arrived. I was expecting Micron chips and got ST chips, but I did some research and I now understand what happened. It looks like what happened is that back in 2008, Intel and ST Microelectronics spun off their flash chips into a new company called Numonyx, which Micron later bought. So these are old chips back from when ST still called them their own.
It's so tiny...I can't wait to assemble one of these SIMMs!
Hey i actually have a bunch of ZIF TSOP sockets that fit these, i think they do anyway, not sure of the pincount, i think its TSOP48 I have.
Yeah, it should pretty much have the same behavior. You can't get any more ROM space in 24bit mode since 0x900000 is Slot 9's 24bit address space. But it should bounce between modes like my driver does, so it should still be accessible even when using a 24bit app or whatever. I'm not sure it has the ability to copy the disk image into RAM to have a writeable boot volume though.
The AV ROMs have a different way of setting up ROM space from the IIsi ROM, which may be related to at least one of the reasons why it won't boot. I might try to poke at this a bit.
I actually really like this idea. Big RAM and large SPI flashes are a lot easier to find than big parallel flashes. My main question about this approach is: how can you get the data out of the serial flash and into the RAM before the CPU does its first access to the ROM? The very first access by the CPU is to ROM to grab the reset vector. That's going to be very very early in the boot process, possibly before the FPGA has had a chance to load much data into RAM. Maybe still use a parallel NOR flash for the lower 1 MB or 2 MB of space and then use the FPGA for accesses above that?
Although there is only 8 MB of available address space in the ROM space, you could use the FPGA to create a register somewhere in the 8 MB of address space to control which page is currently active. The lower 2 MB or 4 MB could always be mapped to the ROM, and the rest of the address space could change depending on which page is selected. The disk driver could use the page selection register to create a practically unlimited ROM disk size. Just dreaming here...
Yeah, these are TSOP48 chips. I didn't even realize that ZIF sockets existed for fine-pitch surface mount components like this. Do the sockets solder onto the same pad layout that the chips solder onto?
Well, that's interesting! It would be pretty cool to make it work with Apple's stock RAM/ROM disk driver, I have to admit.
Edit: I just realized after reading the datasheet for the chips I'm using that they aren't available in the SO44 package. Probably because the TSOP48 package uses 46 of the 48 pins (GND is duplicated, so only 45 are really necessary). Either way, 45 and 46 are still larger than 44. That would explain why it's not available in the SO44 package...so I was wrong earlier when I said I knew this chip was available in SO44.
As long as you are using an FPGA, you could have 2 modes of operation. "loading ROM" mode and "ready" mode.
In "loading ROM" mode, you can hard-code this sort of functionality:
Reset vector:
location 0x0000 0000
At Location 0x0000 0000:
Load reset vector with location 0xXXXX XXXX (default with 0x0000 0000)
Branch to reset vector
The Mac would sit and spin in this mode, changing addresses back and forth so you have something for synchronization to avoid a race condition. When the FPGA is ready and the address changes to 0x0000 0000, swap in the actual reset vector from actual ROM. When the address changes to the reset vector, swap in the ENTIRE actual ROM for ready mode.
I don't think it's out of the question to add clips to the Mac as an optional feature. This would allow us to run additional address lines to the ROM SIMM by clipping them onto the processor's pins or some other convenient spot. Each additional line doubles the maximum ROM capacity. Even supplying thru-holes for a small pin header on an edge of the ROM SIMM would allow people to make these connections on their own for increased capacity. There were certainly commercial Mac upgrades that used clips and it think it would appeal to some of us geeks to know that at least the capability exists.
Ah, that makes sense! Just force it into an endless loop of nothing until the RAM has been completely loaded from the SPI flash and then unlock it. I get it, nice idea!
The clips are an interesting idea. I think it would work as long as we guaranteed that $40800000 (32-bit) and $800000 (24-bit) pointed to the actual ROM because that's what the Mac OS uses for its base address. With the other address clips in place we would be free to use $40000000 to $407FFFFF and $40880000 to $4FFFFFFF for whatever we wanted...that's a lot of space available if the address lines are easily clippable!
The clips are an interesting idea. I think it would work as long as we guaranteed that $40800000 (32-bit) and $800000 (24-bit) pointed to the actual ROM because that's what the Mac OS uses for its base address. With the other address clips in place we would be free to use $40000000 to $407FFFFF and $40880000 to $4FFFFFFF for whatever we wanted...that's a lot of space available if the address lines are easily clippable!
With this theoretical FPGA / RAM module on a ROM SIMM, would it be feasible to then make a volatile read/write ROM disk? How about Non-volatile? I'm not aware of how the 68k does a write operation to memory or if that signal is available in the ROM SIMM slot.
I don't know how the 68k does it either, but a write signal is not available in the ROM SIMM. We'd probably need to find it somewhere else. Also, I don't know for sure, but the MMU might have to be set up to allow writes to that region.
I think it would be feasible at that point to make a volatile ROM disk (although bbraun has already done this by copying the ROM disk contents into RAM and doing a RAM disk). I'm not sure about non-volatile...if each write could wait for the SPI flash to finish its corresponding write, I think it could be done.
With all that said, I don't know the first thing about FPGAs other than basically how to control an LED with a push button in VHDL and I also don't know how fancy of an FPGA we would need to meet the ROM timing requirements...
I think it would be feasible at that point to make a volatile ROM disk (although bbraun has already done this by copying the ROM disk contents into RAM and doing a RAM disk). I'm not sure about non-volatile...if each write could wait for the SPI flash to finish its corresponding write, I think it could be done.
With all that said, I don't know the first thing about FPGAs other than basically how to control an LED with a push button in VHDL and I also don't know how fancy of an FPGA we would need to meet the ROM timing requirements...
For non-volatile, there is probably no way to directly write to the Flash in real time, so it would need to be buffered or double buffered. If we can supply twice as much RAM on this SIMM as ROM, then that would give us space for a double buffer. When the SIMM first powers on, it would need to make two copies of ROM into RAM. One of these copies would be the "working" copy, the version that the Mac uses directly. The other copy would be a representation of the flash contents.
That allows us to add a function to the FPGA that constantly cycles through the RAM and compares the working copy to the buffer. When it finds a difference, it would then update the Flash with a write operation. This method uses the minimum number of write cycles to the Flash which will prolong its life.
A different option, the single buffer, uses less RAM but uses a lot more write cycles. You could set a flag on any write operation, then based on this flag, handle it by turning the flag off and writing all Flash from the information stored in the SIMM's RAM. If the flag is set again during the update, it will do another update again at the end of the current update. If the flag is set 10 minutes later, then all of the time in between will be spent not updating to preserve write cycles.
That allows us to add a function to the FPGA that constantly cycles through the RAM and compares the working copy to the buffer. When it finds a difference, it would then update the Flash with a write operation. This method uses the minimum number of write cycles to the Flash which will prolong its life.
A different option, the single buffer, uses less RAM but uses a lot more write cycles. You could set a flag on any write operation, then based on this flag, handle it by turning the flag off and writing all Flash from the information stored in the SIMM's RAM. If the flag is set again during the update, it will do another update again at the end of the current update. If the flag is set 10 minutes later, then all of the time in between will be spent not updating to preserve write cycles.
There are of course intermediate options to improve the single buffer method as well, for example, having a multitude of flags for discrete chunks of memory, then updating just the chunks that have been flagged.
I'm brainstorming here - not necessarily is any of this reasonable or within scope for these hobbiest gizmos, but it's at least fun to think about and useful when making more realistic ideas.
I'm brainstorming here - not necessarily is any of this reasonable or within scope for these hobbiest gizmos, but it's at least fun to think about and useful when making more realistic ideas.
