exxos's Atari, Amiga & retro forum

agranlund wrote: 10 Dec 2025 09:13

luciodra wrote: 10 Dec 2025 08:35 - At the moment, I removed OPLMIDI from AUTO, but I no longer get audio from Picogus;

Did you do these steps?
- put rvsnd.prg in c:\auto
- put rvsnd.inf in c:\
- you'll then want to edit rvsnd.inf, and under the [midi] section, replace

Code: Select all

out = Raven

with

Code: Select all

out = opl

- if you need to run pgusinit every time for it to 'start' then it should run before rvsnd.prg
(sorry, not sure off the top of my head if it's a one-time configuration tool or if it needs to run at every boot. I suspect it is the former)

- and you'll want isabios to run before those above programs which is using the isa bus.

If you enter the EmuTOS commandline, then go to c:\rvsnd and run 'rvsctrl devs', do you see opl under the list of chips as well as midi?

- To get peak performance, do I always need to have CACHEON in AUTO, or can I launch it after boot?

You can get rid of it completely.
If you have the 'cache' option turned on in the EmuTOS menu then EmuTOS will enable caches for you automatically.
The on/off programs are mostly there in case you need manual control for some particular reason.

I confirm everything you said and everything works perfectly.

bbisi wrote: 27 Dec 2025 16:14 Here is my Autostart Order
....
Can anyone give me the best order

Hi!

I usually do something like this:
I don't have it installed at the moment so can't remember if I used to have MiNT last, or earlier up and before rvnova.

But in any case, you don't want to have emulator.prg nor sta_vdi.prg in the auto folder.
rvnova.prg launches the correct ones based on the driver you have selected.

If you don't have an explicit use-case for setenv or autoexec then you can remove or disable them.
I use setenv here to adjust the path environment variable for the EmuTOS console.
I used to have autoexec run some stuff before but now mine is empty so I've disabled it.

For fun I tried if standalone Atari AES + Desktop works over EmuTOS on Raven and from the small tests I did it looks like it does.
Not really sure this is actually useful in any way but it was cool to test :)

Here is AES 3.40 from Falcon TOS.
From some leaked atari sources archive. It already contained a pre-built standalone AES binary so I didn't even need to compile it myself :)
Here is AES 4.10 from MultiTOS beta 1.08
Reporting TOS 2.06 because that's what EmuTOS for Raven is identifying as.
To be clear, this is still EmuTOS providing the core Bios + Gemdos.
Only the AES + Desktop is replaced with the Atari ones (by launching them from the AUTO folder).

I removed BS and Eiffel from the Raven and now the Yamaha audio works, so no damage, but BS and Eiffel need to be reviewed. But I'm happy anyway.
The problem of the 16-bit ISA slots remains but that too probably depends on some soldering gone wrong...

luciodra
what is BS

My Problem is the coremark is with new Rom and software not running
I think the Problem is with Driver RVNOVA and RVBIOS
Without any driver coremark is running

BS = Byteswap adapter

I'm making some attempts and either the Byteswap or Eiffel adapter contain assembly errors that undermine the stability of the system.

bbisi wrote: 29 Dec 2025 19:09 luciodra
what is BS

My Problem is the coremark is with new Rom and software not running
I think the Problem is with Driver RVNOVA and RVBIOS
Without any driver coremark is running

Coremark works well for me, with all the latest software stuff.

Was only doing minor and mostly cosmetic stuff so wasn't meaning to zip up a release just yet.

But then I suddenly fell into a rabbit hole of 060 unaware stuff so here is one anyway :lol:
https://github.com/agranlund/raven/rele ... .A1.latest
The biggest thing here is the patched NOVA drivers and XBOOT. Do update these.

They were all messing with the CACR register, but as they don't know what a 68060 is they did so in a 68030 fashion.
Not great for performance, but also quite dangerous and especially so if you use copyback.
Now, these will no longer put the cache in a weird half disabled state during AUTO folder processing.

I saw there already exists an XBOOT patched for 060 because of CT60 but it was a German version so instead I applied the same kind of fix to the English version I'm using in the distribution. If you want a German XBOOT I recommend looking for the CT60 patched one.

(If you find yourself needing to disable caches at some point during AUTO folder boot then you can always use the cache on/off programs.
Don't know why you would but perhaps if you run some very very old auto program which freaks out by caches)



Side effect of these cache bandits being fixed is that if you were running AES41 over EmuTOS then you'll now end up with caches properly enabled when you get to the desktop.

Or even if you run EmuTOS normally but have not yet done your first 'Save Desktop'.
That's how I noticed something was sketchy in the first place and ended up in the rabbit hole...
Menu item was saying caches on, but speed wasn't there. Inspecting the CACR register I saw something in the AUTO folder must have set it the way you do it on a 68030 -- not good.
(EmuTOS starts with caches on. Runs all AUTO programs. Then runs EmuDesk. EmuDesk reads emudesk.inf and sets cache again according to your saved setting -- and assuming that file existed)

Every time I open Ghidra I'm reminded of someone once saying "everything is open source when you know assembly" :lol:

I'm never convinced that the caches are set correctly on my Milan.

An update on the Mach64 testing: Since I was a little bit un-sure about the status of my card, I tested it using my TT + NOVA. Initially I had some troubles getting it to work with Joebar's latest driver, but after testing with version TT_Mach64_V3.01 it worked really good. I also added some extra DIP RAM IC's to get 2 MB of mem, since I had empty sockets on the board. That also worked perfectly and I could run 1280x1024x256, which was really beautiful :)

Since it's driver version 3.03 in the Raven distro, I of course wanted to try with driver version 3.01, and the results were quite good. There is still something very unstable when executing the VGA BIOS. First boot it said "No VGA bios detected" and it didn't seem to work at all. Second boot it sorta worked, but the display was offset in Y direction by like -100 pixels or something (notice that the mouser cursor is not offset): Third boot was the charm, and it worked perfectly: The instabilities could of course be related to my Raven, I haven't really had a chance to stress test it yet. With the Mach32 however it seems to be quite stable. It seems to fail when initialising NOVA from a cold boot every once in a while (garbled screen), but haven't seen any oddities related to VGA BIOS. With the Mach64 VGA BIOS seems to be sometimes not detected at all, sometimes taking a very long time to execute (like 30+ s) and sometimes executes in a few seconds. However it never prints out anything (like the model of the card) and it always says 8-bit vgamem.

I'm afraid I'm not knowledgeable enough to draw any smart conclusions from the above... Do the NOVA drivers depend on VGA BIOS set-up at all or are they supposed to be able to set everything up on their own? If they are supposed to be totally decoupled from VGA BIOS I guess the VGA BIOS instability might not be the cause of the NOVA start-up instability. Maybe some general instability when accessing video card registers which gets much worse with the Mach64 than with the Mach32?

Hope all of you have a Happy New Year!!