Thread
Another IIci ROM hack
That's kind of what I'm worried about too. At this point moving the microcontroller out of the way to make more space for the USB connector would require many changes...
I agree with ojfd, I think it would be easier just to make an enclosure bigger on that side so the USB connector would be flush. I knew the USB connector would overhang over the side of the board--I did it on purpose to give myself more board space. I have a microcontroller dev board that does it, too.
The other option would be to make the board a bit bigger, but unfortunately the board height is already at the limit for EAGLE light edition
Anyway thanks for the idea jt, but I think I'm going to have to leave that alone at this point. I'd be happy to do it if it was as simple as moving the DB-9 would be, but it's not
I agree with ojfd, I think it would be easier just to make an enclosure bigger on that side so the USB connector would be flush. I knew the USB connector would overhang over the side of the board--I did it on purpose to give myself more board space. I have a microcontroller dev board that does it, too.
The other option would be to make the board a bit bigger, but unfortunately the board height is already at the limit for EAGLE light edition
Anyway thanks for the idea jt, but I think I'm going to have to leave that alone at this point. I'd be happy to do it if it was as simple as moving the DB-9 would be, but it's not
I meant to the right and up, no moving of the microcontroller, just the crystal can a smidge.
I know I'm nit-picking after the fact, but it pays to ask, the only stupid question . . .
It's still
as all getout, DQ! :approve:
I know I'm nit-picking after the fact, but it pays to ask, the only stupid question . . .
It's still
as all getout, DQ! :approve: :lol: I've heard that one, but I prefer R.A.Heinleins quip: An elephant is just a mouse built to government spec! :approve:Otherwise, you know what they say about the camel? It is a horse designed by the committee. [] ]'>
Thanks jt 
It's hard to see in the 3D model, but I have the crystal positioned in such a way that both wires to it are the same length, and moving it around would be problematic. Also I have other wires routed where the USB connector would go. I think I'm going to have to leave it as is...like you said, definitely doesn't hurt to ask though
It's hard to see in the 3D model, but I have the crystal positioned in such a way that both wires to it are the same length, and moving it around would be problematic. Also I have other wires routed where the USB connector would go. I think I'm going to have to leave it as is...like you said, definitely doesn't hurt to ask though
Whats the Microchip IC for? I understand what the AVR is for, but the microchip IC? just curious. it was probably explained several pages back, but going through a several page thread is not easy.
It's a 16-bit SPI GPIO expander chip that I used because the AVR does not have enough IO pins to handle all the data and address lines on the SIMM. I wanted to make sure I used something that has both input and output capabilities as well as pull-ups so that I can also use the board to run some basic tests on newly-assembled SIMM PCBs to find any shorts
All the lines attached to the SIMM (on both the microcontroller and the GPIO expander) have optional pull-up resistors, so I should be able to check if they are shorted to ground by setting them all as inputs, turning on the pull-ups, and making sure none of them read a 0. I should also be able to test for any shorts between pins by setting one pin as an output outputting a 0, and everything else as an input with the pull-up activated. If anything reads back as a 0, it would mean it's shorted to the same line I set as an output. As far as I can tell the only short I won't be able to detect will be a short to VCC, since I don't have pull-down resistors available. Anyway, I wouldn't have thought to do this crazy stuff, but after assembling the SIMMs and fighting shorts, I'm thinking it will be a useful tool to have.
Status update: The OCD in me just finished fixing all traces that were not exactly a multiple of 45 degrees. I'm thinking I'm going to send the first batch off to Seeed Studio tonight...
Status update 2: The gerber files have been sent to Seeed Studio. I went for UPS shipping again Can't wait!
All the lines attached to the SIMM (on both the microcontroller and the GPIO expander) have optional pull-up resistors, so I should be able to check if they are shorted to ground by setting them all as inputs, turning on the pull-ups, and making sure none of them read a 0. I should also be able to test for any shorts between pins by setting one pin as an output outputting a 0, and everything else as an input with the pull-up activated. If anything reads back as a 0, it would mean it's shorted to the same line I set as an output. As far as I can tell the only short I won't be able to detect will be a short to VCC, since I don't have pull-down resistors available. Anyway, I wouldn't have thought to do this crazy stuff, but after assembling the SIMMs and fighting shorts, I'm thinking it will be a useful tool to have.
Status update: The OCD in me just finished fixing all traces that were not exactly a multiple of 45 degrees. I'm thinking I'm going to send the first batch off to Seeed Studio tonight...
Status update 2: The gerber files have been sent to Seeed Studio. I went for UPS shipping again
Can't wait!Mazel Tov! [Status update: The OCD in me just finished fixing all traces that were not exactly a multiple of 45 degrees. I'm thinking I'm going to send the first batch off to Seeed Studio tonight...
Status update 2: The gerber files have been sent to Seeed Studio. I went for UPS shipping again
] ]'>I really have to do some work on the index . . . or . . . any volunteers here want to hunt down and post a batch of links to the important sub-threads? :?:
If you do it in PM to me, it won't ever be seen as tooting your own horn, all you folks have been awesome and I'd like to document your content creation and achievements!
Links to tangential threads would be much appreciated as well, BMOW's "showed up to get involved there" thread posted by Bunsen comes to mind: Plus Too: a DIY Mac clone project (128k -> Plus) That's one I've dug up myself, IIRC he's been posting in here about his incredible project since the last posts in there on Oct. 11th!
I've been home sick . . . not up to a whole lot . . . and a bit (creatively) lazy to boot . . .
. . . besides, procrastination ofttimes pays! }
edit: that was appropriate, this post just rolled us over to p.24! :O Somebody help out with the indexing . . . please!
edit 2: had to quote for context, this is a watershead moment in Mac Hackin' History!
A tool to program the the Jolly Roger SIMMs that's built to test them in production as well.
I think you're up to four layers of hacking here, DQ!
. . . yet another windmill grudgingly crumples to the ground!
)
ah ok. so its basically like a SPI based shift-register. Well, sorta. hehe.
With this programmer, at least youll be able to keep the PLCC ICs soldered down onto the SIMM without needing the sockets.
With this programmer, at least youll be able to keep the PLCC ICs soldered down onto the SIMM without needing the sockets.
It has been a couple days since there has been a a ROMDisk update, so... What I've learned so far from the ROMDisk driver in ROM experiment:
System 6 boots in 24bit addressing mode, at least initially. In 24bit addressing mode, ROM is located at 0x00800000, so pointing the ROM disk driver at 0x40880000 could result in garbage reads. Even though the ROM boots and refers to its self at 0x40800000, 0x00800000 is apparently always mapped, so just changing where the ROM disk driver points fixes that particular issue, and seems to reliably boot to Finder.
My speculation is that the II/IIx/SE30 ROMs were a transition from 24 to 32bit addressing, since the ROMs themselves map to 0x40800000 (the start address for the II ROM is 0x4080002A), but are not consistent in the use of the new 32bit mapping, for example when the ROM loads the DRVR resources, the pointers it returns are in the 0x00800000 range. System 6 boots initially in 24bit addressing mode with reads from 0x40800000 returning garbage, then loads a 'ptch' resource to move into using the newer ROM mappings.
It is not necessary to do a PostEvent(diskEvt, drvNum) for the boot drive, adding it to the Drive Queue is sufficient. When the ROM goes to look for bootable drives, it traverses the Drive Queue, mounts the selected drive, and records the bootdrive number at 0x210. The System picks all this up and runs with it. Only drives that are not the boot drive will then need to post the diskEvt event to get mounted. Subsequent diskEvts for mounted disks are ignored.
Once in Finder, I still have the problem of no cursor movement. As I noted before, the rawmouse low global gets updated, so it looks like interrupts are working, but the CrsrTask isn't getting called. Either it never gets added or something is removing it. I'm leaning towards the removal theory. If I check out the VBL queue once in the Finder, it has 2 entries in it: the Sound driver's VBL task, and another task located in RAM that I'm not too sure about. If I use macsbug and steal an existing VBL queue entry (such as my own), and put the crsrtask address in the VBL queue ptr element, CrsrTask gets run (the cursor is updated), and it works for some short period of time (fractions of a second or so), then that VBL queue element is removed. So, it's possible CrsrTask is removing its own task for some reason.
I'm (somewhat intentionally) not fully emulating the .Sony floppy driver, although at this point I have implemented almost all of the Control and Status entries of the floppy driver. Some of them don't make much sense for the ROM disk (I'm an HD20 with 1024 sectors, because I'm not 400/800/720/etc). The floppy driver installs a VBL task on Open, which seems to poll the floppy for disk insertion, update the SonyVars low global, and fire off a PostEvent(diskEvt) to mount the disk. This isn't particularly relevant for the ROM disk, since it's always attached, but I've tried adding my own VBL task and posting one diskEvt event (subsequent diskEvt events for a mounted disk will be ignored, but no need to do it repeatedly). After boot, I can find my VBL task in the VBL queue, but it makes no difference on the rest of the behavior.
Another thing that's weird about the floppy driver is it has memory at 0x222 which contains pointers to its own Prime/Control/Status and other routines. I'm not touching this space, and it's all initialized to 0xff, except I've noticed some of them are populated with valid looking addresses after boot. Disassembling the code at these addresses, it looks like the System is calling through to the ROM driver's code, then catching the return value and calling off to do something else in specific instances. This should be all harmless, since it appears to require the ROM driver calling these patched routines, which mine doesn't. But, it might be an interesting vector to experiment with bigmessowires' arbitrary sized floppies.
So, I'm trying to figure out the VBL task eater, and what I'm not doing to satisfy it...
System 6 boots in 24bit addressing mode, at least initially. In 24bit addressing mode, ROM is located at 0x00800000, so pointing the ROM disk driver at 0x40880000 could result in garbage reads. Even though the ROM boots and refers to its self at 0x40800000, 0x00800000 is apparently always mapped, so just changing where the ROM disk driver points fixes that particular issue, and seems to reliably boot to Finder.
My speculation is that the II/IIx/SE30 ROMs were a transition from 24 to 32bit addressing, since the ROMs themselves map to 0x40800000 (the start address for the II ROM is 0x4080002A), but are not consistent in the use of the new 32bit mapping, for example when the ROM loads the DRVR resources, the pointers it returns are in the 0x00800000 range. System 6 boots initially in 24bit addressing mode with reads from 0x40800000 returning garbage, then loads a 'ptch' resource to move into using the newer ROM mappings.
It is not necessary to do a PostEvent(diskEvt, drvNum) for the boot drive, adding it to the Drive Queue is sufficient. When the ROM goes to look for bootable drives, it traverses the Drive Queue, mounts the selected drive, and records the bootdrive number at 0x210. The System picks all this up and runs with it. Only drives that are not the boot drive will then need to post the diskEvt event to get mounted. Subsequent diskEvts for mounted disks are ignored.
Once in Finder, I still have the problem of no cursor movement. As I noted before, the rawmouse low global gets updated, so it looks like interrupts are working, but the CrsrTask isn't getting called. Either it never gets added or something is removing it. I'm leaning towards the removal theory. If I check out the VBL queue once in the Finder, it has 2 entries in it: the Sound driver's VBL task, and another task located in RAM that I'm not too sure about. If I use macsbug and steal an existing VBL queue entry (such as my own), and put the crsrtask address in the VBL queue ptr element, CrsrTask gets run (the cursor is updated), and it works for some short period of time (fractions of a second or so), then that VBL queue element is removed. So, it's possible CrsrTask is removing its own task for some reason.
I'm (somewhat intentionally) not fully emulating the .Sony floppy driver, although at this point I have implemented almost all of the Control and Status entries of the floppy driver. Some of them don't make much sense for the ROM disk (I'm an HD20 with 1024 sectors, because I'm not 400/800/720/etc). The floppy driver installs a VBL task on Open, which seems to poll the floppy for disk insertion, update the SonyVars low global, and fire off a PostEvent(diskEvt) to mount the disk. This isn't particularly relevant for the ROM disk, since it's always attached, but I've tried adding my own VBL task and posting one diskEvt event (subsequent diskEvt events for a mounted disk will be ignored, but no need to do it repeatedly). After boot, I can find my VBL task in the VBL queue, but it makes no difference on the rest of the behavior.
Another thing that's weird about the floppy driver is it has memory at 0x222 which contains pointers to its own Prime/Control/Status and other routines. I'm not touching this space, and it's all initialized to 0xff, except I've noticed some of them are populated with valid looking addresses after boot. Disassembling the code at these addresses, it looks like the System is calling through to the ROM driver's code, then catching the return value and calling off to do something else in specific instances. This should be all harmless, since it appears to require the ROM driver calling these patched routines, which mine doesn't. But, it might be an interesting vector to experiment with bigmessowires' arbitrary sized floppies.
So, I'm trying to figure out the VBL task eater, and what I'm not doing to satisfy it...
Woohoo!!!I think you're up to four layers of hacking here, DQ!. . . yet another windmill grudgingly crumples to the ground!
I think if any indexing happens, it won't be me doing it for a while. My brain is fried from all the PCB layout work I did this weekend, haha. 8-o xx( |) Just ordered parts...I got enough of the cheap parts (capacitors, resistors) for 25 boards, but only a few of the expensive parts (the ICs) until I get an idea of how much interest there is in the programmer board. Exciting!
Yep, exactly! Just a little more powerful since it's configurable as input/output on a per-pin basis
Yep! Although some people may still want sockets because it will technically be possible to use the programmer as a burner for any chips with a matching pinout for any purpose...With this programmer, at least youll be able to keep the PLCC ICs soldered down onto the SIMM without needing the sockets.
Edit: And great to see an update bbraun! Hmm...I'd try to help with the VBL task problem but I don't know anything about the system internals.
That's so strange that the ROM disk interferes with the mouse cursor task. Would it possible to use the debugger to catch when the queue element is removed, and then work backwards to see what code is removing it?
Does your ROM disk driver replace the floppy driver, or work independently of it?
I kind of want to get a IIci now, just so I can try out some hacking with dougg3's ROM!
Edit: Could you load your modified ROM image into a Mac emulator like Basilisk II? Then you could single-step and examine all the machine state you could ever want.
Here's the book on PCB Deisgn used for this Dummy's research back in the day.
It covers board design suited for the clock frequencies of the very Macs we're fooling around with in this thread. I read it back in the year it was published:
Google search string with links to his other two books . . .
Handbook of printed circuit manufacturing from the year after the 128k's release and:
Printed Circuit Engineering
I think I'll snag his other two books just for $#!^$-n-Giggles . . . :lol:
. . . and maybe just a tad of 68kMacintosh era PCB "Designer's" brushup!
Links:
Amazon.com: used bargains
powells.com
Related works from a source with an unblemished reputation for all things researchable:
Johns Hopkins University Library
< . . . thinks about assembling a freakin' Bibliography for this thread monster) . . . >
It covers board design suited for the clock frequencies of the very Macs we're fooling around with in this thread. I read it back in the year it was published:
Google search string with links to his other two books . . .
Handbook of printed circuit manufacturing from the year after the 128k's release and:
Printed Circuit Engineering
I think I'll snag his other two books just for $#!^$-n-Giggles . . . :lol:
. . . and maybe just a tad of 68kMacintosh era PCB "Designer's" brushup!
Links:
Amazon.com: used bargains
powells.com
Related works from a source with an unblemished reputation for all things researchable:
Johns Hopkins University Library
< . . . thinks about assembling a freakin' Bibliography for this thread monster
) . . . >I've been trying to do that, so far no luck. If I use atb VRemove, and then set a VBL queue entry to call CrsrTask, CrsrTask gets invoked and dequeued without macsbug being triggered. If I try to set a breakpoint on VRemove or on CrsrTask, then set a VBL queue entry to call CrsrTask, CrsrTask doesn't seem to get invoked, and mouse clicks stop working as well.
Disassembling CrsrTask shows it shouldn't be dequeuing its self. There is code immediately following CrsrTask in RAM that dequeues the Sound VBL, but that shouldn't be hit by CrsrTask.
Right now, my driver is being splatted down on top of the .Sony driver (I'm literally dd'ing the driver on top of the .Sony driver location in the ROM file), and it is claiming to be .Sony. I'm claiming to be .Sony so it gets loaded and opened by the ROM during boot, which it is definitely doing. It is entirely likely that since this is not a floppy driver compatible replacement, things are going sideways but I'd like to understand exactly why. The CrsrTask VBL entry going missing and being removed when I add it is rather strange behavior for something missing from the floppy driver. I've implemented most of the control and status calls, it is correctly identifying the volume as locked so it shouldn't be trying to do any writes. I am using 0x134 (SonyVars) for some state information, which seems OK since Basilisk II is just filling that with 0xdeadbeef. There is also the function pointer stuff at 0x222 which Basilisk II doesn't seem to touch either. I am setting DiskErr consistently, and I think that covers about all the side effects of the driver.
I could, it looks like it'd be a bit of work to make sure the full ROM disk is being added to the emulated address space and loaded and such. Basilisk II is a bit funny because it keeps all state in the emulator, not in the virtual environment. This also makes the drivers essentially the minimum size a driver can be in the 68k side of things, which makes room for all the drivers they adding in. My driver will be much larger than their stubs, but everything should still fit... I may ultimately end up doing that, but it's a slippery slope. The OSX port of BII is in need of some love, and it has been on my todo for a long time, so there's a danger of getting side tracked into BII work.
Duh. CrsrTask is invoked by the ROM's DoVBLTask which calls SlotVBLInt. DoVBLTask takes what looks like a slot number in D0 for the slot to service, which should be between 0x09 and 0x0E inclusive. On the II & IIx ROMs, DoVBLTask() looks like it exits with error -0x168 if the passed in slot number is outside that range, which means DoVBLTask(0) would never proceed to SlotVBLInt, and the cursor task would never be invoked.
Adding CrsrTask to my own VBL task above worked, but only until the vblCount of that task reaches 0 (count is decremented each time the task is invoked), at which point it'll be dequeued. Which is why it works for a short period of time, then vblCount == 0, and done.
The VBL Queue is clearly being processed, and it looks like it is processed by the ROM based VBLInt_VIA, on the vertical retrace interrupt of the VIA's CA1 line. So, that's firing correctly. But DoVBLTask is not called from that handler.
I'm not sure how DoVBLTask() gets called normally, or how it proceeds on to SlotVBLInt to call CrsrTask without a slot VBL.
Basilisk II directly calls DoVBLTask(0) once a second, which seems like it wouldn't do anything on the II/IIx ROM, which looks like it errors out with an argument of 0 (BII ignores the return value). Perhaps the floppy driver's VBL task is calling it somehow? That'd seem odd.
As a workaround, I've made my own VBL task call through 0x8ee to CrsrTask on a recurring 60Hz basis, and it seems to work OK.
So, wooo booting ROM disk (sort of).
Edit: source and drvr The drvr link is the assembled binary driver which can be splatted down on top of the .Sony driver in your ROM. Eventually I'll make a tool that will locate and update the .Sony driver automagically...
Wow, I just discovered this thread and it's freakin' awesome!. Like a dream come true...
Many thanks, dougg3 and all, for your research... and your will to share it
Keep the good work going... all the best,
Many thanks, dougg3 and all, for your research... and your will to share it
Keep the good work going... all the best,
Thanks zuiko
It's fun to see cool stuff come out of the hack like bbraun's project.I'll be damned. That's awesome! I just created my own mini 512 KB boot ROM drive with a minimal System 6.0.8 on it. Stuck it after the ROM, replaced the ROM's .Sony driver, recalculated the checksum, burned it, and...
IT WORKS!
Well, kind of. System 6 wants to rebuild the desktop but can't because it's locked, so it tells me to unlock the disk. When I click OK, it reboots. So I probably need to boot the disk once in my emulator
But IT WORKS! Cool! Thanks for the awesome hack, bbraun!
Yeah, you have to make sure the disk image is exactly the way you want it before programming it. Having the folder window open when you made the image means that'll open every. single. time. you boot. If the window isn't the right size, or has scrollbars, that's just the way things will be forever. Things like that you might not think about the first time through, but after dozens of boots, it can get tiresome.
For the adventurous who want to build from source, I'm using CodeWarrior 1.3 I think. Right now, the "romdrv" project file merges the DRVR resource into the ROMDisk extension file as the .Sony DRVR resource. I'm then doing a nasty cheating hack and copying that to my netatalk server which stores resource forks as appledouble files in a .AppleDouble directory. I then extract the .Sony DRVR resource from the netatalk appledouble file using dd(1) using "dd if=ROMDisk of=/tmp/ROMDisk.drvr skip=2750 bs=1 count=1930" (2750 is the location of the driver within the appledouble file, 1930 is the size of the driver), then dd'ing that into the ROM image using "dd if=/tmp/ROMDisk.drvr of=MyIIx.ROM seek=186156 bs=1 count=1930 conv=notrunc" (186156 is the offset into the IIx ROM where the floppy driver lives), recalculating the ROM's checksum with a hacked up tool I wrote, hex editing the checksum of the ROM file (first 4 bytes), then concatenating all the stuff into one big image using "cat MyIIx.ROM padding diskimage > mybigimage". The padding file is just to get the diskimage located at 512kb into the larger ROM image, since the IIx has a 256kb ROM, that padding file is 256kb. Then splitting it into the 4 components with another hacky tool using "./splitter mybigimage mybigimage_{1,2,3,4}" (numbers are in IC order, not byte order), and then programming the 4 chunks into the ROM.
All of that's automatable, so I'll work on a tool to locate the .Sony driver, splat (I just can't bring myself to use the word 'patch' seriously in this case) the ROMdisk driver into an existing ROM, update the checksum, and split it into programmable chunks (the latter part being irrelevant soon, wooo!).
I'm thinking I'll stick with the 256kb ROM for the IIx and modify the driver to use a 768k disk image instead of 512k, seeing if I can get appleshare on there, macsbug 6.1 fits well and was invaluable during the debugging process. Maybe update my RAMdisk driver and throw it in the system folder to have a small scratch space.
For the adventurous who want to build from source, I'm using CodeWarrior 1.3 I think. Right now, the "romdrv" project file merges the DRVR resource into the ROMDisk extension file as the .Sony DRVR resource. I'm then doing a nasty cheating hack and copying that to my netatalk server which stores resource forks as appledouble files in a .AppleDouble directory. I then extract the .Sony DRVR resource from the netatalk appledouble file using dd(1) using "dd if=ROMDisk of=/tmp/ROMDisk.drvr skip=2750 bs=1 count=1930" (2750 is the location of the driver within the appledouble file, 1930 is the size of the driver), then dd'ing that into the ROM image using "dd if=/tmp/ROMDisk.drvr of=MyIIx.ROM seek=186156 bs=1 count=1930 conv=notrunc" (186156 is the offset into the IIx ROM where the floppy driver lives), recalculating the ROM's checksum with a hacked up tool I wrote, hex editing the checksum of the ROM file (first 4 bytes), then concatenating all the stuff into one big image using "cat MyIIx.ROM padding diskimage > mybigimage". The padding file is just to get the diskimage located at 512kb into the larger ROM image, since the IIx has a 256kb ROM, that padding file is 256kb. Then splitting it into the 4 components with another hacky tool using "./splitter mybigimage mybigimage_{1,2,3,4}" (numbers are in IC order, not byte order), and then programming the 4 chunks into the ROM.
All of that's automatable, so I'll work on a tool to locate the .Sony driver, splat (I just can't bring myself to use the word 'patch' seriously in this case) the ROMdisk driver into an existing ROM, update the checksum, and split it into programmable chunks (the latter part being irrelevant soon, wooo!).
I'm thinking I'll stick with the 256kb ROM for the IIx and modify the driver to use a 768k disk image instead of 512k, seeing if I can get appleshare on there, macsbug 6.1 fits well and was invaluable during the debugging process. Maybe update my RAMdisk driver and throw it in the system folder to have a small scratch space.
Can you put a Cmd-Opt-X-O invoke in the driver? so it loads the ROM disk when that key combo is pressed during boot, like the classic? This would be neat for my SE/30 in case it crashed, i could boot a ROM 7.5NAD image
Yeah, I've been thinking about the best way to do that. I'll be playing with it a bit to figure that out. I might drag my feet a bit until dougg3's programmer is available. My poor PLCC sockets need a rest.
Understandably! I hate PLCC sockets with a passion...can't wait for the programmer board myself.
Here's a video of my IIci booting from the ROM disk, for anyone interested:
Sorry about the camera shake, it's hard to hold my phone steady and move the mouse at the same time!
I hate PLCC sockets with a passion...can't wait for the programmer board myself.Here's a video of my IIci booting from the ROM disk, for anyone interested:
Sorry about the camera shake, it's hard to hold my phone steady and move the mouse at the same time!
:lol: I haven't felt like digging my tripod out, so I've been using a Mop-o-Pod. An inverted broom handle would work fine too! }
p.s. and NO, I am NOT loading Flash again! Once was more than enough!
Geeze that ROM OS is fast once it gets passed the memory check.
Yeah, it really is! I should try to disable the memory test too. I bet that would make booting *really* fast! That IIci has 32 MB of RAM. I can't imagine how crazy long the startup would take if it had 128 MB.
It's actually using a super slow byte by byte copy right now. I have to switch it back to BlockMove and it should be much faster. Then it'd be limited by the speed of rom basically, which afaik is slightly slower than ram (120ns vs 150ns?)
That ROM is definitely smoking through the boot process. It's fast on the Classic, but in the IIci, if you blink, you will almost miss it. Great work guys!
doug3 et al,
What about adding SCSI Manager to your ROMs, just like it's made in the newer machines?
I don't know whether it could be done and how that SCSI Manager operates, but here's the story behind this idea.
Related to another thread about SCSI benchmarking utilities and drive speed issues I dug out my IIci yesterday to check whether ATTO EPT will run on it and how the drive performs. ATTO refused to operate, stating that there's no SCSI Manager present. My OS on that drive was 7.6.1! I then remembered what I read in one of the FWB FAQs:
Wild guess - will real SCSI Manager in ROM permit older Macs to boot from drives larger than 2 GB?
What about adding SCSI Manager to your ROMs, just like it's made in the newer machines?
I don't know whether it could be done and how that SCSI Manager operates, but here's the story behind this idea.
Related to another thread about SCSI benchmarking utilities and drive speed issues I dug out my IIci yesterday to check whether ATTO EPT will run on it and how the drive performs. ATTO refused to operate, stating that there's no SCSI Manager present. My OS on that drive was 7.6.1! I then remembered what I read in one of the FWB FAQs:
So I plugged my Jackhammer (with nothing connected to it) into free available slot of that IIci, and, voila, ATTO stopped complaining and let me run all tests as expected.
Wild guess - will real SCSI Manager in ROM permit older Macs to boot from drives larger than 2 GB?
Generally when someone says something "can't be done" with regard to software, they're really collapsing the states "I don't know how" and "It'll take more time & effort than I think is reasonable" into the single state of "can't be done".
The addition of SCSI Manager 4.3 to ROM is a separate issue from >2GB booting though. I'm booting 4 and 8 GB CF cards on my IIx. The issue with >2GB is needing HFS+ to create >2GB filesystems. AFAIK, that requires the ROM's boot code to know how to parse the HFS+ filesystem to load the bootable bits, which is independent of SCSI Manager.
SCSI Manager 4.3 added support for LUNs, and presumably that's why booting off arrays requires it.
Just doing some quick googling, SCSI Manager 4.3 came as an INIT in System 7.5, which basically means it'd hopefully be relatively simple to load: it should be loading one or more resources (which can be extracted from that INIT) at boot time.
The ROMDisk driver is currently being pretty dumb and just overwriting the .Sony floppy driver out of convenience, since we know the floppy driver is being loaded for us, and we know the floppy driver is big enough to contain the new driver, and we know it isn't required for booting in the configuration desired. A more ideal solution would be to add the ROMDisk DRVR resource to the ROM's list of resources, and have it loaded and opened along side the floppy driver. The first half of that would be the same as loading SCSI Manager: extract the code resource(s) from the INIT, merge them in with the ROM's existing resource list, and get it loaded. I can imagine a whole host of potential complications, no need to overcomplicate things before even starting.
The Jackhammer card has SCSI Manager 4.3 in its DeclROM, and from my initial understanding, it is easier to get resources loaded from DeclROMs since the Slot Manager parses and loads most of that on your behalf. The burden is on getting the sResource directory right and everything formatted correctly.
The addition of SCSI Manager 4.3 to ROM is a separate issue from >2GB booting though. I'm booting 4 and 8 GB CF cards on my IIx. The issue with >2GB is needing HFS+ to create >2GB filesystems. AFAIK, that requires the ROM's boot code to know how to parse the HFS+ filesystem to load the bootable bits, which is independent of SCSI Manager.
SCSI Manager 4.3 added support for LUNs, and presumably that's why booting off arrays requires it.
Just doing some quick googling, SCSI Manager 4.3 came as an INIT in System 7.5, which basically means it'd hopefully be relatively simple to load: it should be loading one or more resources (which can be extracted from that INIT) at boot time.
The ROMDisk driver is currently being pretty dumb and just overwriting the .Sony floppy driver out of convenience, since we know the floppy driver is being loaded for us, and we know the floppy driver is big enough to contain the new driver, and we know it isn't required for booting in the configuration desired. A more ideal solution would be to add the ROMDisk DRVR resource to the ROM's list of resources, and have it loaded and opened along side the floppy driver. The first half of that would be the same as loading SCSI Manager: extract the code resource(s) from the INIT, merge them in with the ROM's existing resource list, and get it loaded. I can imagine a whole host of potential complications, no need to overcomplicate things before even starting.
The Jackhammer card has SCSI Manager 4.3 in its DeclROM, and from my initial understanding, it is easier to get resources loaded from DeclROMs since the Slot Manager parses and loads most of that on your behalf. The burden is on getting the sResource directory right and everything formatted correctly.
. . . which is exactly why I'm so excited by your proposed DeclROM Project!
Thoughts/Wish List:
Loading a larger amount of ROM and even more SRAM onto a larger ROM SIMM, addressing these as two VM spaces under something like RAMDisk+ back in the day
___all drivers etc, bootstrapped from the existing 1MB of ROM space and pointed straight at the larger ROM/battery backed SRAM portion with the system and . . . [] ]'>
Hacking a REALLY big IIfx Card for both connectors with:
___Silicon RAMDisk/VRAM Hack for the back half/PDS Slot, heh! It may only run at 20 MHz, but it ought to fly as compared to HDD transfers, even fast & wide. [] ]'>
___Some kind of VidCard 1080p Hack on the NuBus end w/really fast Ethernet & a TINY Ethernet <-> Wireless box Bunsen PM'd me about . . . and . . . and . . . [}] ]'>
. . . can't be done! :approve:
Thoughts/Wish List:
Loading a larger amount of ROM and even more SRAM onto a larger ROM SIMM, addressing these as two VM spaces under something like RAMDisk+ back in the day
___all drivers etc, bootstrapped from the existing 1MB of ROM space and pointed straight at the larger ROM/battery backed SRAM portion with the system and . . . [
] ]'>Hacking a REALLY big IIfx Card for both connectors with:
___Silicon RAMDisk/VRAM Hack for the back half/PDS Slot, heh! It may only run at 20 MHz, but it ought to fly as compared to HDD transfers, even fast & wide. [
] ]'>___Some kind of VidCard 1080p Hack on the NuBus end w/really fast Ethernet & a TINY Ethernet <-> Wireless box Bunsen PM'd me about . . . and . . . and . . . [}
] ]'>. . . can't be done! :approve:
Well, baby steps. At this point, we've got a driver that is naively overwriting the floppy driver to get loaded, and the whole CrsrTask thing is still an unknown (at least it has a workaround though...). It would be good to get it loading without overwriting the floppy driver, and then that'd be a much cleaner way of adding the driver to the ROM. But, that's a good bit of work and far less sexy than slapping a driver into the ROM, yet at the same time opens more options for future ROM expansion. So, we'll see. If anyone else wants to start hacking, let me know and I'll set you up.
DeclROM hacking is definitely interesting and on the TODO, but we've got a long way to go before exhausting the potential of dougg3's ROM SIMM!
MMU hackery is also on the TODO, as it would be nice to get the full 2MB of the ROM SIMM mapped in at boot time, although that seems like it might require System changes as well. The ROM initializes the MMU and sets up some mappings. The System software then reinitializes all that and sets up mappings the way it wants. Which is why my initial attempts to use 0x40880000 worked in ROM before System boot and after System boot, but not if a read operation came in during boot when the mappings were changing. And also why some System software has more or less ROM mapped in than others. So if we muck with the mappings from the ROM, it gets us access to that space pre-boot, but not during & after boot. For post-boot stuff, the possibilities are much easier since things are not changing as much, but at that point you don't really need to be doing ROM hacking, just throw it all in an INIT.
And then there's time. The ROMDriver was a wonderful coincidence in that I already had written the memory disk driver, so that was easily modified, and dougg3's SIMM arrived right before a holiday, so time was available. I expect my personal contributions to come at a much slower pace in the future. And the TODO list runneth over, as you can see.
On a related note, when I was working on a ROM patcher for the disk driver last night, I noticed the II/IIx ROMs had a pretty significantly different resource layout than the IIsi/IIci ROMs. The IIsi/IIci version seemed to be a much more compact representation, but it's a different way of locating the DRVR resource. I'm thinking of doing a naive check of if the ROM size is <512k, go with the II/IIx way of locating the driver, otherwise, go with the IIsi/IIci method. Checking the checksum or machine id's or anything else in the ROM isn't going to be very reliable since we're all about modifying the ROM now.
I checked the Basilisk II source, and they're using the IIsi/IIci method of locating resources. I don't think Basilisk II will work with the II/IIx ROMs...
So, we'll see. If anyone else wants to start hacking, let me know and I'll set you up.DeclROM hacking is definitely interesting and on the TODO, but we've got a long way to go before exhausting the potential of dougg3's ROM SIMM!
MMU hackery is also on the TODO, as it would be nice to get the full 2MB of the ROM SIMM mapped in at boot time, although that seems like it might require System changes as well. The ROM initializes the MMU and sets up some mappings. The System software then reinitializes all that and sets up mappings the way it wants. Which is why my initial attempts to use 0x40880000 worked in ROM before System boot and after System boot, but not if a read operation came in during boot when the mappings were changing. And also why some System software has more or less ROM mapped in than others. So if we muck with the mappings from the ROM, it gets us access to that space pre-boot, but not during & after boot. For post-boot stuff, the possibilities are much easier since things are not changing as much, but at that point you don't really need to be doing ROM hacking, just throw it all in an INIT.
And then there's time. The ROMDriver was a wonderful coincidence in that I already had written the memory disk driver, so that was easily modified, and dougg3's SIMM arrived right before a holiday, so time was available. I expect my personal contributions to come at a much slower pace in the future. And the TODO list runneth over, as you can see.
On a related note, when I was working on a ROM patcher for the disk driver last night, I noticed the II/IIx ROMs had a pretty significantly different resource layout than the IIsi/IIci ROMs. The IIsi/IIci version seemed to be a much more compact representation, but it's a different way of locating the DRVR resource. I'm thinking of doing a naive check of if the ROM size is <512k, go with the II/IIx way of locating the driver, otherwise, go with the IIsi/IIci method. Checking the checksum or machine id's or anything else in the ROM isn't going to be very reliable since we're all about modifying the ROM now.
I checked the Basilisk II source, and they're using the IIsi/IIci method of locating resources. I don't think Basilisk II will work with the II/IIx ROMs...
iKNOW!
) But when the piccies all line up behind my eyeballs . . .
. . . I just have to translate that collage into .txt here on Virtual Paper with my Virtual Mechanical Typewriter/Ribbon. :approve:
By the way, guys, if Mac II ROMs is of any value to any of you involved in developement, I have two sets of these, you can have them for the price of shipping....from Europe.... [] ]'>
] ]'>