exxos's Atari, Amiga & retro forum

Hi All
Here is my Autostart Order
"
RVBIOS
EMULATOR
XBOOT
RVNOVA
STA_VDI
ISA_BIOS
SETENV
AUTOEXEC
RVSND
MINT060
"

Can anyone give me the best order

Thanks
Bernd

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.