Patched 6.0.8L for more Macs

[croissantking]

While we're on this topic, I'm curious about one thing. Anyone who's used both generations of 100 series PowerBooks knows that the 140/145/170 systems all make a loud speaker pop when they start, and the later ones don't. I do wonder why they designed things that way. In fact, there's a loud speaker pop every time one of those PowerBooks initialize the speaker.

Also:

The 140/145/170 show you the garbled contents of the VRAM before the grey screen.

And:

To power off the 140 etc you just press the power button once, but the 160/165/180 you have to hold it down for a while.

 

[joshc]

In fact, there's a loud speaker pop every time one of those PowerBooks initialize the speaker.

Same for... most Macs of that era I thought? The speaker pop is a sign good things are happening. Happens noticably on my Quadra 650, and the IIci / IIfx as well. As for the actual reason though, I don't know for sure.

 

[3lectr1cPPC]

My IIsi does it after the RAM test finishes but before the screen lights... sometimes. I assumed that's related to my PSU being on its deathbed though, since it is only sometimes.

The 140/145/170 show you the garbled contents of the VRAM before the grey screen.

Or any contents. When it hasn't lost power since last boot, it will just display the desktop (or whatever screen it was on before it was shut off) for a few seconds.

 

[croissantking]

My IIsi does it after the RAM test finishes but before the screen lights... sometimes. I assumed that's related to my PSU being on its deathbed though, since it is only sometimes.

Or any contents. When it hasn't lost power since last boot, it will just display the desktop (or whatever screen it was on before it was shut off) for a few seconds.

I feel like most vintage PowerBooks do this but don’t turn on the backlight until later, so you don’t really notice.

 

[3lectr1cPPC]

My 180c lights up right away and it doesn't. Shows a full white screen, then it initializes the LCD panel and the color changes, then happy mac, boot, and so on.

 

[LaPorta]

Portable does it as well…similarity?

 

[David Cook]

Progress is slow but steady. I have reversed engineering the 6.0.8L boot block code and System data fork code. I can now compile and generate matching object code.

I found a serious overflow bug in the boot block code for computers with 16 MB of RAM or more. I couldn't figure out why this wasn't caught and fixed. I was shocked to find that pre-System 7 boot block code doesn't run on the Macintosh II / SE and later. Yup, in order to run, the high byte of the boot block version must equal 'D' ($44) or the top two bits must be set. Otherwise ROM code runs instead*.



*It's worse than that. The ROM code doesn't check for a return value. So, both the boot block code (if allowed) and the ROM code runs. System 7 hacks this by hard coding a table of ROM addresses and jumping directly into the ROM code if it needs to continue, otherwise it never returns.

Let's see what Inside Macintosh:Operating System Utilities says about the boot blocks. Oh no. This is like a bad version of the telephone game where a developer says 'D' and the tech writer wrote $D, the and/or got confused, and the lower byte isn't actually involved at all.


What I've learned is:
* Starting with the Mac II / SE ROM and from then on, the ROM contains a lot of the start up code.
* Starting with the Mac II / SE ROM, 'old' boot block code is not executed
* System 7 boot code has hard coded addresses into ROM. This is a horrible practice. Using a new modified ROM (ROMinnator) that shifts the code can crash if the disk OS decides it cannot run on that machine and tries to allow the ROM boot process to continue find a better boot drive.

- David

 

[Phipli]

I found a serious overflow bug in the boot block code for computers with 16 MB of RAM or more. I couldn't figure out why this wasn't caught and fixed.

Did this matter as System 6 only boots in 24bit mode? Or does it impact machines with more RAM even if they aren't using it.

I know Optima exists to enable 32bit, but it was third party

 

[David Cook]

As I read through the ROM source code, I found some interesting notes unrelated to my quest to boot 6.0.8L on newer machines.

1. Fred prioritized his girlfriend over work:
"Fix this up, and added judicious comments which Fred was too whipped to do because his ride was here."

