Attempt to break the 10MB limit on the Classic II

[techknight]

Thats what ive been saying all along. EAGLE doesnt matter, you patch all that shit out... The hardest part to the whole thing is developing the hardware and figuring out where to "tap in"...

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, 

Again, your not thinking 4th dimensional! Total RAM reported by eagle to what? Something has to ask it to report it back. Patch that shit out like I said above! I dont think the MMU is used, the EAGLE probable handles where its mapped in the address map. But that doesnt matter. Use a peice of software to setup the MMU inside the chip with both chunks of memory and their start/end addresses after the machine boots and does its required remap for interrupt vectoring. Since your not modifying the hardware on the lower chunk, everything stays the same. the added upper chunk is put inside the MMU tables, and now you have one contiguous chunk of RAM.

After that, its a matter of patching the different variables in low RAM that tells the OS how much RAM is there. Done.... 

I havent seen a classic II board in awhile, so its possible the ROM is socketed and an adapter board could be inserted in place of the ROMs, whereas the new board which has RAM expansion also has flashible ROMs with a modded ROM and all the dougg3 additions within it. Youll still need to run an A25 line or other possible lines such as R/W, etc... 

The other hard part possibly is when adding the RAM together contiguous, it may move/remap the ROM. if it does, it probably wont work. So its something that has to be played around with. 

The address bus is on a 16MB barrier. A24. Technically accessing the 16.1th megabyte, toggles the A25 line, but the bus will just "repeat" as if it were address 0. This may work to our advantage, This will allow system RAM to show up in 2 locations. at 0 to satisfy interrupt vectoring, display refresh, and other stuff. But it repeats itself at the end, and then you map the extended memory right up against the repeated locations, replacing the "ROM repeat" and bingo. you make changes at 0, it gets reflected at the 2nd half of the 16MB chunk. Tell the PMMU to work with ONLY the 2nd 16MB, This allows the OS to still continue to make changes to A-trap handlers, adding.changing vertical blanking stuff, etc... in the upper 16MB. But those changes still point to the same RAM bank. so the "CPU" and hardware is still happy because those changes are being reflected back to the 0 address. 

Thats how you solve RAM/ROM address contiguation conundrum without crashing the whole system. 

I feel this is the only way to make use of full system memory past 10MB. 

Otherwise, your stuck adding RAM at the 2nd 16MB page, and making a program that works like RamDoubler, but uses the additional memory that is segmented. So it still shows 10MB, and then it shows 16MB of Extended memory. So instead of creating virtual memory on the HDD, your creating "virtual memory" in the extended RAM bank. it wouldnt know the difference. 

 

[Gorgonops]

Of course, I suppose one has to be the devil's advocate here and ask exactly what application there is that really needs more than 10MB of RAM but would otherwise run okay on a system only 75%-ish as fast as an SE/30...

 

[Elfen]

Thats what ive been saying all along. EAGLE doesnt matter, you patch all that shit out...

Technically - As I remember it on the Classic Macs and the Mac IIs ROM starts at $00000000, and does a few diagnostic routines before some "Gate-Logic Magic" happens and the addressing of the ROM gets swtiched to some higher area and the CPU jumps to the new address and continues the diagnostics from there. So moving the ROM around is not hard as it is already done in software in the ROMs. It just needs to be moved to a higher place. Note - that on C\PM Machines, the where the ROM also starts at $0000 but is later eliminated after it boots itself into higher memory through some form of bank switching; the circuit that does this is not that hard.

I have a "Prototype" Classic II Board with 4 EPROMS on it instead of ROMs, with Apple © labels over the windows. Right next to it, there is a jumper for "2M/4M ROM." So that adds to the mystery. Throwing more fuel to the fire, the ROMs are set as 32bit - 4 X 8bits. If the RAM is 16bits and the ROMs are 32bits, for the System to keep things straight between the two there has to be a lot of switching back and fourth, which would slow down the Classic II by a lot. If the RAM was 32bit like the ROM, there would be no need to switching between 16/32bit sets and no cause to slow down the Classic II.

