Raven. A homemade Atari-like computer

[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?

[agranlund]

Inspired by CT60 and Firebee and so on I tried running the graphics card VGA-Bios in an x86 emulator at boot, before the OS is started.

That worked surprisingly well and faster than I expected!
EmuTOS, built without graphics card init code, runs fine.



The practical use of all this is quite low, or at least unknown.
In practice, you still want to use NOVA to get a VDI capable of working with nice screen modes. Not to mention the hardware acceleration it supports.
And if you do that you already have a card that EmuTOS is able to start up.

At best, perhaps it would allow you to use just about any VGA compatible ISA card in a B&W EmuTOS desktop.
But perhaps the code could be used as a base to develop some kind of works-with-most-cards driver, in combination with NVDI so one didn't have to write a whole VDI too. Card setup and SVGA functionality are otherwise quite custom per card and to get that stuff almost for free like on PC has to be a benefit.

Perhaps it could come in handy if one wanted to make Raven do something completely different than run TOS and you also wanted graphics.

Regardless, it was a very fun experiment even if I'm not sure what to do with the result at the moment