exxos's Atari, Amiga & retro forum

So it seems.I have some problem again setting up isa_bios. Anders could you share yours I think I have the same cards in. Rtl based network, gus, ess.

Could it be that the midi driver (opl does work mpu401 is one note and crash) of scummvm st is broken now seems to crash the system. Doom works..

Did some more testing with the Mach64, but didn't get far. I couldn't for the life of me get it to work without NVDI, so the benchmarks I've taken are with NVDI enabled. As the screenshots show, it's ridiculously faster than GD5434 at some bits:
The VDI tests absolutely went crazy fast in GEMBench.

Here's Kronos with the "Your Computer" being the ET4KAX. All three cards 100% same environment. We see some details where the Mach64 dominates. All tests were done with write-through cache, as I can't get copyback to work.
What I don't get is why the Hades is faster in FPU.

Anyway, I'm starting to be relieved that I didn't sell the Mach64.

Did some more testing with copyback cache.

MiNT works fine with CB on

MagiC will not work. I tried both loaders.

Here is MAGXBOOT.PRG with TT-RAM flags on:
And here is MAGXBOOT.PRG with TT-RAM flags off: Geneva/Neodesk almost loads with CB, but I suspect it hangs on Neodesk.

Some more testing of CB with EmuTOS. With a minimal setup I can actually get to the desktop but there is no rhyme or reason as to what ACC or PRG will trigger the flood of .f.f.v on the screen. When I loaded NVDI the whole terminal was filled with f.f.f.f. after I saw a flash of the text PANIC or something. Weird. I do have the latest ROM_TOS as well.

Atarian Computing wrote: 04 Jan 2026 10:07 Some more testing of CB with EmuTOS. With a minimal setup I can actually get to the desktop but there is no rhyme or reason as to what ACC or PRG will trigger the flood of .f.f.v on the screen. When I loaded NVDI the whole terminal was filled with f.f.f.f. after I saw a flash of the text PANIC or something. Weird. I do have the latest ROM_TOS as well.

Yeah I would try to isolate each individual program if possible.
And then try to flag offending programs to only use ST-RAM.

Same for ACC and CPX but I'm not sure if you can actually flag these or if you just have to avoid ones that can't deal with copyback or are generally incompatible with 68040/60.
And if in doubt, I'll also google for the program and copyback to see if there's any old CT60 wisdom to learn from :)

XControl doesn't work with copyback cache.
There is a CT60 patch for it, but even with that it still does not work on Raven with copyback cache.
(The patch makes Xcontrol depend on CT60-Bios. Raven does have a partially implemented CT60-bios but something is still amiss and I haven't had a chance to look at it -- for now, you would have to use a different copyback compatible control panel, or use write-through caching if you need Xcontrol)

Gembench also doesn't like copyback, but flagging it to only use ST-RAM will make it happy.

I've mostly done very minimal tests with copyback enabled so it's quite nice you're doing the dirty work here :)

Atarian Computing wrote: 03 Jan 2026 14:34 As the screenshots show, it's ridiculously faster than GD5434 at some bits:

Yep, the Mach32/64 drivers use hardware acceleration for a lot more VDI functions.

Mine will only accelerate blits and filled rectangles. And to be fair, this is by far the most bang for the buck.

But most or even all of these cards usually added similar kinds of hardware acceleration features to keep themselves in business when Windows 3.x came along, so with additional driver work it could accelerate more VDI stuff.

Perhaps the next one on the bang-for-buck list would be hardware text rendering.
And then possibly straight lines.

Other VDI primitives feels like quite a bit of diminishing return outside of benchmarks for the amount of work required.

agranlund wrote: 04 Jan 2026 13:13 Yep, the Mach32/64 drivers use hardware acceleration for a lot more VDI functions.

Interesting. Not sure if you already are familiar with this document: Maybe it'll shed some light? The variant I have is the GX, which is what I suspect all ISA models are. I might just ingest this document with AI to OCR it for RAG and see if I can use AI to answer some questions...

Oldskool wrote: 03 Jan 2026 13:11 So it seems.I have some problem again setting up isa_bios. Anders could you share yours I think I have the same cards in. Rtl based network, gus, ess.

Could it be that the midi driver (opl does work mpu401 is one note and crash) of scummvm st is broken now seems to crash the system. Doom works..

Yep, here is mine attached (as well as isa_bios.log so you can see my entire device tree) But did I understand correctly that you now have wavetable sound working? And that it works in Doom but crashes with ScummST?
And that this is with rvsound drivers?


For my isa_bios.inf I didn't need to configure much so it's quite minimal.. this is it: (KTC2000 card name change is cosmetic only, for a nicer printout when my machine starts. Its actual name was long and ugly)


This is with the MK1869-Extreme card that combines a GUS with ES1869 on the same card.
I had different settings when I used a separate GUS + Soundblaster compatible -- then the GUS card had more devices that I either had to disable or move.

Here, only the main synth exists and I spotted that it's pnp config 2 defaulted to pretty much exactly what I wanted for moving it away from the usual SB ports that I wanted the ES1869 to have. So I basically just made it use that with no further customisations.
And the ES1869 default was just as I wanted it in the first place.

This is how my devices end up configured:

For the network card, you'll want to change the card and device id's to whatever your log says you have.


I'm in the middle of a bit of an ISA_BIOS refactor and it's going to be possible to omit the card id in the future if you don't care.
Ie; to configure a generic NE2000 we can just have this and it should work on all of them: (assuming the card has tagged itself compatible with PNP80D6, which is the generic ID for NE2000 compatible device as decided my Microsoft many moons ago)

The main reason for the refactoring work is so that I can eventually integrate it into rvbios and have a setup page where you can view and configure ISA devices with a GUI.

agranlund wrote: 04 Jan 2026 13:45 But did I understand correctly that you now have wavetable sound working? And that it works in Doom but crashes with ScummST?
And that this is with rvsound drivers?

Indeed. Rvsound. So there are 3 midi drivers. Did not try the Raven one.
Wavetable installed on the Ess card.

Doom: opl and mpu401 are OK
Scummst: opl ok mpu401 nok (crash total system after 1 note) in DOTT

Ok, I've been at it with AI. Let's see if it's any good.

It thinks that the problem might be that the current code maps the framebuffer to ISA address 0x00400000 (4MB). However, ISA graphics cards typically decode their apertures much higher in memory space—commonly at '0x00C00000' (12MB) or '0x00E00000' (14MB). The ATI Mach64 BIOS documentation confirms the aperture location is software-configured during card initialization and stored in EEPROM, not hardwired.

Why It "Sometimes Works":

With the aperture mapped to the wrong ISA address:

- Most framebuffer writes hit unmapped space → no effect
- Occasional address decode quirks or ISA bus wraparound → pixels appear (low success rate)
- Inconsistent initialization → explains the unreliability and crashes

If the mapping was completely wrong, it would **never** display anything—the fact that it occasionally shows a desktop proves the TT driver itself is correct, just accessing the wrong physical location.

It's suggesting the following fixes:

The Corrected Mappings

Version 1: Try ISA aperture at 12MB:
Version 2: Try ISA aperture at 14MB:
@agranlund, is this nonsense? I'll have to try to set myself up to compile this myself at some point, but if its not nonsense, could I trouble you to spin a couple of versions of rvnova.prg?