68kMLA Classic Interface
This is a version of the 68kMLA forums for viewing on your favorite old mac. Visitors on modern platforms may prefer the main site.
| Click here to select a new forum. | | Macintosh Classic 4MB Limit | Posted by: kallisti5 on 2026-09-03 07:04:06
So, with Adrian's Digital Basement getting 4MB of RAM working on the base board, what is the limitation on getting the Macintosh Classics up to 6,8, or 10MB of RAM?
* The 68k processor supports 16MB
* We have 9 address lines per chip across 8 chips... That's 4MiB maximum onboard.
However, we also have the additional chip selects for the other ram chips in the expansion slot.
It feels like at minimum getting to 6,8,10MB should be possible in theory with some ROM tweaking?
The easy solution is to put a Macintosh Classic II logic board into a Classic... but those logic boards are hard to find.
The Classic has limited use with System 7 due to the 4MB limit. Even adding a few extra MB would make it more usable by leaps and bounds. | Posted by: kallisti5 on 2026-09-03 07:42:18
I decided to let some AI loose on the Macintosh Classic and Macintosh Classic II system ROMS. (Comparing them, dissembling them, and trying to find what (if any) software limitation there is. Here's a breakdown:
Classic (Mac-Classic.rom:0x25FA) determines RAM size with a physical probe that is hardcoded to stop at 4MB:
move.l #$54696e61, d1 ; magic marker ("Tina")
movea.l #$3ffffc, a1 ; probe ceiling = 4MB - 4 (0x3FFFFC)
move.l (a1), d2 ; save
move.l d1, (a1) ; write marker at top of 4MB window
...
adda.l d0, a0 ; step up through 0x7FFFC, 0xFFFFC, ... in 512KB jumps
cmp.l (a0), d1 ; find where the write actually "landed"
...
move.l a0, d6 ; d6 = actual RAM top
The marker is written just below 0x400000; on a small machine the write wraps to the real RAM top, and the walk finds it. The scan ceiling 0x3FFFFC encodes the 4MB limit.
The RAM-size probe at Mac-Classic.rom:0x25FA is the blocker:
- movea.l #$3ffffc, a1 — the probe ceiling is hardcoded to 4MB − 4 (0x3FFFFC)
- It writes a magic marker ("Tina", 0x54696E61) at 0x3FFFFC, then walks A0 upward from 512KB in 512KB steps, reading back where the marker actually landed (wrap detection).
- The walk bails out as soon as a0 > a1 (bhi at 0x261A), so it can never report more than 0x400000 (4MB).
With 8MB physically present, the marker would land at 0x3FFFFC (no wrap), the walk would find it there, and the ROM would conclude the machine has exactly 4MB. The result feeds $0108 (top-of-RAM) via the boot at 0x401CE0/0x4000A4, so all derived globals (heap end, etc.) would be sized for 4MB and the upper 4MB would be silently ignored.
The patch
At file offset 0x2606 the probe loads its ceiling:
22 7c 00 3f ff fc movea.l #$3ffffc, a1 ; ceiling = 4MB - 4 Change the immediate to 10MB − 4:
22 7c 00 9f ff fc movea.l #$9ffffc, a1 ; ceiling = 10MB - 4 (i.e. bytes 00 3f ff fc → 00 9f ff fc.)
So. If in theory, someone added 10MB of addressable RAM to the Classic, and patched the ROM with that change... the Classic *MIGHT* be able to address up to 10MB of RAM
We might be able to validate this via an emulator | Posted by: kallisti5 on 2026-09-03 07:54:08
Whelp, that was a fun theoretical journey. It's not possible to get any more than 4MB of RAM due to the address-space layout on the classic..
The probe patch only changes what the ROM believes the RAM size is — it can't change what the board physically decodes, and a "small patch + minor hack" can't get around the two hard problems:
1. The 4–16MB address space is already occupied
The Classic's decode puts hardware throughout the region a bigger RAM window would need:
Address
0x400000–0x47FFFF OS ROM (512K)
0x5FF000–0x5FFFFF video / MMU registeres
0x9FFFF8, 0xBFFFF9 video / hardware ID registers
0xE00000+ VIA,SCC,IWM,SCSI.
There is no clean contiguous region above 4MB. The gaps between these devices are holes, but holes can't be used. There is no free address space between the end of the memory and the OS ROM. It's why Apple redesigned the firmware in the Classic II
2. The Mac OS requires one contiguous RAM block from address 0
(omitted supporting evidence, not relevant) | Posted by: Snial on 2026-09-03 07:54:24
This topic comes up from time to time.
The hardware decoding on a Mac Classic (and SE, Plus, 512K(e) and 128K) has a ROM that starts at $400000 (4MB). That's why the ROMs on Macs that can expand up to 4MB stop checking for RAM after $3fffff.
I think theoretically, it might be possible to add more RAM, with a hole in the address space for the ROM.
-cheers from Julz | Posted by: kallisti5 on 2026-09-03 07:57:02
Yup. It was a fun ride. It's a bummer that the Classic is so snug with System 7. A 6-8MB limit would have made the system a *LOT* more usable. | Posted by: Froggy814 on 2026-09-03 09:17:25
That's why the ROMs on Macs that can expand up to 4MB stop checking for RAM after $3fffff. Couldn't you just expand the rom to check to $4fffff? Or is that not possible? | Posted by: kallisti5 on 2026-09-03 10:20:09
Couldn't you just expand the rom to check to $4fffff? Or is that not possible? Theoretically if we had the full source code of the Macintosh Classic ROM chip, then anything is possible. However since it is a black-box, there really isn't a whole lot we can do.
Patching a few addresses in the ROM blob is a potential viable solution, but a fundamental change to the running binary machine code is less easy. | Posted by: kallisti5 on 2026-09-03 10:25:14
though, of note.. this exists for ROM patching: https://github.com/elliotnunn/cdg5 | Posted by: Froggy814 on 2026-09-03 10:36:07
This is an archive containing all of the most popular Macintosh models ROM files for emulation purposes, ranging from the first 64K ROM from the...
www.macintoshrepository.org
there is a classic rom here I think.
1990-10 - A49F9914 - Mac Classic.rom | Posted by: joevt on 2026-09-03 17:14:19
Theoretically if we had the full source code of the Macintosh Classic ROM chip, then anything is possible. However since it is a black-box, there really isn't a whole lot we can do. There is this:
https://68kmla.org/bb/threads/reverse-engineered-rom-sources-for-mac-128k-512k-and-plus.52189/
Which ROM does the Classic have?
1990-10 - A49F9914 - Mac Classic.rom I think that's a patched ROM (with XO ROMDisk)?
Can we get a ROM dump from an unpatched Mac Classic to verify? | Posted by: zigzagjoe on 2026-09-03 18:08:00
Do remember that address decoding happens in hardware, not software or firmware (ROM). | Posted by: warmech on 2026-09-03 21:05:53
Do remember that address decoding happens in hardware, not software or firmware (ROM). This, unfortunately, is very often the answer to the question "Why don't/can't we have X?" for older (or deliberately hobbled) Macs. Well, not "address decoding happens in hardware," but "because X needs changes to Y, and Y happens in hardware." Unfortunately, this is true of the Lisa as well, which has been absolutely confounding when it comes to trying to improve it. 🙁
This, specifically, is why things like improved RAM capacities for things like the SE/Classic/Plus/etc. back in the day all required some kind of accelerator or expansion card: sit on the bus and use its (the accelerator's) own upgraded decoding logic (usually in a PAL or GAL) to do the heavy lifting and allow access to a larger amount of RAM.
Alas, the 68000 Macs are doomed to live in a 4MB world unless someone rearchitects the hardware to use new decoding logic, but that's no easy (or cheap) task. Unless you're, like, zigzagjoe or Alex Anderson-McLeod or bolle. They're sorcerers and we ought to be offering them gold and incense for all the crazy crap they've managed to accomplish, lol. | Posted by: Froggy814 on 2026-09-04 06:27:53
Alas, the 68000 Macs are doomed to live in a 4MB world Don't forget the Portable... And SuperSVGA who somehow got a lot of ram in the Portable.
This, unfortunately, is very often the answer to the question "Why don't/can't we have X?" for older (or deliberately hobbled) Macs. Well, not "address decoding happens in hardware," but "because X needs changes to Y, and Y happens in hardware." Unfortunately, this is true of the Lisa as well, which has been absolutely confounding when it comes to trying to improve it. 🙁
This, specifically, is why things like improved RAM capacities for things like the SE/Classic/Plus/etc. back in the day all required some kind of accelerator or expansion card: sit on the bus and use its (the accelerator's) own upgraded decoding logic (usually in a PAL or GAL) to do the heavy lifting and allow access to a larger amount of RAM.
Alas, the 68000 Macs are doomed to live in a 4MB world unless someone rearchitects the hardware to use new decoding logic, but that's no easy (or cheap) task. Unless you're, like, zigzagjoe or Alex Anderson-McLeod or bolle. They're sorcerers and we ought to be offering them gold and incense for all the crazy crap they've managed to accomplish, lol. That makes sense. Thanks for the explanation!
Do remember that address decoding happens in hardware, not software or firmware (ROM). Hardware! I didn't know that. Thanks! | Posted by: warmech on 2026-09-04 07:36:46
Don't forget the Portable... And SuperSVGA who somehow got a lot of ram in the Portable. You know, I constantly forget the Portable is a thing, lol, and that it's a 68000 machine, AND that it runs at 16MHz. Maybe I'll own one one day, but repairing and maintaining them scares the bejeezus out of me.
And another clarification - it wouldn't have been a PAL or GAL, it would have been PALS or GALS plural. There are some accelerators out there with a whole host of them on their PCBs, lol. | Posted by: joevt on 2026-09-04 14:53:53
Can we get a ROM dump from an unpatched Mac Classic to verify? To be clear, I don't think there exists a ROM dump of the Classic ROM that has not been patched.
The checksum is supposed to be A49F9914, but if you actually calculate it, it is 78A05CEA.
Use the doonerom command on the ROM dump to read and calculate checksums.
https://tinkerdifferent.com/threads/the-granny-smith-emulator.5587/post-49748 | | 1 |
|