Raven. A homemade Atari-like computer

[agranlund]

SDL1.2 works, it's just a clone with a Nova graphics card and that's supported already.
I used it to build Tyrian and Doom.

Sound is not, but at this stage in time I would put that responsibility on the soundcard driver.

As a "temporary" measure I think the GUS driver should emulate the standard atari TOS4 sound api to let some old/existing things "just work".
That TOS4 API is completely sub optimal for something like a GUS (or even a Vampire V4SA) since it has no idea about fancy multi-channel hardware features or dedicated sound ram - but as a first step and fallback it would be nice.

Ideally someone would make a nice central sound API that is properly hardware-abstracted and understands modern concepts (including any number of devices of same or different kinds). Like Linux, Mac, Windows and even Amiga (with AHI).
Done correctly it could greatly minimize effort of making drivers, as well as application code that wants to play sounds. Letting the bulk of a lot but mostly generic heavy lifting be handled by the sound system in a single place. And then finally teach SDL to support that API too.
A considerable effort, and that imaginary someone would need to have quite a bit of time and dedication on their hands.

[danboid]

Have you looked into the feasability of maybe porting the OSS sound system from FreeBSD or Linux or writing some kind of shim for OSS? That should get us most of the drivers you'd need and it already works with SDL.

I can understand you not wanting to make to too much like BSD or Linux which could be a reason to avoid using OSS.

[agranlund]

Have you looked into the feasability of maybe porting the OSS sound system from FreeBSD or Linux or writing some kind of shim for OSS? That should get us most of the drivers you'd need and it already works with SDL.

I can understand you not wanting to make to too much like BSD or Linux which could be a reason to avoid using OSS.

Yeah I've looked at it for hardware information and for inspiration, AHI too, but not really for the purpose of how feasible it would be to port.

You do get into some softer values in terms of "what would be more fun" too I suppose.
Personally I think I would find it more fun designing and creating something over porting so that'd probably sway me in that direction, regardless of what would make most logical sense.
But then again, I've been off and on thinking it'd be fun to make something like that for a while but never actually sat down to start write any code so I'm starting to doubt anything will ever happen by me :)

[danboid]

I'd be happy enough if someone manages to get the TOS sound API working with something.

Have you got 320x240x8bpp working with SDL yet?

[agranlund]

I'd be happy enough if someone manages to get the TOS sound API working with something.
Have you got 320x240x8bpp working with SDL yet?

That resolution has always worked with ET4000 cards.

My Mach32 is back in the drawer again now that I have the ET4000W32i back in the computer.
The status of Mach32 and that resolution is still very much unfinished test code, to be perhaps picked up some other time. I only felt the urge to explore that recently because I didn't have access to the W32i.

[agranlund]

I've updated the latest binary package with latest.
https://github.com/agranlund/raven/rele ... A1.latest

The biggest change is including the standalone ISA_BIOS as well as the FPU emulator for those that use 68LC060 (also a standalone program for now)
The FPU emulator is a continuation of the old one I made to use with TF53x cards, updated to include support for 68040/60 so it should now work, slowly, on all 680x0 family processors.

Important note about MiNT:
Normally, you want to run fpemu.prg before MiNT is started.
This is so MiNT "knows" that you have an FPU in the system and safely multitask applications using it.

However.. on 68060 specifically, MiNT sees through the facade so you'll have to run fpemu.prg _after_ mint.prg if you want to use it.
There is a huge caveat in doing so; the MiNT kernel will behave as if there is no FPU meaning if you are running two programs and both are using the (virtual) FPU at the same time then bad-things(tm) can happen, or rather, bad floating point results can happen - you have been warned.

Change log:

Code: Select all

20241202
software: added FPU emulator 'fpemu.prg'
software: added ISA_BIOS and example config file
rvbios: fixed GUI glitches on nvram page
rvbios: fixed SP060 issue
monitor: config system and storing settings to nvram

[Badwolf]

However.. on 68060 specifically, MiNT sees through the facade so you'll have to run fpemu.prg _after_ mint.prg if you want to use it.

Naughty MiNT! ;)

I wonder if @mikro or his pals might consider adding the FPEmu codebase into MiNT so it could handle all this itself? No real FPU found? Activate the virtual one. Or perhaps it can be done as an XDD or similar?

Sorry, bit off topic, but you know I'm a big fan of FPEmu and this seems a pity :)

BW

[stephen_usher]

Newer MiNT kernels just replace all the OS below it and do their own thing, so not a surprise. I think the kernel only really checks where the hard drive driver has gone and preserves that. This is why you can't exit the kernel and go back to TOS any more, as you could originally.

[agranlund]

I wonder if @mikro or his pals might consider adding the FPEmu codebase into MiNT so it could handle all this itself? No real FPU found? Activate the virtual one. Or perhaps it can be done as an XDD or similar?
Sorry, bit off topic, but you know I'm a big fan of FPEmu and this seems a pity :)
BW

Based on this:
The lower WORD is reserved for information about software support via the Line-F trap, and is at present not yet in use. According to Atari, a non-zero value indicates that Line-F support is present.

I was going to propose a small mint init change to look for this in the existing _FPU cookie and act accordingly.
But then I immediately found that if I put things in the lower word Gembench gets very confused about the cookie and has no idea what it means.
I live with it if it's just that program but it made me question what other ones might be parsing that cookie incorrectly too - the low word has pretty much always been zero.

So it comes down to either:
a) completely invisible and thus most compatible, but not necessarily multitasking safe.
b) reveals itself through the low word of _FPU cookie, opens up for a possibility to have MiNT recognise it. But maybe incompatible with programs that reads the _FPU cookie wrong.

I had decided to drop it and leave as-is but maybe option b is the better one after all? After all, Mintlib programs detect the fpu in the correct way and that'll be the majority of them, probably.


The absolutely best is to have these kinds of things in a kernel.
It is on Linux and BSD and by being tightly integrated lets them avoid doing expensive emulated fsave/frestore at every context switch -- they can just access the emulators memory directly to save/restore those virtual registers.
NetBSD didn't even bother implementing fsave and frestore in their FPU emulator because they don't need them. I added support for these in our Atari port because we do.

[viking272]

Can Gembench be modified by exxos (he has the source) if that's the only app that struggles?