Disclaimer: I have no answers your post just got me curious.

What hardware / OS is this emulator running on could that support nanosecond timing with any sort of accuracy?

Currently it's confirmed running on Android(later builds on Samsung Galaxy S7, although somehow crashing on 1kIPS/1kCycles/sec due to still unknown reasons), Windows(active building platform(Windows 10, although should run on anything from XP and up due to MSYS2/MinGW compatiblity issues with older OSes) where I debug my apps on mostly using Visual Studio 2015) and compatiblity mode on PSP(haven't tested for some time, but should still run). Linux compilation(not distributed myself) should also still be possible, but can't test those due to not having LInux installed anywhere(closest is my phone 🤣 (Android) ). So currently generic x86/x64. some ARM processors(Android) and the PSP processor(32-bit MIPS32 R4k-based CPU, named Allegrex).

So in short:
- Windows
- Linux
- Android
- PSP(pretty much too slow to be workable atm, but it's the original target when I was started building the app(before switching to using SDL, but even now it should still work with the SDL1.2 included with the PSPSDK))

All timing is simply kept as amount of nanoseconds passed, which are added together and substracted(varying between 0ns and 1 second usually). So the values being added(any immediately substracted) are usually in the 0.0-1000.0 range when running in sync with realtime, although it can do additions as high as up to 1 second(1000000000.0 being added(once) and substracted(in tiny portions according to CPU cycle intervals, so up to 31.25ns(CPU running at 32MHz, which is the currently largest default(for 80486)))).

Since the CPU runs at a 1kIPS/1kCycles/second, the values being added to the core time(CPU core and emulated hardware core time) are 1000000.0(1ms) when they're at their biggest increase steps. The increase of the realtime loop(which syncs to system time to try to keep the emulation up to speed and not too fast(although it currently fails to get up to speed even on a Intel Core I7@4.0GHz)) is dependant on the system speed vs emulated speed(the time of the inner loop of the two, which should be taking 1us at the most usually, due to simple block count limits).

I do not use floats or doubles. I use uint64_t since all I am doing is adding, subtracting and comparing. The only float I use is for the frequency ratio of any device to the CPU frequency. But that is a fixed number that never changes.

The problem with floating point values is they lose precision as the value increases. That is if you are looking into dealing with 10^7 or more values then their precision decreases. At that range, fixed point or just integer values serve you better.

Well, the floating point parts in UniPCemu only apply to non-14MHz hardware timings, like the Soundblaster sampling, wave output sampling of all sound hardware(including the output from the PIT, not the PIT counter itself) etc.. All(most) are called with a rate of 14MHz, except variable or irregular videocards(e.g. non-14MHz video cards(all but CGA)). The 14MHz rate itself is recalculated using floating point each cycle(cycle-accurate mode) or instruction(IPS mode) by multiplying either cycles(Cycle-accurate mode) or completion status(boolean being 0(unfinished instruction) or 1(instruction finished)) with the CPU cycle(or instruction when using IPS mode) time(in nanoseconds).

And of couse they're used in filtering and resampling audio at varying rates(44.1kHz up to 5MHz(game blaster processing blocks)).

Edit: Btw vladstamate, just tried the latest version of Cape(0.6) with my current(running in UniPCemu correctly) AT BIOS, but it fails when powering up(empty display with cursor) giving beep codes? I tried both 6 and 8MHz, but it keeps failing? Just wanted to see if some app that crashes in UniPCemu(Maniac Mansion) ran in Cape. That way I'd know if it's a problem with UniPCemu or a documentation problem?

That is because that version is ancient. I need to make a new release very soon. You can get it then and try it with programs to compare.

vladstamate wrote:

That is because that version is ancient. I need to make a new release very soon. You can get it then and try it with programs to compare.

Just a little question: does it support the IPS instruction mode(like UniPCemu does)? That would come in handy to compare the instruction logs(otherwise a single cycle would make it uncomparable due to interrupts etc. being shifted differently in time).

No sorry 🙁 But you can still compare logs, just ignore timing interrupts.

I will try adding a IPS mode.

Btw, it isn't Maniac Mansion I'm trying to get running(not the first one). It's Day of the Tentacle(Maniac Mansion II). Noted the wrong part.