For me, 16MB would be perfect for a Classic II and LC/LC II. System 7.5 has a lot of PowerPC Gunk in it, bloating it greatly - as much as 8megs I have seen in some systems. This is why I use a PowerPC Code Stripper to remove the offending PowerPC Code and shrink the system software to nearly half or more. This becomes a god-send for me because now the system software is 4megs or less, and that in a machine like the Classic II, LC and LC II with only 10megs of RAM gives you a lot more room for your apps and games to do work on! Even better if you strip the PowerPC Code out of them too!

Why 10MB? Electronically that is A8 + A2 that needs to be logically added to make A10 on an address pin. With 16MB, it is A16 and does not need the extra electronics to add bits together to get there.

I agree with Techknight on this that it is not that hard or impossible to do. My original concept as to expand the data bus to 32bits so you do not need to expand the addresses, as that would give one 20MB of RAM. But that idea as shot down last year as not doable - because of the Eagle Chip's interference. But what if we bypass the Eagle Chip, using D16-D31 and R/W from the ROMs to access the data path from CPU for the RAM?

 

[Elfen]

Of course, I suppose one has to be the devil's advocate here and ask exactly what application there is that really needs more than 10MB of RAM but would otherwise run okay on a system only 75%-ish as fast as an SE/30...

As I stated here and in other areas through out the forum, I have seen System 7.5 - 7.6 on these little 030 Macs 8MB or bigger in size because they are bloated with PowerPC Code that the 68K does not use. With a system OS of 8MB on a 10MB machine, you only have 2MB for your apps and games, which is not much at all. This causes a lot of "Low memory" errors that plagued these machines, even if you use RAM Doubler or Virtual Memory!

In my case I use a PowerPC Code Stripper to remove the offending PPC Code and the system shrinks by half. Now that the system is about 4MB on the 10MB System, this leaves 6MB for apps and games. 6MB is not a lot if you want to use System 7's multi-tasking but at least it's enough to run what you need and get something done.

And like the system, if you strip the PowerPC Code from your apps, this give you more room in your RAM.

 

[johnklos]

Unless you could use the MMU to reorganize the memory, you wouldn't be able to have contiguous memory with the Eagle without extra hardware. As an example, let's say that it maps 8 megs of memory from 8 megs through 16 megs in the memory map, and you want to add an address bit so you can access 16 megs through 32 megs. If you use larger SIMMs through the Eagle, you'd have to have the Eagle be in one configuration for 8 through 16 and another for 16 through 24 gigs. Or, if you leave the Eagle configured as it is, you'd have to put logic between the address bus to negate A23 when A24 is high. Or you'd have memory from 8 through 16 megs and from 24 through 32. This is a pain, but now imagine if the memory is really mapped from 4 megs through 12 megs and other things are mapped between 12 and 16 megs.

It's easier to get an LC III

 

[Gorgonops]

Why 10MB? Electronic-ly that is A8 + A2 that needs to be logically added to make A10 on an address pin. With 16MB, it is A16 and does not need the extra electronics to add bits together to get there.

Uhm... no. A8 is "bit 9", and is therefore active every other 256 *bytes* of RAM, while A2 is bit 3, IE, every other block of eight bytes. In the most simplistic case of *fully* decoding, say, a 16MB block of RAM at the bottom of a 32 bit address space the address lines you'd watch would be A24 and *higher*. (IE, you'd have chip enable for the RAM when all of those higher address lines were *not* active. Decoding 10MBs of space requires adding logic to say you only enable that ram when A23 is set when either/or A22, and A21 are *not* set. That's a couple gates worth, not a huge deal when you're doing everything with an ASIC.)

I agree with Techknight on this that it is not that hard or impossible to do. My original concept as to expand the data bus to 32bits so you do not need to expand the addresses, as that would give one 20MB of RAM. But that idea as shot down last year as not doable - because of the Eagle Chip's interference. But what if we bypass the Eagle Chip, using D16-D31 and R/W from the ROMs to access the data path from CPU for the RAM?

You're still missing the point about addresses; this has nothing to do with the Eagle. The addressing of the 68000 series of CPUs is *BYTE ORIENTED*; you can't just double the width of the RAM "without needing more addresses" because it's a nonsequitor so far as the CPU is concerned. The only way you could "work around" the EAGLE like you suggest would essentially be to rip off the address lines, shift them all up by one and change the memory map accordingly; the result would then be *completely incompatible* with a normal Mac, in addition to also not working because the SIZ/DSACK signals will now be completely F'ed up.

