From 16 to 32 Bits; Expanding the LC RAM Bus Possible?

[Elfen]

This has been on my mind for years, and have never acted on it. But where does it say that an LC or Classic is stuck at 10 Megs of RAM? Most II Series data bus is 32 bits, thus making a 4MB address into 16MB of RAM in 32 bit.

But the LC and a couple of others are 16 bits, which would make a 4MB address into 8MB of RAM in 16 bit. Thus the 10MB RAM size in an LC is just in 16 bits. If the bus can be expanded to 32 bits, it increases the RAM size to double!

Since finding the Classic II and comparing it to the SE/30, there is very little difference between 16 bit Classic II and the 32 bit SE/30. The SIMMs share many lines. Thus is one can pull out the lines into a separate board to add RAM into the missing 16 bits, I believe one can expand the RAM to double on these machines.

Looking at the Classic II, there are 4 - 4 bit X 1 Meg Chips - 44C1000-8, giving the board 2 MB in 16 bits. On a separate board with 4 more 44C1000-8, and have them share all but the Data Bus Lines and then line up each data bus line to the missing bits, you have just increased the RAM from 2 MB in 16 bits  to 4 MB in 32 bits. Doing the same with 2 added SIMM sockets on the same board, you can now increase the RAM on the Classic II from 10MB to 20MB!

Question is, would ROM Routines stop this? The ROMs themselves are in 32 bits - 4 - 27C010 EPROMS on my board; each 27C010 is 8 bits wide. 4 X 8 is 32. This is also true with the LCs

So the question is, can it be done? In theory it can. In my mind I believe it can. So I provide a simple diagram from which a board can be drawn up. If you think that it can't, explain what you know. Don't just say that it can't, prove from what you know why it can't.

Given time and money I will try to build such a board and try it on the Classic II. If successful, then I can design and create another for the LC's.

 

[IPalindromeI]

Can everything else handle it? I'm not familiar with the LCs, but is there DMA and controllers? They might not be able to handle it.

 

[Trash80toHP_Mini]

Question is, would ROM Routines stop this?

Yup, Apple hobbled those machines thoroughly. bbraun posted the info on this somewhere or other, dunno if he found a workaround.

AFAIK, a Presto Plus(?) is the only way to un-Road them Apples.

.

 

[Paralel]

So, one would have to end up re-writing most of the ROM then... That's an unenviable task, to say the least...

 

[Elfen]

Not the entire ROM, but the part that flips the ROM to it's higher place and then forces the 68K to be in 16bit mode for the RAM. If anything, less than 30 bytes. 30 bytes out of 1 or 2 megs worth of code, though this would be at the very beginning of the ROM, perhaps within the top 2K of it if not smaller.

 

[Paralel]

I seem to remember someone here thinking the same thing a while back, but as they dug further and further into it, it got uglier and uglier...

 

[Elfen]

Frankenstein's monster was pretty ugly too. It only got worse when it asked the doctor to give him a mate. I'll give it that.

Got Link, Paralel? I want to compare notes.

 

[olePigeon]

Sonnet did it with their Presto Plus.  Some sort of wizardry, and they added another 32MBs of RAM.

 

[Trash80toHP_Mini]

I think the adding that RAM SIMM onto the '040 Processor Upgrade/Ethernet Card is just about all the magic needed, aside from the system enabler that just flat out ignores the icky parts of the LC ROM, of course.

The LC ain't gonna be addressing more than 10MB ever, by the time it can, it's an LC no more . . .

. . . more like a Quadra:

http://www.everymac.com/upgrade_cards/sonnettech/presto/presto_plus.html

.

 

[Gorgonops]

Not the entire ROM, but the part that flips the ROM to it's higher place and then forces the 68K to be in 16bit mode for the RAM.

