Atarian Computing's Raven Build

[Atarian Computing]

@agranlund @PhilC

So I got my GD5434 today and got it installed. I need some help with setting it up. It's a 2MB Orchid card:

20251206_181834687.JPG (288.05 KiB) Viewed 269 times

256 colors give a weird pattern instead of solid colors:

20251206_181818365.JPG (344.02 KiB) Viewed 269 times

16 colors gives a good image:

20251206_182011014.JPG (387.02 KiB) Viewed 269 times

16bit is just black with colored background

I assume that I need to create my own driver folder in the NOVA folder? I tried that but I have no idea how to use the VMG.PRG because anything I do in it results in a blank screen and cannot recover from it.

Would you two have some advice and possibly some drivers and BIOS files I could try? Thanks.

[agranlund]

That looks hardware-blit related, as in an issue with the the fill-pattern data which is uploaded to the cards vram and used during hardware blit.
In this case the pattern is supposed to be a solid pattern to achieve a solid blitter-fill.
(the driver doesn't do hardware blits in 16 color mode so that further cements the idea that it's related to the blitting code)

Are all fill-styles broken?


No need to mess with the vmg tool for these drivers. The bibs are only there beacuse that's the only way Nova-aware programs can enumerate display modes.. They never exposed that functionality in the public Nova API so all individual programs opens and parses these files themselves, to get the information they need to pass onto the Nova API when they want to change display mode :/

In the case of the Cirrus, WDC and StandardVGA driver; the bibs are more or less dummies for that purpose, with a bit of name and resolution infos.
Timing or hardware specific register values are completely ignored since the driver doesn't need them -- the bios on the card knows how the card works and has the correct settings.

(For the old and official ET4000 and Mach drivers, those bibs are very hardware+driver specific and you may need to mess with them using the version of VMG.PRG which was specifically built for the driver you are using)

[Atarian Computing]

That looks hardware-blit related, as in an issue with the the fill-pattern data which is uploaded to the cards vram and used during hardware blit.
In this case the pattern is supposed to be a solid pattern to achieve a solid blitter-fill.
(the driver doesn't do hardware blits in 16 color mode so that further cements the idea that it's related to the blitting code)

Would this be a hardware or software problem if true?

Are all fill-styles broken?

I looked in Jinnee desktop patterns and colors and all seemed normal there:

20251207_090626470.JPG (395.52 KiB) Viewed 226 times

20251207_090618540.JPG (391.57 KiB) Viewed 226 times

Also desktop colors are solid and the colour CPX shows the colors normally but the scroll bar elements have issues.

20251207_090901775.JPG (265.37 KiB) Viewed 226 times

But at the same time the Nova ACC has issues displaying the colors...

20251207_090639552.JPG (404.41 KiB) Viewed 226 times

No need to mess with the vmg tool for these drivers. The bibs are only there beacuse that's the only way Nova-aware programs can enumerate display modes.. They never exposed that functionality in the public Nova API so all individual programs opens and parses these files themselves, to get the information they need to pass onto the Nova API when they want to change display mode :/

In the case of the Cirrus, WDC and StandardVGA driver; the bibs are more or less dummies for that purpose, with a bit of name and resolution infos.
Timing or hardware specific register values are completely ignored since the driver doesn't need them -- the bios on the card knows how the card works and has the correct settings.

(For the old and official ET4000 and Mach drivers, those bibs are very hardware+driver specific and you may need to mess with them using the version of VMG.PRG which was specifically built for the driver you are using)

Maybe I'm dumb but how on earth do I create a 1280x720 resolution for the card? If the BIBs have the resolution infos, I tried creating a 1280x720 but it doesn't appear anywhere to select.

[agranlund]

Would this be a hardware or software problem if true?

My gut reaction says software related.
Perhaps the next step would be to build you a version of the driver that has hardware-blit disabled, to narrow down and make certain it's related to that. Or perhaps just with blitter-fill disabled and leaving blitter-copy enabled.

Maybe I'm dumb but how on earth do I create a 1280x720 resolution for the card? If the BIBs have the resolution infos, I tried creating a 1280x720 but it doesn't appear anywhere to select.

You basically don't, at least not at the moment.
The driver can only set (S)VGA modecodes that the cards vgabios has support for.
(it doesn't actually set it itself so I can't take much credit, it just asks the bios on your gfxcard to do it)

And since all these cards are old none of them have modecodes for 16:9 resolutions.

I would like 1280x720 on these as well so it's on my wishlist to implement support for custom resolutions.
But it's a whole different ballgame compared to the almost one-liner of just asking the card to set one of its "built-in" resolutions.


The bib's only reason for existing, in this context, is to provide a list of names, sizes and such for whatever program wants to "know" what resolutions are available. So I populated a few "dummy" entries with the usual resolutions.

