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).
OK, I'll have to properly learn about RISC OS modules then
.I guess so, but we can see it wasn't good practice.
OK, I'll have to properly learn about RISC OS modules then
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 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.
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.)
I won't
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.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.
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).
