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
The internal CD-ROM is SCSI, not IDE. Pippin is (as far as I know) the only machine with a discrete MESH SCSI controller (it's built-in to O'Hare/Heathrow/Paddington). And the ROM is a pretty standard 4 MB SuperMario build. The "insert disk" is heavily customized but it's otherwise fairly boring.
Now that Pippin games boot in MAME I've been surprised at how little it hides that it's a Mac. There's a custom splash screen instead of the "Mac OS" one but you still get the extension icons, and the preferences panel in some games is literally just a Mac OS dialog box.
Now that Pippin games boot in MAME I've been surprised at how little it hides that it's a Mac. There's a custom splash screen instead of the "Mac OS" one but you still get the extension icons, and the preferences panel in some games is literally just a Mac OS dialog box.
Last edited:
Pippin uses Grand Central instead of O'Hare/Heathrow/Paddington. MESH is a discrete in all the Grand Central machines that have MESH (includes TNT/PowerSurge machines such as the Power Mac 9600).
That's a real surprise
! A low-cost IDE controller is barely more than a 16-bit latch.The ROM on the CD, because there's a 1MB AMD Flash.
Aaaah, I was expecting DingusPPC.
For me that's the least surprising thing ;-) . I was just checking on HD costs in mid 1996.
BYTE 1996 09 OCR : Free Download, Borrow, and Streaming : Internet Archive
BYTE 1996 09 OCR
archive.org
Cheapest HD is $170 for 1.2GB, CD-ROM is $100. That's $270. I guess if a Pippin cost $599, then this would cost $770 if it had both. However, I don't think there's room. I've recalculated the dimensions. It's 25.8cm at the bottom, 22.9cm at the top (it tapers in) and 6.7cm high (No idea where T3 got its measurements from). So, there's only space for a HD or a CD, not both, unless it's a laptop HD, which would be even more expensive and a relatively small capacity. Elsewhere in that issue of Byte (Page 211), I found hard disks about 500MB to 600MB for about $154 to $164.
A Power-Pip Mac wouldn't be a satellite Mac and we'd be working in basically a pre-broadband internet so the real challenge would be installing software. However, I think it's reasonable to assume that most people who had a computer would have an external CD-player by 1995. So perhaps software installation via CD audio at a minimum would work?
Let's scale it up from modem speeds. Modems assumed an 8kHz x 8bpp x mono bandwidth audio stream. And from this you could achieve 56kbits/s. So (naively), 20.05kHz x 16bpp x stereo would give 20.05/8*2*2*56=561.4 kbits/s or about 56kBytes/s. This is about as good as early broadband. I think it's likely people would be willing to wait an hour to install software, because we were willing to wait an hour to download and install software. This gives a maximum size of 56*3600=201,600 or 201MB. And that's big enough for applications and OS updates into the late 1990s.
So, e.g. Mac OS 8.1 is only 39MB on Infinite Mac (12 minute download).
This brings me to the next problem. A Power-Pip Mac saves costs mostly by eliminating ports, expansion slots and at least one storage device. That approach works well from the mid 2000s (when the real Mac mini appeared), and even better from the 2010s (when Mac minis lost their optical drives), but it wouldn't have worked well in the mid-1990s, because a practical machine would need SCSI external expansion (USB made expansion much cheaper) or PCI (no room); the internet wasn't fast enough for System/App downloads and cheap hard disks would rapidly run out of space. Case in point: my PowerMac 4400 had a whopping 1.1GB HD, but I fairly quickly had to start offloading stuff to my Zip drive.
Consequently, my audio CD software-install approach feels somewhat silly. This means a Power-Pip Mac would be barely usable as a standalone device, but in a corporate or school lab its lack of expandability might be an asset as it'd be easier to stop kids or employees downloading rubbish or malware. AppleTalk would work for installing software, or accessing software from a server to offload its own lack of storage. Which essentially would turn it back into a Network Computer, as Apple envisioned for its successor.
Oh, I thought it had 128kB of battery-backed RAM for saving game state. I should have thought about whether the ROM was on CD, because it only had 6MB of System RAM as standard, and a 4MB ROM would eat nearly all of that.
Yes, we used GALs for a PC-based, IDE-based PCMCIA card storage system in the mid 1990s. And this was for 386-class PCs. I suspect that a 66MHz PowerPC really was fast enough to do it entirely in software, with just a couple of latches ( a 23-bit output latch and a 17-bit input latch). I don't think this has been done on any Mac, but some MCU IDE interfaces for retro systems have, I think.
Checking this. StarDot covers Archimedes IDE interfaces using a few latches and a single GAL.
An interface using an 8255 (roughly equivalent to a VIA):
Wesley's PIC Pages: IDE Controller
The above is quite an interesting post as it means an IDE interface could be made just using an Arduino + an 8-bit output latch (or 2 arduinos). An Arduino as standard has D0..D19, 20 I/O pins. Allocating pins as follows:
- Ser D0..D1 Rx and Tx to the host, an Arduino can buffer a whole sector at a time.
- DBLo = D2..D9 => IDE_D07A02Cs01RWRst
- DBHi = D10..D17 => IDE_D8_15
- D18 => Op
- D19 => nLatch
So, I think you can do that with an open-collector latch +1 transistor + 1 resistor per fake OR gate.
Vcc--+-----[220R]=-|
. +[220R]| +---nIdeRd
LatchR -----+----|<
Op----------+. |
. GND
Thus if either LatchR or Op are low, nIdeRd is high, but if both are high, then nIdeRd goes low. Thus:
| Step | Rd [drive=d] | Wr |
|---|---|---|
| 1 | DbLo=A0..A2 + CS01=11, RW=10. | DbLo=A0..A2 + CS01=11, RW=01. |
| 2 | nLatch=0 | nLatch=0 |
| 3 | nLatch=1 | nLatch=1 |
| 4 | DbLo=A0..A2 + CS01=2-d, RW=10. | DbLo=A0..A2 + CS01=2-d, RW=01. |
| 5 | nLatch=0 | nLatch=0 |
| 6 | nLatch=1 | nLatch=1 |
| 7 | DbLo.DDR=input, DbHi.DDR=Input | Out DbLo, Out DbHi |
| 8 | Op=1 (forces nRd low) | [Delay?] |
| 9 | [Delay?] | Op=1 (forces nWr low) |
| 10 | In DbLo, In DbHi | [Delay?] |
| 11 | Op=0 (nRd.= high now). | Op=0 (nWr.= high now). |
| 12 | DbLo.DDR=output, DbHi.DDR=output | DbLo=A0..A2 + CS01=11. RW=00. |
| 13 | DbLo=A0..A2 + CS01=11. RW=00. | nLatch=0 |
| 14 | nLatch=0 | nLatch=1 |
| 15 | nLatch=1 |
About 22 cycles for a Read (1.45MB/s max) and 16 cycles for a Write (2MB/s), but in reality speeds are limited by serial data rates.
