#powerpc

So I tore out its insides (leaving the CRT screen intact) and replaced them with a brand new Mac Mini M4.

PikaPC Runs First Code

I've finished wiring the essentials on my PikaPC homebrew computer project. As it sits currently, it has the PowerPC 403GA CPU clocked at 24MHz, 512kB of flash ROM on an 8-bit bus, 1MB of SRAM on a 16-bit bus, and one serial port. I'm using an ATX power supply because it has the standard +3.3V, +5V, +12V, and -12V rails that I need. That should be everything necessary to start testing and running some simple software.

I just need to get it working.

I have been procrastinating on this project. Sometimes when I start something new I get excited and a little carried away. Instead of stopping and testing each piece as I go along, I'll blow through and wire the whole thing in one go. This means that by the time I get around to testing, I've already put in a lot of effort and there is far more to go wrong. It can be really intimidating and hard to know where to start when there is a problem.

I wired the whole thing. And it's really intimidating. It is Schrodinger's project — until I throw the switch and observe, it is both working and not working. But the only way to move forward is to push past the anxiety and throw the switch.

Here goes …

It didn't immediately blow up, that's a good first step. Nothing is getting hot, so probably no direct shorts. Clock is running just fine, and reset signal is behaving as expected. Only thing left is to throw some code onto a ROM and see what happens.

I've decided to try running PPCForth, a Forth environment targeting the PPC403 family with special features for loading code over serial and even re-flashing its own ROM. It's just the thing for a project like this! The author was targeting the PPC403GC, whereas I have the PPC403GA, so there were a few minor adjustments I had to make to get it to compile.

I burned it to ROM, connected serial port to a terminal, and … nothing.

Pulled out the oscilloscope. No movement on the serial Tx pin. Reset & clock are still working, the boot option pins are strapped to the right values. But there is no activity on any of the address, data, or control wires.

Or so I thought. My oscilloscope is an older style analog scope that some wonderful person gifted me at VCF Southwest 2023. It is a great tool for repeating signals, but is not a capture scope so it's easy to miss very fast transient signals. Some things just need a logic analyzer.

It's doing something. It toggles the data read strobe and the ROM chip select signal for about 6 milliseconds before stopping. Much too quick for me to be able to see reliably on my scope. But the CPU is not indicating that it is halting. I need to capture more to see what is happening.

The data bus looks interesting. It starts out moving slowly and then speeds up.

Which is exactly what it is supposed to do.

The PPC403GA has an on-board memory controller. It runs the bus slowly on reset for broad compatibility, and then software can configure the memory controller to run at the proper speed for the attached devices. That's what is happening here. It is running code at least long enough to configure the memory controller.

With the logic analyzer capture, I can read through the data it's fetching to see where in the code it is halting. I traced it down to the putch routine, which outputs data over the serial port. It got as far as checking if the UART was ready to send data and then never loaded any more code.

But that is actually expected behavior. The CPU has 2kB on-board cache and is running a tight loop. It doesn't need to fetch any more code until it exits the loop, and it won't exit the loop until the UART is ready to send data.

This actually had me stuck for a while. Best I could get it to do was sometimes output garbage on the terminal. I double- and triple-checked my wiring and serial pinout. And finally, I buzzed out the IDC-to-DE9 adapter I was using. Instead of ground being on pin 5 of the DE9 connector, it was on pin 3?

Ah. There are two different standards for IDC-to-DE9 adapters, and I was using the wrong one. As a result, the CPU never saw the Clear To Send signal it was expecting, so it never signaled to the program that it was ready to send data.

It was running! And then immediately crashing.

It turns out the code still had some references to an LED GPIO pin that the PPC403GA doesn't have. I just needed to comment out a few more lines of code and update my ROM.

And now my little PikaPC boots up to a welcoming Forth prompt.

All in all that was a surprisingly painless bring-up. No major wiring errors; I had just grabbed the wrong adapter. And save for a few minor adjustments, the code just worked too.

I did surgery on Ticky! some parts felt as anxiety provoking as if I were prodding into a human (POSIC?) I removed a staple I found on it's hard drive, which I think was because it was a school machine

here's it before I fixed him, confirming the hard drive is broken, he would go to a gray screen and make ticking sounds

now quiet and boots fine!

this is considered one of the hardest older laptops to repair, according to a YouTube tinkerer that I watched to learn about it, there are many tabs and everything can break easily

there was a STAPLE I found on top of the broken hard drive, I wonder if it somehow damaged it? it came through the vent

this is my second fixed machine, the other one had RAM with bad pins that seemed scraped and corroded and I think it's because seller said there used to be a swollen battery, I think it pushed up and damaged the RAM

it was fun and not so expensive actually, but I broke two spudgers trying to carefully pry the tabs!

🎄💾🗓️ Day 10: Retrocomputing Advent Calendar - BeOS 🎄💾🗓️

BeOS, developed by Be Inc. in the mid-1990s, was an operating system for multimedia applications, multitasking, and multithreading. Initially designed for the BeBox—a proprietary hardware platform featuring dual PowerPC processors—BeOS was later ported to the Macintosh and x86 architectures. Its kernel was monolithic, and the system was primarily written in C++. It featured a 64-bit journaling Be File System (BFS), which supported metadata and allowed rapid file queries and fast performance for multimedia tasks. Despite its technical strengths, including support for symmetric multiprocessing and a responsive graphical user interface, BeOS struggled to gain market traction. Development ceased in 2001 after Palm Inc. acquired Be Inc.'s assets. BeOS continues through Haiku, an open-source project aiming for binary compatibility with BeOS R5.

A bunch of resources and links for this one!

🖥️💾🎨📀

📅 This day - on July 3, 1991, Apple and IBM signed a letter of intent to form the AIM alliance, which included Motorola. This alliance aimed to create an industry-wide open-standard computing platform based on the POWER instruction set architecture.

💻 The primary goal was to design a new hardware platform and develop a next-generation operating system that would unify the computing industry. IBM planned to bring the Macintosh OS into the enterprise market, while Apple aimed to be a major customer for the new POWER hardware.

🛠️ IBM and Motorola allocated 300 engineers to co-develop chips at a joint facility in Austin, Texas. Motorola would manufacture and sell these chips to Apple and other customers. Over 400 people from the three companies worked to create a unified corporate culture, promising to "change the landscape of computing in the 90s."