Attempt to break the 10MB limit on the Classic II

[Paralel]

I was looking at the way the memory is setup in the Classic II, and it finally dawned on me why the RAM is limited to 10 MB.

They only used 24 address lines! As such, 10 MB RAM + 4 MB ROM leaves 2 MB of addressable space for things like VRAM, etc... through the EAGLE Gate Array chip.

That's why it's impossible to go above 10 MB, there just aren't enough address lines run to the EAGLE Gate Array. In order to go above 10 MB one would need to make a new EAGLE chip, run new address lines to it, etc... it would be a huge task.

Its no wonder they let the Classic II be a cripple, the amount of work to make it address more RAM wasn't worth the effort.

 

[360alaska]

10Mb really isn't an awful limit for a B&W Mac, I run 7.6.1 on mine and it actually runs pretty good

 

[Paralel]

I love my Classic II as well, I'm just glad to finally understand why things were done they way they were done.

I would have preferred more RAM to ROM, but at least they expanded the ROM as much as possible.

 

[techknight]

Yup. 32-bit CPU on a 24-bit system. Basically a 020/030 shoehorned into a 68000 based machine. 

Of course you can draw an extra address line from the CPU, and add an additional 16MB on the tail end of the main address bus. Problem is, you would need a custom driver written to tell the OS to use the 25th address bit as RAM. But keep in mind the system would never be "32-bit clean" and probably isnt now... 

 

[Paralel]

What I find interesting is that the ROM in the Classic II is apparently considered "32-Bit Clean"

 

[commodorejohn]

If the address bus is (effectively) only 24-bit, does it really matter if the ROM is 32-bit clean?

 

[techknight]

"Technically" it doesnt as long as the databus is 32 bit and not 16 or 24 bit.. 

Address bus wouldnt matter, now that I think about it... 

Anyways, all you need is a address decoder/RAM RAS/CAS driver mux for the 25th+ address bit, and somehow write a driver to patch the OS, and trap the various routines in ROM to "stitch" RAM together, if its possible... 

Otherwise you could only allocate a RAM Disk to it using a custom control panel/driver like some accelerator cards supported. 

If you went with SRAM, you wouldnt need all that extra crap. Just an 4 to 16 Decoder with the appropriate lines hooked up. But, you still need the driver/OS/ROM patches to stitch the RAM together, or at least tell the OS where the RAM begins, ignoring the whole lower 10MB.

it would be fun to expand the RAM, but at the same time, do we really need more than that in these machines?

 

[Paralel]

The RAM table is stored in the ROM for the MMU, so I would imagine that is what would need to be patched.

The RAM is originally routed through the EAGLE gate array, but is unnecessary if we're interfacing with the processor directly. I would imagine the EAGLE does all the things you mentioned if you aren't using SRAM. I'd go SRAM since it would just be easier.

I think it would make the machine much more useful in many ways and not such a cripple case if the RAM could be maxed out.

The RAM limit is the one thing people always bitch about, if it can be fixed, why not?

 

[Elfen]

Look at the LC III and LC 475; both have similar Designs to the Classic II but yet address more than 10 Megs.

Plus - they limit the data bus to 16bits instead of 32bits, which would have brought up the RAM to 20megs. The Classic II is nothing more than an LC II crammed into a Classic Mac Case.

But Realization is a Rabid Female Dog!

10Mb really isn't an awful limit for a B&W Mac, I run 7.6.1 on mine and it actually runs pretty good

10MB on a '030 BW Mac (like the SE 30) sucks the Oscar Meyer Wiener. 8Megs is awful on the Classic II, while 16MB is a lot more better. Plus getting RAM to get to 10MB - using 2 4MB SIMMs to get 8 with 2MB on the board. Without that you would need 2 8MB SIMMs for 16MB and get used too the idea that your machine will be blind to 6MB and never use it.

I also have System 7.6.1 on my Classic II and I had to trim the system down by removing resources it would never use - like Color Icons and PowerPC Code!

 

[johnklos]

The width of the data bus has nothing to do with the amount of addressing that can be done. The m68000 has A0, just as the m68020 through m68060 have A0 and A1. When using the bus at 16 or 32 bits, that doesn't give you the ability to make use of A0 and/or A1 to extend addressing past 16 megs on an m68000 or 4 gigs on an m68020, '030, '040 or '060.

The LC III and 475 both have 32 bit data busses, and neither use 24 bit addressing.

There are tricks to extending memory on m68k CPUs, but none would work in the context of Mac OS. For instance, one can use the FC0, FC1 and FC2 pins to separate memory for supervisor mode from memory for user mode. Since Mac OS is always in supervisor mode, this wouldn't be useful on an m68k.

 

[Gorgonops]

The width of the data bus has nothing to do with the amount of addressing that can be done. The m68000 has A0, just as the m68020 through m68060 have A0 and A1. When using the bus at 16 or 32 bits, that doesn't give you the ability to make use of A0 and/or A1 to extend addressing past 16 megs on an m68000 or 4 gigs on an m68020, '030, '040 or '060.

Indeed. Or to put it another way, the address bus on these CPUs is oriented to BYTES, not WORDS. There is a separate set of signals that control how many bytes are transferred over the data bus in a given bus cycle, and these interact with the state of A0 and A1 in various ways dependent on the circumstances.

