Raven. A homemade Atari-like computer

[Atarian Computing]

Ok, trying the version 3.01 drivers resulted in a marginally better result, but only in successfully getting display output at the desktop. It was still trial and error, and it would fail/hang more than not. The display output was inferior to that of the release package drivers. The gamma was much darker, and the colours were not accurate. There was also significant ghosting of the icons and mouse cursor across the screen, like a band.

When I got the release drivers to boot that one time, the screen and colours were immaculate. And hooooooly moly is the Mach64 fast. So much faster than the GD5434 that I suspect that I need to try different BIOSes for the Cirrus. I'll post some Kronos screenshots a little later.

[Oldskool]

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..

[Atarian Computing]

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:

mach64_gembench.JPG (328.49 KiB) Viewed 670 times

gd5434_gembench.JPG (337.94 KiB) Viewed 670 times

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.

kronos_1.JPG (285.01 KiB) Viewed 670 times

kronos_2.JPG (291.42 KiB) Viewed 670 times

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.

[Atarian Computing]

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:

20260104_104221388.JPG (201.52 KiB) Viewed 623 times

And here is MAGXBOOT.PRG with TT-RAM flags off:

20260104_103501383.JPG (394.01 KiB) Viewed 623 times

Geneva/Neodesk almost loads with CB, but I suspect it hangs on Neodesk.

[Atarian Computing]

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.

[agranlund]

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

[agranlund]

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.

[Atarian Computing]

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:

vga-s00700-05_mach64_vga_register_guide.pdf

(13.31 MiB) Downloaded 75 times

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...

[agranlund]

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)

isa_bios_inf.zip

(2.22 KiB) Downloaded 48 times

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:

Code: Select all

dev.GRV0001.GRV0000.conf	= 2
card.KTC2000.name		= "Kingston KNE20"
dev.KTC2000.RTL8019.io		= 300
dev.KTC2000.RTL8019.irq		= 3

(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:

Code: Select all

--------------------------------------------------------------------------
Configured
--------------------------------------------------------------------------
0 - ID:  GRV0000 
    IO:  0240 0340 034c 
    IRQ: 11 
    DMA: 5 7 

1 - ID:  RTL8019 PNP80d6 
    IO:  0300 
    IRQ: 3 

2 - ID:  ESS0006 
    IO:  0800 

3 - ID:  ESS1869 
    IO:  0220 0388 0330 
    IRQ: 5 
    DMA: 1 

4 - ID:  ESS0001 PNPb02f 
    IO:  0201 

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:

Code: Select all

dev.PNP80D6.io = 300
dev.PNP80D6.irq = 3

(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.

[Oldskool]

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