Now, that doesn't mean they necessarily exist -- it's an unfortunate side effect of the original Nova API lacking a "Give me all supported resolutions" functionality.
Thus, every program needs to open the bib, parse it, and then pass the bib-resolution info to the driver.

The driver will then disregard most of that info except for width, height, and bpp. Cross reference against what the particular card actually supports and finds the modecode for the closests match. Then asks vgabios to apply that modecode.

[Atarian Computing]

Would this be a hardware or software problem if true?

My gut reaction says software related.
Perhaps the next step would be to build you a version of the driver that has hardware-blit disabled, to narrow down and make certain it's related to that. Or perhaps just with blitter-fill disabled and leaving blitter-copy enabled.

Maybe I'm dumb but how on earth do I create a 1280x720 resolution for the card? If the BIBs have the resolution infos, I tried creating a 1280x720 but it doesn't appear anywhere to select.

You basically don't, at least not at the moment.
The driver can only set (S)VGA modecodes that the cards vgabios has support for.
(it doesn't actually set it itself so I can't take much credit, it just asks the bios on your gfxcard to do it)

And since all these cards are old none of them have modecodes for 16:9 resolutions.

I would like 1280x720 on these as well so it's on my wishlist to implement support for custom resolutions.
But it's a whole different ballgame compared to the almost one-liner of just asking the card to set one of its "built-in" resolutions.


The bib's only reason for existing, in this context, is to provide a list of names, sizes and such for whatever program wants to "know" what resolutions are available. So I populated a few "dummy" entries with the usual resolutions.

Now, that doesn't mean they necessarily exist -- it's an unfortunate side effect of the original Nova API lacking a "Give me all supported resolutions" functionality.
Thus, every program needs to open the bib, parse it, and then pass the bib-resolution info to the driver.

The driver will then disregard most of that info except for width, height, and bpp. Cross reference against what the particular card actually supports and finds the modecode for the closests match. Then asks vgabios to apply that modecode.

Ah, I see now. Ok, I'd like to experiment with the blitter-fill disabled and see where that goes.

Would the BIOS have any effect on issues like these?

[PhilC]

I keep meaning to make a program to list all the VGA Bios settings. So I could tell what the difference was between driver settings.

For instance, certain bosses don't work with the pine graphics card. For instance, using the Diamond card bios gives screen corruption but using others makes the card run really slow.

[agranlund]

@Atarian Computing , check if this makes your card behave.
Should have hardware blitting disabled for Cirrus cards so it's only really meant as a way to verify if your issue is related to that or not.

emulator.prg.zip

(9.51 KiB) Downloaded 4 times

( replaces emulator.prg in the folder c:\nova\default\auto\ )

[Atarian Computing]

@Atarian Computing , check if this makes your card behave.
Should have hardware blitting disabled for Cirrus cards so it's only really meant as a way to verify if your issue is related to that or not.

emulator.prg.zip

( replaces emulator.prg in the folder c:\nova\default\auto\ )

Thanks, but that doesn't work at all. I get a version error:

20251209_085942321.JPG (141.62 KiB) Viewed 135 times

20251209_085948432.JPG (278.43 KiB) Viewed 135 times

[agranlund]

Thanks, but that doesn't work at all. I get a version error:

Just to double check, emulator.prg was placed in c:\nova\default\auto and not c:\auto like so:

autofolders.png (354 KiB) Viewed 121 times

This one should be no different, but I zipped up the entire "c:\nova\default" maintaining folder structure:

C_nova.zip

(96.9 KiB) Downloaded 9 times

(this time I actually tested on my computer. Swapped in the GD5434 card and ran with the blitter-disabled version of emulator.prg and could notice everything being very slow )

[Atarian Computing]

Thanks, but that doesn't work at all. I get a version error:

Just to double check, emulator.prg was placed in c:\nova\default\auto and not c:\auto like so:


This one should be no different, but I zipped up the entire "c:\nova\default" maintaining folder structure:
C_nova.zip


(this time I actually tested on my computer. Swapped in the GD5434 card and ran with the blitter-disabled version of emulator.prg and could notice everything being very slow )

Hi, yes, I'm 100% sure I had the correct AUTO folder. But your DEFAULT folder indeed fixed the anomalies.

However, that version error I got bugged me so I thought I'd try the OG EMULATOR.PRG with the DEFAULT you provided. Sure enough. There's a major difference as you can see:

20251209_120821423_preview.jpeg (387.22 KiB) Viewed 109 times

20251209_120854851_preview.jpeg (387.7 KiB) Viewed 109 times

Previously the background was normal, now it's not. However the color boxes in NOVA acc are normal now.

Jinnee now looks almost normal apart from the scroll bar

20251209_120955699_preview.jpeg (351.5 KiB) Viewed 109 times

This is 16bit mode. It's the same with both EMULATOR.PRG

20251209_121050078_preview.jpeg (407.65 KiB) Viewed 109 times

The black bar under the menu is some screen corruption that appears all the time in Jinnee, even with blitter disabled.