exxos's Atari, Amiga & retro forum

Not got round to testing the 5429 but will.

However, I must be doing something wrong, I've edited RVGA.INF and uncommented the mclk option and set it to $2f which is the fastest that the Diamond 5434 will do, which is pretty blooming fast btw but it doesn't set this speed. I still need to poke the two locations in the auto exec for any speed change to take effect.

Also, I changed the nova driver to SVGA and I do get a great 1280x720 screen but then Doom or Quake graphics are corrupted(like screen width is way out) but using the Default Nova driver its still works fine but I don't have the 1280x720 option.

PhilC wrote: 08 Mar 2026 16:22 $2f which is the fastest that the Diamond 5434 will do

I take it you have quite fast ram on your board :)
Mine starts to freak out above $2c

I still need to poke the two locations in the auto exec for any speed change to take effect.

Did you update c:\auto\rvnova.prg ?

Perhaps get rid of the following files too.
They get regenerated as needed so I don't think it'll make a difference but who knows.
(and after reboot, go into bios->nova reselect your resolution and exit)
c:\auto\xmenu.inf
c:\auto\sta_vdi.bib
c:\auto\emulator.bib

Could also try getting rid of c:\nova and copy it anew in case the old default folder is somehow messing something up.
It shouldn't, but a pesky bug wouldn't care what should or shouldn't happen :)

Since the speed of the card isn't being changed I'm mostly suspecting c:\auto\rvnova.prg
That's the guy reading rvga.inf from disk (and then passes settings onto drivers)

I'm attaching the one I've been using.
In case the example one in the zip is wrong somewhere, or if maybe there are issues with Atari vs Unix vs Windows newlines, or anything else of that sort. Newline format _should_ not matter, but I've only tested with an rvga.inf edited in Qed v3.97 using Unix newlines.

Also, I changed the nova driver to SVGA and I do get a great 1280x720 screen but then Doom or Quake graphics are corrupted(like screen width is way out) but using the Default Nova driver its still works fine but I don't have the 1280x720 option.

Hmmn, I've been using Castaway for testing desktop<->game resolution switch. Will have to try Doom also.
Update: Doom behaves the same here on my GD5434. That's great that I can reproduce the issue here, thanks for reporting this!

https://github.com/agranlund/raven/rele ... .A1.latest
* Doom and other things built with SDL should now work when using the SVGA driver.
My bib generator was writing terrible values for screen pitch. Thanks for making me aware @PhilC :)
If you're cherry picking this particular fix then you'll want to copy
software/nova/svga/auto/sta_vdi.bib -> c:\nova\svga\auto\sta_vdi.bib
But easier to just replace the entire c:\nova\svga folder and c:\auto\rvnova.prg

* UIP is a little bit faster now.

* Castaway can now use real floppy drive if you have one. This is very slow, and copy-protected games don't work.
Borderline useless feature but I had a really good time running some of my own very old programs off a real floppy so it was totally worth it!
To use: run Castaway without drag-and-dropping a disk-image onto it.
If you have a floppy drive and a disk inserted then it will use it.

Cool thanks @agranlund I'll have a go in the morning. Might find my floppy controller too :D

PhilC wrote: 08 Mar 2026 19:17 Cool thanks @agranlund I'll have a go in the morning. Might find my floppy controller too :D

While slow, I think the floppy does bring a weird sensation of Atari authenticity to Raven.
I found "Fleet Street Publisher" in my box of old floppies and remember using that program for school homework.
Even though it loads near enough instant from hard disk there is something special about being able to load it directly from my old floppy disk :)

agranlund wrote: 09 Mar 2026 10:35

PhilC wrote: 08 Mar 2026 19:17 Cool thanks @agranlund I'll have a go in the morning. Might find my floppy controller too :D

While slow, I think the floppy does bring a weird sensation of Atari authenticity to Raven.
I found "Fleet Street Publisher" in my box of old floppies and remember using that program for school homework.
Even though it loads near enough instant from hard disk there is something special about being able to load it directly from my old floppy disk :)

All fixed with that last update, thank you. I've got to think how I'm going to mount a floppy in this case as there are no external drive bays.

Another observation. I've got some graphics glitches/oddities.
This happens whether the mclk is left as bios standard or when set at an over locked value.

See the small box under Disk C and the menu options.

Btw, I did a full wipe of the C files and copied over everything anew, which made the graphics oddities appear.

I have several problems with the latest release. I remember I'm using ET4000. The biggest one is that the screensaver starts and the screen becomes black and unusable while the computer is "alive". Castway also no longer works well and has a dirty screen.

luciodra wrote: 09 Mar 2026 16:37 I have several problems with the latest release. I remember I'm using ET4000. The biggest one is that the screensaver starts and the screen becomes black and unusable while the computer is "alive".

If the screensaver kicks in then I would double check that you have these files installed:
c:\nova_col.acc
c:\nova_col.inf
c:\auto\sta_vdi.inf

(the inf files from the release package should already be configured to kill the two different ways Nova screensaver can trigger. One is time-based and the other can start the screensaver by mouse-coordinate -- both are broken in that they seem to trigger almost "randomly" and can never resume. I do not know why and Nova screensaver behaves equally broken on my (accelerated) Atari ST with ET4000)

Castway also no longer works well and has a dirty screen.

I take it you are using the Nova ET4000.Tx driver? Out of curiosity, do you experience the same issue when using the SVGA driver?

PhilC wrote: 09 Mar 2026 13:45 Another observation. I've got some graphics glitches/oddities.

Thanks! But annyoing that I am not seeing any of these issues on my GD5434.


And if you would have moved the mouse cursor over "Read .INF file..." and then away from it you would have been left with the purple bars there too?
And if that guess was true, how would it look with the mouse cursor steady over one of the menu options before leaving it. Correctly inverted colors or also wrong? :)
(I am only guessing that where you have the purple bars you have already hovered the mouse over these entries? And the ones that are fine are fine because you have yet to mouse over them)

The small box under Disk C appears to be some other issue, or perhaps a different symptom of the same root cause.
Gut reaction, maybe a fillpattern blit where the pattern offset ended up wrong by a pixel, that could make the checkerboard not align in screenspace.
But the location of them are weird, unless one of the windows was there originally and then moved away -- leaving those lines?
(if so, then that reinforces the theory of misaligned source position for the fillpattern)