-
Hello MLAers! We've re-enabled auto-approval for accounts. If you are still waiting on account approval, please check this thread for more information.
System 6 on a Performa 475
- Thread starter onlyonemac
- Start date
I'm using a...ahm...Performa 475 ROM :lc: with Basilisk II (the emulator normally runs System 7.1P5, like my real Mac-don't know about 24 bit addressing, but the real Mac supports it).
Basilisk II is *not* an accurate copy of the hardware of any real Mac. It requires a Mac ROM, but it patches the snot out of it to make it work in a simulated environment that allows it to perform better than any cycle-accurate emulator would, at the cost of making it a *bad* place to try experimenting with hardware specific software patches.
And yet it can use a real Macintosh modem and printer!!! OK, I'll try the real Mac.
Maybe that's also why it won't work with Virtual Memory (once heard some talk about lack of MMU)? (Let's not make this a discussion about Basilisk II.)
Maybe that's also why it won't work with Virtual Memory (once heard some talk about lack of MMU)? (Let's not make this a discussion about Basilisk II.)
It didn't work on my real Mac 
. I got the same flickering dialog.
While I was at it (at trying my System 6 disk, not at the Mac
), I thought I'd try the 6 finder with system 7. It started up, of course, and the finder opened, but then as soon as it displayed a dialog, it went into the same flickering state as before. I couldn't even read the message, because the Mac didn't draw it!
So I'm thinking it's something to do with the dialogs?
. I got the same flickering dialog.While I was at it (at trying my System 6 disk, not at the Mac
), I thought I'd try the 6 finder with system 7. It started up, of course, and the finder opened, but then as soon as it displayed a dialog, it went into the same flickering state as before. I couldn't even read the message, because the Mac didn't draw it!So I'm thinking it's something to do with the dialogs?
What I really need is a list of 68040 opcodes, compared with 68030 opcodes. Then I'll be more successful...
Some accelerators retain the original CPU. Otherwise it would have an opcode translator table stored in ROM somewhere... in which case I'd like a copy of that ROM!!!
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.
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?
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 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.
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.
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.So one could conceivably make a 90mhz 060 romless accelerator .....
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.
