Skip to main content
Home Forums System 6 on a Performa 475 System 6 on a Performa 475
Thread

System 6 on a Performa 475

System 6 on a Performa 475 68k 44 posts Nov 9, 2012 — Feb 19, 2013
The Radius Rocket had '030 and '040 modes, switchable in Mission Control. RocketWare 1.3.2 required 7.0.1. But ISTR the Rocket running under 6.0.8 as an accelerator under the first release of RocketWare, but that's really hazy and the RocketBag is AWOL, ATM.

What I really need is a list of 68040 opcodes, compared with 68030 opcodes. Then I'll be more successful...
I think my brain hurts.

Download the Motorola 68040 manual and read it, it's not hard to find. The 68040's *FPU* doesn't support some instructions that the 68881/2 do (section nine) and when it encounters those instructions it suspends execution and calls a handler which emulates the missing instructions (section eight). That's it. The code for doing that is in ROM on any 68040 Mac, presumably it's either in the driver software or ROM for any 68040 upgrade, and it's "mostly transparent" to the OS.

There is also one other small category of programs that blow up on the 68040 that work on the 68030, and it involves some really esoteric issues with cache handling and self-modifying code. (Technically self-modifying code was a bad idea ever since the 68020 but you could still mostly get away with it. It blew up on the 68040 because it has split instruction and data caches, which would cause a write to a block of code that happened to already be in the instruction cache not to show up unless it was flushed and re-populated from main RAM.) The only way to fix programs that have this issue is to rewrite (IE, RESTRUCTURE) the code in question. I'm really confused what your plan is here. Are you intending to do a global search and replace on a disk image hoping that swapping every binary occurrence of "&FEED" with "&BEEF" will do it, or what?

I'm really confused what your plan is here. Are you intending to do a global search and replace on a disk image hoping that swapping every binary occurrence of "&FEED" with "&BEEF" will do it, or what?
Pretty much!
FWIW, there were ROMless 040 accelerators for 030 and earlier machines which predated the 040 and did not have 040 instructions in ROM. The Presto LC for the original LC for instance, has no ROM on it (AFAICT). The Daystar 040 has ROM and is doing a bunch of ROM patching, but some of these other accelerators are significantly simpler.

I haven't done a whole lot of investigation (accelerators aren't my thing, the difference between fast and slow 68k macs is lost in 20+yrs of advancement to me). The primary areas of concern and/or interest would be around cache: the 040 introduced separate instruction and data caches as well as copyback, and the MMU: the translation control register was 32bits in 68851 and 030, and 16bits in 040.

Of these, the MMU is the biggest concern.

For the FPU, all the ROMs included the SANE FPU emulation anyway, so I'm suspecting any unimplemented FPU instructions would trigger an unimplemented instruction trap and fall back to the SANE emulation.

For the cache, I wouldn't be surprised if the vendors wired in the cache inhibit line to always be asserted, essentially running the 040 cacheless. This would solve the incompatibility problems, and the 040 would still be as fast or faster than the 030. Or possibly running cacheless until some driver software is loaded or some such.

That leaves the MMU. My guess is while not being totally compatible, it's good enough for the relatively limited use of MacOS.

And most of the rest of the differences aren't as much compatibility as much as lack of optimization, like the faster BlockMove for 040. Again, potentially solveable with driver software loaded at boot time.

Anyway, that's just the CPU compatibility, and for accelerator manufacturers, the burden of compatibility was on them. Compatibility between machines with different memory controllers, video, etc. is something entirely different. Not to mention different ROMs with different memory managers. The differences in the memory manager between newer ROMs and System6 seems to be the source of the instability on my LCIII once it got booting.

I think your issue is that you only have one mac, and you are trying to make it do something, that it was never designed for.

However, :-) I just thought of a VERY cool solution!

I have a extra LC-II main board, it should pop right into your Preforma case, all the ports are the same.

slide this mainboard in, install 6.0.8 Bam, your machine will now run 6.0.8.

ok, because it's just a 10.5oz main-board it will fit into a first-class padded envelope.

I will send you this freshly re-capped LC-II mainboard for your machine.

i can also include a stick of ram 32mb for your 040 board as well.

a total of 12.5 oz's

postage is $11.40 US to UK, If you gift me $11.40 in paypal or send me a letter /w cash/check for that, I can send this out.

So one could conceivably make a 90mhz 060 romless accelerator ..... :)

So one could conceivably make a 90mhz 060 romless accelerator ..... :)
That could work, but my understanding is that there are enough differences in the 68060 that significant portions of the Mac ROM and/or OS need to be patched/rewritten in order to execute properly on it.
I'd love to be proven wrong, of course :) .

It would be interesting if anyone can actually accomplish this feat (System 6 on machines which don't normally support it).

c

Could there be clues in those machines/ systems that can be cajoled into running System 6, even though they aren't supposed to, like the PowerBook 170 and the Classic II?

I think the biggest problem with this is not the difference in instruction sets, but operating system support for the hardware, which was embedded directly into system file. One of the tricks to the powerbook 170 hack was realizing that hardware support was partly in the linked patch resources. This is a kind of resource that was not used much before Mac OS 7, but was present in the Japanese version of system 6 that ran on the PB170. There is an outside chance that adding linked patch resources from OS 7 to the OS 6 system file might help. Of course, this doesn't do everything. All the other resources that support hardware, drivers, INITs, and a host of other system resources that support specific hardware may still stymie you. But in OS 7 there was an effort to focus hardware support into the linked patches.

I've added all the hardware specific resources (INIT, PTCH, mntr, etc.) from the system 7 file to the system 6 file. I've not longer got flashing dialog boxes! Instead, I get a bomb dialog (not flashing, but steady, readable, with working cursor and operable restart button) that says "Illegal Instruction".

I think we've gotten past the hardware barrier and have now hit on an 030/040 incompatibility. Any ideas as to how to find the source of the "illegal instruction"?

Hi,

Perhaps that is indicative of the MMU problem that bbraun mentioned awhile back.

That being said, maybe it's possible to patch System 6 to somehow workaround this issue. I have a feeling it's very non-trivial, though.

Perhaps this experiment will be more successful if we use a late model 68030 based system (such as a Color Classic or LC III) for testing purposes.

c

Anyone got such a Mac available for use?

Anyone got such a Mac available for use?
I have a Color Classic and LC III!
The CC is in storage, but I can use the LC III, if someone will tell me what to do.

c

Right! I need a copy of a suitable system 7 file for the LC III, and then I'll try the same trick I tried with the '475, but with the LC III's resources.

Then I'll email you the patched system 6, along with normal system 6, and see what happens.

I'll PM you my email.

mp.ls