Maybe what's happening here is you're confusing the difference between the CPU's address lines and the addresses generated for the SIMMs? I mean, yes, if you look at the addresses running to the memory subsystems you'll see something like this:

For an 8 bit system a 64K block of RAM will have 16 address lines (A0-A15), because the 64K worth of bytes consists of a 2 dimensional array 8 bits locations wide by 64k bit locations deep. This is something you could trivially implement with a single 8 bit wide SRAM. By comparison, a 32bit wide memory of the same capacity will only have *14* address lines, A0-A13; because it is 4 times wider than the 8 bit version it only needs to be 1/4 as deep. (And of course, implementing this same array would require using different parts than the 8 bit one; you could use four 16Kx8 SRAMs, two 16Kx16 ones, whatever.) At this point you're probably screaming something along the lines of "But, see, this proves my point! If we quadrupled the width of the 8 bit version we'd have 256k of RAM with no more address lines!". And yes, you would... but the point you seem to keep missing is that, at least with the 68000k family (and most other modern CPUs), the address lines *always correspond to bytes no matter how wide the memory bus is*. In the case of a 32 bit wide memory composed of 8 bit wide components (IE, 30 pin SIMMs in the Mac's case) those "smaller" address bus counts just reflect the fact that each chip is only handling a fraction of the total word.

When a 68030 is running with a 32 bit memory and asks for a *word aligned* 32 bit word from location X the memory subsystem *essentially* ignores A0 and A1 and returns the contents of all four adjacent memory cells *while also telling the CPU it was able to give it all four bytes at once*. Since the 68020 and higher can tolerate mis-aligned memory accesses there are cases even when using a 32 bit wide memory subsystem that the CPU will have to perform multiple bus cycles to fetch a full word, and in these cases the contents of A0 and A1 *do* matter. AND THIS IS WHY YOU CAN'T JUST PIGGYBACK ANOTHER SET OF SIMMS IN THERE, CONNECT THEM TO D16-31, AND HAVE IT SOMEHOW MAKE SENSE. Putting the RAM there without changing the memory controller to behave sensibly to the SIZ/DSACK signals and changing the memory map so it's actually addressable wouldn't do squat.

Again, if you can avoid the EAGLE *entirely* by hitting the CPU socket it should at least be theoretically possible to wedge a block of RAM with its own memory controller in there at some arbitrary location over the 16MB boundary and use the MMU to juggle everything into a semi-reasonable memory map. But I do think it's not going to be quite as trivial at Technight handwaves it. The biggest problem I see is that I'm 100% positive that another of the EAGLE ASICs jobs is to provide chip select for all the peripherals in the system (in addition to decoding them on the memory map), and since it only really seems to care about the first 24 address lines (And A30?, given on where it remaps ROM and I/O in 32 bit mode?) your daughtercard will probably have to include some buffers on it to keep random bits on the motherboard from being activated when you're addressing arbitrary locations in your expansion RAM.

 

[beachycove]

This is probably a complete red herring, as I am reading this stuff and finding that I am out of my depth, but Maxima (a software ram disk utility available from gamba) allowed 24-bit access to 14MB of RAM (the additional 6MB of which I think had to be used as a RAM disk). A Classic II will run (a special version of) System 6, or presumably System 7 in 24-bit mode. Would Maxima work its magic in a Classic II, and is this relevant to the discussion at all?

I can't test, firstly because my CII is seriously ill and out of action, and secondly because I do not have any suitable SIMMs in any case, which would presumably need to be 2 of those little 16MB beauties--small and perfectly formed!

 

[Elfen]

Something I noticed, at least under emulation...

With Balisk, SheepShaver, et al, you can combine different ROMs with different CPUs. One example I found here - "A Color Classic with a 040 running 128megs of RAM"

https://68kmla.org/forums/index.php?/topic/25339-basilisk-for-android-port

I problem I see is that if this is emulated, than the Color Classic ROM would halt the RAM test at what - 24MB, it's own high end limit? The Emulated Color Classic would have it's ROM say "This is where we have our RAM Limit so after that there should be no more RAM." But it is not the case and it continues to 128MB. So the Eagle emulated in this set up is negated and the ROM continues to count RAM through the CPU/MMU somehow. The Eagle is functioning as a traffic cop of sorts. But under emulation, the traffic cop is not there.

 

[Gorgonops]

