Thread
Another IIci ROM hack
Exciting! Sounds like it's getting close!
This is the first time I've had to go to the hacks forum to find this thread . . .
*********B*U*M*P*********
. . . whatever, I hope you're enjoying this joyous season ans not stressing over this project, DQ! That goes for the rest of you tech troops too! [
] ]'>
I was thinking about ways to program the larger ROMs for the DIMM Modules in my PowerMacs, especially my PEx and came up with a wild notion . . .
Back in the day, we used four 32k SRAM ICs to emulate the 32k and 64k EPROM ICs on out target cards. Huge advances have been made in memory of every kind in the intervening 22 years.
I'm most impressed with the SD and, especially, the tiny MicroSD Chiplets so . . .
Why not create a daughtercard for the problematic PowerMac ROM DIMM that addresses a Chiplet as the four ROM ICs on the 81/110 DIMMs I've been collecting for surgery?
In 1989, the SRAM was so much faster than the target ROMs that there was no problem with speed in the emulation process. The same ought to be the case for whatever circuitry would be necessary for the Memory I/O conversion to emulate the PowerMac ROM ICs using SD/MicroSD as a non-volatile substitute.
Dunno, just thought I'd throw that notion to the WarDawgs of the 68kMLA Tech Contingent for consideration . . .
. . . or ridicule . . . :?:
*********B*U*M*P*********
. . . whatever, I hope you're enjoying this joyous season ans not stressing over this project, DQ! That goes for the rest of you tech troops too! [
] ]'>I was thinking about ways to program the larger ROMs for the DIMM Modules in my PowerMacs, especially my PEx and came up with a wild notion . . .
Back in the day, we used four 32k SRAM ICs to emulate the 32k and 64k EPROM ICs on out target cards. Huge advances have been made in memory of every kind in the intervening 22 years.
I'm most impressed with the SD and, especially, the tiny MicroSD Chiplets so . . .
Why not create a daughtercard for the problematic PowerMac ROM DIMM that addresses a Chiplet as the four ROM ICs on the 81/110 DIMMs I've been collecting for surgery?
In 1989, the SRAM was so much faster than the target ROMs that there was no problem with speed in the emulation process. The same ought to be the case for whatever circuitry would be necessary for the Memory I/O conversion to emulate the PowerMac ROM ICs using SD/MicroSD as a non-volatile substitute.
Dunno, just thought I'd throw that notion to the WarDawgs of the 68kMLA Tech Contingent for consideration . . .
. . . or ridicule . . . :?:
It's been a while 
Yeah, I've just been taking it easy during the holidays! (Also, it doesn't help that the NBA season is back in full force distracting me with games spaced really close together now after the lockout...)
The latest update is really just that I've started making a bootloader and I think I have a pretty good solution to make the SIMM programmer unbrickable. When you first power up the board, it *always* goes into the bootloader and waits for a command -- either to re-flash the firmware or to "boot" the firmware. Normally the first command sent to it would be to boot into the firmware, and then it would accept commands for programming the SIMM.
If bad firmware somehow gets flashed that prevents the board from working, it's OK because the next time power is cycled, it's waiting in the (totally untouched) bootloader for commands, and it can be sent the "re-flash firmware" command instead of the "boot" command to replace the bad firmware. I'm just trying to make it so you cannot screw up the board no matter what you do (short of physically damaging it).
I could have also put a button on the board you hold down when you plug it in to force it into the bootloader, but I used every single GPIO pin for something on this board, and I didn't want to mess around with reusing one of the pins as a bootloader entry pin. This strategy of always entering the bootloader should work fine for a simple device that doesn't have any time sensitivity for booting up.
As for your ROM DIMM idea, I think it could be done -- load the contents of the SD card into RAM chips which then act as ROMs. I'm pretty sure the SD card is too slow to directly be the ROM, but loading the SD card's contents into RAM would work. I like it! It would be a lot simpler (I think) than making a ROM DIMM + ROM DIMM programmer board. The tough part I can think of off the top of my head would be loading the SD card contents into the RAM chips at power-up so that they are ready by the time the CPU needs to read the first instruction. We wouldn't have a lot of time to get everything loaded.
Yeah, I've just been taking it easy during the holidays! (Also, it doesn't help that the NBA season is back in full force distracting me with games spaced really close together now after the lockout...)The latest update is really just that I've started making a bootloader and I think I have a pretty good solution to make the SIMM programmer unbrickable. When you first power up the board, it *always* goes into the bootloader and waits for a command -- either to re-flash the firmware or to "boot" the firmware. Normally the first command sent to it would be to boot into the firmware, and then it would accept commands for programming the SIMM.
If bad firmware somehow gets flashed that prevents the board from working, it's OK because the next time power is cycled, it's waiting in the (totally untouched) bootloader for commands, and it can be sent the "re-flash firmware" command instead of the "boot" command to replace the bad firmware. I'm just trying to make it so you cannot screw up the board no matter what you do (short of physically damaging it).
I could have also put a button on the board you hold down when you plug it in to force it into the bootloader, but I used every single GPIO pin for something on this board, and I didn't want to mess around with reusing one of the pins as a bootloader entry pin. This strategy of always entering the bootloader should work fine for a simple device that doesn't have any time sensitivity for booting up.
As for your ROM DIMM idea, I think it could be done -- load the contents of the SD card into RAM chips which then act as ROMs. I'm pretty sure the SD card is too slow to directly be the ROM, but loading the SD card's contents into RAM would work. I like it! It would be a lot simpler (I think) than making a ROM DIMM + ROM DIMM programmer board. The tough part I can think of off the top of my head would be loading the SD card contents into the RAM chips at power-up so that they are ready by the time the CPU needs to read the first instruction. We wouldn't have a lot of time to get everything loaded.
Welcome back from R&R, trooper. I"m glad you've got something to do in between programming sessions (interminable commercial breaks) for relaxation! [
)] ]'>
Rats! I was hoping the chiplets have come far enough long in terms of response time to act as ROMs. That way I could do the PCB, now it sounds like a micro-controller will be necessary and that requirement puts the project way over my head. [
] ]'>
Is there some other kind of non-volatile memory slottage thingamahoozie available?
If not, battery backup for SRAM on the daughtercard will make it a real ROM emulator, just like the old days! [}] ]'>
Since you like the idea, at least I can get a start on the project. Depopulating a DIMM and turning it into a machine pin porky-pine for a wire wrap proto-emulator setup will do! [] ]'>
)] ]'>Rats! I was hoping the chiplets have come far enough long in terms of response time to act as ROMs. That way I could do the PCB, now it sounds like a micro-controller will be necessary and that requirement puts the project way over my head. [
] ]'>Is there some other kind of non-volatile memory slottage thingamahoozie available?
If not, battery backup for SRAM on the daughtercard will make it a real ROM emulator, just like the old days! [}
] ]'>Since you like the idea, at least I can get a start on the project. Depopulating a DIMM and turning it into a machine pin porky-pine for a wire wrap proto-emulator setup will do! [
] ]'>
Well, other than just the speed issue, SD cards use more of a serial communication scheme. It looks like you can get 4 bits at a time out of it for maximum performance, but even if the SD card access time was fast enough to get the data out in time to directly be the ROM, you'd still need something like a microcontroller to send the SD card commands and translate the resulting chunks of 4-bit data into 32-bit parallel data for the ROM emulation. So I guess my point is that either way we would need something like an MCU
I know there are chips out there (non-volatile SRAM) that are essentially RAM on top of Flash that automatically save the RAM contents to flash when power is removed (and load the RAM from the flash when power is applied), but they are very expensive, so that's probably not an option. I hate to put a battery in anything, but we may not have a choice...
PCB design for something like that is going to get tougher. I seem to recall someone saying that it's probably going to take a 4-layer board to do DIMM stuff...it's probably somewhere in this monster of a thread!
I know there are chips out there (non-volatile SRAM) that are essentially RAM on top of Flash that automatically save the RAM contents to flash when power is removed (and load the RAM from the flash when power is applied), but they are very expensive, so that's probably not an option. I hate to put a battery in anything, but we may not have a choice...
PCB design for something like that is going to get tougher. I seem to recall someone saying that it's probably going to take a 4-layer board to do DIMM stuff...it's probably somewhere in this monster of a thread!
That'd be to do a replacement DIMM, I'm talking about a KlugeCard that would socket onto the pads of depopulated stock DIMMs. Hence the soldering of machine pins (cones down) to all necessary signal pads on the DonorDIMM. There'd be matching machine pin sockets pointing down from the ProtoKluge.
Battery backup ought to be very simple, they did it on exceedingly small (compared to my four chip beast) ROM emulators back in the early nineties. IIRC, SRAM retains info until it's powered back on, which flushes it out. Battery backup avoids that, a few one way diodes and you're (hopefully) good to go using the Macs power when it's available. But a button cell ought to be good as the ONLY Power Source for the SRAM for quite some time.
Dunno . . . it's a great day for impossible dreamin' about the coming year's projects.
Battery backup ought to be very simple, they did it on exceedingly small (compared to my four chip beast) ROM emulators back in the early nineties. IIRC, SRAM retains info until it's powered back on, which flushes it out. Battery backup avoids that, a few one way diodes and you're (hopefully) good to go using the Macs power when it's available. But a button cell ought to be good as the ONLY Power Source for the SRAM for quite some time.
Dunno . . . it's a great day for impossible dreamin' about the coming year's projects.
Wow...it's been forever since I've posted here! I honestly have not touched this project since I last posted. I think my hobbyist side goes into hibernation during the winter months |) Don't worry, I haven't forgotten about the project and still intend on finishing it soon.
I finally got around to working on the SIMM programmer today. I've got it mostly working aside from a few bugs. The UI is not very elegant but works. I really just want it to the point where it reliably reads from and writes to the SIMM over USB and can accept firmware upgrades over USB. Once it's at that point, the user interface prettification. detailed error checking, RS-232, etc. can be added in later. I'm pretty close to having the basic feature set done now. Just have a few kinks to work out. Stay tuned for more soon!
Meanwhile, I have a lot of sweet hack projects to catch up on in this forum now!
I finally got around to working on the SIMM programmer today. I've got it mostly working aside from a few bugs. The UI is not very elegant but works. I really just want it to the point where it reliably reads from and writes to the SIMM over USB and can accept firmware upgrades over USB. Once it's at that point, the user interface prettification. detailed error checking, RS-232, etc. can be added in later. I'm pretty close to having the basic feature set done now. Just have a few kinks to work out. Stay tuned for more soon!
Meanwhile, I have a lot of sweet hack projects to catch up on in this forum now!
Can't wait.
Same here! I look forward to that programmer and everything that enables.
Got a lot of cleanup work done on the SIMM programming firmware/software this weekend. I wrote the PC controlling software for it using Qt, which allows me to use one codebase to compile an app for Windows, Linux, and OS X. It's working pretty well in Windows right now, but not yet tested in Linux or Mac OS X (hopefully soon--I anticipate it will need some fixes before it works on all three platforms flawlessly). There are still some issues to work out, but I'm getting close to having the SIMM programmer board ready to go.
I've uploaded all of the bootloader, firmware, and PC controlling software code to a Google Code project for everyone to peek at:
http://code.google.com/p/mac-rom-simm-programmer/
It's getting exciting!
I've uploaded all of the bootloader, firmware, and PC controlling software code to a Google Code project for everyone to peek at:
http://code.google.com/p/mac-rom-simm-programmer/
It's getting exciting!
Great, welcome back! It was beginning to get boring around here without you and your mega-thread even showing up in the "Active" category for so long. )
edit: speaking of mega-threads PAGE 29! :O
) edit: speaking of mega-threads PAGE 29! :O
Gah! That anticipation is killing me! :lol:
More progress, and I'm pretty much ready to take orders! I built two SIMM programmer boards today and they both work fine...woohoo!
I've got the control program working on OS X 10.7, 10.6, Windows 7, and Ubuntu Linux 12.04. Ideally I'd also like to make it work on OS X 10.5 and 10.4. I'll see how well Qt can handle it, but no guarantees. The software should work fine on older versions of Windows and Ubuntu. The bootloader firmware seems to be rock solid, so I am pretty comfortable sending boards out to people now (although it helps if you have an AVR ISP programmer just in case we need to change something in the bootloader later on). The board is unbrickable. If you flash bad firmware on it, it's OK because it always starts up in bootloader mode and then jumps to the actual SIMM programmer firmware after the control program tells it to. This is kind of strange because it will actually disconnect the USB connection, jump to the programmer board firmware, and then reconnect the USB the first time you talk to it after plugging it in, but that process seems to work just fine in every OS I've tried.
I anticipate we will run into minor glitches as the software gets tested on various people's setups, so if you're interested in one, be prepared to take some time to work with me to make it work.
I'm not mounting any of the RS-232 hardware right now -- just sticking with USB. This lowers the cost of the parts for one, and you need a USB port to power it anyway, so you might as well use USB to communicate with it. USB is faster than 115200 bps serial, which is probably what your serial port supports at max. Plus, I don't have any software written for the RS-232 port anyway
The cost of the programmer board is going to be $40. It's not so much the cost of the parts (about $15 per board and over half of that is just the microcontroller + PCB), but the labor it takes to assemble this beast. There are various small parts and some of them are crammed pretty close together, so it takes some serious time to assemble it all compared to the SIMM, which is easy because it's basically doing the same thing 4 times with very few parts.
I'll have binaries of the programmer software ready for download really soon, so you can at least open it and make sure it runs on your computer. The board will work out of the box without any drivers in OS X and Linux. Linux will need a small udev rule installed to set the serial port permissions though. Windows needs a very simple INF to tell it to load its built-in USB CDC modem driver.
Anyway, for everyone who's interested in a programmer board ($40 plus $5 shipping to USA), SIMM ($20 plus $5 shipping to USA), or both (combine the shipping together so you pay $5 total for shipping), let me know via PM so I can get an idea of how many programmer boards I need to build for the first batch. (I have several SIMMs already built up and ready to ship whenever, if anybody cares.) The programmer boards are easier to build in batches because of how many different parts there are to get out from my stash...
Remember, the programmer board will be compatible with any SIMM I built that has the red LEDs with olePigeon's graphic. The first board revision which did not have those is not compatible with the programmer board.
Last but not least, THANK YOU olePigeon for finding a source for the 64-pin SIMM sockets. All of the sockets I've tried so far have worked fine. Without you, this project would have been much more difficult to realize!
I've got the control program working on OS X 10.7, 10.6, Windows 7, and Ubuntu Linux 12.04. Ideally I'd also like to make it work on OS X 10.5 and 10.4. I'll see how well Qt can handle it, but no guarantees. The software should work fine on older versions of Windows and Ubuntu. The bootloader firmware seems to be rock solid, so I am pretty comfortable sending boards out to people now (although it helps if you have an AVR ISP programmer just in case we need to change something in the bootloader later on). The board is unbrickable. If you flash bad firmware on it, it's OK because it always starts up in bootloader mode and then jumps to the actual SIMM programmer firmware after the control program tells it to. This is kind of strange because it will actually disconnect the USB connection, jump to the programmer board firmware, and then reconnect the USB the first time you talk to it after plugging it in, but that process seems to work just fine in every OS I've tried.
I anticipate we will run into minor glitches as the software gets tested on various people's setups, so if you're interested in one, be prepared to take some time to work with me to make it work.
I'm not mounting any of the RS-232 hardware right now -- just sticking with USB. This lowers the cost of the parts for one, and you need a USB port to power it anyway, so you might as well use USB to communicate with it. USB is faster than 115200 bps serial, which is probably what your serial port supports at max. Plus, I don't have any software written for the RS-232 port anyway
The cost of the programmer board is going to be $40. It's not so much the cost of the parts (about $15 per board and over half of that is just the microcontroller + PCB), but the labor it takes to assemble this beast. There are various small parts and some of them are crammed pretty close together, so it takes some serious time to assemble it all compared to the SIMM, which is easy because it's basically doing the same thing 4 times with very few parts.
I'll have binaries of the programmer software ready for download really soon, so you can at least open it and make sure it runs on your computer. The board will work out of the box without any drivers in OS X and Linux. Linux will need a small udev rule installed to set the serial port permissions though. Windows needs a very simple INF to tell it to load its built-in USB CDC modem driver.
Anyway, for everyone who's interested in a programmer board ($40 plus $5 shipping to USA), SIMM ($20 plus $5 shipping to USA), or both (combine the shipping together so you pay $5 total for shipping), let me know via PM so I can get an idea of how many programmer boards I need to build for the first batch. (I have several SIMMs already built up and ready to ship whenever, if anybody cares.) The programmer boards are easier to build in batches because of how many different parts there are to get out from my stash...
Remember, the programmer board will be compatible with any SIMM I built that has the red LEDs with olePigeon's graphic. The first board revision which did not have those is not compatible with the programmer board.
Last but not least, THANK YOU olePigeon for finding a source for the 64-pin SIMM sockets. All of the sockets I've tried so far have worked fine. Without you, this project would have been much more difficult to realize!
Yay! I participated! )
) In case anybody's bored and wants to try the software, I have uploaded Windows binaries for the control program. You won't be able to do anything with it yet except look at the about box, but the software is functional underneath once an actual programmer board is plugged in. It also includes a firmware binary and a driver INF file. If you're interested in using the programmer board with a Windows machine, you should download this program and make sure it runs OK on your computer...
http://code.google.com/p/mac-rom-simm-programmer/downloads/list
Tested on Windows XP 32-bit and Windows 7 32- and 64-bit.
Linux and Mac OS X binaries coming soon...
For those of you who PM'ed me, I built programmer boards yesterday and today, so I'll be getting ahold of you very soon!
Would it be possible to load device drivers into the ROM so you can boot from them? Devices like Jaz drives, MO drives, etc. I can boot from them if I use my Jackhammer card, but not from the internet SCSI bus. Doesn't like them.
Have you tried booting from one of these drives manually by holding Apple+option+shift+delete at startup? The drives you mentioned may take too long at power-on and the Mac gives up looking for them, finding instead your internal hard drive. That key combo prevents booting from SCSI ID 0 for as long as you hold it down.
Yeah, I just get blinking floppy (or in my case, skull and crossbones.)
Okay, good info. Just a couple of ideas that popped to mind from that:
Try the IIfx ROM
Format the Jaz drive with different programs, i.e. HD SC setup, FWB hard disk toolkit, possibly a special program just for that type of drive
I'm thinking that the hard disk drivers are not boot-compatible with these drives on your built-in SCSI bus for some reason. The ROM is set up to use a driver form the device itself except for floppies. For example, burned CDs with blessed system folders won't boot unless the CD is also burned with a disk driver. (Pre-OS X versions of Toast can do this.)
I think that the key to this problem is in that driver, maybe trying a few different formatters might make something work. I suppose there's a SLIGHT chance of a termination problem, I don't know - I've seen stranger things from terminators. It's bizarre that it works on your SCSI card and not built-in SCSI, I'm stuck on that detail.
I wonder if it could be a SCSI-1 vs SCSI-2 sort of thing?
Try the IIfx ROM
Format the Jaz drive with different programs, i.e. HD SC setup, FWB hard disk toolkit, possibly a special program just for that type of drive
I'm thinking that the hard disk drivers are not boot-compatible with these drives on your built-in SCSI bus for some reason. The ROM is set up to use a driver form the device itself except for floppies. For example, burned CDs with blessed system folders won't boot unless the CD is also burned with a disk driver. (Pre-OS X versions of Toast can do this.)
I think that the key to this problem is in that driver, maybe trying a few different formatters might make something work. I suppose there's a SLIGHT chance of a termination problem, I don't know - I've seen stranger things from terminators. It's bizarre that it works on your SCSI card and not built-in SCSI, I'm stuck on that detail.
I wonder if it could be a SCSI-1 vs SCSI-2 sort of thing?
Just a quick update to this project -- I have all source code, schematics, and PCB layouts for this whole project available for download now. You can find it all at the Google Code project:
http://code.google.com/p/mac-rom-simm-programmer/
In case anyone doesn't know, I'm now selling the programmable ROM SIMMs and the SIMM programmer. Again, just to be clear, I can't flash custom ROM images for you, but now you can do everything yourself with the SIMM programmer, or if you have an EEPROM burner you can use that.
The SIMM programmer requires a USB connection and is compatible with: Windows XP and later, Mac OS X 10.5 (Intel) and later, and Linux (you'll have to compile it yourself for Linux though). The SIMM should work in any of the following Mac models: SE/30, IIx, IIcx, IIci, IIfx, IIsi, and Quadra 700.
SIMMs cost $24 (including 4 chips) and the programmer costs $40. I have a ton of raw SIMM PCBs available, so if you want to try the challenge of building it yourself, I'll sell the unpopulated SIMM PCB for $5 (soldering the PLCC sockets is NOT fun though, just a warning). Shipping is $5 within the USA for your total order. Shipping outside the USA costs more--ask me and I'll check. I'll make a post in the Trading Post about this too.
http://code.google.com/p/mac-rom-simm-programmer/
In case anyone doesn't know, I'm now selling the programmable ROM SIMMs and the SIMM programmer. Again, just to be clear, I can't flash custom ROM images for you, but now you can do everything yourself with the SIMM programmer, or if you have an EEPROM burner you can use that.
The SIMM programmer requires a USB connection and is compatible with: Windows XP and later, Mac OS X 10.5 (Intel) and later, and Linux (you'll have to compile it yourself for Linux though). The SIMM should work in any of the following Mac models: SE/30, IIx, IIcx, IIci, IIfx, IIsi, and Quadra 700.
SIMMs cost $24 (including 4 chips) and the programmer costs $40. I have a ton of raw SIMM PCBs available, so if you want to try the challenge of building it yourself, I'll sell the unpopulated SIMM PCB for $5 (soldering the PLCC sockets is NOT fun though, just a warning). Shipping is $5 within the USA for your total order. Shipping outside the USA costs more--ask me and I'll check. I'll make a post in the Trading Post about this too.
These are awesome by the way. The programmer makes things much easier than popping and programming the 4 chips individually.
I've been using it extensively on 10.6 to refine the romdisk concept. Using the IIsi ROM in a IIx, it can boot from a 1.5MB image when holding down the 'r' key. Details here: http://synack.net/~bbraun/macromboot.html
I've been using it extensively on 10.6 to refine the romdisk concept. Using the IIsi ROM in a IIx, it can boot from a 1.5MB image when holding down the 'r' key. Details here: http://synack.net/~bbraun/macromboot.html
Very nice work -- both to Dougg3 and to Bbraun.
Doug, it's been said, but it bears repeating. That's a nicely developed product.
Rob, I just read your linked page. I saw your initial posts here, but didn't realize you had done all that development. Wow. Also, in case I forgot to say it before, thank you, thank you, thank you for your coding help with the PEx ROM project. I have a weekend coming up with the family will be out of town and I might actually get to put the code into chips and solder it down.
Doug, it's been said, but it bears repeating. That's a nicely developed product.
Rob, I just read your linked page. I saw your initial posts here, but didn't realize you had done all that development. Wow. Also, in case I forgot to say it before, thank you, thank you, thank you for your coding help with the PEx ROM project. I have a weekend coming up with the family will be out of town and I might actually get to put the code into chips and solder it down.
Very nice work bbraun! I'd like to try your hack once I get a programmer.
I was wondering, does code in the ROM give the disk image a disk icon, hard disk, RAM disk, or something that can be defined with a formatting utility? How's the boot-up speed?Also, you noted you used a 512KB disk image, but that you can go up to 1.5MB (provided there's room on the ROM), does there need to be additional tweaks to the patcher to go up to 1.5MB?
This code doesn't provide any icon, and the system just uses the default floppy disk icon. I did this because I was trying to fit the driver within 580 bytes, which is the size of the .netBOOT driver I was replacing. However, by adjusting the resource layout and replacing both the .netBOOT and .ATBOOT drivers, I'm up to about 1152 bytes (plus or minus some resource header space). This could be used to provide custom icons, although I've also got some additional functionality I'd like to squeeze in as well, so we'll see how it goes.
You might be able to provide a custom volume icon just by replacing the icon in the Get Info dialog, when you're creating the image. I haven't tried that, it might be a good compromise solution.
Boot up speed is fast with 6.0.8 on the IIx. I haven't quantified anything, but I guess I should make a video or something.
Originally, I was using a 512KB disk image because in my early experiments with replacing the floppy driver, I had problems and believed I couldn't access beyond 1MB of ROM (512KB IIsi ROM + 512KB disk image). Maybe I was wrong or maybe it doesn't apply the the IIsi ROM (I was initially using the IIx ROM). But either way, there's nothing special necessary to use the full 2MB of the ROM SIMM (512KB for IIsi ROM, 1.5MB for disk image). The driver has a hard coded constant of how big the disk image is, and that needs to match reality. The ROM Patcher I provided expects a 1.5MB disk image, while the other stuff there used a 512KB disk image.
I had some visions of checking for additional keys held down and optionally instead of a ROM disk, copy the disk image into RAM and boot from that. That'd allow a writeable boot disk, which opens up some additional possibilities. But there are some challenges there, so I'm not sure.
You might be able to provide a custom volume icon just by replacing the icon in the Get Info dialog, when you're creating the image. I haven't tried that, it might be a good compromise solution.
Boot up speed is fast with 6.0.8 on the IIx. I haven't quantified anything, but I guess I should make a video or something.
Originally, I was using a 512KB disk image because in my early experiments with replacing the floppy driver, I had problems and believed I couldn't access beyond 1MB of ROM (512KB IIsi ROM + 512KB disk image). Maybe I was wrong or maybe it doesn't apply the the IIsi ROM (I was initially using the IIx ROM). But either way, there's nothing special necessary to use the full 2MB of the ROM SIMM (512KB for IIsi ROM, 1.5MB for disk image). The driver has a hard coded constant of how big the disk image is, and that needs to match reality. The ROM Patcher I provided expects a 1.5MB disk image, while the other stuff there used a 512KB disk image.
I had some visions of checking for additional keys held down and optionally instead of a ROM disk, copy the disk image into RAM and boot from that. That'd allow a writeable boot disk, which opens up some additional possibilities. But there are some challenges there, so I'm not sure.
Thanks for explaining, just wondering how the hack works from a user perspective since I haven't seen it yet. A video would probably clarify, but if it takes time away from coding... 8-o
Applying an icon within System 6/7 probably makes the most sense. I was curious how the system treats the disk image, and it sounds like the answer is a floppy. In the code's current state, is the disk image kept in the ROM or is it loaded into RAM as read-only? I'm guessing if it stays in ROM, then it's probably a bit slower when read than being stored in RAM, but would save RAM space.
Applying an icon within System 6/7 probably makes the most sense. I was curious how the system treats the disk image, and it sounds like the answer is a floppy. In the code's current state, is the disk image kept in the ROM or is it loaded into RAM as read-only? I'm guessing if it stays in ROM, then it's probably a bit slower when read than being stored in RAM, but would save RAM space.
I made a video a while back of an early version of bbraun's ROM disk hack on a IIci:
The main delay is the RAM test, I think. If we can get that disabled, I'm pretty sure it'll boot REALLY fast. Once the Happy Mac comes up, you're almost instantly to the Desktop at least with System 6...
The main delay is the RAM test, I think. If we can get that disabled, I'm pretty sure it'll boot REALLY fast. Once the Happy Mac comes up, you're almost instantly to the Desktop at least with System 6...
Nice, yes it is very fast after the happy Mac appears. I haven't booted a IIci before... what is the initial delay (from switch flip to blank screen getting populated) before the RAM test? It seems to be as long as the RAM test (gray screen). How much RAM is installed?
I don't know for sure what causes each delay, but this IIci has 32 MB of RAM I think.
bbraun: I tried your patch onto a IIsi ROM (ran the patcher utility), appended a 1.5 MB disk image to the end of the resulting file, and burned it to my SIMM, but for some reason, it causes a Sad Mac and chimes of death in my IIci. :-(
bbraun: I tried your patch onto a IIsi ROM (ran the patcher utility), appended a 1.5 MB disk image to the end of the resulting file, and burned it to my SIMM, but for some reason, it causes a Sad Mac and chimes of death in my IIci. :-(
Well, a bit of disappointing news it looks like.
The 1MB restriction seems to be real. The 1.5MB image works because all the bootable bits were in the first 512KB (first 1MB of ROM overall).
I'll go back to playing with it and see if there's much I can do.
Thanks for the testing!
The 1MB restriction seems to be real. The 1.5MB image works because all the bootable bits were in the first 512KB (first 1MB of ROM overall).
I'll go back to playing with it and see if there's much I can do.
Thanks for the testing!
Oh bummer, it looks like the IIci has only clearly supports 1 MB of address space for ROM:
http://developer.apple.com/legacy/mac/library/documentation/Hardware/Developer_Notes/Macintosh_CPUs-68K_Desktop/Mac_IIci.pdf
Another thing to consider is that in 32-bit mode, there seems to be about a gigabyte of address space after the ROM before running into the I/O space at 0x5000 0000. Although we're using a "32-bit clean" ROM for these cool adventures, it may be that the ROM starts in 24-bit mode and automatically switches over - after the creation of this super awesome ROM disk.
Can we verify that the Mac boots in 32-bit mode with the ROM disk? Maybe something is tripping this up, or maybe running System 6 puts it back into 24-bit mode, etc??
dougg3 - Do I recall that you were able to use more than 1MB ROM for one of your startup sounds? If so, this is a very important clue.
http://developer.apple.com/legacy/mac/library/documentation/Hardware/Developer_Notes/Macintosh_CPUs-68K_Desktop/Mac_IIci.pdf
Interestingly, the address space directly after that spills into NuBus slot $9 in 24-bit mode, and that NuBus slot does not exist in the IIci. So it's possible that it could still work. We had a little quirk with deciding whether or not to skip a bit in the ROM slot when dougg3 was making his awesome SIMM - it was not clear if the actual address lines included this bit or not. This could be causing the ceiling we're seeing, either that or there is some logic on the board that enables the ROM's /OE pin only if the address bus is specifically valid for the ROM range in the document above.
Another thing to consider is that in 32-bit mode, there seems to be about a gigabyte of address space after the ROM before running into the I/O space at 0x5000 0000. Although we're using a "32-bit clean" ROM for these cool adventures, it may be that the ROM starts in 24-bit mode and automatically switches over - after the creation of this super awesome ROM disk.
Can we verify that the Mac boots in 32-bit mode with the ROM disk? Maybe something is tripping this up, or maybe running System 6 puts it back into 24-bit mode, etc??
dougg3 - Do I recall that you were able to use more than 1MB ROM for one of your startup sounds? If so, this is a very important clue.