Thread
Another IIci ROM hack
Hah, tell me about it. My IIci has 128 MBs. I usually hit the power button, then go make a sandwich.
:lol: That reminds me of a friends story about hitting the play on the cassette deck and going to the fridge for a beer!
Dang, you missed it, oldbird ------------- 25 Pages ------------ [
] ]'>
Go, DQ & Company! :approve:
Dang, you missed it, oldbird ------------- 25 Pages ------------ [
] ]'>Go, DQ & Company! :approve:
Sounds like we definitely need to disable the RAM test then 
It can't be too hard to do.
I just got an e-mail saying my PCB file is under processing. I guess we'll see if it meets the design requirements. I just realized I used a 12 mil diameter drill for most of the vias (except for power/ground ones), which is pretty much the smallest they offer. Hopefully I'm not pushing it too far on the via diameter limit...
It can't be too hard to do.I just got an e-mail saying my PCB file is under processing. I guess we'll see if it meets the design requirements. I just realized I used a 12 mil diameter drill for most of the vias (except for power/ground ones), which is pretty much the smallest they offer. Hopefully I'm not pushing it too far on the via diameter limit...
Do you need SIMM sockets?
It'll probably be at least another week before I have a board to assemble and test, and it'll take a while to develop the software to test it out, but yes, I will be needing to buy some SIMM sockets from you soon...
Woah... today is the first time in months that I've hit "View New Posts", and not seen this thread in the list. The horror!
I'll send you a few anyway. With it being so close to the holidays, it might actually take a week for them to get to you.
I'm pretty certain that disabling the RAM test at start-up is controlled by one of the PRAM memory settings.
Either or both of the Daystar Turbo040 and the Turbo601 Control Panels have a setting to disable the start-up memory test. It should be possible to dump the PRAM contents before and after to find the controlling location.
Of course, it may be more complex than that, with the Daystar Firmware taking an active role, but I hope not.
Either or both of the Daystar Turbo040 and the Turbo601 Control Panels have a setting to disable the start-up memory test. It should be possible to dump the PRAM contents before and after to find the controlling location.
Of course, it may be more complex than that, with the Daystar Firmware taking an active role, but I hope not.
The II/IIx ROMs are different from the 32bit ROMs (and the 040 ROMs look different from the 32bit 030 ROMs), and I'm trying to understand it all, but the II/IIx ROMs toggle the ram test based on whether it's a warm boot, which checks 0xCFC for the value 0x574C5343 to see if it's a warm or cold boot. The RAM test can be called from several locations in the ROM though, so it might just be easier to throw an RTS in at the RAM test location. The accelerators probably just fake a warm start.
According to Gamba it's a combo of PRAM and DayStar ROM: http://www.mail-archive.com/compact.macs@mail.maclaunch.com/msg06028.html
Well, the accelerator software would store it's setting in PRAM and the card's firmware would read that to determine whether it should disable the check or not. The system ROM doesn't check the PRAM.
It would be interesting to add the SCSI Manager to the ROM of the Quadra 900 and Quadra 950. Each of those machines has two physcial SCSI buses, but treats them as a single logical bus.
Presumably, SCSI Manager in ROM would or could cause them to be treated as two logical SCSI buses at boot time.
That would be a most excellent hack! :approve:
Well, pooh. That's the worst case I referred to in my last sentence. Setting in PRAM, but Daystar firmware required in order to do anything with the setting.
I wonder how useful it would be to add aspects of the Daystar firmware to ROMs even in machine in which an upgrade won't be used.
A package of useful ROM routines would be nice, including the ability to disable the memory startup in a control panel or other app. and SCSI Manager 4.3.
Although, I'd really like to rewrite/replace SCSI Manager 4.3 with a more versatile -- can't remember the name -- but the search function comes to the rescue.
http://68kmla.org/forums/viewtopic.php?p=20085#p20085
From 2007:
The advantage to writing a replacement for SCSI Manager is that one could put in actual IDE support and add the hooks for USB support, in theory. Adding USB hardware would be relatively easy. There are USB chipsets (or were) whose interface side is for regular micros and not PCI. Adding firmware/driver support would be a pain.
Heh, rereading that old post, I see that I was log-jammed in projects back then too. Four years ago and it mentions those blank circuit boards on my desk, which are still there. Sigh. Also mention of the concept of an SE/30 ROM SIMM.
Two aspects to this:
1) I'd like to see an app that applies our known patches to existing ROMs. Add the ROMdisk driver, set bootup sound, set icons, etc. When we know how to do more, fold that in, and have a central tool that can pop out ROMs with modifications we know about. There's a bunch of details to sort out on that, but it seems reasonable.
2) Selectively disabling the memory test based on PRAM settings. The challenge here IMO, is PRAM is not mapped directly into the address space, it is accessed via the RTC chip. So, I don't know how to retrieve PRAM without using RAM. Using RAM to know whether you can trust RAM seems like a bad situation to be in. Maybe I'm just being dense and it's easier than I think... Just disabling it in the ROM image entirely (no checking) would be the easy route, and probably at least the first step.
Well... There are lots of ways to go about adding USB Mass Storage Class support, if that's the goal.
My understanding of the User to SCSI target call chain is limited, but here's my understanding at the moment.
On boot, the ROM eventually loads SCSI Manager, which is really a set of calls and a driver (but not a DRVR that occupies the Unit Table, SCSI drivers are different) for the actual SCSI controller. The ROM then uses SCSI manager to look for disks, reads block 0 which is expected to contain a driver descriptor record, using the driver descriptor record it then loads the disk's driver into RAM and adds a copy of the disk's driver to the Unit Table, opens the driver, and all subsequent access is through that driver. Using the loaded driver, partitions are then parsed by the Start? SCSI? Manager, a Drive entry is added to the Drive Queue for each partition, and a diskEvt notification is posted for each drive in order to get mounted. Then when the entire SCSI chain has been traversed, all drives & partitions found, drivers loaded & opened, it returns and the booting process continues, selecting a boot disk based on the usual criteria (boot floppy if there's one inserted, eject floppy if mouse is down, consult PRAM to figure out the selected boot disk if no floppy is inserted, etc.).
If just using a USB disk as bootable storage on 68k is the goal, as opposed to full USB support, there are shortcuts! Have a microcontroller handle the USB interface to the device (USB OTG seems cheap and readily available, and probably has sample code available for this), and have a dead simple interface between the host CPU and the microcontroller. Mac block device drivers only know how to do 3 things: 1) read data in 512byte block multiples from a given location, 2) write the same, and 3) verify the data written was correctly written. Everything else is implemented as an optional Control call (format, eject, icons, etc.) All of that could be offloaded to the microcontroller, resulting in a fairly straightforward driver that would be advertised in a declrom. There's a bunch of details in there, including the fact that partitions wouldn't work since only SCSI drives can have partitions, apparently due to the fact that SCSI Manager is what parses partitions.
Actually that's no problem at all-- the Mac Plus ROM does exactly that at start-up, and other Macs probably do the same. Check out the fdplus commented ROM disassembly from fdisasm.
If I recall, there's a self-contained routine in ROM that takes the PRAM address to read in a register, and returns the value in another register, with no use of RAM.
If you disable the RAM test entirely, will there be some other way for the Mac to know how much RAM is installed? You could probably write a different routine that only checks every 1MB or something, instead of testing every single byte.
Ah, right, it looks like the ClkNoMem stuff would work well, thanks!
At least for the Mac II, finding the size of memory seems to be independent of the RAM test, but I'll take a closer look next time I reprogram my SIMM. Basilisk II disables the RAM test for the Classic ROM, but doesn't bother for the 32bit ROM path.
At least for the Mac II, finding the size of memory seems to be independent of the RAM test, but I'll take a closer look next time I reprogram my SIMM. Basilisk II disables the RAM test for the Classic ROM, but doesn't bother for the 32bit ROM path.
Sorry if I already asked this, but is the RAM limitation on the LC a ROM or hardware limitation?
Earlier, a ROM patching program was mentioned. We're not there yet, but I've setup the beginnings of one at:
http://code.google.com/p/macrompatcher/
The idea behind this is to have a C library that has functions to apply known ROM modifications, and that library can then be used "wherever" for front ends to use for nice user friendly ROM modifications.
Ultimately, it'd be nice to have a cross platform GUI. That's not done yet.
At the moment, it just contains a library that applies the ROMdisk driver, and a posixy command line tool that uses it.
If anyone wants to contribute, let dougg3 or myself know and either of us can provide access. Feedback welcome.
http://code.google.com/p/macrompatcher/
The idea behind this is to have a C library that has functions to apply known ROM modifications, and that library can then be used "wherever" for front ends to use for nice user friendly ROM modifications.
Ultimately, it'd be nice to have a cross platform GUI. That's not done yet.
At the moment, it just contains a library that applies the ROMdisk driver, and a posixy command line tool that uses it.
If anyone wants to contribute, let dougg3 or myself know and either of us can provide access. Feedback welcome.
In other news, all the parts I need for the SIMM programmer (apart from the PCBs themselves) are here other than SIMM sockets--olePigeon and I are working together on that soon. Woohoo! So now I play the waiting game to see if the PCBs pass the manufacturing test with Seeed Studio.
In the process of building a couple more ROM SIMMs tonight, I accidentally lifted a pad on one of the PCBs
I had accidentally messed up one of the PLCC sockets so I had to remove it. I tried Chip-Quik and it worked great, but I think I pulled up with too much force (and perhaps had my iron set too hot) and the pad came right off...ughh. I'm now an official member of the pad lifter club.
In the process of building a couple more ROM SIMMs tonight, I accidentally lifted a pad on one of the PCBs
I had accidentally messed up one of the PLCC sockets so I had to remove it. I tried Chip-Quik and it worked great, but I think I pulled up with too much force (and perhaps had my iron set too hot) and the pad came right off...ughh. I'm now an official member of the pad lifter club.
LOL! I joined it over twenty years ago, welcome aboard. Just try to avoid the brotherhood of the magic smoke on your quest, DQ! [ 
bbraun, that sounds like you're still making tremendous progress, nice work. :approve:
bbraun, that sounds like you're still making tremendous progress, nice work. :approve:
LOL...I'm definitely taking all precautions necessary to avoid joining the magic smoke club
Here's an interesting tale. One of the SIMMs I assembled last night didn't work. I found a short, but it wasn't between two nearby pads or a pad and a via or anything like that. I searched over and over and over and couldn't find anything that looked bad. However, I could tell it had to be between a PLCC pad and a trace nearby it, because it was between two lines that are next to each other (when one line is at a PLCC pad, the other line's trace is running next to that pad, and vice versa at multiple spots on the SIMM). So I got frustrated last night and gave up.
I came back to it today. I ran a really low current through the short and measured the voltage at various places to see where the short was. You can see the voltage keep increasing at various points (or dropping, depending on which side you start from) as the current flows through the circuit, it's kind of cool. I pinpointed where the short should be, but couldn't find anything, I'm guessing because it was a board defect under the solder mask, near the PLCC pad and impossible to see under the socket.
Anyway, since I had nothing to lose, I ran about 3 amps at a low voltage through the short and suddenly it wasn't drawing any more current. The short is gone and the SIMM works fine now I zapped it!
Here's an interesting tale. One of the SIMMs I assembled last night didn't work. I found a short, but it wasn't between two nearby pads or a pad and a via or anything like that. I searched over and over and over and couldn't find anything that looked bad. However, I could tell it had to be between a PLCC pad and a trace nearby it, because it was between two lines that are next to each other (when one line is at a PLCC pad, the other line's trace is running next to that pad, and vice versa at multiple spots on the SIMM). So I got frustrated last night and gave up.
I came back to it today. I ran a really low current through the short and measured the voltage at various places to see where the short was. You can see the voltage keep increasing at various points (or dropping, depending on which side you start from) as the current flows through the circuit, it's kind of cool. I pinpointed where the short should be, but couldn't find anything, I'm guessing because it was a board defect under the solder mask, near the PLCC pad and impossible to see under the socket.
Anyway, since I had nothing to lose, I ran about 3 amps at a low voltage through the short and suddenly it wasn't drawing any more current. The short is gone and the SIMM works fine now
I zapped it!You blew it like a fuse, I guess.Anyway, since I had nothing to lose, I ran about 3 amps at a low voltage through the short and suddenly it wasn't drawing any more current. The short is gone and the SIMM works fine now
LOL! and the PCB contained the extra magical benevolent white smoke! 
)
)
Haha, yep! I did blow it like a fuse. I saw online that some people have had mixed success with the approach so I gave it a shot and it worked I hope it blew the short enough that it won't creep back in. I guess if it's under the solder mask that probably won't happen.
That's the kind of magic smoke that I like! :-D
I hope it blew the short enough that it won't creep back in. I guess if it's under the solder mask that probably won't happen.That's the kind of magic smoke that I like! :-D
The programmer PCBs just shipped. If my last UPS shipment is typical of what to expect, they should be arriving later this week.
I also just placed my (final) order for 100 ROM SIMM PCBs since I only have one of the rev. 2 boards left (aside from the one I lifted the pad on). I made one final change at the request of bbraun to make it easy to add a switch that allows you to change the mapping so you get either the top 1 MB or lower 1 MB of the ROM space. 100 of them should be enough to last us for a while!
Also, page 26
I also just placed my (final) order for 100 ROM SIMM PCBs since I only have one of the rev. 2 boards left (aside from the one I lifted the pad on). I made one final change at the request of bbraun to make it easy to add a switch that allows you to change the mapping so you get either the top 1 MB or lower 1 MB of the ROM space. 100 of them should be enough to last us for a while!
Also, page 26
goodie! I woudlnt mind having one of those with a SIMM to mod my SE/30.
Edit: Dumb question, What is the minimum block write size of the Flash ICs your using? Just wondering because i hope the AVR has enough RAM to buffer a block write. Well i guess it doesnt matter as long as the serial data can keep up.
Edit: Dumb question, What is the minimum block write size of the Flash ICs your using? Just wondering because i hope the AVR has enough RAM to buffer a block write. Well i guess it doesnt matter as long as the serial data can keep up.
Woohoo, I'm looking forward to these things!
Also, the SE/30 is fun to have a working image with the ROM SIMM. The SE/30 is the worst for access to the SIMM slot.
Also, the SE/30 is fun to have a working image with the ROM SIMM. The SE/30 is the worst for access to the SIMM slot.
Bump! And another page bites the dust! Bump! Bump!
I was wondering if the programmer would be able to handle something like reading the DeclROM of the Duo MiniDock (PLCC or some such) and then burning it onto a ROM compatible with the original DuoDock?
I have a sneeeeeeking suspicion that it may well work with the the little dog's bits installed, so's the Big Dog's Dock Services and the LCD would be enabled at the same time if booted in that config. We know that the NuBus ChipSet's function is independent of the Big Docks DeclROM because the slots work if it, or its power, are pulled.
Sooooo, the next step would be . . . [}] ]'>
I was wondering if the programmer would be able to handle something like reading the DeclROM of the Duo MiniDock (PLCC or some such) and then burning it onto a ROM compatible with the original DuoDock?
I have a sneeeeeeking suspicion that it may well work with the the little dog's bits installed, so's the Big Dog's Dock Services and the LCD would be enabled at the same time if booted in that config. We know that the NuBus ChipSet's function is independent of the Big Docks DeclROM because the slots work if it, or its power, are pulled.
Sooooo, the next step would be . . . [}
] ]'>
Cool Well it'll take a while to write the firmware for it! Haha. I have some electrical test code written and I'm anxious to test it out.
The chips are writable a byte at a time. They have to be erased in 128-byte sectors, though, but that's not a big deal.
I haven't thought a great deal about performance, so we'll see how that goes. I'm hoping I can fit a bootloader on it to allow for firmware updates over USB. Hopefully the USB stack (I'm thinking about using LUFA) won't use up all my resources.
The AVR I'm using is the AT90USB646, with 64K of flash and 4K of RAM. I think if that ends up not being enough, I can switch to the AT90USB1286, which would have 128K of flash and 8K of RAM. I'm pretty sure I can make it all work with the smaller chip though, assuming the USB stack isn't a huge memory hog.
No idea on the DeclROM compatibility. I suppose if it doesn't fit the pinout of the chips I'm using, you could run wires from the pin header to hook it up correctly...
Well it'll take a while to write the firmware for it! Haha. I have some electrical test code written and I'm anxious to test it out.The chips are writable a byte at a time. They have to be erased in 128-byte sectors, though, but that's not a big deal.
I haven't thought a great deal about performance, so we'll see how that goes. I'm hoping I can fit a bootloader on it to allow for firmware updates over USB. Hopefully the USB stack (I'm thinking about using LUFA) won't use up all my resources.
The AVR I'm using is the AT90USB646, with 64K of flash and 4K of RAM. I think if that ends up not being enough, I can switch to the AT90USB1286, which would have 128K of flash and 8K of RAM. I'm pretty sure I can make it all work with the smaller chip though, assuming the USB stack isn't a huge memory hog.
No idea on the DeclROM compatibility. I suppose if it doesn't fit the pinout of the chips I'm using, you could run wires from the pin header to hook it up correctly...