Color me Mr. Skeptical, but I doubt that there's anything in the LC's ROM that has anything to do with the 16 bit bus width. (Other than *possibly* some device driver handling code but I'm not going to get into that other than note that open-source *nix authors have discovered when porting Linux/xBSD to the 680x0 Macs that Apple was sometimes *incredibly* lazy with how they implemented bus decoding; it's possible there are devices in the LC that are not transparently handled by the process I'm about to describe.)

The 68020 and 68030 have hardware support for "Dynamic Bus Sizing"; there are a couple *input* lines to the CPU (DSACKx) through which an external device (be that a memory mapped peripheral, RAM, whatever) can automatically signal whether it's 8, 16, or 32 bits wide thereby instructing the CPU will use an onboard multiplexer/buffer to split up the read/write operation into a suitable number of bus cycles. (Information on this is in the 68030 user manual, you can look it up.) This process is completely transparent to software running on the system, and I am 99.44+% sure that the memory controller in the LC handles all the work of signalling the CPU to switch into 16 bit mode when it accesses the RAM area. In fact, I rather doubt there *is* a software command you could give the 68020/30 that would force it to mask out a whole area to be accessed at X bus width *without* setting the hardware up appropriately.

In fact, you can basically prove that the LC/LCII is using the dynamic bus sizing just by looking at the block diagram in the developer note. (Unfortunately I could only find the Devnote for the LC II, which concentrates only on the few differences between the systems; the straight-up LC Devnote probably explains in detail how it's using DBS.) Note how data lines *16 through 31* connect to RAM via a set of 74245 buffers, not 0 through 15; as explained in the 68030 manual it's the uppermost address lines that are used for any given bus size. (IE, if you throttled the bus down to 8 bit you'd use 24-31, not 0-7. And in fact, if you look at the block diagrams you'll see the SCSI and SWIM chips, 8 bit peripherals, are indeed hung off of those lines.) So what does this mean for the prospect of trying to double the RAM size by paralleling another set of RAM chips onto the bottom 16 bits of the CPU data bus? Well, it means that unless you were to cut the DSACK lines loose from the stock memory controller and insert a circuit that would instead generate signals indicating a full 32 bit bus width was available when the CPU addressed the RAM area the system would *completely ignore* your pasted-on memory.

Switching over to the Classic II devnote, since I can find that, I see another possible problem. It looks to me as if the onboard memory controller is actually physically mapping all 10MB of the possible RAM into a linear block from $00000000 to $009FFFF; unlike the "Real" Mac II family, where the SIMM socket addresses are scattered over a huge addressing range and the MMU is used to collate all the physical memory together into a linear block the Classic II and LC/LCII appear to do that in hardware. Here's the problem with that: If you did hack DSACK and parallel on another RAM bank then instead of RAM cutting off at the 10MB mark it'll cut off at the 20MB mark... and therefore land right on top of where the video, ROM, and expansion areas are mapped in 24 bit mode. This would be a *physical* contention, not a "logical" one. So, yeah... that ain't going to work.

Short answer is it seems to me you're not going to be able to do this without essentially replacing the onboard RAM controller. (Which is essentially what a board like the Presto Plus does.) Frankly it seems like you'd have better luck just hanging another bank of RAM off the PDS slot and using a low-level device driver to instruct the system's MMU to map that memory contiguously after the 10MB onboard when the system is in 32 bit addressing mode. (Which the Presto Plus may well also do.)

 

[Gorgonops]

... Too late to edit, but, yes; the Classic II's developer note specifically says that the "EAGLE" system controller generates DSACK bus sizing signals when RAM is accessed.

 

[Elfen]

Those are some excellent points, Gorgonops. Thanks for pointing it out.

There is one point I do not agree with and thats is where 20megs would land if the databus bus were to be expanded. It would not do down past $009FFFF, but only widen the bus, still being with 10megs of memory barrier but 20megs at 32 bits and not 10 megs at 16bits. Thus it would not land into video memory if added by widening the bus.

But everything else is every informative. Thanks for your input.

 

[olePigeon]

I think the best idea would be the PDS route.  I had this idea not too long ago, though I don't know how feasible it'd be since I'm not very knowledgeable with this kind of stuff.  Have a PDS card with 8 RAM slots on it.  Have a device driver that maps the memory for you.  Or do something like the 128k/512k/SE upgrades and make it a RAM disk instead, then just use software such as Virtual Compact (or a driver in ROM) and use the RAM disk as virtual memory storage.

 

[Gorgonops]

There is one point I do not agree with and thats is where 20megs would land if the databus bus were to be expanded. It would not do down past $009FFFF, but only widen the bus, still being with 10megs of memory barrier but 20megs at 32 bits and not 10 megs at 16bits. Thus it would not land into video memory if added by widening the bus.

No, it *would* be 20MB of RAM. Addresses on the 680x0 series of CPUs are in bytes, not words, look it up. By doubling the width you're doubling the size and landing it on top of the 24 bit ROM/peripheral area. (And again, this is why doubling the width would effectively require a new memory controller. You have to map that additional chunk of RAM "somewhere else" and have a mechanism for switching it in when you go to 32 bit mode.)

(Edit: Actually, that points out another problem, which again means "new memory controller": It's the ASIC that generates the addressing signals for the RAM from the address bus output by the computer. That ASIC knows that RAM is only 16 bits wide and translates accordingly. So, yet again, *IT* has to know you doubled the width of memory or you're essentially going to end up with... 10MB of RAM that's double-mapped, not the 20MB you *want* to get out of this.)

 

[Elfen]

Interesting...

 

[Gorgonops]

Read the section about "Byte Selection Logic" in the 68030 manual, it tells you all you need to know. Heck, it even has an example illustrating the bus cycles generated from a scenario involving fetching an odd-byte-aligned 32 bit word from a 16 bit wide RAM. Section 12, page 10 of this manual.

The unsurmountable problem here is the default memory controller ASIC is set up to generate 16 bit aligned addresses for its "private" bus to the onboard RAM (IE, the multiplexed area) for all "true" addresses between 000000 and 9FFFFF. If you double the *width* of the RAM then you need to re-jigger that ASIC so it knows to activate the correct "slice" of RAM for any given address produced by the CPU. (IE, instead of presenting its 10 MegaBYTEs of RAM as 5Mega-16-Bit-ShortWords it instead needs to present itself as 2.5Mega-Longwords... while, again, having it also generate the correct DSACKx signals for a 32 bit memory bank.) If you don't fix this and just hack DSACK then... I suspect what will happen is that every other word written to RAM will end up in a different "half bank" depending on its 16 bit word alignment, which will translate to massive memory corruption. Aaaand, as noted already, even if you do fix *these* problems entirely (both the word alignment and reported transfer sizes) you're still limited to 10MB of RAM, albeit 32 bit wide instead of 16, unless you also figure out a mechanism to map the *other* 2.5 million words of memory space to a non-conflicting area in 24-bit addressing mode and patch the ROM so it knows how switch it back into linear alignment when you switch to 32 bit.

For that last part you *could* potentially use the 63030's built in MMU on the LCII and Classic II but if you want compatibility with the 68020 LC then you'll have to use an address/bank switch built into your new memory controller. And really, that's what this boils down to, needing a new memory controller. Since the VRAM address bus is also generated this thing patching around it externally so it handles DSACKx correctly for wider RAM would be... non-trivial. So far as that goes, it looks like the thing only sits on address lines 0-23 (and 31, which is only used in 32 bit mode to move the peripheral space), so... it actually is physically incapable of handling RAM that would cross the 16MB mark unless you added more external address decoding hardware. (Which, as noted, isn't that big of a deal because you wouldn't be able to use any more than 10MB unless you added bank switching logic too...)

In short, these things are *really* hardwired to be the way they are. If you give up on the "make it wider" thing (that adds too many problems) then... I dunno, *maybe* you could piggyback another set of SIMMs onto the SIMMs that are there and use a blob of external logic to add another 10MB wide 16 bit memory bank running from $01000000 to $019FFFFF? To do that you'd decode A24, cut the chip enable lines that run to the existing RAM, and put an gate on it so if A24 were high the new SIMMs would drive the bus, if not the low set would. You'd still have a 6MB "memory hole" between that bank and the first one that you'd have to program the MMU to close, so it's still not going to work on the original LC, but it's the only way I can see for adding RAM using the original controller that doesn't require completely gutting it and/or using a PDS slot.

 

[Trash80toHP_Mini]

RoadApple'd-n-run'dover-GOOD! LC POS!

 

[Gorgonops]

Honestly... I sort of have to respect what they did here. Clearly they were on a mission to make a Color Macintosh as cheaply as possible and they pretty much pulled no punches doing it. Or, to put it another way, it comes by its cheapness "honestly" rather than just being a better machine trivially kneecapped. There are advantages to the way they did it; by limiting system RAM to 10MB they removed the need to remap memory out of the 24 bit addressing area, which meant the 68020's lack of an MMU was no problem. (And the resulting chipset could be simpler than the HMMU they stuck in the original MMU-socketed-Mac II.) In fact, the architecture is so "16 bit-y" I have to wonder if they might have given thought to basing it on the 68000 and only discarded the idea because they didn't want to encourage authors to write non-32-bit-clean color software. (Or maintain a 68000 version of Color Quickdraw.)

Of course, a downside of using a downsized bus for RAM means that not only is the bus half as wide, it has to run in asynchronous mode. (IE, you can't use the synchronous or burst modes supported by the 68030.) That makes it a minimum of three clock cycles per bus transfer, vs. the two of a machine that can use synchronous mode, *plus* needing at least two bus cycles to read a 32 bit word. (Three if it's not word-aligned, although that probably wasn't a huge problem most of the time because the 68000 requires at least instructions to be aligned to even addresses; that restriction was lifted with the 68020 but violating it entails a speed penalty.) So compared to, say, a "real" 68030 Mac like the IIfx, a typical instruction read takes at least six clock cycles verses two. Ouch. But hey, it's honestly cheap!

Oh, another thing that sort of torpedoes this "make it wider" idea: The memory controller also has the sound generation hardware embedded in it and that uses 16 bit DMA. There's basically no way you're going to be able to patch that up externally.

 

[Trash80toHP_Mini]

Honestly... I sort of have to respect what they did here. Clearly they were on a mission to make a Color Macintosh as cheaply as possible and they pretty much pulled no punches doing it.

Sounds more to me like they added color ROMs & misc. I/O while copying the design of the Radius_16 Accelerator outright.

< . . . widening the data bus of an LC . . . the icing on the . . . turd? >

.