E-Maculation

Posted: **Sun Feb 05, 2017 3:27 pm**

Apparently, DOSBox has Voodoo2 emulation working, that translates Glide2 calls to OpenGL.

http://www.vogons.org/viewtopic.php?t=25888

http://dl.dropbox.com/u/7801769/DOSBox% ... _Intel.dmg

I wonder if we can use this with Qemu to emulate a Voodoo2 in OS 9?

Here are the diff's for it, but I'm not sure what version of DOSBox's source code they are build against.

DOSBox ?Windows?.

https://drive.google.com/open?id=0B9sU4 ... Hd6aUF6VjQ

DOSBox OS X:

https://drive.google.com/open?id=0B9sU4 ... GNWREt4Wm8

Posted: **Sun Feb 05, 2017 10:46 pm**

Just looking at the code for DOSBox, it looks like it uses SDL for windowing and OpenGL calls to the host. So, I figured a good starting place would be to get a working SDL build of Qemu.

I tried first with the Qemu source from GitHub, but that built, but I got some crazy error when I run make install, about a missing file. Remembering that alex made an SDL build, I used his source linked in the mega thread, and it seemed to build fine with --enable-sdl --disable-cocoa in the configure script.

Now I have an SDL build, that supports screen scaling in windowed mode:

I guess that's the easy part, I've tried to apply the diff's to DosBox's latest SVN, but I get errors when I try and make it. Once I figure out how to get it to compile clean, I'll start to figure out how it does it's voodoo emulation, and how hard it will be to port to Qemu.

Here is an updated diff against the lastest SVN for DOSBox, still need to run the OS X diff linked in my first post.

https://drive.google.com/open?id=0B9sU4 ... VdiZFA5bWc

Just cd to the DOSBox source dir and run:

Code: Select all

patch -p0 -i < voodoo_20160825.diff

and:

Code: Select all

patch -p0 -i < voodoo_fix.diff

Posted: **Mon Feb 06, 2017 12:57 pm**

Ok, so now I think the next step is to get the Voodoo2 to enumerate on the PCI Bus of the emulated mac, I found something interesting in the pic_database.c:

Code: Select all

static const pci_dev_t vga_devices[] = {
    {
        PCI_VENDOR_ID_ATI, PCI_DEVICE_ID_ATI_RAGE128_PF,
        NULL, "ATY",      "ATY Rage128", "VGA\0",
        0, 0, 0,
        NULL, NULL,
    },
    {
        PCI_VENDOR_ID_QEMU, PCI_DEVICE_ID_QEMU_VGA,
        NULL, "QEMU,VGA", "Qemu VGA",    "VGA\0",
        0, 0, 0,
        NULL, NULL,
    },
    {
        0xFFFF, 0xFFFF,
        NULL, NULL, NULL, NULL,
        -1, -1, -1,
        NULL, NULL,
    },
};

static const struct pci_iface_t vga_iface[] = {
    {
        0x00, "VGA controller", NULL,
        vga_devices, &vga_config_cb, NULL,
    },
    {
        0x01, "8514 compatible controller", NULL,
        NULL, NULL, NULL,
    },
    {
        0xFF, NULL, NULL,
        NULL, NULL, NULL,
    },
};

static const pci_subclass_t displ_subclass[] = {
    {
        PCI_SUBCLASS_DISPLAY_VGA, "display controller",
        NULL, NULL, vga_iface,
        NULL, NULL,
    },
    {
        PCI_SUBCLASS_DISPLAY_XGA, "XGA display controller",
        NULL, NULL, NULL,
        NULL, NULL,
    },
    {
        PCI_SUBCLASS_DISPLAY_3D, "3D display controller",
        NULL, NULL, NULL,
        NULL, NULL,
    },
    {
        PCI_SUBCLASS_DISPLAY_OTHER, "misc display controller",
        NULL, NULL, NULL,
        NULL, NULL,
    },
    {
        0xFF, NULL,
        NULL, NULL, NULL,
        NULL, NULL,
    },
};

I wonder why there is a ATY, Rage128?

Anyway, I think the part I'm interested in is PCI_SUBCLASS_DISPLAY_3D, "3D display controller". I don't think the Voodoo2 was a VGA device, I think it just did VGA passthrough, tho I'm not sure what class of device it was, I think the subclass was "3D display controller".

Posted: **Mon Feb 06, 2017 2:37 pm**

hmmmmmm...................

The ATI Extensions didn't load, I'm sure the Startup would have bombed out if they did. I really still emulating the QEMU_VGA, I think I just changed the Vendor ID the Device ID and the name in the Device Tree, but that should have been enough to load the ATI Extensions?

