Can the Macintosh Plus be modified to support 16MB RAM?

[wskjinfen]

Is it possible to generate the RA10 signal by some method, and do I need to consider the refresh issue? If this is possible, does the ROM need to be modified?

 

[croissantking]

That’s a hard no, I’m afraid!

While the 68000 can address 16MB, some of that is used for ROM and I/O. And I think the ROM resides at the 4MB mark which means in order to use some of the available space for extra RAM, it would have to be non-contiguous, which isn’t supported as there’s no MMU.

 

[finkmac]

there's several accelerators that do 16mb


of course they also add a 68020 or 68030...

 

[croissantking]

there's several accelerators that do 16mb


of course they also add a 68020 or 68030...

Ah yes, you could through an accelerator, but I thought op wanted to do it without one.

 

[wskjinfen]

That’s a hard no, I’m afraid!

While the 68000 can address 16MB, some of that is used for ROM and I/O. And I think the ROM resides at the 4MB mark which means in order to use some of the available space for extra RAM, it would have to be non-contiguous, which isn’t supported as there’s no MMU.

QAQ ok thanks

 

[croissantking]

The Macintosh Portable and PowerBook 100 are the only 68000s that can address more than 4MB, but I forget how they do that.

 

[olePigeon]

You can with some clever tricks. A few accelerators bypassed the limit by using a combination of a RAM disk & virtual memory. The software was called Compact Virtual by Connectix. The extra RAM was first used to make a RAM disk, then a virtual memory implementation utilized the RAM disk for the VM storage. Since it's a RAM disk and it ran at RAM speed, that meant there was little to no slowdown for the virtual memory.

I don't know if this trick would be possible without an MMU, though. But ... maybe?

 

[olePigeon]

Some basic Googling seems to indicate that you can't use virtual memory without an MMU.

Probably why even the simplest upgrade was also an accelerator with a 68010 or 68020 so they could add that MMU and utilize the full 16 MBs.

 

[adespoton]

68000 has fixed offsets referenced and a 4MB boundary due to the fixed ROM address, as @croissantking mentioned. This means that you'd need to do something like add a secondary controller (ie MMU) that could page the first 4MB out to some other location and page the higher memory in. I suppose if you were willing to give up a register the secondary controller could use to track pages, you could do something, but then you'd slam right into the fact that existing software expects the 68k registers to behave in a particular manner already.

I wonder if the ROM itself could be rewritten in such a way that it moves itself to a higher address after initial load, freeing up the entire 16MB for RAM addressing? Kinda-sorta seems like there might be a way to do it by replacing the ROM with something a bit more capable, assuming it isn't hardware-bound, which it shouldn't be (since the ROM gets patched all over the place already). It *might* require patching the OS to treat the ROM as a masked out area of memory? Probably wouldn't work with System 4.x and lower that load everything from the base address, but System 7 should be able to handle that, even without an MMU, and System 6 *might* be able to?

Any way you look at it, it would involve more than just adding in two 8MB SIMMs.

 

[Snial]

68000 has fixed offsets referenced and a 4MB boundary due to the fixed ROM address, as @croissantking mentioned. This means that you'd need to do something like add a secondary controller (ie MMU) that could page the first 4MB out to some other location and page the higher memory in. I suppose if you were willing to give up a register the secondary controller could use to track pages, you could do something, but then you'd slam right into the fact that existing software expects the 68k registers to behave in a particular manner already.

I wonder if the ROM itself could be rewritten in such a way that it moves itself to a higher address after initial load, freeing up the entire 16MB for RAM addressing? Kinda-sorta seems like there might be a way to do it by replacing the ROM with something a bit more capable, assuming it isn't hardware-bound, which it shouldn't be (since the ROM gets patched all over the place already). It *might* require patching the OS to treat the ROM as a masked out area of memory? Probably wouldn't work with System 4.x and lower that load everything from the base address, but System 7 should be able to handle that, even without an MMU, and System 6 *might* be able to?

Any way you look at it, it would involve more than just adding in two 8MB SIMMs.

