Living the dreamm~ PowerMac G5

[jpreza]

Replying this directly from Power Mac G5.
View attachment 91792

View attachment 91793

Best regards,
Link.

NICE!!! I'm going to have to try this on my watercooled 2.5GHz DP PMG5!

 

[Link4Electronics]

Well, took a while since last post here, lot's of things going on

Found a totally open source MMO/RPG game (including assets etc), Eternal Lands
but on big-endian is more like flatlanders edition, since everything is flat not rendering 3d models, could see other players sending messages on chat and see their icon moving on overworld map


Another cool game, Whiplash/Fatal Racing, added a preliminar support for mac os x, don't know if it'll work on mac though

yahooo! (there's still a small issue with this one, after car makes a first jump, engine sound stops working)

and just today, got Mania Drive working too, there's some initial mac os x support


repositories for the last two

GitHub - Link4Electronics/ROLLER: Reverse engineering the 1995 game Whiplash/Fatal Racing

Reverse engineering the 1995 game Whiplash/Fatal Racing - Link4Electronics/ROLLER

github.com

GitHub - Link4Electronics/ManiaDrive: A fork trying to modernize ManiaDrive

A fork trying to modernize ManiaDrive. Contribute to Link4Electronics/ManiaDrive development by creating an account on GitHub.

github.com

Regards,
Link.

 

[Link4Electronics]

Managed to make OpenGL 4.6 to work which was broken for AMD radeon R600/Terascale 2 (it was stuck on a broken OpenGL3.2)


And Lego Island port to work too on big-endian devices, it supports OpenGL ES3.0, GL ES 2.0 and OpenGL 1.1

GitHub - Link4Electronics/mesa_r600_be: r600 bigendian fixes to bring OpenGL 4.6

r600 bigendian fixes to bring OpenGL 4.6. Contribute to Link4Electronics/mesa_r600_be development by creating an account on GitHub.

github.com

GitHub - Link4Electronics/isle-portable: A portable version of LEGO Island (1997)

A portable version of LEGO Island (1997). Contribute to Link4Electronics/isle-portable development by creating an account on GitHub.

github.com

Regards,
Link.

 

[Andrew-R]

Managed to make OpenGL 4.6 to work which was broken for AMD radeon R600/Terascale 2 (it was stuck on a broken OpenGL3.2)
View attachment 100279

And Lego Island port to work too on big-endian devices, it supports OpenGL ES3.0, GL ES 2.0 and OpenGL 1.1
View attachment 100280

GitHub - Link4Electronics/mesa_r600_be: r600 bigendian fixes to bring OpenGL 4.6

r600 bigendian fixes to bring OpenGL 4.6. Contribute to Link4Electronics/mesa_r600_be development by creating an account on GitHub.

github.com

GitHub - Link4Electronics/isle-portable: A portable version of LEGO Island (1997)

A portable version of LEGO Island (1997). Contribute to Link4Electronics/isle-portable development by creating an account on GitHub.

github.com

Regards,
Link.

Cool!

 

[Andrew-R]

Edit: while vdpau st was removed from mesa, I am not sure vaapi ever worked for decoding on BE hosts? There are at least two reports on tracker about vaapi NOT working on BE on r600

GPU lockup when using r600g VDPAU on powerpc (#588) · Issues · Mesa / mesa · GitLab

Submitted by j.r..@..ok.com Assigned to Default DRI bug account Link to...

gitlab.freedesktop.org

 

[Link4Electronics]

Hi, yes one of first things that came to mind is vaapi/vdpau when opoengl4.6 finally got working, but according to internet for r600 vaapi/vdpau never worked properly, they removed on Mesa 22 for r600 and then completely for all drivers on mesa 25.3. I guess in the future they only want to stay with vulkan, vulkan video for encode/decode, and zink for opengl wrapper. I forgot about OpenCL to check if it works but I don't think much would run on that nugget R5 230(HD 6450 rebrand)

QMPLay2 which is my favorite multimedia player, still have some issues when choosing opengl to render, but qpainter/sw render works fine, but I think the issue of GL relies on qmplay2.

Right now I already have RMG n64 emulator working on the G5, trying to make the dynarec mips-to-ppc to work, so far audio and input works, using interpreter games already goes ingame but very glitchy.

Regards, Link.

 

[Andrew-R]

Hi, yes one of first things that came to mind is vaapi/vdpau when opoengl4.6 finally got working, but according to internet for r600 vaapi/vdpau never worked properly, they removed on Mesa 22 for r600 and then completely for all drivers on mesa 25.3. I guess in the future they only want to stay with vulkan, vulkan video for encode/decode, and zink for opengl wrapper. I forgot about OpenCL to check if it works but I don't think much would run on that nugget R5 230(HD 6450 rebrand)

QMPLay2 which is my favorite multimedia player, still have some issues when choosing opengl to render, but qpainter/sw render works fine, but I think the issue of GL relies on qmplay2.

Right now I already have RMG n64 emulator working on the G5, trying to make the dynarec mips-to-ppc to work, so far audio and input works, using interpreter games already goes ingame but very glitchy.

Regards, Link.

I think vaapi state tracker still there, you just need to enable more interesting codecs like

-Dvideo-codecs="all" as argument for initial configuration.

 

[Link4Electronics]

Hi, I figured out what's the issue with QMPlay (or any other video related app) why it doesn't play videos when trying to use opengl, linux kernel is causing issues when it boots, gpu fails on ring 5, ring5 is UVD3.1 training for AMD CAICOS and since it fails it disables it so no encode/decode via GPU. Just like on first slot pci-e x16 that is connected directly to the IBM CPC945, it fails with ring0 and disables GPU acceleration, need to put the GPU on slot x8, I'm trying to make it work though via first slot x16, issue seems to be DMA address range

Got some new games working too

Perfect Dark decompilation project which uses OpenGL3.0


Minecraft 1.16.5


OpenRCT2, still has some issues to place Rides with RCT2 (RCT1 is fine) and is missing some texts


RMG Nintendo 64 emulator, still with static interpreter and some small graphics issues, using OpenGL2.x

GitHub - Link4Electronics/archpower-packages: Packages for ArchPOWER

Packages for ArchPOWER. Contribute to Link4Electronics/archpower-packages development by creating an account on GitHub.

github.com

GitHub - Link4Electronics/perfect_dark: work in progress port of n64decomp/perfect_dark to modern platforms

work in progress port of n64decomp/perfect_dark to modern platforms - Link4Electronics/perfect_dark

github.com

GitHub - Link4Electronics/RMG: Rosalie's Mupen GUI

Rosalie's Mupen GUI. Contribute to Link4Electronics/RMG development by creating an account on GitHub.

github.com

GitHub - Link4Electronics/OpenRCT2: An open source re-implementation of RollerCoaster Tycoon 2 🎢

An open source re-implementation of RollerCoaster Tycoon 2 🎢 - Link4Electronics/OpenRCT2

github.com

Regards,
Link.

 

[joevt]

Just like on first slot pci-e x16 that is connected directly to the IBM CPC945, it fails with ring0 and disables GPU acceleration, need to put the GPU on slot x8, I'm trying to make it work though via first slot x16, issue seems to be DMA address range

The x16 slot is handled by a different PCIe host than the other slots.
The PCIe host for the x16 slot has access to all the PCIe config space for each device (all 4096 bytes per device/function).

The other PCIe host (used by the other PCIe slots) seems to only have access to the PCI config space (256 bytes per device/function).

The CPC945 manual is interesting. It mentions conformance with HyperTransport Link Specification 1.04 (256 bytes for config space) but does have a mention of the 1.05 spec (allows 4096 byte config access) in the list of references.

The 0xF0800000 config address and 0xF0C00000 config data registers allows PCIe config space access (4096 bytes) for the host (type 0 access) and the x16 slot (type 1 access).

/pci@0,f0000000
00:0b.0-[0a]    [106b:005b] [060400] 
0a:00.0         [10de:0092] [030000]

The 0xF2xxxxxx and 0xF3xxxxxx ranges (for type 0 and type 1 direct accesses respectively) allow PCI config space access (256 bytes) to the other devices and slots.

/ht@0,f2000000/pci@1
00:00.0         [106b:0074] [060000]
00:01.0-[04]    [1166:0130] [060400]
00:02.0-[05]    [1166:0130] [060400]
00:03.0-[06]    [1166:0132] [060400]
00:04.0-[07]    [1166:0132] [060400]
00:05.0-[08]    [1166:0132] [060400]
00:06.0-[09]    [1166:0132] [060400]
00:07.0-[02]    [106b:0053] [060400]
00:08.0-[01]    [106b:0054] [060400]
00:09.0-[03]    [106b:0055] [060400]
01:07.0         [106b:004f] [ff0000]
01:0b.0         [1033:0035] [0c0310]
01:0b.1         [1033:0035] [0c0310]
01:0b.2         [1033:00e0] [0c0320]
02:0f.0         [106b:0051] [020000]
03:0c.0         [1166:0240] [01018f]
03:0d.0         [106b:0050] [ff0000]
03:0e.0         [106b:0052] [0c0010]
05:04.0         [14e4:166a] [020000]
05:04.1         [14e4:166a] [020000]

 

[Link4Electronics]

Hi, thanks for the information, from your lspci log, already noticed two different things, it does have RlxdOrd and NoSnoop both enabled for x16 slot, AMD Caicos almost certainly requested both, if RlxdOrd failed, could explain the ring0 failure and adding a patch to clear it on GPU's DevCTl (or on the bridge's DevCtl). But didn't have time to test anymore the x16 slot, took so many attempts and takes a while to compile kernel again and again, reboots etc, I'll leave this for later, when have more free time and analyze it calmly.

joevt, I used your flashrom tool to dump the openfirmware rom of PowerMac G5 and a Mac Mini G4 silent update, I wonder if is there any preservation effort going on for these newer macs roms? Couldn't find anywhere on the internet, wonder if would be ok to share my dumps here? I used MacOS X Tiger to dump them, I noticed that if use Leopard it'd dump but the checksum would be different, so I doubled checked that with Tiger.

In terms of games, got re3/reVC working (only issue remaining is with car's horn which is like rapid fire/cutting it) I know these 2 maybe doesn't sound that impressive since both are at macintoshgarden a few years ago (although I suspect opengl requirement was relaxed to make them work on Tiger/Leopard), re3/reVC uses OpenGL 3.0+

Got dolphin-emu working too, but only with cachedinterpreter so extremelly slow, luigi's mansion got 15fps and this game ran at 30fps on real console. Was trying to implement a native code execution for powerpc, but hit a dead wall (apparently IBM changed a lot from 750cxe PowerISA 1.01 to PowerISA 2.01? of 970PPC CPU, removed paired integers and many other instructions and adapted/consolidated them on altivec?), so ported that to a just-in-time targeting specially powerpc 970 AltiVec with ELFv2 and 64kb pagesize, it's around >90% implemented but having issues with some altivec trampoline, ppc32->ppc64 or registers/fastmem. Dolphin-emu is using OpenGL 4.6 core profile with AMD Caicos R5 230 gpu. Wii games boots but has issues to store some game files in internal storage that dolphin emulates, issue with storage encryption.

GitHub - Link4Electronics/dolphin

Contribute to Link4Electronics/dolphin development by creating an account on GitHub.

github.com

Regards,
Link.

 

[Andrew-R]

Barracuda156 implemented (with AI assistance) some vp9/aac/ac3/hevc/h264 decoding speedups for ffmpeg8 in latest patch series:

powerpc-ports/multimedia/ffmpeg8/files at main · macos-powerpc/powerpc-ports

Overlay repo with fixes to use with MacPorts on macOS PowerPC - macos-powerpc/powerpc-ports

github.com

I guess - feel free to test on Linux?

 

[joevt]

Hi, thanks for the information, from your lspci log, already noticed two different things, it does have RlxdOrd and NoSnoop both enabled for x16 slot, AMD Caicos almost certainly requested both, if RlxdOrd failed, could explain the ring0 failure and adding a patch to clear it on GPU's DevCTl (or on the bridge's DevCtl). But didn't have time to test anymore the x16 slot, took so many attempts and takes a while to compile kernel again and again, reboots etc, I'll leave this for later, when have more free time and analyze it calmly.

Note that my PCI config capture is from Open Firmware, not Mac OS X or Linux. I don't know what those flags are for or if or why an OS might change them.

joevt, I used your flashrom tool to dump the openfirmware rom of PowerMac G5 and a Mac Mini G4 silent update, I wonder if is there any preservation effort going on for these newer macs roms?

I don't know of any preservation efforts. I have all of them locally and on Dropbox. MAME might have a iMac or B&W G3 dump.
All the ones I have are listed at https://forums.macrumors.com/thread...l-work-in-a-beige-power-macintosh-g3.2303689/ in the "List of Open Firmware versions".
ROMs I've obtained are also indicated in the romidentity.cpp source file of DingusPPC as comments that state Open Firmware version and build date. I've attached romlist.txt which lists all the Mac ROMs.

Also in the attachment is MAME rom list.worksheet which I haven't updated in a couple years. It has a list of 16 New World ROMs but I don't know (or don't remember) where or if they have downloads available for them.

I used MacOS X Tiger to dump them, I noticed that if use Leopard it'd dump but the checksum would be different, so I doubled checked that with Tiger.

Post-grackle era New World Macs (after G4 Yikes), starting with 3.2.4f1, store NVRAM on the same flash as the firmware. This changes when you change the startup disk.

The ROMs you have are these (which I already have):

Mac Mini G4
2005.0712  4.9.4f1  0x0282.01  f4dc2533  31c3da94.afc428e3.6ffcc00a.eb0ab168

G5 Dual or Quad Core PCIe
2005.0930  5.2.7f1  0x22c2.02  b7fe51fc   f64cfc26.4a455557.beca915e.eeec8109

The first checksum (e.g. f4dc2533) is a partial checksum of the config block which excludes Open Firmware version and build date. This is used as one of the identifiers in romidentity.cpp for identifying a machine model. The config block contains the model and revision (e.g. 0x0282 translates to PowerMac10,2 and 0x22c2 translates to PowerMac11,2) and info about features of the model.

The next four checksums are: start (PowerPC exception vectors and HWInit), config block, recovery, and romimage. DingusPPC will calculate those and verify them but will not use them for the sake of machine identification.

Although DingusPPC has code to identify these post-grackle era New World ROMs, it does not yet emulate any of them.