Breaking the 36MB RAM limit on the LCIII

[trag]

Thanks for jumping in with both feet, bud! I know work has you well and truly knackered. So much information! Looks like the one RAS line thing for the eight chips on the IIsi board in my diagram is correct after all?

One review question: I have a suspicion that we figured that addressing two 32MB 72pin SIMMs from a bank of four 30pin SIMMs was the way to go for converting something like the SE/30 or IIsi over to 72pin SIMMs? 64MB SIMMs was not the way to go? Do you remember offhand? So, so long ago, sigh!

I don't remember (probably didn't) seeing such discussion. It seems to me that each bank of four SIMM sockets on the SE/30 could be replaced with a single 64 MB 72-pin SIMM (or one bank of a 128 MB SIMM). I don't know if that would cause any current loading issues. You'd be loading the bus quite a bit less than in a standard configuration. It would be similar to using four 2-chip 16MB SIMMs in each 30-pin slot.

Do 2-chip SIMMs work in SE/30? I seem to remember some discussion from Zane about it causing some kind of refresh issue.

 

[max1zzz]

Thanks @trag I was having the same problem as @alxlab "Where the hell is 2^27 coming from!" it makes sense to me now and I can get the maths to work

I have done some more testing with the simm breakout board and am pretty confident that as it is it just isn't going to work, I have scoped VCC on the board and didn't see any instability when accessing RAM so don't think it is a power issue. It could be a timing issue, it could be a crosstalk issue but whatever it is I don't feel like spending any more time on it as I don't think it would even fit in the LCIII case anyway!

Going forward my plan is to make a custom RAM simm for the LCIII that incorporates 4 ranks of memory into a single SIMM

In regards to trying to find A11 to get larger simms to work I have probed round most of the unconnected pins on the sonroa and did not see anyhting that looked like a extra address however I need to recheck this as I was assuming that I would see activity on it as long as the system is running which may not be the case

 

[Trash80toG4]

Have you got a schematic of your breakout board. Extra eyes looking at it might find any problem should there be one?

Doubt you'd see activity. Got pinout of Sonora? Comparison to MDU might be helpful. Since the LCI was developed from the LC bloodline, it may be entirely different. If Sonora was Combo'd for the Q605/475 MEMCjr controller, that might give some clues as well?

Data and address buses and CAS/RAS lines are discrete systems in the two banks supported by MDU in the IIsi (and IIci?) if memory serves? If such is the case with the LCIII your breakout board wouldn't see Bank A at all. That would need to be a Logic Board level hack.

Such isn't readily apparent in my diagram. It well illustrates requirement for bodging the second pair of RAS lines and A11 from MDU heading in from the right. But it's probably not clear to anyone but myself that all connections heading into the 72pin SIMM from the left are pulled from lines leading to the pads of Bank A soldered memory? If this discrete Bank system implementation of MDU holds true in Sonora, that could be the glitch you're running into on your LCIII board?

A second SIMM replacing Bank A memory would required to reach maximum potential. My WAG is that that is the block you are running up against in the LCIII?

It's not necessary to limit memory in ROM for Bank A, as that's constricted at the PCB layout level by leaving the bold lines unimplemented. The only block in ROM of which I am aware was the hobbling of Bank B in the LC?



edit: check Sonora for lines leading only to resistors placed there to keep unimplemented connections from swinging in the breeze. I think you might find your missing links on that map?

 

[alxlab]

In regards to trying to find A11 to get larger simms to work I have probed round most of the unconnected pins on the sonroa and did not see anyhting that looked like a extra address however I need to recheck this as I was assuming that I would see activity on it as long as the system is running which may not be the case

Going back to this quote from the LC III dev notes:

"At system startup, the boot code determines the amount of RAM installed in all banks and
then sets a RAM configuration register in Sonora."

I would assume if there was any activity on the address lines it would be during boot up only while it's trying to figure out the capacity of the SIMMs. This is assuming it detects the size of the SIMMs by trying to write and read at different addresses.

 

[max1zzz]

