How Apple's developers reflashed Mac ROMs in the '90s
downtowndougbrown.com
downtowndougbrown.com
Only downside was that you lost the image on power down, so I can see why EEPROM was more important to Apple in developing their systems.
The only thing that came to mind were these Newton development boards from about that era. I believe they were more or less Newtons shoved into one of the slots of a Quadra-like machine (perhaps the PDS slot?).
My memory of that era is fuzzy though.
I still have and cherish my 8600, the very first Bad Motherfucker computer I ever managed to obtain. :)
It's not quite the full system. It may be best to think of the original Mac OS as a software library. The application is in primary control, and uses the OS as a library directly - jumping right into the OS code sometimes. Modern ideas about layers of separation and protection did not yet exist.
A significant portion of the ROM is QuickDraw, routines for doing bitmap graphics and text very quickly. There are some other rather generic routines, like string handling, a sort of a standard library. There are also drivers, interrupt and timer handling, etc. The Chicago system font is in ROM too.
Since it was all designed together, it was not too hard to just make it modular, and have some of the modules in the ROM, and the rest loaded from disk. There is a central dispatch table kept in RAM. When a program makes a Mac OS call, the dispatcher looks up the current vector from the table. When the OS loads, any patches to ROM are handled by redirecting the dispatch to the new routines or patches. It's important to remember classic Mac OS had resources (labelled sections). Large blocks of code are referred to with handles, not pointers. The resource manager can transparently load/unload them behind the scenes as needed.
The Mac has gone through a fair bit of setup before it starts reading the disk. The OS memory manager is running, and the device manager is configured, the disk driver service is set up as well. The boot splash (grey background and the happy Mac icon) is drawn using standard graphics API calls. The calls would do the same thing if used in a normal Mac OS app. The boot sector on disk is loaded using the same calls as in a Mac OS app if you wanted to do low-level disk access.
The resource manager is then told about all the resources in the system file, and any patched resources are patched, etc. And then the finder application is loaded and started. When it goes to look for resources, it'll find them mapped to ROM or the system file through the in-RAM resource map. And when it goes to make a system call, it'll find them mapped to ROM, or the routines loaded in RAM from the System file, through the trap table.
Here's a good article (2019) doing a much deeper dive: https://macgui.com/news/article.php?t=496
> became useless because there was no way to update the ROM
The original Mac 128 and 512 were limited, because their ROMs were the original code, and also 64 KB in size. The later Mac software needed at least 128 KB of ROM (new file system, etc.) and so could never run on those machines. But later system software was never going to run on those machines, anyway.
RAM was extremely expensive in the mid-80s. That is really the only reason for this. The original Mac would have needed an extra 64 or 128 KB of RAM otherwise. That would have bumped the price up several hundred dollars. RAM prices imploded shortly after the Mac's release, of course. System 7 loads around 100 KB of patches to the ROM on a Mac Plus. By 1990 it would clearly have been better to just have it all in RAM. But the architecture was already fixed. (Later Macs would just load a complete ROM image off disk.)
There is one more minor factor: the original Mac can execute code from ROM at full speed. The RAM is contended with the video hardware and has slightly slower throughput. So there is a slight plus to having QD in ROM!
You're right about the ROM, but parent is talking about something else: the built-in bootable system that came in ROM on the Classics. Cmd-opt-x-o at startup would boot you straight into 6.0.3, at the cost of RAM (it made a RAM disk to run from).
The reason why so many early 1990s UIs have this kind of color scheme is part fashion and part technological opportunity.
Rainbow pastel colors were really popular around 1986 - 1993. It was a reaction to the muted browns and oranges that characterized '70s and early '80s design, and also a reflection of the economic optimism of the era.
At the same time, computer displays evolved beyond monochrome (original Mac) or garish 16-color palettes (PC EGA). With 256 colors out of a palette of millions, it became possible to display those fashionable pastels on a computer too. So why hold back?
(Personally I'm still stuck in this era. Light background is a must. I never use dark mode on anything. I genuinely don't understand the kids who want their IDEs in black like some depressing 1982 textmode VAX. For me it's warm pale yellow and baby blue terminals all the way; extra bonus for dark purple text highlights and a mint green piqué shirt.)
Dark mode is fundamentally a hack around two things.
First, shitty screens that can't run light mode anywhere near dim enough once the sun goes down (which is at least a 5-nines percentage of all screens ever produced). A good chunk of this is due to insufficient PWM frequency but software has a lot to do with it too- and if I can't make the screen go dark enough, well, then I'll just tell all the pixels to be black and use white text.
Second, shitty flat UI design has made it more difficult to see borders between items. It seems to be easier to pick out a bright glowing spot in a field of black than the reverse- it's worse for comprehension, but not for identification/differentiation. It's easier to see that something is selected when you're using white-on-black, and if you already have a good idea what that something is the comprehension penalty is irrelevant.
Those two things predate most proper dark mode implementations; I assert they created the need for it to exist in the first place.
Kid here (34). My understanding is our generation grew up spending much more time looking at a screen in general. Gaming, socializing, following news, doing work, doing homework, talking to parents, talking to partner(s), reading books, painting, sculpting, paying taxes, managing finances, applying jobs, applying for visas... The list is too long to fit here. Participating in society demands more screen time than ever.
Dark mode makes screens blend with the environment better by emitting light where only needed. Since we can't reduce our screen time without any compromise, we try to optimize with the dials we are left with, in this case, pixel brightness.
Admittedly this theory is only backed by personal preference and some vague recollections of CRT-era ergonomics discussion in 1990s UI design books.
Same for my argument too.
There is also the cultural factor. The age when I was going to make a decision about which high school to choose and what kind of study to pursue, we had the chance to enjoy the release of a few of the best sci-fi movies/shows ever made. Those movies had the black screen, neon green/blue strokes and fonts as the main design language. Looking at the letters falling down in the movie Matrix, it was like "coooool, I wanna be able to type those in real time and make computer do stuff".
Now with floaters I have to use dark background and many games are now unusable as they have light background and medium unreadable text and strain my eyes.
My personal theory is that some people are just genuinely more light-sensitive than others, but that the main factor is which scheme came (back) into fashion during someone's formative years, so it will always be associated with being new and novel to that person.
In terms of practicality:
- Dark mode uses less energy and doesn't burn your eyes at night.
- I've only ever found light mode useful when the ambient light is really strong, e.g. direct sunlight shining on my laptop screen. When this happens dark mode is basically impossible to read even with full screen brightness.
So 99.9% of the time dark mode will suit my needs better.
When Americans first got easy access to refrigeration and food became significantly cheaper, we got jello casserole. People would suspend literally anything in jello because it was so novel at the time. Bright, colorful, wobbly abominations. Just like this UI.
Do you have any examples? Because from the early 1990s I only remember Windows pre-XP (mostly black and white and blue), AmigaOS (mostly gray, including the newer frameworks like MUI), NeXTStep (gray). Only exception: the colored tabs in OS/2 Warp, if I remember correctly.
http://toastytech.com/guis/irix.html
It's more muted, but follows the principle of "let's use these truecolor hues now that we've got them."
The global fashion trend after 1990 was moving away from bright pure colors and towards increasingly muted pastels. So for examples of more bright-colored UIs on 256-color displays, I think the Mac II / System 6 era would be the place to look. Early CD-ROMs might be a rich vein.
It is the windows 3.1 aesthetic on much more capable hardware.
Edit: never mind. The link by pavlov has more examples.
It's a reflection in UIs of Memphis Design, which dominated the 1980s: https://en.wikipedia.org/wiki/Memphis_Group
CDE had different default color schemes from different vendors but most of them were pretty colorful in pastel hues.
I actually liked it better than CDE.
And then, jealousy intensified, I close the tab and go back to debugging my MVC webapp.
1. There are always people far brighter than the people who wrote most of what we use every day.
2. You are far more capable than you realize.
No one is ever likely to make a living reverse-engineering 30-year-old ROM-flashing utilities, just like no one is likely to make a living figuring out how to convert early-2000s console game data to standard formats, but that kind of hobby project builds skills that are uncommon and useful in certain lines of work.
Also "How X" != "How to X"
This was the nightmare of Apple from the early days and they actively pursued it. Also, intelligent people in the creative professions were inventing things.
if you take half-a-second, longer than I spent reading that article, you would know this is a personnel account, right? do you need to repeat "AI" rumors here ? It is neither amusing nor adding any substance to the topic IMHO
If the title contains a gratuitous number or number + adjective, we'd appreciate it if you'd crop it. E.g. translate "10 Ways To Do X" to "How To Do X," and "14 Amazing Ys" to "Ys." Exception: when the number is meaningful, e.g. "The 5 Platonic Solids."
Just the relevant bit:
translate "10 Ways To Do X" to "How To Do X"
What happened to the don't editorialize rule, because that's exactly what's being done in the provided example. You're not just shortening an acceptable length title, but you've changed the meaning.
Pretty weird and un-Apple-like to have a physical eject button at all. The mid-90s were such a weird time to be alive.
I was a little excited, because these jewels were expensive back then, and usually always taken by someone that seemed to have more important design tasks to do than I had. Now I had the opportunity, for once.
I inserted my floppy, opened the document, sent it to the printer. All went fine until I wanted to get back my disk to rush to the lab session. No button to eject, nowhere to be found, so I asked one of my fellows sitting at a PC. He told me to drag the disk into trash bin. Yeah, right, sure I believe that! So I asked another guy, and sure he said I should throw my disk into the bin.
Now, these lab reports were important, because you needed to pass all of them to be allowed to write the test at the end of the semester and there were only two substitute dates. So I had little choice. I dragged the little disk icon over the little bin icon and let go. I already saw all my work on the disk gone but to my great surprise the disk ejected immediately and completely unharmed.
My lab report was handed over in time, it passed. The two substitute dates at the end of the semester never materialized because the prof was sick, as every year before and after - as I lerned. So, good on me to trust my fellow students but g00daxxit terrible UI!
Actually, if memory serves, dragging to the trash was a shortcut for ejecting AND... what did they call it... putting it away, I think. Normal eject would leave a ghost of the floppy disk so when you inserted another one, you could copy from one floppy to another. You had to 'put away' to remove the ghost.
In this world, the split makes perfect sense: you eject a disk when you want the drive slot to be free, but you don’t put it away until you’re done with it. Once hard disks became standard equipment, the floppy drive was relegated to data transfer and you almost always wanted “Put away”, but renaming the menu items to what new users expected would have confused existing users.
Fortunately, the lack of an eject button was a farce on this machine. The CD drive was just your garden variety PC drive and if you aren't shy about abusing the facade door Apple placed over top of it you can still get to the eject button.
What happens when you push the eject button on the lower right, below the floppy drive? If you say "Ackshually, it's the power button. Macs don't have floppy eject buttons", feel free to go back in time and tell that to the many, many, many users at my college who pushed that button to eject the floppy and instead turned the computer off. This happened so often that we had to tape paper barriers over the buttons.
But you could “eject” (unmount) anything with it, disk images etc. It wasn’t hardwired to any particular drive.
not sure why my comment is downvoted to -3