2. The 4*8, 8*24, GC boards had a bug in their ROM which the System had to patched to fix in a really hacky way:
"Trident/4¥8/8¥24/GC video card's secondaryInit code. The Trident card's secondaryInit code has a call to _sNextTypesRsrc. Instead of setting "clr.b tbMask(a0)" the error is using "clr.b sptbMask", which clears byte $30 in low mem (fortunately benign). This fix looks at every sExec block being executed. If it sees a "clr.b $30" next to a _sNextTypesRsrc, then it changes the instruction to a "clr.b $30(a0)".

3. The 8*24 GC was given special treatment in the OS and ROM patch code to work properly:
"Load 8¥24 GC software from separate file in the control panels folder (or from the system file)."
"GC card cached the offscreen gworld. Must get and use the gc card cache addr."
"Fixing QDDone parameters so the good;ol GC card works properly."

4. The IIfx had its SCSI DMA hobbled in later system releases. I'll bet a little performance testing will determine which OS did this.
"commented out the installation of SCSI DMA so we stop trashing hard disks on the IIfx."
"SCSI DMA is now disabled on the IIfx due to bugs"

 

[David Cook]

Did this matter as System 6 only boots in 24bit mode?

I couldn't prove it to myself because I discovered the code wasn't running. They are allocating file control blocks (FCBs) based on the total amount of memory. Unfortunately, the FCB size value is a signed word.

mulu.w d1,d0 // Multiple FCBs queue size for each 128KB of memory
// Default is 300 bytes for each 128KB of memory
// That's 18600 bytes of FCBs for an 8MB system
addq.w #2,d0 // Add two bytes to queue size to hold size of queue
// This overflows on a system with more than 27904KB of memory
// Because 65535/300=218*128=27904
// Is MemTop constrained to 8MB?
// Worse, see MoreFCBs in FileMgrPatches.a
// The length is considered signed, so overflow at half that amount

If MemTop is always <= 8MB, then this isn't a problem. But, it turns out this isn't a problem regardless, as the boot block code is never run except on a MacPlus or earlier.

 

[cheesestraws]

Ah, it's always a pleasure watching people discover the total insanity that is the boot sequence around the 6/7 transition.

I always say it's like watching three people do a cup and ball trick all at once, then you realise they're all somehow using the same ball.

The control flow is absolutely bonkers!

 

[Phipli]

As I read through the ROM source code, I found some interesting notes unrelated to my quest to boot 6.0.8L on newer machines.

1. Fred prioritized his girlfriend over work:
"Fix this up, and added judicious comments which Fred was too whipped to do because his ride was here."

2. The 4*8, 8*24, GC boards had a bug in their ROM which the System had to patched to fix in a really hacky way:
"Trident/4¥8/8¥24/GC video card's secondaryInit code. The Trident card's secondaryInit code has a call to _sNextTypesRsrc. Instead of setting "clr.b tbMask(a0)" the error is using "clr.b sptbMask", which clears byte $30 in low mem (fortunately benign). This fix looks at every sExec block being executed. If it sees a "clr.b $30" next to a _sNextTypesRsrc, then it changes the instruction to a "clr.b $30(a0)".

3. The 8*24 GC was given special treatment in the OS and ROM patch code to work properly:
"Load 8¥24 GC software from separate file in the control panels folder (or from the system file)."
"GC card cached the offscreen gworld. Must get and use the gc card cache addr."
"Fixing QDDone parameters so the good;ol GC card works properly."

4. The IIfx had its SCSI DMA hobbled in later system releases. I'll bet a little performance testing will determine which OS did this.
"commented out the installation of SCSI DMA so we stop trashing hard disks on the IIfx."
"SCSI DMA is now disabled on the IIfx due to bugs"

I found a list of bug fixes in the source that included a fix specifically for MS Flight Simulator.

Also one mentioning the green tint bug on the 610/650/800.

 

[Crutch]

