exxos's Atari, Amiga & retro forum

mikro wrote: 11 Jul 2022 08:27

stephen_usher wrote: 10 Jul 2022 21:47

Might be useful to allow a full ST emulation on a TT or Falcon though for games.

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ THIS!

To make it a bit more specific, there are two huge areas of interest to explore:

- cycle non-exact (Win)UAE (i.e. taking m68k instructions as they are) (think of modern AGA demos)
- cycle non-exact Hatari (with, say, cache disabled and perhaps some stack frame fixes) (think of dirty games overwriting memory, using disk images etc)

I'm following this project with great interest but MacOS is totally alien to me. Amiga/Atari OS on the other hand... :)

What you could probably do is allow all non-priviledged instructions run normally, catching access to hardware. Priviledged code would have its own sandbox with only the privileged instructions emulated. Exception stack frames would therefore be written by the hypervisor as 68000 stack frames.

Remember, this isn't an emulation like UAE or Hatari, it's a virtual machine running the code on a real CPU, like VMware or VirtualBox on an Intel box.

You guys do realise you're both talking in the wrong thread, this is the fpu emulator thread.

It derived from the way that the FPU emulator may go in the future, to allow complete emulation.

But yes, it is a divergence from the core.

A newer version:
http://www.happydaze.se/wp-content/uplo ... 220711.zip


Changelog:
- compiled with optimisations enabled this time (oops... :oops: )
- partially implemented fsave / frestore instructions (ftrapcc is still unimplemented)
- implemented VBR masking


This version should fool most types of direct-hardware tests.
If you put it before Mint.prg in the auto folder it'll fool it too.


The only thing that would break the illusion is if something else moves the VBR too. I know some HDD game patches from some group I can't remember does that kind of stuff.


Still not sure if it's a great idea. Perhaps I should build two different versions.
Or maybe a .CPX module for settings (I've been looking for a reason to learn how to do those things anyway)

Nice ...

mikro wrote: 11 Jul 2022 08:31 While this is a nice project (and it certainly has some use), this particular problem (-m68020-60 requiring FPU even if it doesn't really use it) is a bigger problem to solve and this "fix" would just replace it with another problem -- instead of people complaining that their software is showing the strange error message people would report sudden and random slowness.

Much easier to explain one error message than a flood of random bug reports.

I'm a 100% with you on this @mikro. This is a workaround more than a proper long term solution.
The thought did cross my mind if this thing would do more harm than good. It'll be hard for a user to know if random slowness, or even crashes, are due to the fpu emulator is kicking in. This could easily cause unnecessary and wrongly directed bug reports toward Mint..

Not sure how I feel about that, but it'd also feel weird not to share code with people.

In any case, it's an interesting and fun small project as a bit of a break from Basilisk :)

FPU Benchmark ...

https://github.com/czietz/linpack-atari/

agranlund wrote: 10 Jul 2022 01:14 So.. I couldn't resist :lol:

Here's a software FPU emulator for Atari:
http://www.happydaze.se/wp-content/uplo ... /fpemu.zip

Yes!!

This is great. Many thanks, Anders.

How well an accelerator card with no FPU does with Linpack may very well be the next big benchmarking trend. :lol:

BW

Badwolf wrote: 12 Jul 2022 13:04
Yes!!

This is great. Many thanks, Anders.

How well an accelerator card with no FPU does with Linpack may very well be the next big benchmarking trend. :lol:

BW

The FPU test in Gembench takes 5minutes+ so it’ll be a slow race indeed :)
Kronos test is a lot shorter though.

Comparing the NestBSD vs Linux implementation I have a feeling the Linux one might be quicker. But i dont have that one working enough to know.
They’ll both be incredibly slow in the grand scheme of things so maybe readable code is preffered.

The NetBSD one is a lot easier to work with since it’s all C except for the new Atari specific entry/exit code.
I’m sure there is a lot of room for hand optimization.

I think it’s cool though and I very much enjoy making stuff work in unintended ways through the magic of software :)

I agree it's a very cool idea. I can contribute some benchmark results from my TT:

Atari TT030 @ 48 MHz            FPEMU_220712    Real 68882      Factor
-----------------------------------------------------------------------
LINPACK 100: kFLOPS             1.59            281             177x
NemBench:
Float multiply: MFLOPS          0.006           0.811           135x
Float divide: MFLOPS            0.002           0.526           263x
Linear stalled float: MFLOPS    0.008           1.338           167x
Interleaved piped float: MFLOPS 0.007           1.336           191x

Note: TT needs to run EmuTOS. Atari TOS 3.06 will not boot without FPU.