The PowerBook 100 did it by moving the ROM to a higher address (@croissantking ), allowing up to, I think about 9MB (well, at least 6MB, because my PB 100 had 6MB). Theoretically, and we'e covered this before: a Mac Plus could do with its existing ROM it if we accept non-contiguous RAM. Here's how:

1. The Mac Plus boots its ROM and sees 4MB - that's fine.
2. The Boot blocks run and then the OS starts to be loaded.
3. There's an INIT (or extension in System 7) added to the OS which modifies the heap:
   1. it searches for RAM in other locations, e.g. from just after the ROM at $41ffff to $800000: looking for another 3.875MB of RAM.
   2. It creates an allocated hole in the RAM corresponding to the ROM to prevent it being allocated.
4. You have an application space from 0 to 4MB (-the screen) + 4.125MB to 8MB.

You might think this is a bit pointless, but it's not, because although you can't run programs bigger than 3MB you can run more apps up to a total of nearly 7MB. And with System 7 taking up 1MB+ the upper RAM area would be bigger.

I wrote an app which simulated the beginning of this and you can read about it here.

MacSE-RAM, a crazy Mac SE PDS RAM concept!

I'm afraid there are lots of places in the OS, especially in early boot, where it assumes the RAM is all contiguous. Once the memory manager is started, yes, you might be able to get away with permanent allocations, but getting it to the point where the memory manager is working will be more...

68kmla.org

Since I have a better understanding of the pce-mac emulator, I might be able to modify it to simulate 8MB of RAM and turn the app into an INIT/Extension.

 

[Jens Larsen]

I hope you have lots of spare time! I just acquired a Plus from a member here. I'm always looking for ways to tweak my various computers. Adding RAM? Moving ROM into RAM? Sounds good to me. IF you go this route, I hope you'll keep us in the loop.

 

[Trash80toHP_Mini]

The PowerBook 100 did it by moving the ROM to a higher address (@croissantking ), allowing up to, I think about 9MB (well, at least 6MB, because my PB 100 had 6MB).

It's 8MB as was mine in the day as soon as I could get an order off to APS for that card, their faster Modem, and a 230MB HDD for BabyPB.

Since I've learned of the Portable's 9MB capability, I've been very curious about the RAM based Video Out card for the PB100. I wonder if Sony reserved the memory space for that 9th Meg for the VidCard? Likely not, max RAM loadout appears to have been reduced by installing that interface card?

Be that as it may, I held off on posting the "HARD NO" that @croissantking let you down with (as softly as possible) in the first response.

I still have my doubts about the inability to address additional memory in a non-contiguous fashion for the 68000. IIRC using RAMdisk+ to set up a (virtual memory?) RAM Disk boot drive within the luxurious 8MB I had to play with in my spankin' new PB100. It was wicked fast, with over 4MB of System Memory left for normal use. Then again it was under 6.0.8, which seemed very fast to begin with as opposed to my SE running that newfangled System 7, even with Radius 16 on board.

Dunno, not likely, but might this longwinded drivel shake something loose in the noggin of one of our resident boffins?

 

[Snial]

It's 8MB <snip> Portable's 9MB capability <snip> RAM based Video Out card <snip> wonder if Sony reserved

From the Developer notes: https://www.macdat.net/files/pdf/apple/developer_notes/powerbook_100.pdf

From the document, the PB 100 has some 70ns video RAM. An earlier page shows the block diagram for the PB 100:



But it's wrong here, the Internal Expansion connector should say "A22-A1", because A19-1 only provides for 2MB. It's a typo, copied from the internal RAM address range. A22-A1 limits the RAM expansion to 8MB. Either that, or they mean there's 3 /CS signals + A19-A1 so that 3x 2MB of expansion RAM can be connected.

My personal opinion is that the early memory map on a Mac all the way to a Plus was dreadful. For the cost of a 74138, they could have put the ROM and I/O in the top 2MB (16MB/8) and subdivided further into 8x 256kB blocks for ROM, and all the devices (ROM, VIA, IWM, SCSI, Serial, + 5 spare for expansion?). Then 14MB Macs would have been possible.

