Hamby wrote on 2021-09-04, 19:22:
How difficult is it to "talk" to ISA or PCI? Or I guess more accurately, how does one go about talking to an ISA or PCI bus?
In DOS, not difficult, ISA has direct access, PCI there is a layer between iirc, but DOS applications are pretty close to the metal. In windows ths is no longer the situation as the OS abstracts this away from any application and requires a 'driver' to communicate.
Having a PI on a peripheral card like this could make it one bad-ass co-porocessor for an old system, however the problem would be the same problem as back then, bandwidth of the BUS. This would severely limit the usefulness of certain applications.
Hamby wrote on 2021-09-04, 19:22:
Hmm... putting a pi on a 16-bit ISA card, giving it a glide wrapper for its gpu... modern 3D acceleration for old computers. Hey, people are using PIs for display adaptors for Amigas and Macs and other old computers already...
Unfortunately it doesn't work like this. On the Amiga, the PI communicates via the GPIO (I say communicate, it's just the Amiga sending the same information as it always did, so one-way communication), then the PI converts the RGB singal to HDMI (software running on the pi) which is then displayed using the PI's HDMI. So it literally acts like a converter/up-scaler and provides a 'modern' display interface. The Amiga is none the wiser.
Providing 3D acceleration is a whole other ball game. In order for applications to use 3D, they need to use an API which is provided (or at least the implementation is provided) by the device driver which is software, running on the host machine which deals with the device communication. This is what the 3dfx driver does, and is what doesn't need to be done when programming directly to VGA. You might have access to the LFB (Linear frame buffer), however this simply means the ISA PI is nothing more than a dumb framebuffer (display adaptor).
In the case of glide, the host CPU performs the triangle setup and transform (so the PI won't help). Voodoo in this regard is literally just a rasterizer with memory to store the framebuffer and textures and active vertex lists to mitigate having to transfer this data to the card each frame. Of course you don't want to transfer each texture over the BUS each frame (although this still needed to happen when texture requirement outpaced VRAM size... this is known as texture thrashing) as it was bottle-necked by the bandwidth of the BUS and manifested as stuttering/reduced framerates).
So not only would you need to write drivers for the 'new' ISA 3D accelerator, all current software using glide would also need to be rewritten to use it, so you are effectively creating an entirely new graphics subsystem for 3D, using an old API, which no software written for that API would ever work with 🙁.
It's not all doom and gloom though since there were '3D accelerators' using ISA... TM34XXX cards (TIGA), IrisVision etc... so a possible application could be to have a PI emulate these cards, but it wouldn't be able to introduce much more speed-up and any increase in VRAM probably wouldn't be usable as 3D applications written back then were written with the hardware in mind. Although card capability increases, the software then becomes the bottleneck since it probably wasn't written in a way that could capitalise on any performance increase by the ISA device.
Could be a fun little project, but a lot of effort, and given the limited number of applications using IrisGL and TIGA, it would be very very niche, even within the realms of the already niche 'retro' scene.
