Testers Needed: Modified ROM for LC475/Q605

[eharmon]

Yes I pushed the ROM speed to the lowest (fastest), with the CayMac universal SIMM, and no issues. I ran another quick benchmark comparison, this time between 40MHz/60ns RAM/120ns ROM and 40MHz/60ns RAM/55ns ROM, and the faster ROM does make a small but noticeable difference for just about every test. Would be cool to have a really deep Toolbox routine to really vet out the performance improvement.

As I continue testing, I really want to bake all these speed improvements into the ROM. So no CDEVs or INITs needed. At least that's what I am aiming for, for selfish reasons. With all this in place, this Q605 is a really snappy and fast machine. I'm excited now to see if I can break past that ~50Mhz threshold.

Neat!

From the overclocking thread there is likely a major bottleneck on ethernet timing, at least on some Quadra's. They seem to hang forever while booting the OS when pushed too fast, hopefully just due to insufficient waits and not bus instability. Unfortunately while there's a driver baked into the ROM, it's most often overridden by the OS or its extensions on boot. There's a way around that though, if a driver fix could be determined. Then 50+ is likely significantly more stable on a wider set of machines (unless another roadblock is found after), I suspect.

 

[zigzagjoe]

The best way to benchmark ROM performance I've found is hammering on quickdraw routines. That is where I saw the most measurable benefit when implementing my ROM boost function on the booster cards. Disk routines also benefited, small possible sequential accesses as norton system info benchmarks spent the most time in ROM code and saw a corresponding increase in performance. However, that was all on the 68030 which does not have enough cache to hold some QD routine hot loops in cache. I would expect much less benefit on the 040 machines. There was also a measurable benefit to boot time but it wasn't huge.

Something to be aware of on ROM timings, though: I've recently found that the TSOP type flash used on the rominator and caymac simms do not have the drive strength to achieve the rated speeds of the flash chips. That flash is rated about an eighth of standard TTL drive - 0.1ma source, 1ma sink - pretty miserable. They were intended to drive small private buses to SOCs and the like, not an extended system bus as seen in vintage machines. I haven't done a full study of it myself yet but a friend was seeing data line transitions 90+ns after address stabilized on a SE30. Not great for flash rated 55ns. That said, SE30 does have long traces on the data bus particularly on the least significant data bits so the simpler LC475 board may be better off.

Still, you may need to back off the ROM sooner than you think. You could measure average time from /TS + /ROM_OE to data lines fully stablized to figure out the speed in practice. That said, if it boots at all a certain speed, odds are it will continue to work unless you change things. You notice really quickly when you start getting bad data from ROM

ROMs with integrated buffers like pgreenland's design, Garrett's workshop's design, or my own ISP SIMM won't have the drive strength issue, though they will incur a small delay over the flash rated speed due to the buffers. The SST flash as used on the older GG Labs simms also have more drive and were able to run fast enough to support higher speed ROM access. Those aren't suitable for use in a Quadra, though.

 

[Joopmac]

on a sidenote, would it be possible to change the startup sound of the 475 to the classic original LC boot chord?

 

[derFunkenstein]

This is a very cool project. Alas, my 475 has no ROM SIMM, just the pads.

 

[Joopmac]

Yes i guess most of them don't have the slot, but it's easy added and the slots are still available =)

 

[frontein1]

Sorry, been out of pocket for a while working on some other hobbies. Returning to my newly arrived Q650, I can get it to register 328MB of RAM so far (8 onboard + 128 SIMM + 128 SIMM + 32 SIMM + 32 SIMM).

I am running into the same issue BBRAUN documented back in 2012, where 3x or 4x 128MB SIMMs results in bad chimes. So I'm deep in SIZEMEMORYPATCH disassembly (offset A0000) and djMEMC land right now. Curious if I can figure this out.