(The 68020 and higher are perfectly capable of running with 4GB of 8-bit wide RAM should such a thing make some sort sense to you. If you really want the nitty gritty details it's all in chapter five of the 68020 user manual, a trivial to Google PDF.)

Didn't we basically have this same discussion about the architecture of these machines about a year ago and likewise debunk this "it would be 20 megs if it were wider!" notion then?

 

[Paralel]

I do remember that conversation. It was interesting. I'll have to read it again.

Well. I guess the Classic is stuck at 10 MB then...

 

[techknight]

Yea there was another thread. 

Thats why I said you can stick RAM at the end of the main address bus. Starting at the 25th Address bit. 

Its just a matter of hacking up ROM/OS to use it as RAM. 

 

[Paralel]

From going over the Dev Note carefully, it looks like it would be really difficult to do, the MMU table in the ROM would be easy to handle, but apparently the total RAM amount is reported by the EAGLE gate array, so that would need to be completely reverse engineered, figure out how it come up with the total RAM, how it reports it, how it can be expanded... I can see why no one ever bothered...

What's interesting is that there is at least one accelerator out there that is able to break the 10 MB barrier for the LC series, and pushes it to 12 MB, which is really no big deal, but its something. But from the DEV note apparently the EAGLE gate array handles RAM differently than the LC did, so that solution is unlikely to work, I would imagine.

Does the CC use an EAGLE gate array? If so, maybe, eventually, if someone could reverse the Eagle gate array, it would at least benefit both the Classic II and the Color Classic.

 

[yuhong]

Color Classic is basically another variant of the LC/LC II logic board design I think. I think the reason why a LC III based logic board design for the Classic II case was never done was that the mono 512x342 display was getting obsolete.

 

[Gorgonops]

From going over the Dev Note carefully, it looks like it would be really difficult to do, the MMU table in the ROM would be easy to handle, but apparently the total RAM amount is reported by the EAGLE gate array, so that would need to be completely reverse engineered, figure out how it come up with the total RAM, how it reports it, how it can be expanded... I can see why no one ever bothered...

This is me being too lazy to look up that other thread and see if the answer was already in there, but I did google up the Classic II DevNote and I'm left wondering something: do the "neutered" LC-based systems actually use the MMU on the 68030 to manage their memory map?

I vaguely recall why/how the "real" Macintosh II-based Macs equipped with RAM sockets that can take different-sized SIMMs use the MMU instead of dedicated hardware to "pack down" the RAM in physically dis-contiguous banks into a logically linear chunk for the MacOS (and also how they mask/juggle parts of the memory map when they're set to operate in 24 bit addressing mode), but... the LC was designed to use both an MMU-less CPU (the 68020) and only has two SIMM sockets, so would it not be logical to just hardcode the limited mapping possibilities into the system ASIC and switch between them by tickling a register? It seems a little suspicious how the Classic II devnote specifically claims it's the EAGLE's responsibility to provide memory mapping functionality.

So... yeah, I'm genuinely curious if the 68030's MMU is used in these "LC-type" machines for performing any address translation work like it does in the "bigger" models, or if it's literally completely redundant unless virtual memory is enabled. (The only other 68020-based Mac, the original Mac II, came with that dingus that could do address translation but no paging in the 68851 MMU socket; apparently that thing was at least partially compatible with the 68851 because the same ROM code can run a Mac II with either installed... but I don't see any reason why Apple would have bothered with building something that sophisticated into the LC's system ASIC since it was specifically designed to *not* be upgradable to an MMU. Of course, that everything other than the original LC shipped with an MMU anyway so... I have no idea what they were thinking.)

Anyway, as Techknight says, since all these machines other than the original LC *do* have programmable MMUs I don't see any real barrier in principle to hanging additional RAM directly off the CPU bus (although there are practical issues, like how doing so would probably call for having to desolder the CPU in order to stick in a daughterboard) that's physically mapped to the A25 and higher address lines, but there would be some devils in those details. The biggest issue I see is according to the memory map in the Classic II devnote the framebuffer is actually located at *just under* the 10MB boundary in *both* 24bit and 32bit address mode. (Because the Classic II steals system RAM for video, unlike the SE/30 which has a tiny chunk of dedicated VRAM mapped like a NuBus card.) This means that you would have to use either the MMU or some hardware on your daughtercard to relocate that upwards so MacOS can have the contiguous chunk of RAM it wants, and you'll have to modify the video driver to understand that you've moved it... ugh. That's actually sort of a gross problem. Maybe the simplest way to handle it would actually be to, when running in 32 bit addressing mode, map your expansion memory to the *zero* position and swap the EAGLE controlled RAM to the end, adjusting ScrnBase accordingly.

 

[yuhong]

I think that is exactly what the original Mac LC does. LC II I think switched to using the PMMU hardware inside the 68030.

 

[Paralel]

Gorgonops, that's a really good point. Why have the EAGLE involved at all? Its a curious situation.

 

[Elfen]

Gorgonops, that's a really good point. Why have the EAGLE involved at all? Its a curious situation.

Now that is a good question...

This situation also seems to be the case with the PowerBooks from what I hear (and the Duo's as I seen it as that is what my PB Collection mainly is. An EAGLE crippling the MMU in the '030s? Hmmmm....). The Powerbooks are not as limited as the Classic II or the LC II but in thinking about it there is a limit as to how far can they go.