Projects Content

Closer and closer

It's been 2 weeks since the last update and I feel like posting something about Paula32's progress.

The good news is :

Paula boots past all execution hangs, reaches the rendering phase (FE8236 ~ Paint)) and technically opens the screen without crashing.

But... yeap... there's always a "but"....Instead of a proper graphical menu, the screen displays visual noise, random pixels and faint raster lines (as seen in the screenshot).

If you ask my opinion, this has to be the coolest buggy screen (right click for a bigger resolution),

My current task is to investigate why the rendering routine (E684FE) maps the bitplanes to empty memory rather than the actual decoded data.

~ Scatman

Not really an update

I'm making this post mostly to test out posting on the new site layout and at the same time, I wanted to give a quick update on where the emulator currently stands. As I mentioned in my previous post, I've been developing it steadily and without interruption. I'm currently at 50–65% boot progress. The custom chipset is already writing Copper and BPLCON registers, and we are just a hair away from the first native visual frame.

A fast report :

I finally managed to kill the Exec Alert 87000000 -> Fixed a corrupted stack-based MemList (ml_Num = 0) where AllocEntry mistakenly read a string pointer (00F9F505) as an allocation size.
Surgical Memory Guard -> Replaced a broad MEMF_CLEAR (which broke task enqueues) with a precise guard that clears memory only when preW0 == 4EF9 (JMP-stub soup).

They might sound innocent but both of them gave me a hard time.

Current situation :

Wiping out the 4EF9 junk successfully eliminated the old Address Error (JMP (A4) crashing on odd PC 1F024EF9).
The Catch -> The dos LibBase struct at 00C59A00 now arrives with its +4 (ln_Pred) field as a clean 0 instead of junk. Consequently, the JMP (A4) now results in a NULL JMP because an expected pointer is never written prior to F9F892.

I'm tracking down which initialization or enqueue routine is supposed to populate C59A00+4. I strongly believe that once that's locked down, the path to the bootmenu and the first graphical frame opens up! Fingers crossed!

~ Scatman

Definitely NOT dead!

Three weeks ago I ran into a serious setback as my main hard drive died without warning. The result was painful... I lost several important files, including the full backup of my website. Even though I still had the raw files from my hosting provider, I decided not to simply restore everything as it was. It felt like it was the right moment to rebuild the site with a cleaner structure and a more "modern" look. Well, at least more modern than before.

So I designed a completely new layout from scratch, updated almost all of the links and refined a lot of the content. The downside is that the older updates will not be re‑uploaded. From here on, the timeline continues fresh.

The CD32 emulator project is still very much alive. In fact, the development approach has evolved significantly.

I need to mention that the Kickstart ROMs are extremely demanding. They essentially force me to follow the native execution flow 100% without shortcuts, hacks or any deviation. If the ROM sees anything non‑native, it simply refuses to co-operate. It's super frustating at times but it is what it is.

I have to admit: the emulator originally relied on several ROM‑flow hacks. Removing them and rebuilding the system so that the Paula32 behaves as close to real hardware as possible has made the work more challenging than ever.

In simple terms, Paula32 is becoming , slowly , a fully native CD32 machine. Blame the roms for that! :D

Hopefully, I will write some newer updates later this month. Till then, check out the new site!

~ Scatman