The hardware environment in BasiliskII is *completely* synthetic and the emulator simply patches around significant portions of the ROM code, including essentially all the hardware initialization portions. The technical details of the source system are pretty much entirely mooted.

 

[johnklos]

I problem I see is that if this is emulated, than the Color Classic ROM would halt the RAM test at what - 24MB, it's own high end limit? The Emulated Color Classic would have it's ROM say "This is where we have our RAM Limit so after that there should be no more RAM." But it is not the case and it continues to 128MB. So the Eagle emulated in this set up is negated and the ROM continues to count RAM through the CPU/MMU somehow. The Eagle is functioning as a traffic cop of sorts. But under emulation, the traffic cop is not there.

In emulations, the ROMs are called for what's needed - they're not run outright. Also, not even the tiniest bit of a memory controller is emulated. If you read Christian Bauer's notes (he's the author of ShapeShifter, SheepShaver and Basilisk), he talks about how easy much of the emulation was because the ROMs were written so universally to be able to support so many different kinds of hardware.

I recently found my Amiga A-Max IV board. It has real 128K ROMs from a Mac Plus, but adds on software support for Color QuickDraw, multiple screens, ethernet through the Amiga and support for hardware on the card itself - the card has two LocalTalk ports and a pass-through floppy controller which allows the Amiga floppy drive to support both 1.4 MB, 800 KB and 720 KB Mac floppy formats. It might even support 400 KB floppies - I forget. The point is that the underlying hardware and the ROMs can easily have little to do with one another.

 

[Paralel]

TechKnight, you are correct about not thinking in higher dimensions, I was being way too linear. If one can shove enough hardware out of the way and do things a different way, more becomes possible. It just depends on how difficult it becomes.

Elfen, if you want to noodle out a way to get beyond the limitations imposed on the 10 MB machines, I'll all for it. Put me down for one if you do it. Once I'm done with the Classic II FPU/ROM card, and getting a custom ROM Loaded I'll be happy to help if you want to do it.

 

[techknight]

I wouldnt even shove the hardware out of the way. I would leave it alone, and just add new hardware for the A24+ addressing. 

the EAGLE is doing not much more than a simple address decoder with DTACK generation for the first 24bits of addressing. Not data. different thing entirely... 

Sure theres other stuff in there like video, the E clock for VIA, etc... I am oversimplifying it specifically for addressing purposes. thats it. 

But once we move outside of A23 and A24 goes high, the EAGLE no longer does anything under normal conditions. The only catch to this I see, is if the EAGLE still wants to activate DTACK, and bus above A23, then thats going to create bus contention. Easy way around that though is tie off the R/W or CS line to the EAGLE when A24 goes high. 

As far as the hardware design, yes your going to need an additional decoder, buffers, if using DRAM, additional DRAM controller thats in sync with the pulse from the EAGLE/System clock, etc.... Thats easy for the most part. 

I also forgot to mention in my last post, youll need some glue logic to decode A0/A1/SIZ0/SIZ1 to generate the upper and lower data strobes for the RAM. But thats easy, as that circuitry is already on the web, erm... cloud, or whatever the F you call it these days. 

The only problem like I mentioned before, is figuring out what direction to take on how to tell the OS that there is RAM, and where... 

I dunno... maybe I talk to much? 

 

[Elfen]

I would like to see a Classic II Memory Map and compare it to a SE\30 Memory Map. For one reason and one reason only:

On the Mac 128K - Plus and SE, like I stated, ROM starts at $00000000, does a couple things in diagnostics and then with some bit flipping and gate array flips the ROMs' address to $00080000(?), does a RAM Test and then searches for a bootable drive and loads the System. RAM is on $00000000 to $00040000 on these Macs (for 4MB total) but there is room for at least for 4MB more for a total of 8MB. No one never took advantage of that. But that's history. Even Dougg3 states that there are large gaps in the classic Macs' memory map for one to put in added RAM or I/O into.

With the Classic II (LC, LC II and others) these gaps would be bigger! For example - the 6522 VIAs on the logic board are in area (I think is) $000E0000 (Classic Macs) and is stated to up 1 meg of space. HOW?!!! I'm an old Commodore Boy and the one of many things I remember is that the same 6522 used in Mac is the same one used in the Vic20, Commodore PET and other Commodore Computers and they only takes up 64 bytes or so of physical address locations for their registers and other I/O and Buffer functions! 64 Bytes! How can 64 bytes in a 6502 machine translate to 1mb of space in the 68k Mac?!! That is impossible. You can fit 64 6522-VIAs in the space of 1MB and still have room for many other things.

