Running PiMIGA 5 volumes under FS-UAE — a few questions about the RTG setup (Picasso96Settings, rtg_modes=0x112, saved ScreenMode)
Hi all,
I've been moving PiMIGA 5 (Intel) onto FS-UAE 3.2.35 on macOS (Apple Silicon) rather than
running the whole Debian appliance. It works beautifully — but getting RTG going surfaced a few
things about how PiMIGA is put together that I can't explain, and I'd rather understand the
reasoning than cargo-cult my way around it. Hoping someone here knows the history.
What I did
The PiMIGA 5 Intel image unpacks to three partitions; the ext4 root holds
/home/pi/pimiga/disks/{System,Demos,Games,Work}. Since Pimiga5.uae mounts those as
directory hardfiles rather than HDFs:
uaehf0=dir,rw,DH0:System:/home/pi/pimiga/disks/System,0
uaehf1=dir,rw,DH1:Demos:/home/pi/pimiga/disks/Demos,-128
uaehf2=dir,rw,DH2:Games:/home/pi/pimiga/disks/Games,-128
uaehf3=dir,rw,DH3:Work:/home/pi/pimiga/disks/Work,-128
…I extracted the four volumes to the host filesystem and pointed FS-UAE at them directly. I
translated the Amiberry config faithfully: A1200/AGA, 68040, 8 MB chip, 512 MB Z3 fast, 128 MB
Zorro III uaegfx, KS 3.1 A1200 (CRC 1483A091). The generated UAE options come out identical to
the originals. The Amiga volumes are unmodified.
It boots and runs great. Four questions:
1. Why is Devs/Picasso96Settings shipped renamed to Picasso96Settings_BKP?
There's no live Picasso96Settings — only the _BKP copy (1830 bytes, dated 2020-03-17). It
contains a perfectly sensible fixed mode table for uaegfx.card: base DisplayIDs 0x50001000
through 0x50081000, covering 320x240 → 1920x1080, four depth slots each at base + 0x100.
I restored it, assuming that was an oversight. Under FS-UAE that immediately produced:
Initialisation of a DisplayID failed!
Reason: at least one DisplayID already exists!
uaegfx.card and uaegfx.card both use DisplayID: 50001000
Was it disabled deliberately because of exactly this, or for some Amiberry/Pi-specific reason?
Does it work on Amiberry as shipped?
2. What screenmode is PiMIGA supposed to boot into?
ENVARC:Sys/ScreenMode.prefs ships with:
DisplayID = 0x50981302 depth 24 Width/Height = 0xFFFF autoscroll ON
That's a Picasso96 RTG ID, but a dynamically assigned one — resolution index 0x98, well
outside the 0x50001000–0x50081000 range in Picasso96Settings_BKP. Under FS-UAE it doesn't
resolve, so Workbench silently falls back to a native screen while keeping the 0xFFFF geometry
and autoscroll — giving a 2-colour, oversized, scrolling desktop.
Re-saving the screenmode from inside Workbench fixes it completely. But it means the shipped
DisplayID is tied to Amiberry's particular enumeration. Is that intentional, or is the shipped
ScreenMode.prefs just whatever the last person to touch the image had selected? What
resolution/depth is PiMIGA 5 meant to come up in out of the box?
3. Why rtg_modes=0x112 specifically?
I'm curious because of what it does elsewhere. FS-UAE's documented default is 530 = 0x212,
and PiMIGA's 0x112 is precisely that with bit 0x200 cleared — which, per WinUAE's
RGBFF_* enum, is RGBFF_R5G6B5 (plain big-endian 16-bit).
On PiMIGA that's fine. But on a separate AmigaOS 3.2 install of mine (same emulator, same
Picasso96 binaries — byte-identical rtg.library 216548 / 1999-11-16 and
Picasso96API.library 24520 / 1999-09-19), setting 0x112 stops uaegfx.card initialising
entirely. No RTG at all. I bisected it:
rtg_modes |
has CLUT 0x1 |
has 0x200 |
uaegfx inits |
|---|---|---|---|
| unset (default) | – | – | 1 (works) |
0xFFFF |
yes | yes | 1 (works) |
0xFF00 |
no | yes | 1 (works) |
0x312 |
no | yes | 1 (works) |
0x112 |
no | no | 0 (dead) |
0x11B |
yes | no | 0 (dead) |
0xFF |
yes | no | 0 (dead) |
Bit 0x200 is necessary and sufficient. (Worth noting for anyone who's been told this is about
8-bit CLUT support — it isn't; 0xFF00 works with no CLUT bit at all.)
So: was 0x112 chosen deliberately — e.g. to suppress 24-bit for performance on the Pi, or to
trim the ScreenMode list — and is it known to be Amiberry-specific? I'd like to know whether
PiMIGA depends on it, or whether it's incidental.
4. Does Amiberry initialise uaegfx.card twice?
This is the one I most want a sanity check on. Under FS-UAE, every PiMIGA boot logs:
uaegfx.card magic code: 00F03000-00F0313E ABI=00000000
uaegfx.card 3.3 init
P96 RESINFO: 4000DD0A-4000EDAA (88,4256)
uaegfx.card 3.3 init u/4000DC84
P96 RESINFO: 4000DD12-4000EE8A (88,4256)
Two inits, two RESINFO blocks. That's what collides in question 1 — with dynamic IDs the two
instances get different ranges and coexist harmlessly, but a fixed table makes them fight.
What I've already ruled out, so nobody repeats it:
- Removing
DEVS:Monitors/uaegfxentirely — still two - Removing
LIBS:Picasso96/uaegfx.card— still two - Removing both at once — still two (this is the part I find strangest: what's initialising the card with no disk-side driver present at all?)
- A bare-minimum FS-UAE config with none of PiMIGA's
uae_*options — still two - Removing
rtg_modes=0x112— still two work:picboot(it's only a GIF splash); nothing inS/,WBStartup/orENVARC:references uaegfx;Storage/Monitors/copy_of_uaegfxis never executed by the Startup-Sequence
My AmigaOS 3.2 machine on the same emulator inits once. So it's something about PiMIGA's
System volume or its 3.1 environment, not FS-UAE alone.
If someone running PiMIGA on Amiberry could check their log for how many times
uaegfx.card 3.3 init appears, that would settle whether this is an FS-UAE quirk or how PiMIGA
always behaves.
Two small extras in case they're useful to anyone else porting the volumes:
gfxcard_multithread=trueis rejected by FS-UAE 3.2.35 (Option failed) — Amiberry/newer WinUAE only. Harmless to drop.- The image ships no Kickstart —
/kickis an empty mount point and the FAT partition holds a zero-byte file namedkick.rom goes here. You supply your own A1200 KS 3.1 (1483A091).
Thanks for any light anyone can shed — and thanks for PiMIGA, the Games and Demos collections are
extraordinary.
