Thanks for the tips! First step is to get it up and running at all. 
-
Hello Guest! We're hosting a challenge to welcome vintage Intel macs to the MLA during the month of July! See this thread for more information. -
We've made some quality of life improvements to the Trading Post. More info here.
Will RPi4 run OS9 in emulation
- Thread starter Trash80toHP_Mini
- Start date
i just had a read up on you thread on the build progress.
you mention over there that about removing the hdmi port. it shouldnt be to hard to do if you can remove the solder from the four pins going through the pcb then either hot air or drag soldering the iron on the hdmi pins topside should allow you to remove it without much effort.
rather then running a full size hdmi cable throught the powerbook back to the lcd driver board depending on your soldering skills you might consider using a ribbon cable and either soldering on a flat flex connector or just soldering the ribbon cable directly to the pads..
ive used something like whats in this link below this to do just that in the past.
the kit i got at the time the flat flex cables had one extra pin but the pin pitch was the same as the HDMI pads on the circuit board so i ordered some of the same flat flex connectors and on the board i was installing them i just scrapped away some of the solder mask on the top ground plane to solder the connector anchor points down
you mention over there that about removing the hdmi port. it shouldnt be to hard to do if you can remove the solder from the four pins going through the pcb then either hot air or drag soldering the iron on the hdmi pins topside should allow you to remove it without much effort.
rather then running a full size hdmi cable throught the powerbook back to the lcd driver board depending on your soldering skills you might consider using a ribbon cable and either soldering on a flat flex connector or just soldering the ribbon cable directly to the pads..
ive used something like whats in this link below this to do just that in the past.
the kit i got at the time the flat flex cables had one extra pin but the pin pitch was the same as the HDMI pads on the circuit board so i ordered some of the same flat flex connectors and on the board i was installing them i just scrapped away some of the solder mask on the top ground plane to solder the connector anchor points down
Hi folks,
Just going back to this old project:
A single core on a PI 4 runs at 1.5GHz delivering a maximum of 3 IPC (4500MIPs). A PPC 603/75 can manage at most 2 IPC (in practice 1.4), though it can do some branch optimisations. This gives 150MIPs max. Thus, we need an average of 30 host cycles per target cycle.
This is probably, just doable with a dedicated ARM64->PPC JIT compiler. It's possible because an ARM64 has 32 x 32-bit Integer registers and the same FP regs and in many cases, there will be a 1:1 mapping between a PPC instruction and ARM instruction (e.g. ALU instructions that don't modify the condition codes).
In addition, if we implement a bare metal emulator (which perhaps could be done, since DingusPPC mostly relies on SDL2 and I think there's an SDL2 bare metal library for the PI); then it should be possible to map ARM64 pages to PPC MMU pages... or do a SheepShaver and not emulate the MMU at all to begin with!
Even if we didn't map ARM to PPC instructions directly, and instead used a context register for the emulated PPC state, a fairly simple JIT could convert a PPC ALU instruction to 4 ARM instructions: ( load, load, alu, store) and the 4 cycles involved with that is still far less than our 30 cycle limit.
Finally, we'll have enough RAM in a PI to JIT the entire memory space used for executable code. A Performa 5200 was limited to 64MB. At any one time on a fully-expanded P5200, maybe 32MB could be code and this corresponds to 128MB of target code. A QEMU emulator spends 1% of the time compiling and 99% of the time running target code[1]. So:
0.01 x CompileCyclesPerIns + 0.99 x JitCyclesPerIns = 30 (JitCyclesPerIns==4), so
0.01 x CompileCyclesPerIns + 0.99 x 4 = 30 so
CompileCyclesPerIns= (30-0.99*4)/0.01=2,604.
Yep, so if QEMU can generate an instruction in 2604 ARM64 cycles, it can emulate a slow PPC 603/75 quickly enough. But why would anyone want to do that?
PowerPip Mac: A Fantasy PowerPC Mac
Is my answer. Yesterday or the day before I was musing about the relationship between the Apple Pippin and the Mac mini. In some sense it seems to me that the mini is its descendent. Here's why: the Pippin was an ambiguous machine, because it was basically a Mac with 6MB of RAM and a cut-down Mac OS 7.5. You could also (I understand) expand it to 16MB or more and add an ADB keyboard. It had internal slots (so perhaps a HD was possible) and this would turn it into a Mac. It had a cut-down ROM (the 'ROM' was on a CD), which is like the Mac OS ROM. It was also sold for $599, I believe.
So, then I wondered, could a Pippin variant have been released around the same time-frame of 1996? It'd have to be a less powerful Mac than the P6300s and P6400s. By being ruthless, its 34.3cm x 34cm x 22.6 cm dimensions[2] ( vs 32cm x 41.9cm x 10.9cm for a P6200)... (it couldn't have been that big - did T3 confuse cm with inches [ 13.5cm x 13.4cm x 8.0cm]? !) could have been squeezed down to close to a Mac mini.
I would have scrapped the other video ports and replaced the phonos with a pair of 3.5mm jack sockets.
The internal IDE is for the CD-ROM, but I guess it could feed a 2.5" HD too. We need that. I'd scrap the PCI slot, because I can't see how there would be room with a CD drive too.
Anyway, regardless, @Trash80toHP_Mini 's hardware design is certainly small enough for a fantasy Mac like this.
[1] https://past.date-conference.com/proceedings-archive/2012/PDFFILES/IP1_01.PDF
[2] https://www.t3.com/features/apple-b...eripherals-games-software-and-legacy-detailed
Just going back to this old project:
Rethinking your original statement about emulating a PPC Mac at realistic speeds on a PI 4. Although DingusPPC (as it stands) can't emulate even the slowest PPC used in a Mac (a 603/75 or 601/60) a JIT could. Let's do the math again.<snip> This is a reboot of a two decades old project aimed at lavishing unending love upon my very first laptop, a brand spankin' new, remaindered PowerBook 100 <snip> I just asked up front if my decades old OS of choice for all my Graphics/CAD/CAM applications and equipment might be a possibility. OS9 is not a necessity!<snip>
A single core on a PI 4 runs at 1.5GHz delivering a maximum of 3 IPC (4500MIPs). A PPC 603/75 can manage at most 2 IPC (in practice 1.4), though it can do some branch optimisations. This gives 150MIPs max. Thus, we need an average of 30 host cycles per target cycle.
This is probably, just doable with a dedicated ARM64->PPC JIT compiler. It's possible because an ARM64 has 32 x 32-bit Integer registers and the same FP regs and in many cases, there will be a 1:1 mapping between a PPC instruction and ARM instruction (e.g. ALU instructions that don't modify the condition codes).
In addition, if we implement a bare metal emulator (which perhaps could be done, since DingusPPC mostly relies on SDL2 and I think there's an SDL2 bare metal library for the PI); then it should be possible to map ARM64 pages to PPC MMU pages... or do a SheepShaver and not emulate the MMU at all to begin with!
Even if we didn't map ARM to PPC instructions directly, and instead used a context register for the emulated PPC state, a fairly simple JIT could convert a PPC ALU instruction to 4 ARM instructions: ( load, load, alu, store) and the 4 cycles involved with that is still far less than our 30 cycle limit.
Finally, we'll have enough RAM in a PI to JIT the entire memory space used for executable code. A Performa 5200 was limited to 64MB. At any one time on a fully-expanded P5200, maybe 32MB could be code and this corresponds to 128MB of target code. A QEMU emulator spends 1% of the time compiling and 99% of the time running target code[1]. So:
0.01 x CompileCyclesPerIns + 0.99 x JitCyclesPerIns = 30 (JitCyclesPerIns==4), so
0.01 x CompileCyclesPerIns + 0.99 x 4 = 30 so
CompileCyclesPerIns= (30-0.99*4)/0.01=2,604.
Yep, so if QEMU can generate an instruction in 2604 ARM64 cycles, it can emulate a slow PPC 603/75 quickly enough. But why would anyone want to do that?
PowerPip Mac: A Fantasy PowerPC Mac
Is my answer. Yesterday or the day before I was musing about the relationship between the Apple Pippin and the Mac mini. In some sense it seems to me that the mini is its descendent. Here's why: the Pippin was an ambiguous machine, because it was basically a Mac with 6MB of RAM and a cut-down Mac OS 7.5. You could also (I understand) expand it to 16MB or more and add an ADB keyboard. It had internal slots (so perhaps a HD was possible) and this would turn it into a Mac. It had a cut-down ROM (the 'ROM' was on a CD), which is like the Mac OS ROM. It was also sold for $599, I believe.
So, then I wondered, could a Pippin variant have been released around the same time-frame of 1996? It'd have to be a less powerful Mac than the P6300s and P6400s. By being ruthless, its 34.3cm x 34cm x 22.6 cm dimensions[2] ( vs 32cm x 41.9cm x 10.9cm for a P6200)... (it couldn't have been that big - did T3 confuse cm with inches [ 13.5cm x 13.4cm x 8.0cm]? !) could have been squeezed down to close to a Mac mini.
I would have scrapped the other video ports and replaced the phonos with a pair of 3.5mm jack sockets.
The internal IDE is for the CD-ROM, but I guess it could feed a 2.5" HD too. We need that. I'd scrap the PCI slot, because I can't see how there would be room with a CD drive too.
Anyway, regardless, @Trash80toHP_Mini 's hardware design is certainly small enough for a fantasy Mac like this.
[1] https://past.date-conference.com/proceedings-archive/2012/PDFFILES/IP1_01.PDF
[2] https://www.t3.com/features/apple-b...eripherals-games-software-and-legacy-detailed