So... in the Classic II, ROM should start at $00000000 and then gets moved elsewhere by Gate-Logic-Array magic; the thing is where is it moved too? Is that space large enough to put RAM into and add it to the 10MB or would RAM need to be placed above ROM Space? And in all this, where is I/O? And where is Eagle in this Memory Map and why is it there?

It is interesting that the emulation takes shortcuts in to satisfy situations that are not present in Mac. But if the ROM are generalized that much, can you take any ROM (like from an SE\30) Put it into a Classic II and it should run. Should! There might be some things that would prevent it from working and that is a given.

Thanks Paralel... I am interested in that Classic II FPU/ROM project you and the others are doing. Everything in my head is just theory and conjecture. Maybe if I wave a dead chicken over a Classic II, I can get some answers.

 

[techknight]

Developer Notes.... 

 

[Gorgonops]

But once we move outside of A23 and A24 goes high, the EAGLE no longer does anything under normal conditions. The only catch to this I see, is if the EAGLE still wants to activate DTACK, and bus above A23, then thats going to create bus contention. Easy way around that though is tie off the R/W or CS line to the EAGLE when A24 goes high.

See, this is where I get a little hung up on thinking that there might be difficulties. Is there a "CS" signal you can just "tie off" trivially to keep the EAGLE from doing its thing? All indications seem to be that it's the component on the board that actually generates all the CS signals for all the other peripherals, I doubt that it's ever really "disabled", and therefore given that it's only tied to A0-23 and A31 my assumption would be that the entire physical memory map above the 16MB boundary consists of at least 127 mirrored copies of the bottom 16MB...

But I'm also saying this in ignorance because I'm not solidly familiar with how the bus cycle in the 680x0 CPUs works other than it's a bit more complicated (IE, involves active negotiation with the memory/peripheral controllers regarding bus size, etc) compared to the strictly synchronous bus of something like a 6502(*). Mostly I'm wondering how many signals you'd have to mask off to keep a read/write to your expansion memory from either A: inappropriately loading the bus because multiple chips are trying to respond, B: Having the EAGLE butt in with inappropriate DSACK signals because, fer instance, you happen to access a 16 or 32 bit wide RAM region that based on the state of the address lines makes the EAGLE think you're talking to the 8 bit SCSI controller, or C: having a write operation likewise duplicate into the wrong place. I assume it *should* be more trivial than having to put selectable buffers/line drivers  across the whole bus to cut off the motherboard when you're hitting your expansion RAM, but still curious how much you need to mask at minimum. I'm sure someone actually capable of building the board wouldn't have a problem with it.

Also sort of wondering if there might be *anything* on the board that does DMA to the EAGLE-controlled RAM other than the video display (which is already a problem). Sorta doubt the SCSI chip does DMA but it's possible, how about the sound chip on those systems, is it an "I/O" device or is it a synchronous DMA dingus like it is in the "classic" 68000 systems? If it's the latter the driver hacking you do to make the video display work at where it's going to have to be moved when running in "bigmem" mode will also have to take that into account.

I also *seriously* doubt the 68030 in most Classic IIs is socketed, but I suppose that's also a theoretically solvable problem if you're determined enough to really go through with trying to stuff more RAM in one of those boxes.

 

[techknight]

Ill have to look and see if I have the schematic for the CII. I cant recall. But I know the glue logic is tri-stateable. 

 

[Paralel]

One thing I can't figure out is why does the EAGLE accesses A31? It shouldn't have any reason to do that.

 

[Gorgonops]

I was wondering about A31 myself, as it is at odds with the memory map, which shows ROM and I/O being mapped up to just above the 1G mark when in 32 bit addressing mode. Wouldn't it need to watch A30 instead?

 

[Paralel]

Your guess is as good as mine on that one. There has to be a reason, but Apple didn't see the need to discuss it apparently.

 

[Bunsen]

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

Okay, correct me if I'm wrong here ... but if the system can recognise the extended RAM as a drive, and you point the Memory control panel's virtual memory to that drive .... aren't you good to go?