Prometheus&Firebird with Firestorm firmware support thread

[Hedeon]

The PCIBPMC from Dynamic Engineering works. I noticed that some bridges crash when nothing is behind it

[PainDictator]

Originally Posted by Hedeon

OpenPCI sits on top of prometheus.library (and pci.library etc)

You can do both.

Ok. I am in the funny situation, that I basically have all basic functionality and some acceleration for the Matrox Mystique running, but cannot get a .card driver for P96 to work for whatever reason. Something in my BoardInfo makes P96 crash (at a later point) as soon as the BoadInfo is internally added to the list. No idea why and hard to debug, since the actual crash is outside my code and process.



So now I try the .chip+Prometheus.card variant hoping it avoids whatever is wrong with my card. Still confident, to get most of the Matrox hardwarerunning soon (as time permits).


Thanks for your valuable advice. The S3 driver already helped a lot as an example (though I am doing assembly).

[PainDictator]

Originally Posted by Hedeon

OpenPCI recommended as you automatically support multiple pci solutions

Was also my idea. Thus, I so far have sticked to using OpenPCI and avoiding to rely on prometheus.library. However, I dont see how to do it using OpenPCI. Any idea?

[pipper]

Matrox MGA100 was on my list, too! But I have not started working on it yet.

I don't think its possible to write the driver in OpenPCI only, mainly because it lacks the API to hand out DMA memory to the system. It only has APIs to allocate and free DMA memory from the system.

I have seen graphics drivers that do not separate .card and .chip libraries. I think this is fine (i.e. only provide a .card driver) and it might even be helpful in the beginning as it removes complications from dealing with building libraries.
The separation of .card and .chip was done so various cards with the same VGA chip can share code.

WRT card driver crashing the system: share the source and we can take a look. P96 typically fills in most if not all functions with default implementations.
Its possible that the .chip library does not have a proper structure? Is it being built as library?

[PainDictator]

Originally Posted by pipper

Matrox MGA100 was on my list, too! But I have not started working on it yet.

I don't think its possible to write the driver in OpenPCI only, mainly because it lacks the API to hand out DMA memory to the system. It only has APIs to allocate and free DMA memory from the system.

I have seen graphics drivers that do not separate .card and .chip libraries. I think this is fine (i.e. only provide a .card driver) and it might even be helpful in the beginning as it removes complications from dealing with building libraries.
The separation of .card and .chip was done so various cards with the same VGA chip can share code.

WRT card driver crashing the system: share the source and we can take a look. P96 typically fills in most if not all functions with default implementations.
Its possible that the .chip library does not have a proper structure? Is it being built as library?

