Search results

Yes. With Mode 32 installed in the System, the Memory Control panel offers the ability to switch to 32-bit. I have the AMMU installed. It seems like the 68030 MMU overrides it. Agreed. I was actually hoping that maybe we could install custom IIsi ROMs with the memory check disabled. Yes. It...

What part# of EPROM (or similar technology) would be needed to replace the Mac II ROMs? It might be worth upgrading the ROMs rather than side-stepping to be able to get the benefit of >8MB of RAM since the Doubler has a PMMU. Anyone interested in making 4 MB or 16 MB SIMMs using the OR-chip...

Oh. Very interesting.

Earlier today, I had a Macintosh II that wouldn't boot from SCSI (Floppy EMU worked fine). I also toned out the SCSI connector like you did. I've been working on a hunch with my pile of bad IIsi computers that often the SCSI problem is with VIA1 or VIA2, as they connect to the SCSI chip. In the...

I picked up a Macintosh II with a surprise inside: The Sonnet Allegro Doubler Mac II. The board has a 68030 processor fed double the native clock (15.6672->31.3344) which is marketed as 16 MHz -> 33 MHz. Besides the speed bump, the other benefit is that the 68030 includes a built-in MMU. This...

That is amazing! Great write up. I never would have believed this was going to get found. @JDW would very much like to know about it.

Found the code! So there you have it. The File Manager is intentionally reading and overwriting portions of the first block of the resource fork when it is closed. TFSRFN2.a FClose() ; 16-May-85 PWD Added options to FlushCache call, added code to write a copy ; of the...

Actually, I am only checking on the disk after the resource file closes. I'm not sure if the resource header is fully loaded into memory and accessible. I modify the resource, call ChangedResource, and then close the file.

Oh! It's even weirder (or less weird?) than I originally thought. Every time the resource file is modified, the 'directory' information in the header is updated. So, not just when the file is copied, but anytime the resource fork is changed. 1. Rename or move. No change. 2...

Ha! That's exactly the reaction I had. The resource manager code has so many patches for fonts, compression, printers, and ROM resources. It is a mess. I agree. Since the File Manager is actually doing to heavy lifting of creating a resource fork, I imagine the code is in there. I stepped...

<2> 7/3/90 PK For 800K floppies only, reduce allocation blocks from 1594 to 1593, so System 6 Finders don't do physical disk copies. /* Special case for 800K GCR disk: decrease the number of allocation blocks by one. This is so 6.x Finders won't...

I took a BinHex file (no resource fork) named "0x90 test.Hqx" and called HCreateResFile (but didn't add any resources). As you can see, the header and the start of the resource blocks are properly created. But, there is still a lot of garbage following the filename. It is hard to tell from one...

You can rename the file or drag to another folder (not option drag) and the resource header will be unchanged. This is because only the directory entry is being modified -- not the file. As for your question... I dragged the original "untitled" file to a different volume (named "System 7.1...

For testing and cataloging purposes, I wrote a routine that compares two files to determine any differences. Everything works well, except when comparing the resource forks. It turns out, in classic Mac OS, a portion of the resource fork header differs when a file is copied. Steps to Reproduce...

Here is a SuperMac Thunder/8 (not 24) ROM, version 1.7.2b. And just to put it somewhere, here is a Radius Pivot IIsi 2.6 ROM.

Very interesting. This is consistent with the assertion that old school desktop Macs didn't reduce reduce power consumption on idle (in contrast to Portable / PowerBooks). Did you measure the temperature of the chip? I guess if we pretend that temperature was somewhere in the middle of 0C...

Yes! Nice pictures

Correct. They have a big D on the case.

Here are two more serial numbers for silkscreen Drexel Macs. Looks like they break the 'divide by 5' pattern. F4061UFM0001 Manufactured in: F => Fremont, California, USA Year of production: 1984 Week of production: 6 Production number: 1UF => 2123 Model ID: M0001 => original Macintosh 1984...

I just looked at the release notes, and indeed those are improvements that they noted. I'll be interested in your experience as you use it.