Search results

Does Apple's hidden option in Mac OS 8.6 work on your 7100? If it does, there could be another code path.

The code seems to do the "run startup ram test" byte write as long as CHRPNess (bit 6 of $2400) is set AND one of the other three (HeathrowExists, OHareExists, GrandCentralAddr) is set. I have done the same tests/checks in the No Ram Test system extension so I think any model that Apple...

Cooked up a system extension for System 7.6.1 that mimics Apple's hidden option in MacOS 8.6 to disable the startup ram test on Power Macintoshes. I have only tried it on my Power Macintosh 8500 on System 7.6.1. Thread on the analysis with @joevt here...

Ok, cooked up a system extension that will register a shutdown proc and overwrite that 0x09 with a 0x00 which then skips the ram test on the next cold boot. All it does is register a shutdown procedure which executes before power off and essentially mimics what Apple does (even in System 7.6.1)...

Looks like I should be able to register a shutdown procedure that runs after Apple's that writes to NVRAM. Already see my procedure being called after Apple's. Only question is whether it's too late in the shutdown sequence and some subsystems aren't available anymore. But we'll see.

For the MacOS 8.6 Memory CDEV, what it does: On mouse click of the Startup Memory Tests On Calls _DeleteGestaltValue for 'kdia'. On mouse click of the Startup Memory Tests Off Calls _NewGestaltValue for 'kdia'. On close of the control panel Makes changes to the System Folder -> Preferences...

Looked at the disassembled code for the Memory control panel in Mac OS 8.6. So far look at what happens when you close the control panel. It looks like it saves a copy of the settings inside the System Folder -> Preferences -> Memory Preferences file. If the ram test is disabled, it creates a...

Traced through on System 7.6.1 and it's very similar. Same check of bit 1 on the response to the 'misc' gestalt selector before deciding whether to clear a field at $0ddc. Same check to determine if the expansion manager trap exists. On System 7.6.1, it does NOT look for the 'kdia' gestalt...

Bit 1 is tested. I think I saw that Bit 0 and Bit 2 are documented only. Hex $68. This was a static address so another global.

Oh hmm.. I turned off the memory tests and stepped through the code again (this is still on MacOS 8.6). I wanted to see where it branches away from writing to NVRAM. With the memory tests turned off, it looks like the call to Gestalt for the 'kdia' selector returns 0. And it bails there.

The gestalt calls seem to be for the 'misc' and 'kdia' selectors. If 'misc' is supported, it's clearing something out a $0ddc and if 'kdia' is supported, it's reading something at $0dd8 offset $68. If that value is non-zero it is written to NVRAM otherwise it defaults to $09. It then reads bit 6...

I traced through parts of the shutdown code via MacsBug today under MacOS 8.6 and found where it's writing that '9' to NVRAM. There's a chain of handlers invoked during the shutdown and it looks to be in one of them -- I'm guessing these are the registered shutdown handlers. The first handler...

Yeah, last I left it, I was only able to use 4MB but Compact Virtual was showing 8MB or 16MB depending on how much I had installed. I just couldn't get it to let me use the additional memory. But it definitely saw it.

Yeah, I sold it. But it went to @tt. If he still has it, you could try asking him? FWIW, 4MB worked fine and 8MB/16MB was stable but I could not get Connectix Virtual to recognize it and allow me to use the extra memory as a ram disk, etc.

Well like I said, I was just making an observation regarding the superglue. I was NOT going to coat my cases in it :)

I'm sorry, I think my brain is fried... Here are the two lines from the fast dump and the slow dump: 27F448FE FFF0D000 5D5CC8CE FFF0D000 FFF04C4C FFF201F8 00000000 00000000 // FAST 27F45CFE FFF0D000 DF7DC8CE FFF0D000 FFF04C4C FFF20270 00000000 00000000 // SLOW...

My guess is it's the same everywhere and the bit I saw toggling was just a coincidence because that byte (and the 3 bytes before it) certainly looks like an address. From the source you shared, it's a 32bit read/write of offset 0x1040 and a zero skips the test and a non-zero runs it. That does...

Attached two outputs from your tool, one after booting without ram test and one after booting with ram test. ROM version 077d.28f2 checksum $9630c68b

- calls CheckForInitialzation - reads from 0x1254..0x1257 = Link1 - calls RunTests - writes to 0x1254..0x1257 = Link1 Misread the 0x1257 above for 0x1258. My mistake. So then I'm not sure why I'm seeing that bit in 0x1258 toggling in sync with the skip/non-skip of ram tests across 20 power...

Your earlier note had 0x1258 being written to and read during startup - that's why I was mentioning that what I saw was maybe just some of that IO which may be deterministically setting that bit based on whether it ran a ram test or not - and that it wasn't the flag. Yeah, I had patched out...