Mac68k Forums: djMEMC support for 128MB SIMMs (610, ...

 

[joevt]

Sorry, been out of pocket for a while working on some other hobbies. Returning to my newly arrived Q650, I can get it to register 328MB of RAM so far (8 onboard + 128 SIMM + 128 SIMM + 32 SIMM + 32 SIMM).View attachment 91550

I am running into the same issue BBRAUN documented back in 2012, where 3x or 4x 128MB SIMMs results in bad chimes. So I'm deep in SIZEMEMORYPATCH disassembly (offset A0000) and djMEMC land right now. Curious if I can figure this out.

Mac68k Forums: djMEMC support for 128MB SIMMs (610, ...

Too bad SIZEMEMORYPATCH is not in the supermario git repository.

I think MAME can emulate a Macintosh Quadra 650? I would try that to see if the ROM supports the RAM configuration that you want to try. Make sure the emulator chooses the same ProductInfo as your Mac.

It looks like each bank can be up to 64 MB for 640 MB total? See RamBankInfo at 0D2BA8 in the attached ROM Fiend output (assuming I'm looking at the correct ProductInfo).

Does the ROM have to be the 1993-02 - F1ACAD13 - Quadra, Centris 610,650,800 ROM? Later ROMs also include the Quadra 650 ProductInfo (such as the Quadra 640av/880av ROM or the 6100/7100/8100 ROM).

 

[Joopmac]

Cool, intrigued if this works
At the moment i am running 4x64+8MB in my "Q750"

 

[frontein1]

I'm pretty close to getting 512MB to register in the Q650, at least I hope. I do think it may have to do with the power/voltage drain by the big SIMMs. When I poke the 50F0E000 register and set the OneBufferedBus bit, the Q650 posts and does a full boot with 4x 128MB SIMMs. But by setting this bit, the video is also forced to the data bus and I get no display. So right now I have some low voltage SIMMs on the way so I can give these a try.

The comments from the original Apple developers indicate that WOMBATs (ie, the Q650 machine) should not set the OneBufferedBus bit. Makes sense I think, as the djMEMC can address the RAM in parallel.

 

[Jockelill]

Do you have any Nubus video cards? Would be worth seeing if you get display there and it does a full boot.

 

[frontein1]

Do you have any Nubus video cards? Would be worth seeing if you get display there and it does a full boot.

Unfortunately not. I was thinking about getting one however. With the OneBufferedBit set, I can tell the Q650 boots all the way into the OS as the normal soft shutdown does the alert, then enter powers it down.

I have some new SIMMs on the way: each chip 16Mx4 (=8MB), 8 chips per bank (=64MB), FPM non-parity, and compatible with both 3.3V and 5V. I'll find other uses for these SIMMs if they all do not work at the same time however. Next step after that I was thinking about getting a nubus video card.

 

[Jockelill]

Interesting, maybe this is also the reason why apple never officially supported 128MB on these machines? I have several spare High Resolution Video cards, can send one in next package.

 

[terrier]

@frontein1 if you're not averse to hardware tweaks, I'm really curious about what the system behavior is if the onboard ram (banks 0/1) is completely unpopulated, or, in the other direction, if the onboard mem DRAS and DCAS lines are bodged to a simm slot with a 64 or 128MB SIMM.

 

[frontein1]

Interesting, maybe this is also the reason why apple never officially supported 128MB on these machines? I have several spare High Resolution Video cards, can send one in next package.

Yes I may take you up on this. I'll certainly pay for the card too.

@frontein1 if you're not averse to hardware tweaks, I'm really curious about what the system behavior is if the onboard ram (banks 0/1) is completely unpopulated, or, in the other direction, if the onboard mem DRAS and DCAS lines are bodged to a simm slot with a 64 or 128MB SIMM.

I did go so far as zeroing out banks 0/1 in the SIZEMEMORYPATCH routine in the ROM. But basically same behavior. Although one time I did get the system to boot just fine with 3x 128MB SIMMs. So banks 2/3 4/5 6/7 were each the full 64MB. Darn it though I didn't record what I did, but I do remember it showed a really odd amount of RAM, something like 370MB.

 

[cy384]

Although one time I did get the system to boot just fine with 3x 128MB SIMMs. So banks 2/3 4/5 6/7 were each the full 64MB. Darn it though I didn't record what I did, but I do remember it showed a really odd amount of RAM, something like 370MB.

Maybe you've seen it already, I have run 3x 128MB in my slightly modified Centris 650 (details here). My (weakly supported) opinion is that the RAM detection code doesn't set up the memory controller properly and it's probably not a power supply issue. When I tried it left a gap in the configured memory banks. I've been meaning to replace the detection loop with hard coded values, but haven't gotten around to it in uhhhh... the last four years!

 

[frontein1]

Maybe you've seen it already, I have run 3x 128MB in my slightly modified Centris 650 (details here).

OK very interesting! No I hadn't seen this thread yet. What you are saying in this thread surely makes sense to me, and I may give this a go (ie, hardcoding the values). I did re-write large chunks of the resizing code in assembly but that hasn't cracked the nut yet.

 

[frontein1]

* bank0: 0 (onboard)
* bank1: 4 (onboard)
* bank2: 8 (first half of first 128MB)
* bank3: 72 (second half of first 128MB)
* bank4: 136 (first half of second 128MB)
* bank5: 200 (second half of second 128MB)
* bank6: 264 (first half of third 128MB)
* bank7: 328 (skipped)
* bank8: 328 (second half of third 128MB)
* bank9: 392 (unused)

@cy384 I'm still digging into this. I wanted to bounce this off of you, so I quoted your above post here. This is from when you booted with 3x 128MB SIMMs.

I am wondering if the banks are setup like this in the Q650? So take just one 128MB SIMM.... I see from the wombat tool that it shows the following:

bank 2: 64 MB bank
bank 4: 64 MB bank

If this is the case, maybe the sizing routine was really showing this for you?

* bank0: 0 (onboard)
* bank1: 4 (onboard)
* bank2: 8 (first side of first 128MB SIMM)
* bank3: 72 (first side of second 128MB SIMM)
* bank4: 136 (second side of first 128MB SIMM)
* bank5: 200 (second side of second 128MB SIMM)
* bank6: 264 (first side of third 128MB SIMM)
* bank7: 328 (skipped)
* bank8: 328 (second side of third 128MB SIMM)
* bank9: 392 (unused)

 

[frontein1]

Here is probably a better way to visualize what I am trying to say. I'll do some more testing tonight. If this is how it works, then technically I suppose a single installed double-sided SIMM would never be interleaved (ie, banks 2 and 4 populated). So this would be a good way to test this theory.

 

[frontein1]

To help keep myself organized, I put together a template to use for several iterations of testing different ROMs and SIMMs on my Q650. Attached are my notes, and admittedly my handwriting is AWFUL! But, I think this testing confirmed to me at least that the memory is being sized correctly. Even when I have 3 128MB SIMMs and utilize the RAM disk, the banks are populated as expected. In closely reviewing the SIZEMEMORY patch, the djMEMC doesn't appear to take into account any sort of change for the presence of a RAM disk ("EDISK"). So perhaps this patch is completing successfully and something downstream during the POST is failing.

I have a NUBUS video card on order, and I am going to poke around more at the registers without relying on the onboard video.