Search results

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...

I rebuilt the batteries on a PowerBook 160 with Sanyo NiCd cells, same size as the originals and it lasted 90 minutes to 120 minutes consistently. The main thing was it only fully charged with Apple‘s external charger. When inside the Powerbook, it charged only partially and lasted 20 minutes...

FWIW, I was using superglue to fix a crack in a yellowed case and found that in under a minute, the area of the case touched by the glue was back to the original color. Tested this again by just putting a drop on, waiting 30 seconds, wiped it off, and it was back to the original color. Now I am...

I counted right.. used xxd and the value I was looking at is indeed at 0x1258. Given it was in sync with the ram test configuration, and based on what you found, I'm guessing what I saw was left over data from the test and it was just holding a 0 or 1 depending on whether the test was run or...

Interesting.. the OS changing the value was what I suspected given it works on System 7 the first time. I also didn't see anything outside of the normal changes to XPRAM from the memory control panel which is why I was looking at the greater NVRAM after your first note. The write on shutdown...