Be that as it may, I held off on posting the "HARD NO" that @croissantking let you down with (as softly as possible) in the first response.

I don't feel let down, I just don't think it's correct.

I still have my doubts about the inability to address additional memory in a non-contiguous fashion for the 68000.

A 68000 would be able to address all the remaining holes in the address space non-contiguously of course. What you can't do is expect the Plus's RAM slots to support 8MB easily. However, you could probably patch an additional address line from the 68000 to the 30-pin SIMM slots. 30-pin SIMMs have /CAS and /RAS address lines wired in, but have 12 address lines (A0-A11) and can individually address up to 16MB. However, A Mac plus has 2 SIMM slots so in theory it could address up to 32MB if the 68000 could (which of course it can't, unless you use the FC signals. Then you could have 16MB user space + 16MB supervisor space at least).

Instead, in the 4MB configuration, SIMM A0-A10 are mapped to A1-A11 (for /CAS) and A12-A21 (for /RAS) on the 68000's address bus. Not being totally familiar with the actual schematic, I suspect there's latches for /RAS and /CAS for A1-A11 and A12-A21; as well as data latches for D0-D15. Decode logic forces /WE high and D0-D15 read enable high if A22 NOR A23 [ /WE=MC68000.WE OR (A22 NOR A23); /RamRd=MC68000.RD OR (A22 NOR A23); ]. Note, the schematic will use different signal names.

In theory then I think that by patching A22 through to the A10 /RAS latch and by replacing (A22 NOR A23) with different decode logic (A23 OR (A22 AND NOT(A21 OR A20 OR A19 OR A18)) means 8MB would be supported, except for 256kB of RAM from $400000 to $43ffff . I don't know if screen memory would also be mirrored at the top of 8MB and 4MB if that was done; I don't know if the upper address bits are fully decoded for that.

<snip> RAM Disk boot <snip>

In the previous discussion, centred on the SE, it was suggested that the PDS card could be used to provide a RAM disk

Dunno, not likely, but might this longwinded drivel shake something loose in the noggin of one of our resident boffins?

So, I think that in my earlier post, I provided a software mechanism to access up to nearly 8MB and did some early experimentation. The next step, I think would be for me to modify the pce-mac emulator to support 8MB of RAM with a 25kB hole for ROM at $400000 and then change my AppGap app to an INIT which expanded the heap and allocated a fixed 256kB hole in the heap for RAM; which I'll call MacPlusROM (i.e. in the Finder or MultFinder it would look like there's a fixed application called MacPlusROM occupying 256kB in the middle of the application space).

-cheers from Julz

 

[croissantking]

Be that as it may, I held off on posting the "HARD NO" that @croissantking let you down with (as softly as possible)

LOL. Maybe a better answer would be that nobody has figured it out yet. Sorry to anyone I may have upset.

Could an early Mac have a custom ROM installed (like a Rominator) that maps the ROM to a higher location, the same as the PB100 and Portable? If software expects the ROM to be at $400000 could a custom bootloader or extension translate the addresses on the fly?

 

[Trash80toHP_Mini]

Now that I'm waking up, I see a possible problem. Luggable and PB100 use PSRAM with the direct addressing setup of SRAM. But the Compact Mac uses DRAM in Banks with CAS/RAS complications.

Plus/SE/Classic may only have a single bank(?) but its setup is very different from PB100/Luggable, no? Guessing a bodge in emulation might work, but hit a brick wall in hardware?

 

[Snial]

LOL. Maybe a better answer would be that nobody has figured it out yet. Sorry to anyone I may have upset.

It's OK, I wasn't remotely upset. One thing I have realised though is that the INIT can't be quite as I imagined, because I can't allocate a process until Multifinder is booted up and I don't think I can adjust the whole memory size after MultiFinder is booted. Really, then I need an INIT that can modify the RAM size and create a memory hole at a fixed location too.

Could an early Mac have a custom ROM installed (like a Rominator) that maps the ROM to a higher location, the same as the PB100 and Portable? If software expects the ROM to be at $400000 could a custom bootloader or extension translate the addresses on the fly?

If I was going to relocate a Mac Plus ROM, I'd relocate it to the highest 128kB slot I could so that perhaps you could get more than 8MB of contiguous RAM.

But there are a few problems, besides the obvious ones of having to track down all the absolute addresses. One major problem is that you can construct absolute addresses in non-obvious ways, such as the mechanism used to modify the 64kB ROM to support the mythical 256kB Mac:

000002DE 7204 MOVEQ #$00000004, D1
000002E0 4841 SWAP D1
000002E2 2241 MOVEA.L D1, A1
000002E4 D281 ADD.L D1, D1
000002E6 2041 MOVEA.L D1, A0
000002E8 42A0 CLR.L -(A0)
000002EA 4AA1 TST.L -(A1)
000002EC 6602 BNE.S $000002F0
000002EE E489 LSR.L #$2, D1
000002F0 2041 MOVEA.L D1, A0

The MOVEQ, SWAP, MOVEA, MOVEA sequence at 4 words is 2 words shorter than MOVEA #40000,A1: MOVEA #80000,A0. There's a high likelihood ToolBox programmers used comparable tricks on the Mac Plus ROM (partly because even though they now had 128kB, most of the ROM will be a copy of the 64kB ROM).

Again, though, the most sensible thing to do is to try it with an emulator first. I suggest Pce-Mac rather than MAME or miniVMac, because it's easier to hack even if people aren't so familiar with it.

 

[olePigeon]

@Snial Could that INIT also allow for virtual memory beyond 8MBs to the maximum of 16MBs? Or would that still require the hardware MMU component?

 

[Snial]

@Snial Could that INIT also allow for virtual memory beyond 8MBs to the maximum of 16MBs? Or would that still require the hardware MMU component?

Macs with virtual memory support always have an MMU and therefore can support physical RAM beyond 8MB and virtual memory beyond 16MB.

 

[Snial]

@Snial Could that INIT also allow for virtual memory beyond 8MBs to the maximum of 16MBs? Or would that still require the hardware MMU component?

Hi @olePigeon , I was a bit terse with the last reply and I think I should rephrase it. The topic here is whether 68000 compact Macs which normally have a 4MB RAM limitation could be hacked to support far more than that. There are three basic options people have considered:

1. On an SE, you could add extra discontiguous RAM on a PDS card and use it as a RAM disk. I think there are references to a product of this kind.
2. On a Plus, SE or Classic, by relocating the ROM to a higher address to make more room for RAM, as it was done on a PowerBook 100. I would have thought that this is easier for a Plus than the other two because the ROM is smaller.
3. On a Plus, SE or Clssic by adding RAM in the 4MB to 8MB region, then creating a hole in RAM for the ROM. You need to add an INIT to let the Mac see the extra 4MB and create the hole (i.e. a block of unpurgeable, allocated memory). The OS will then allocate memory around the hole. This is the approach I'm curious about, because it means you don't have to relocate the ROM.

None of these Macs have virtual memory support, even though they can support up to System 7.5.x, because the MC68000 doesn't have an MMU. There are some projects to replace the CPU with a 68030, in which case these systems become a lot like the Mac SE/30 or Classic II. In practice all the Macs which do support virtual memory also support at least 8MB of RAM (like the Mac II, which with an external MMU was still limited by its ROM not being 32-bit clean) or 10Mb of RAM in the case of the LC II. And of course, Macs that support VM can have far more disk space allocated to VM than a standard MC68000 can support. For example, you could take a stock LC II with 4MB of RAM and set VM to 20MB if you want. The computer would likely be horrifically slow as it continually swaps from disk to a meagre 4MB of real RAM, but it could be done.

I hope that's a more comprehensive answer.

 

[Trash80toHP_Mini]

You might want to consider that the Luggable/PB100 are akin to (based upon) the more advanced SE Slot Manager architecture. You might have some luck barking up that tree in terms of your emulation adventures?

Methinks the other 68000 Compacts would be very much the wrong tree, just lift your leg on those.