G100 should be almost the same as mystique hardware-wise (from what I have seen so far. I expect, that largely the same code (with few additions) can finally serve Millenium, Millenium II, Mystique, Mystique 220, G100, G200, G400, G450, G550. BTW: Did you see a PCI G100? All I found are AGP. Most other boards I have already acquired for testing. Currently, only Mystique and Mystique 200 work (because that is what is implemented).



Regarding OpenPCI, that fits my impression. Maybe it would make sense (later) to modify it to allow providing the memory via the library (rather than through the backend libraries), because that enables "pure" OpenPCI drivers. Currently, I consider using the prometheus.library for providing the memory (if present) and sticking to OpenPCI for the rest, but have not checked this in detail.


Will share the source soon, its supposed to end up on GitLab anyway. Can mail you "as is" if you are interested. Can however mail you the code anytime if you are interested. Currently, it all only works in the "test" program while the actual driver is wired to work, but does not.


I am wondering if it is an issue, that I do not provide anything as the Chip, even internall because I see no need to and the documentation seems to say its not required. The chip libary usually seems to only provide a single function, that is supposed to be called be the individual InitCard. I just do everything in InitCard without chip.

[pipper]

Yes, you should be able to go without the .chip library.

WRT OpenPCI: the idea is nice, but it seems, OpenPCI doesn't support anything other than Prometheus anyways(?)
https://github.com/jeperk/OpenPCI
There's indications that GRex/Mediator support was once there, but I don't see any code in there still supporting them.
IDK the state of affairs there... is this the original OpenPCI library or a reimplementation? Why has the non-Prometheus code been removed?

[Hedeon]

The SDK or whatever it is called for Mediator at least is behind an NDA. Maybe that's it.

Regarding .chip and .card. you can have it in one file. Just need the initcard and initchip to be there.

Also the old boardinfo structure is smaller than the current one (2.1 vs 3.0)

And of course there are function pointers in the boardinfo structure so maybe it crashes there?

What kind of debugging tools are you using?

[PainDictator]

Originally Posted by pipper

Yes, you should be able to go without the .chip library.

WRT OpenPCI: the idea is nice, but it seems, OpenPCI doesn't support anything other than Prometheus anyways(?)
https://github.com/jeperk/OpenPCI
There's indications that GRex/Mediator support was once there, but I don't see any code in there still supporting them.
IDK the state of affairs there... is this the original OpenPCI library or a reimplementation? Why has the non-Prometheus code been removed?

I suspect there are non-public versions of the openpci.library that do work with GRex and Mediator. But yes, it seems the open source version does not include anyhting but Prometheus.

[PainDictator]

Originally Posted by Hedeon

The SDK or whatever it is called for Mediator at least is behind an NDA. Maybe that's it.

Regarding .chip and .card. you can have it in one file. Just need the initcard and initchip to be there.

Also the old boardinfo structure is smaller than the current one (2.1 vs 3.0)

And of course there are function pointers in the boardinfo structure so maybe it crashes there?

What kind of debugging tools are you using?

I have no InitChip as there is no .chip library in my implementation. The documentation says, that the library is supposed to be loaded by InitBoard and that InitBoard() also is the caller of InitChip. So it seemed ok not to have it all, but I really wonder if not having the ChipBase set in the end runs into something for P96.



Other than that, I have all unimplemented functions pointing to dummy so I see what is called. Debugging takes place in MonAm (the debuger included with HiSofts DevPac Assembler). What I see is that right after the instruction that inserts the the BoardInfo into P96s's internal list, dragging a screen makes the computer reset. One instruction before everything is fine. So it seems ther is something in my BoardInfo that makes P96 choke when it comes across it but I cannot see what. Already spent days looking for that ...

[grelbfarlk]

Cool Matrox Mystique!
I had one of those back in the day, since the 3D part is pretty much useless at least people won't be pining for Warp3D drivers.

The Firestorm really runs quite well, I thought the 1/4 decrease compared to the Mediator would be a lot more noticeable with a PPC card, but it's really not that much worse.
A4000 with a CSMK2 060@50MHz, A4091, Voodoo 3-3000, Ragnarok 800MHz:
Quake demo1 640x480 16bpp 640x480 = 49FPS
Quake 2 demo1 640x480 16bpp 640x480 = 60FPS
ScummVM 2.2 ELF monster version runs great, COMI intro is very smooth
MESS 320x200 8bpp Frameskip 2 runs perfectly
Wipeout 640x480 16bpp very smooth
SBLive 7.1 and AHI 6.7 works fine with:
Amplifier and mpega.library PPC Libmad version to play MP3s
QuakeGL, even in 16 bit 44100
HexenGL 2 as usual it works fine at 16bit 44100 PCI sound perfectly, for some reason

[Hedeon]

Originally Posted by PainDictator

I have no InitChip as there is no .chip library in my implementation. The documentation says, that the library is supposed to be loaded by InitBoard and that InitBoard() also is the caller of InitChip. So it seemed ok not to have it all, but I really wonder if not having the ChipBase set in the end runs into something for P96.

Had a quick look and indeed the InitChip() seems to not be needed. The library needs FindCard() and InitCard().

I can't seem to find that ChipBase is needed.

Maybe install the COP debugger

[PainDictator]

Originally Posted by Hedeon

Had a quick look and indeed the InitChip() seems to not be needed. The library needs FindCard() and InitCard().

I can't seem to find that ChipBase is needed.

Maybe install the COP debugger

Any particular Idea what I should look for at COP? Does this do anything specific (like catching that reset in a way)?

[Hedeon]

Originally Posted by PainDictator

Any particular Idea what I should look for at COP? Does this do anything specific (like catching that reset in a way)?

It catches almost all crashes. You can trace trough interrupts, that kind of stuff.

[PainDictator]

Originally Posted by Hedeon

It catches almost all crashes. You can trace trough interrupts, that kind of stuff.

Helped indeed. Turned out, my idea to use ALERT for debug Output in SetDisplay kills the system as the function is called during screen changes where apparently the system is not ready to display an alert ...


So far, things start to work. Think I will put something up shortly.

[Hedeon]

Originally Posted by grelbfarlk

ScummVM 2.2 ELF monster version

Steve is back in the house BTW. Compiling ELF binaries.

Regarding speed, mediator is faster if you use the 17.13b version as it is in asm. But was getting a nightmare to maintain.

[Hedeon]

Originally Posted by PainDictator

Helped indeed. Turned out, my idea to use ALERT for debug Output in SetDisplay kills the system as the function is called during screen changes where apparently the system is not ready to display an alert ...


So far, things start to work. Think I will put something up shortly.

Output to serial I mostly use. And regarding the last sentence: pics plx

[PainDictator]

Originally Posted by Hedeon

Output to serial I mostly use. And regarding the last sentence: pics plx

You can find First Screenshots here

https://www.a1k.org/forum/index.php?threads/91414/

[pipper]

Very cool! Can you post some P96Speed results as well?

Gute Arbeit!

[grelbfarlk]

Wunderbar Kekstraube!

[Hedeon]

Originally Posted by PainDictator

You can find First Screenshots here

https://www.a1k.org/forum/index.php?threads/91414/

So how did you do it? Linux drivers? Documentation?