It maybe easier to try and emulate the Rage 128, than the Voodoo2, I still have to track down the 3DFX Voodoo2 Extensions, they seem to be lost to the internet, and I'm unsure of the Class Type of a Voodoo2, but I have all that nice code from DOSBox, that gives the perimeters of the Voodoo2, and translates Glide calls from the Guest, to OpenGL calls for the Host.

However, I believe AMD released the Technical Documentation for the Rage Chips, and there are Open Source Linux driver for it, so maybe I can glean the info needed to emulate the Rage Chip, and the Rage Pro 128 has OpenGL drivers in OS X, and there are no drivers for the Voodoo.

Posted: **Mon Feb 06, 2017 2:58 pm**

Hmmmmm.............

That's Panther( 10.3.9 ), I get some weird screen redraws, and the mouse pointer tends to disappear, but then I'm not emulating the Rage 128 chip, itself, I'm still emulating whatever GPU QEMU_VGA uses?

It's progress, none the less.

Posted: **Mon Feb 06, 2017 4:02 pm**

Ok, I need to extract the NDRV from the Rage 128 Pro rom:

http://campahunta.free.fr/Downloads/ROM ... p_full.zip

I know it starts with:

Code: Select all

Joy!peffpwpc.........

But I don't know where it ends?

Alex?

Posted: **Mon Feb 06, 2017 4:36 pm**

There's another emulator that have the Voodoo 2 emulation. It's PCem that implement Voodoo/Voodoo 2 emulation on register level.
And, the Voodoo 2 Macintosh drivers can be found here: http://falconfly.de/voodoo2.htm

Posted: **Mon Feb 06, 2017 5:25 pm**

If you want software compatability, ATi Rage is the way to go, not Voodoo; a lot of 3D-dependent software from the OS 9-10.2 era depended explicitly on the Rage chipset, due to that being inside the iMac.

The best route forward is probably a Rage 128 -> OpenGL 1.2 emulation, if we can figure out how to pass that through to the host graphics subsystem; probably not a good idea to make it platform specific and have to maintain Mac/Win/Lin branches.

Posted: **Mon Feb 06, 2017 6:22 pm**

kikyoulinux wrote:There's another emulator that have the Voodoo 2 emulation. It's PCem that implement Voodoo/Voodoo 2 emulation on register level.
And, the Voodoo 2 Macintosh drivers can be found here: http://falconfly.de/voodoo2.htm

Thanks, tho I may go the Rage/Radeon rout, once I get some preliminary support going, I'll revisit the Voodoo chipsets, as I love Glide.

Posted: **Mon Feb 06, 2017 6:28 pm**

So far, my code changes to Qemu, should build on any platform. I'm going to try to just get SDL to pass the OpenGL calls to the Host, should work on all platforms.

I can't find the Rage Pro 128 documentation, ATI/AMD may have never released it, tho there is an open source Linux driver, so it maybe best to target the Readon 8500, as that is the last GPU that supports OS 9 and X, but I think it will be a lot harder than the Rage 128, so may more registers to write and debug.

Posted: **Mon Feb 06, 2017 9:25 pm**

Hmmmmmmmmm............................................

Posted: **Mon Feb 06, 2017 9:28 pm**

kikyoulinux wrote:There's another emulator that have the Voodoo 2 emulation. It's PCem that implement Voodoo/Voodoo 2 emulation on register level.

So does Bochs, but it's not in the official binaries. The relevant patch is derived from DOSBox; perhaps whatever changes were made there would be useful here?

Posted: **Mon Feb 06, 2017 10:01 pm**

Likely would, I think Qemu uses the VGA code from Bochs.

Posted: **Wed Feb 08, 2017 10:21 am**

At lot of work has been done in qemu to provide opengl to guests:

https://wiki.yoctoproject.org/wiki/Open ... gh_in_QEMU
https://www.kraxel.org/slides/qemu-opengl/
https://virgil3d.github.io/
source code: https://cgit.freedesktop.org/virglrenderer

best,
Cat_7

Posted: **Fri Feb 10, 2017 12:24 pm**

I tried playing around with Bochs, to get an idea how Voodoo2 emulation works, but it's dog slow.

I mean, it was faster on my old Powermac 8600 with a 450 Mhz G3 upgrade card, 45 Mhz bus.

Even running Dos in Bochs is too slow, what a piece of crapware. I don't know what they did to Bochs in the last 15 years since I used it last, but I can't see how useful Voodoo emulation is supposed to be on a system that can only emulate an 8 Mhz cpu.

