Patched 6.0.8L for more Macs

Snial

Well-known member
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.
IMHO, I didn't think the original Mac ROM patching scheme was bad: vectoring all the Toolbox routines via RAM addresses isn't so dissimilar to how the BBC micro (and I believe the Archimedes) vectored all the main OS routines. Given the number of bugs in the 64kB, it made good sense ;-) . The problem is when they started to rely on specific ROM addresses for subroutines in the patches ( I guess, which is part of this topic).
 

David Cook

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

Yep. And I appreciate that you warned me to set my expectations appropriately. : )

I haven't given up yet. At some point, I'm going to find the missing/conflicting piece and fix it, or at least I'll know why the puzzle can't be solved.

I spent some time stepping through the debugger on a Quadra 700. It has the same ROM as the PowerBook 170, which works with 6.0.8L. But, the Quadra crashes with an illegal instruction at the start of ROM seemingly at random before finishing the boot. I don't know if memory is moving on a patch or there is a cache flush missing or a bad driver / interrupt, but the semi random nature and lack of stack trace sure is making it challenging.
 

NJRoadfan

Well-known member
It is amusing reading this and comparing it to Apple's OTHER contemporary GUI operating system, GS/OS. The dev team learned quite a bit from the Macintosh dev teams on what NOT to do. For starters, the base toolbox code in the ROM gets patched to the latest version. Everything else is loaded from disk. The dev team went further and simplified things and dropped ROM 00 support to eliminate having to patch that revision when GS/OS came out. This mechanism of updating the ROM tools actually dates back to 1986-87 with ProDOS 16.
 

cheesestraws

Well-known member
OK, I'll have to properly learn about RISC OS modules then :) .

Sorry for briskness last night, I was half asleep. The point here is that you can replace chunks of ROM in one go in a semantically coherent and, more importantly, versioned manner, without resorting to ad hoc patches. Most of the time. Except when you can't. :D

I guess so, but we can see it wasn't good practice.

It wasn't, but it was also about par for the course at this time for this kind of system. Quite a lot of companies learned the hard way about patching ROMs being harder than patching on disc - those that didn't were either learning from other people's mistakes or just got lucky banking on availability of cheap mass block storage to start with rather than cramming everything into the ROM.

It's easy in hindsight to see that this was a major misstep but let's not forget that at the time people were talking about even the colour mac being basically a major rearchitecture, and there was a lot of optimism sloshing about. Even now, people at work think I'm a cynic when I say that there's no such thing as a temporary measure, and if code leaves your laptop, you're supporting it forever. And there's far more evidence for that now

(Also, @NJRoadfan is bang on with the learning in GS/OS here - but in general, all software systems have to steer a course between not being expandable at all and second system syndrome, all while trying to get the job actually done. Tradeoffs happen. Sometimes the wrong ones.)

Sorry, I'll stop derailing the thread now.
 

Phipli

Well-known member
Sorry for briskness last night, I was half asleep. The point here is that you can replace chunks of ROM in one go in a semantically coherent and, more importantly, versioned manner, without resorting to ad hoc patches. Most of the time. Except when you can't. :D



It wasn't, but it was also about par for the course at this time for this kind of system. Quite a lot of companies learned the hard way about patching ROMs being harder than patching on disc - those that didn't were either learning from other people's mistakes or just got lucky banking on availability of cheap mass block storage to start with rather than cramming everything into the ROM.

It's easy in hindsight to see that this was a major misstep but let's not forget that at the time people were talking about even the colour mac being basically a major rearchitecture, and there was a lot of optimism sloshing about. Even now, people at work think I'm a cynic when I say that there's no such thing as a temporary measure, and if code leaves your laptop, you're supporting it forever. And there's far more evidence for that now

(Also, @NJRoadfan is bang on with the learning in GS/OS here - but in general, all software systems have to steer a course between not being expandable at all and second system syndrome, all while trying to get the job actually done. Tradeoffs happen. Sometimes the wrong ones.)
Have to remember Apple had loads of new architecture projects on the go, they were expecting to move away from these patched ROMs, but project after project fell through. Their custom processor, the Tesseract etc etc. The piltdownman based machines being based on the 68k ROM and going on for another 10 years was probably the last thing they expected!
Sorry, I'll stop derailing the thread now.
I won't :)
 

Snial

Well-known member
Sorry for briskness last night, I was half asleep. The point here is that you can replace chunks of ROM in one go in a semantically coherent and, more importantly, versioned manner, without resorting to ad hoc patches. Most of the time. Except when you can't. :D
No worries. I've got a sudden interest in the 64kB ROM and how to patch it so that it can recognise a 128kB Mac with 256kB of RAM. I've recently read on this site, possibly on this thread that even the 64kB ROM properly checks for up to 4MB, but on the MacGUI site I read on one of the blog posts about the mythical 256kB Mac which could almost be booted, except that some of the code doesn't properly check for 256kB, only 128kB and 512kB. Anyway, even looking through the ROM in a .hex format yesterday made me realise that there doesn't seem to be any spare space at all! Nevertheless that wouldn't be a showstopper for what I'm thinking.
 

Arbee

Well-known member
It is amusing reading this and comparing it to Apple's OTHER contemporary GUI operating system, GS/OS. The dev team learned quite a bit from the Macintosh dev teams on what NOT to do. For starters, the base toolbox code in the ROM gets patched to the latest version. Everything else is loaded from disk. The dev team went further and simplified things and dropped ROM 00 support to eliminate having to patch that revision when GS/OS came out. This mechanism of updating the ROM tools actually dates back to 1986-87 with ProDOS 16.
Yeah. The IIgs toolbox also learned from the large amount of boilerplate code in Mac applications (which resulted in frameworks like MacApp and the Borland equivalent) and provided wrappers like _TaskMaster and _StartUpTools so that you could get a working desktop app running in less than a page of code (plus resources).

You can fault the IIgs hardware for a lot of things, but the system software was better than it had any right to be. I want to visit the multiverse where instead of Copland they ported GS/OS and the IIgs toolbox extensions to native PPC. I know several people from that team went on to work on System 7.5 but they didn't bring any of the unique goodies over (including, back to the topic, the modular startup sequence that allowed Kelvin Sherlock to make GS/OS boot off of an HFS volume).
 

voce1

New member
Any status update? I am very interested in this. Happy to test. I have a stock CC (and a CC Mystic). I've been using hacked stripped down 6.0.4 and 6.0.8 for a few years on the stock CC, but it is limited, albeit much snappier than 7.
 

David Cook

Well-known member
Any status update? I am very interested in this. Happy to test. I have a stock CC (and a CC Mystic). I've been using hacked stripped down 6.0.4 and 6.0.8 for a few years on the stock CC, but it is limited, albeit much snappier than 7.

I've learned a ton and continue to work on it little by little. Do you have a link to the stripped down 6.0.4 and 6.0.8 that you are using on a Color Classic? It would help me make progress. My major sticking point at this moment is a hard crash that sends it to the start of ROM which prevents Macsbug from telling me the source of the crash.
 

voce1

New member
Sure. Have to dig them up. Nothing fancy.

6.0.8 is just a "minimal" install. Simply "g" through two DSAT error messages using Macsbug ("need a new model" and "this disk was made with a minimal installer and will not work").

6.0.4 is a CMS rescue floppy. To avoid DSAT error, branched around _SysError in PTCH 0.

Keep in mind. I'm not a programmer. Just a user who likes to experiment and is picking up as I go.
 
Top