Another IIci ROM hack

[bigmessowires]

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.

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.

 

[Trash80toHP_Mini]

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 ) . . . >

 

[bbraun]

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?

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.

Does your ROM disk driver replace the floppy driver, or work independently of it?

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.

Could you load your modified ROM image into a Mac emulator like Basilisk II?

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.

 

[bbraun]

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.

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...

 

[zuiko21]

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,

 

[dougg3]

Wow, I just discovered this thread and it's freakin' awesome!. Like a dream come true...

Thanks zuiko It's fun to see cool stuff come out of the hack like bbraun's project.

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...

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!

 

[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.

 

[techknight]

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

 

[bbraun]

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.

 

[dougg3]

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!

 

[Trash80toHP_Mini]

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!

 

[olePigeon]

Geeze that ROM OS is fast once it gets passed the memory check.

 

[dougg3]

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.

 

[bbraun]

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?)

 

[tt]

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!

 

[ojfd]

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:

Can I use an array volume as my startup volume?Yes, IF your machine has SCSI Manager 4.3 in ROM, you can start up from a striped, spanned, or mirrored array volume. Machines with SCSI Manager 4.3 in ROM include all Power Macintosh (and later) models (but no PowerBooks except the PB3400 and later models), Quadra 660AVs, Quadra 840AVs, and NuBus Macs with SCSI JackHammers (the JackHammer makes it appear to the system that SCSI Manager 4.3 is in ROM)

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?

 

[bbraun]

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.

 

[Trash80toHP_Mini]

. . . 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:

 

[bbraun]

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...

 

[Trash80toHP_Mini]

Well, baby steps.

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: