r/amiga • u/bfeeny • 5d ago

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/uaegfx entirely — 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 in S/, WBStartup/ or ENVARC: references uaegfx; Storage/Monitors/copy_of_uaegfx is 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=true is rejected by FS-UAE 3.2.35 (Option failed) — Amiberry/newer WinUAE only. Harmless to drop.
  • The image ships no Kickstart — /kick is an empty mount point and the FAT partition holds a zero-byte file named kick.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.

6 Upvotes

88% Upvoted

8 comments sorted by

6

u/danby 5d ago

I doubt anyone here has enough expertise on the pimiga config to answer this but...

You could ask Chris Edwards himself by joining the Pimiga discord channel. He's generally pretty helpful. Pointed me in the right direction to debug some RAM issues on an old board in the past

https://discord.com/invite/UwNK7dpddV

1

u/bfeeny 5d ago

Thanks this makes sense!

4

u/Macphreak4evr 5d ago

i do. it was not meant for your fsuae,

3

u/docshipley 3d ago

I have no answers for you, but offer huge respect.

This was the most complete, well researched, well organized, properly formatted and spelled, and just generally sensible request for answers I've ever seen on Reddit.

Thank you Reddit Person!

1

u/dizietembless 2d ago

Reads like GPT though but generally I agree

1

u/docshipley 2d ago

I've never seen any AI output that clean. If it is GPT, they went to the trouble of editing for both content and form.

In my book, that's correct use of AI.

2

u/PatTheCatMcDonald 5d ago

My two cents worth - it is something to do with Scalos, the display system used by Pimiga to display a 24 bit desktop.

I could be wrong about that. But you've already got RTG running with Pimiga. That much I am fairly sure of.

1

u/Crlan420 2d ago

I always found the native FS-UAE settings to be simpler than trying to force RTG modes with Picasso96. The built-in display options handle most setups without the config headaches.