Have you got a schematic of your breakout board. Extra eyes looking at it might find any problem should there be one?

Sure, I'll post the KiCad project on here later tonight

Got pinout of Sonora?

Not a full one, I got 3/4 of the way round the chip before getting distracted by the hole "ooh there's two extra RAS lines" rabbit hole

It's not necessary to limit memory in ROM for Bank A, as that's constricted at the PCB layout level by leaving the bold lines unimplemented. The only block in ROM of which I am aware was the hobbling of Bank B in the LC?

Bank A (the onboard bank) is restricted in ROM, I have tested this by removing all the soldered RAM, disconnecting the normal RAS signals from the onboard SIMM slot and connecting the RAS from the onboard bank to the onboard SIMM slot - the result of this being that the system works with a 16mb stick installed but only 4MB is recognised. It appears the ROM dose not size the onboard bank and just assumes 4MB is installed.

ROM patching is out of my skillset but if anyone wants to give it a go let me know

I would assume if there was any activity on the address lines it would be during boot up only while it's trying to figure out the capacity of the SIMMs. This is assuming it detects the size of the SIMMs by trying to write and read at different addresses.

I assume thaat is what it is doing, the LCIII dose not use the "Presense Detect" pins of the SIMMS so I can't see any other way for it to size the SIMMS. I have been back over the unused pins in the RAM area of the sonora and did not see any activity on them during boot

edit: check Sonora for lines leading only to resistors placed there to keep unimplemented connections from swinging in the breeze. I think you might find your missing links on that map?

I'll double check, There isn't anything along those lines in the area where all the other RAM signals are but there are some pins like this over on the other side of the chip

 

[Trash80toG4]

Bank A (the onboard bank) is restricted in ROM, I have tested this by removing all the soldered RAM, disconnecting the normal RAS signals from the onboard SIMM slot and connecting the RAS from the onboard bank to the onboard SIMM slot - the result of this being that the system works with a 16mb stick installed but only 4MB is recognised. It appears the ROM dose not size the onboard bank and just assumes 4MB is installed.

I'll try to wrap my head around that when I can examine the traces. Do you have a utility that reports how much memory is installed in each of the two banks or is statement based upon reporting of total memory detected from both banks?

Might be important? It sounds like you're combining RAS from Bank A with the CAS and addressing lines present on Bank B to come up with that result? CAS, RAS and A0-10 are a distinct set of lines for Bank A in IIsi/MDU and same is true for those lines (+A11) in Bank B.

If Sonora is anything like MDU I'd be surprised to see any memory detected at all in your configuration. If detected, it would be in addition to RAM in Bank B I'd think. Do you have that memory reported as being in Bank A specifically?



edit: If that's the case, it would make perfect sense. ROM limitation would be for expansion memory in Bank B as it is in the LC. Again, there's no reason for imposition of ROM limitations on Bank A soldered memory.

 

[cy384]

ROM patching is out of my skillset but if anyone wants to give it a go let me know

Found, I think, the right spot in the LCIII ROM, I'll make some tweaked ROMs this evening with different values. I think it has to be multiples of four, do 8, 16, 32 work for you?

 

[max1zzz]

View attachment 6444

Found, I think, the right spot in the LCIII ROM, I'll make some tweaked ROMs this evening with different values. I think it has to be multiples of four, do 8, 16, 32 work for you?

Awesome
16MB is what I am trying to replace it with (Anything higher than that requires more RAS lines then we have)

 

[Trash80toG4]

Found, I think, the right spot in the LCIII ROM, I'll make some tweaked ROMs this evening with different values. I think it has to be multiples of four, do 8, 16, 32 work for you?

Fabuous work! Can't wait to see results. Still wondering why they'd block Bank A when over expansion in SIMM Bank B would be the more obvious problem to be addresse, just as in case of LC.

/Occams Razor

 

[cy384]

Here it is, set for 16MB. To make it, I flipped that one byte from 1 to 4, and then recalculated the checksum for the ROM.

 

[Kai Robinson]