Posted: **Sat Feb 11, 2017 9:34 pm**

I'm trying to work on the voodoo2, I've got it initializing in Open Firmware, and OS X can see it in the IOReg, but the drivers can't see the device in OS 9.

The System Profiler doesn't show the card in OS 9, or OS X, so I need to figure out why?

Posted: **Sun Feb 12, 2017 9:30 pm**

Which machine are you emulating in qemu?

Posted: **Sun Feb 12, 2017 10:08 pm**

I'm emulating mac99, seems I need to set the subsystem-id, and maybe the sub-device-id, and sub-class id, for OS 9 to load the drivers.

Posted: **Tue Feb 14, 2017 12:48 am**

It seems pcem emulates the Voodoo1 and 2:

https://bitbucket.org/pcem_emulator/pce ... at=default

Best,
Cat_7

Posted: **Thu Feb 16, 2017 2:00 pm**

Hmmmm...............

I can't seem to understand where the NDRV is coming from in Qemu, I'm handing it the proper FCode rom, but somehow it's getting an NDRV, from somewhere other than the Rom file:

Posted: **Thu Feb 16, 2017 6:07 pm**

Where are the VGA additions being injected? This could help answer the NDRV question. Could that area in the OpenBIOS also be where the NDRV data is being populated?

Posted: **Thu Feb 16, 2017 10:10 pm**

adespoton wrote:Where are the VGA additions being injected? This could help answer the NDRV question. Could that area in the OpenBIOS also be where the NDRV data is being populated?

I'm not sure what the question you're asking is.

Here's what I get when I try and load OS 9 with the Voodoo4 NDRV:

Posted: **Fri Feb 17, 2017 1:18 am**

What I'm asking is up a layer from that... I'm wondering at what point the VGA patch injects into the OpenBIOS. I can probably find out by statically walking through the OpenBIOS code when I next get a chance. I just know that the VGA code is loaded as an entire object into memory, and this could be happening with the NDRV entry too, not during the regular load sequence.

Posted: **Fri Feb 17, 2017 2:00 am**

adespoton wrote:What I'm asking is up a layer from that... I'm wondering at what point the VGA patch injects into the OpenBIOS. I can probably find out by statically walking through the OpenBIOS code when I next get a chance. I just know that the VGA code is loaded as an entire object into memory, and this could be happening with the NDRV entry too, not during the regular load sequence.

You lost me, it's a bit over my head.

Seems I can't access the Option Rom I'm injecting for the Voodoo5, PCI Peak gives me the Rom Address, 82010001, so the last bit is set, I do:

>swc 11804 6

Then drop into Macsbugs and try and dump the first 100 bytes of the Rom:

dm 82010000 100

But it returns an error that it can't read from that address?

http://mirror.informatimago.com/next/de ... n2000.html

Seems I'm not getting a proper Assigned-Adresses .property:

Posted: **Fri Feb 17, 2017 3:50 am**

Ok, it seems when I use the -device secondary-vga argument, that I use to init the Voodoo2, I'm able to read the Rom from the Voodoo5.

E-Maculation

Add Voodoo2 emulation for Qemu?

Add Voodoo2 emulation for Qemu?

Re: Add Voodoo2 emulation for Qemu?

Re: Add Voodoo2 emulation for Qemu?

Re: Add Voodoo2 emulation for Qemu?

Re: Add Voodoo2 emulation for Qemu?

Re: Add Voodoo2 emulation for Qemu?

Re: Add Voodoo2 emulation for Qemu?

Re: Add Voodoo2 emulation for Qemu?

Re: Add Voodoo2 emulation for Qemu?

Re: Add Voodoo2 emulation for Qemu?

Re: Add Voodoo2 emulation for Qemu?

Re: Add Voodoo2 emulation for Qemu?

Re: Add Voodoo2 emulation for Qemu?

Re: Add Voodoo2 emulation for Qemu?

Re: Add Voodoo2 emulation for Qemu?

Re: Add Voodoo2 emulation for Qemu?

Re: Add Voodoo2 emulation for Qemu?

Re: Add Voodoo2 emulation for Qemu?

Re: Add Voodoo2 emulation for Qemu?

Re: Add Voodoo2 emulation for Qemu?

Re: Add Voodoo2 emulation for Qemu?

Re: Add Voodoo2 emulation for Qemu?

Re: Add Voodoo2 emulation for Qemu?

Re: Add Voodoo2 emulation for Qemu?

Re: Add Voodoo2 emulation for Qemu?