Snial
Well-known member
Let's imagine, for a moment, Apple had decided to go with the M88x00 RISC successors to 680x0 Macs instead of PowerPC.
Gary Davidian had already created an emulator which worked on an LC and could boot Mac OS 7.x by 1991. So, in theory this could have meant an architectural shift, a full 2 years ahead of PowerPC (1992 instead of 1994), probably with the M88200 at 25MHz to 50MHz instead of PPC at 60..80MHz.
The M88x00 was quite a different CPU to PowerPC, mostly because it spliced off the Data and Instruction, 16kB L1 caches to external chips, which resulted in greater (3c) latency. The instruction set was simpler and easier to learn, but it lacked some of the bit field masking instructions (which are really useful for emulation). In addition it had four execution units: Data load/store, Instruction Load, IU, FPU. So, in many ways it looked like a primitive PowerPC 603e.
What would a M88 Mac have looked like? First, I want to give model names. The 680x0 Macs ended up with 3 digit models and PowerPC Macs, 4 digits: 1x00, 3x00, 4x00, 5x00, 6x00, 7x00, 8x00). I'm going to switch the other way and give the M88K Macs a letter+2 digit model numbers, released in this order: R41 (consumer, like an LC Mac), R61 (1 slot NuBus big Pizza style), R71 (3 slot NuBus). There's no top-end M88K Mac to displace Quadra 950 Macs as they sit alongside M88K Macs until they reach maturity.
The inner emulation core for the M88x00 Macs will look a lot like this:
So, one of the upshots is that an R41 at 25MHz would emulate slower than a 68000 and therefore the performance (like PowerPC Macs) would come from converted ROM routines and also Native code segments in the loaded OS and applications. In The M88K model, QuickDraw, Segment Manager and the Modern Memory manager are native, as is a nano kernel (like PPC). But there's no PPC Segmentation (which is different to Mac OS 68K code segments) and no fragments. Instead, we use RCDE resources which mirror CODE resources. When an application is loaded on an M88K Mac, it looks for RCDE 0, which contains the jump table for the M88K: normal execution addresses for 68K CODE resources, but execution addresses | (1<<0) for M88K RCDE resources, i.e. an odd address. Thus if 68K code calls an RCDE segment routine the emulator traps into M88K execution. Then Mixed-mode management duplicates RCDE jump tables so that M88K to M88K calls execute directly from the shadow jump tables, but M88K to M68K calls re-invoke the 68K emulator.
Application ABIs also change, to be more register oriented on the 68K side as well as M88K side. D0..D2, A0..A1 are callee-saved; D3..D5, A2..A3 are caller-saved; D6, D7, A4 are temps. On a mixed-mode call, they are immediately loaded into their equivalent M88K registers: R2..R4, R5..R6. Other regs are used as per the Motorola standard ABI. This also means mixed 68K / M88K apps need modified compilers that use the correct ABI.
M88K environments have access to globals (like PPC). The emulator emulates a 68000 (not 68LC040) for simplicity and returns gestalt68000 when you pass it the selector gestaltProcessorType. But it still supports VM traps and 32-bit addressing. A-line and F-line traps are mapped to M88K addresses (with bit 0 set) for supported M88K routines, which also applies to M88K natively patched System code.
Function pointers have the same issues as per the PowerPC Mixed-Mode manager, except that as described above, an address needs to have bit 0 set to indicate an M88K routine, via the Empp(address) Toolbox API which is implemented as nothing for 68K apps, but checks the Jump-Table for an equivalent M88K routine in the PCDE resource. So, this is a simplified routine descriptor concept (though we could support Routine descriptors section 1-15) with kM88kISA=2).
M88K doesn't support shared import libraries (1-20). The M88K environment shadows A5 in a native 'linker' register, and as standard supports up to 64kB of globals (vs 32kB for the 68K environment), but the application's resource info can specify any additional amount of globals, which are added after the A5 world (because address offsets are unsigned and +ve in the M88K).
The Memory Manager on the M88K however, does and must support Macs with just 4MB of RAM, with VM turned on to at least 6MB (historical note: the 6100.. series was supposed to originally ship with 4MB) and because PCDE resources must be contiguous, File Mapping has the same semantics as for the PowerPC environment: application code doesn't occupy heap space (1-54). In addition, System, Finder and other Mac OS 68K code segments are re-organised to be contiguous in order to support application code file mapping (but not Read-only data file mapping).
The 25MHz R41/4/40, 40MHz R61/6/60 and 50MHz R71/8/100 ship in 1992 with System 7.1 so no 7.1.2 version is needed, running with VM in 2MB of RAM leaving 4MB of VM spare with 6MB of VM, or 4MB of RAM with VM turned off. It means fewer 68K Macs are released as the cross-over happens earlier. A cut-down Disk Tools runs in 3MB of RAM with VM turned off to allow 4MB RAM systems to be set up. Obviously far less native software would be available by then: System OS would be almost entirely 68K, ClarisWorks 1.5 ships with key M88K acceleration as does Photoshop and an early version of RenderMan. The R41 is targeted at Math, Physics and Biology students, offering slightly slower than LC speeds (12MHz equivalent) in normal GUI operation, but workstation speeds for targeted Math, Physics and Organic chemistry modelling thanks to NIH sponsored application frameworks. Dual Ensoniq DOC and Audio AV/ MIDI PDS (and NuBus) later in 1992 opens the R41 to R71 to early DAW applications.
Well, this is fantasy ;-)
Gary Davidian had already created an emulator which worked on an LC and could boot Mac OS 7.x by 1991. So, in theory this could have meant an architectural shift, a full 2 years ahead of PowerPC (1992 instead of 1994), probably with the M88200 at 25MHz to 50MHz instead of PPC at 60..80MHz.
The M88x00 was quite a different CPU to PowerPC, mostly because it spliced off the Data and Instruction, 16kB L1 caches to external chips, which resulted in greater (3c) latency. The instruction set was simpler and easier to learn, but it lacked some of the bit field masking instructions (which are really useful for emulation). In addition it had four execution units: Data load/store, Instruction Load, IU, FPU. So, in many ways it looked like a primitive PowerPC 603e.
What would a M88 Mac have looked like? First, I want to give model names. The 680x0 Macs ended up with 3 digit models and PowerPC Macs, 4 digits: 1x00, 3x00, 4x00, 5x00, 6x00, 7x00, 8x00). I'm going to switch the other way and give the M88K Macs a letter+2 digit model numbers, released in this order: R41 (consumer, like an LC Mac), R61 (1 slot NuBus big Pizza style), R71 (3 slot NuBus). There's no top-end M88K Mac to displace Quadra 950 Macs as they sit alongside M88K Macs until they reach maturity.
The inner emulation core for the M88x00 Macs will look a lot like this:
Code:
Macro Next
ld.h r19,rIp,0 ;rIp^instruction, r19=opcode.
ld r20,rVecBase,r19<<2;dependecy on r19.
jmp.n r20 ;jump with delayed branch again, dep on r19.
add rIp,2 ;6c.
ENDM
;So, NOPs at 8c each? So, at 25MHz, that's about 3MIPs for NOP.
;Simple Ins:
OpCodeMoveLd0d0:
ld r5,rDRegs,kD0
ld r6,rDRegs,kD1
add.u r5,r5,r6 ;update flags too.
lcr r10;save flags (flags need translating for a number of scenarios).
st.l r5,rDRegs,n ;store result.
Next ;So, 7cycles to 10 cycles, so 18c, so 1.39MIPs.
So, one of the upshots is that an R41 at 25MHz would emulate slower than a 68000 and therefore the performance (like PowerPC Macs) would come from converted ROM routines and also Native code segments in the loaded OS and applications. In The M88K model, QuickDraw, Segment Manager and the Modern Memory manager are native, as is a nano kernel (like PPC). But there's no PPC Segmentation (which is different to Mac OS 68K code segments) and no fragments. Instead, we use RCDE resources which mirror CODE resources. When an application is loaded on an M88K Mac, it looks for RCDE 0, which contains the jump table for the M88K: normal execution addresses for 68K CODE resources, but execution addresses | (1<<0) for M88K RCDE resources, i.e. an odd address. Thus if 68K code calls an RCDE segment routine the emulator traps into M88K execution. Then Mixed-mode management duplicates RCDE jump tables so that M88K to M88K calls execute directly from the shadow jump tables, but M88K to M68K calls re-invoke the 68K emulator.
Application ABIs also change, to be more register oriented on the 68K side as well as M88K side. D0..D2, A0..A1 are callee-saved; D3..D5, A2..A3 are caller-saved; D6, D7, A4 are temps. On a mixed-mode call, they are immediately loaded into their equivalent M88K registers: R2..R4, R5..R6. Other regs are used as per the Motorola standard ABI. This also means mixed 68K / M88K apps need modified compilers that use the correct ABI.
M88K environments have access to globals (like PPC). The emulator emulates a 68000 (not 68LC040) for simplicity and returns gestalt68000 when you pass it the selector gestaltProcessorType. But it still supports VM traps and 32-bit addressing. A-line and F-line traps are mapped to M88K addresses (with bit 0 set) for supported M88K routines, which also applies to M88K natively patched System code.
Function pointers have the same issues as per the PowerPC Mixed-Mode manager, except that as described above, an address needs to have bit 0 set to indicate an M88K routine, via the Empp(address) Toolbox API which is implemented as nothing for 68K apps, but checks the Jump-Table for an equivalent M88K routine in the PCDE resource. So, this is a simplified routine descriptor concept (though we could support Routine descriptors section 1-15) with kM88kISA=2).
M88K doesn't support shared import libraries (1-20). The M88K environment shadows A5 in a native 'linker' register, and as standard supports up to 64kB of globals (vs 32kB for the 68K environment), but the application's resource info can specify any additional amount of globals, which are added after the A5 world (because address offsets are unsigned and +ve in the M88K).
The Memory Manager on the M88K however, does and must support Macs with just 4MB of RAM, with VM turned on to at least 6MB (historical note: the 6100.. series was supposed to originally ship with 4MB) and because PCDE resources must be contiguous, File Mapping has the same semantics as for the PowerPC environment: application code doesn't occupy heap space (1-54). In addition, System, Finder and other Mac OS 68K code segments are re-organised to be contiguous in order to support application code file mapping (but not Read-only data file mapping).
The 25MHz R41/4/40, 40MHz R61/6/60 and 50MHz R71/8/100 ship in 1992 with System 7.1 so no 7.1.2 version is needed, running with VM in 2MB of RAM leaving 4MB of VM spare with 6MB of VM, or 4MB of RAM with VM turned off. It means fewer 68K Macs are released as the cross-over happens earlier. A cut-down Disk Tools runs in 3MB of RAM with VM turned off to allow 4MB RAM systems to be set up. Obviously far less native software would be available by then: System OS would be almost entirely 68K, ClarisWorks 1.5 ships with key M88K acceleration as does Photoshop and an early version of RenderMan. The R41 is targeted at Math, Physics and Biology students, offering slightly slower than LC speeds (12MHz equivalent) in normal GUI operation, but workstation speeds for targeted Math, Physics and Organic chemistry modelling thanks to NIH sponsored application frameworks. Dual Ensoniq DOC and Audio AV/ MIDI PDS (and NuBus) later in 1992 opens the R41 to R71 to early DAW applications.
Well, this is fantasy ;-)
Transplanting the Mac’s Central Processor: Gary Davidian and His 68000 Emulator
Last week Apple announced its switch from Intel to its own ARM-based processors for all future #Macs. Apple has done this multiple times in its history, starting with the transition from Motorola 68000 chips to PowerPC in the early 1990s.
computerhistory.org
Mac Release Dates 1992 - Macs By Year: EveryMac.com
Technical specifications for all Apple Mac models released in 1992. Dates sold, processor type, memory info, hard drive details and more.
everymac.com
MAME 0.255 Released!
MAME 0.255 As you may have expected, it’s MAME 0.255 release day! Following on from April’s breakthroughs, Namco System 10 MP3 audio is now supported, making Golgo 13: Juusei no Requiem, Seishun Quiz Colorful High School and Nice Tsukkomi fully playable. On top of that, Point Blank 3 and Gunbalin...
forums.atariage.com