I love the bespoke bug fixes in the ROM. Somewhere there is one (I think in SetTrapAddress) that prevents only HyperCard 2.0 from patching only SysBeep, because for some reason that Broke Things.

 

[LaPorta]

* System 7 boot code has hard coded addresses into ROM. This is a horrible practice. Using a new modified ROM (ROMinnator) that shifts the code can crash if the disk OS decides it cannot run on that machine and tries to allow the ROM boot process to continue find a better boot drive.

- David

I have no insights into programming at all, but why would this be an issue from Apple’s standpoint? They were making their own, fixed ROMs that would basically never change. “ROMinator” was not something they worried about, as it’s a total hack.

 

[David Cook]

I have no insights into programming at all, but why would this be an issue from Apple’s standpoint? They were making their own, fixed ROMs that would basically never change. “ROMinator” was not something they worried about, as it’s a total hack.

The problem is that the patches to the ROMs started becoming unwieldy to manage. It slows startup as well as runtime, it takes away RAM, but more importantly, it increases engineering maintenance costs and decreases stability. By my count, they had 55 models all with the same base ROM (version $067C) as the Macintosh IIci, with patches applied on top. Instead, it would have been better to fix the actual base ROM source code itself.

Think of writing a book. Each edit and update you add to the end of the book as "errata". The advantage is that you can always point to page 52 paragraph 12 to refer to the same text in every edition. The disadvantage is that you now have chapters of mistakes and updates that that all are tacked on at the end. A big mess.

 

[Snial]

I have no insights into programming at all, but why would this be an issue from Apple’s standpoint? They were making their own, fixed ROMs that would basically never change. “ROMinator” was not something they worried about, as it’s a total hack.

It's an issue because Apple made a big deal about application programmers not relying on specific ROM addresses, because they were subject to change, which is what happened. So, if Apple system programmers broke their own rules, that's a poor show.

 

[Snial]

The problem is that the patches to the ROMs started becoming unwieldy to manage. It slows startup as well as runtime, it takes away RAM, but more importantly, it increases engineering maintenance costs and decreases stability. By my count, they had 55 models all with the same base ROM (version $067C) as the Macintosh IIci, with patches applied on top. Instead, it would have been better to fix the actual base ROM source code itself.

Think of writing a book. Each edit and update you add to the end of the book as "errata". The advantage is that you can always point to page 52 paragraph 12 to refer to the same text in every edition. The disadvantage is that you now have chapters of mistakes and updates that that all are tacked on at the end. A big mess.

Do you have a disassembly of the original 64kB ROM? Is there *any* space left over? (e.g space to add a patch to check for 128kB or 256kB, or wouldn't it need to do that?).

 

[cheesestraws]

It's not great, but the thing is by that point, they were already committed to this course. To a certain extent, that's why it must have been very obvious that "classic" MacOS's fate was sealed by System 7, and why 8 was meant to be a redesign. The ROM + patch idea, the way it was done by Apple, is a huge design defect in the system. It's interesting to compare this to how RISC OS does it with modules that are (mostly) soft-loadable over the ROM without needing to rely on the details of how the ROM is organised. Not that RISC OS aged much better than MacOS, but in this case, the design is clearly better.

 

[LaPorta]

It's an issue because Apple made a big deal about application programmers not relying on specific ROM addresses, because they were subject to change, which is what happened. So, if Apple system programmers broke their own rules, that's a poor show.

I now understand. Thanks for your succinct, easy-to-understand explanation.

 

[LaPorta]

It's not great, but the thing is by that point, they were already committed to this course. To a certain extent, that's why it must have been very obvious that "classic" MacOS's fate was sealed by System 7, and why 8 was meant to be a redesign. The ROM + patch idea, the way it was done by Apple, is a huge design defect in the system. It's interesting to compare this to how RISC OS does it with modules that are (mostly) soft-loadable over the ROM without needing to rely on the details of how the ROM is organised. Not that RISC OS aged much better than MacOS, but in this case, the design is clearly better.

...leading to the software ROM of the iMac and beyond?