@cy384 how are you disassembling these ROM's - IDA Pro?

 

[cy384]

@cy384 how are you disassembling these ROM's - IDA Pro?

all in Ghidra! ...and also referencing the leaked copy of the ROM source code, which helps a lot! I figured out a way to tell Ghidra about Macintosh A traps last night, which makes it go much more smoothly. I put some defails in my repo at https://github.com/cy384/68k-mac-rom-maps

I was thinking about doing a little blog post or something about how I'm going about it.

 

[max1zzz]

Here it is, set for 16MB. To make it, I flipped that one byte from 1 to 4, and then recalculated the checksum for the ROM.

Great, many thanks! I'll test it after work tomorrow and report back

 

[Kai Robinson]

all in Ghidra! ...and also referencing the leaked copy of the ROM source code, which helps a lot! I figured out a way to tell Ghidra about Macintosh A traps last night, which makes it go much more smoothly. I put some defails in my repo at https://github.com/cy384/68k-mac-rom-maps

I was thinking about doing a little blog post or something about how I'm going about it.

Oooh lovely! I tried disassembling the SE FDHD and early 800k ROM with both IDA and got absolutely nowhere

 

[Trash80toG4]

I was thinking about doing a little blog post or something about how I'm going about it.

Am I the only one left from olden times when documenting projects with Q&A developments in forum threads was a big deal and the way to go for stuff like this?

Blogging was great back then for self absorbed drones to disappear out on the fringes of the web where we could ignore them. Not all that crazy now that everyone seems to be doing it, but I feel it dead ends technical projects in niche applications such as this. Seems disjointed and unproductive to labor in relative isolation and then blogging about it to me.

The point of BBS and Forums software back when was learning through give and take of discussions and cooperative ventures like the SE/30 insanity and general craziness of the gamba gang. Far superior to newsgroups then, blogging seems like a step back into the wilds of usenet to me.

 

[trag]

Far superior to newsgroups then, blogging seems like a step back into the wilds of usenet to me.

How were blogs superior to newsgroups?

Newsgroups were the forums of the early days. And they had the advantage of not being at the whims of their creator for how long they persisted.

In theory, everything ever posted in Newsgroups should still be available.

Of course, once they lost ubiquitnous and ISPs stopped supporting Usenet, their distributed nature became not so distributed.

Nevertheless, I can probably find my old postings from the '90s that were in News Groups. Difficult because Google Groups is a steaming cesspit of incompetence, but usually possible. Postings to old forums such as Mike Breedan's XLR8yourmacintosh, Jeff Keller's PowerWatch, and the MacGurus forums are gone forever. Oh, and DealMac. They had quite a good Macintosh forum back in the day too. All gone now.

But to your original point, yes, I think postings to forums are better than Blogs.

On the other hand, when a project has reached some level of completion, a Blog offers a way to post a concise and organized summary of the project. Whereas forums are likely to include large amounts of extra posts to wade through.

Still, the person doing the work can post in whatever fashion they choose...

 

[Trash80toG4]

Read again? Thought what I said was that BBS and Forums were far superior to newsgroups for cooperative ventures, blogging is a step backward into the wilds from BBS and Forums.

Usenet rocked. Great point about linking to a blogged summary, well organized and concise from an invariably messy development thread.

IMO, development should be done in the threads so neophytes along with the less than expert members of the community can learn, sometimes asking pertinent questions from outside viewpoints to help the sorcerers?

 

[trag]

Hey, jt, sorry if i misunderstood you. Also, I think I mistook who wrote your posting. Bleary brain.

 

[max1zzz]

Here it is, set for 16MB. To make it, I flipped that one byte from 1 to 4, and then recalculated the checksum for the ROM.

Just tested it, unfortunately the LC is still reporting only 4MB of ram with 16 installed

 

[cy384]

Just tested it, unfortunately the LC is still reporting only 4MB of ram with 16 installed

Ok, just read some more code, I think I've found a better spot to mess with, I'll post another attempt once I get it figured out.