[Core Port Req.] eien's quickerNES

[YoshiRulz]

Merged on 2024-03-22 and released with 2.10.

Open tasks:

• re-triage remaining issues in the Core: QuickNes label (at the time of the merge, there were 3)
  • also decide whether to continue using that label or create a new one (doesn't matter, just keep it -- Morilli)
• update build scripts (done with d17352a ?)
• add Virtual Pads for Arkanoid peripherals (may be able to re-use NesHawk's)
• update Nix expression unmanaged deps aren't split out so there's nothing to do
• Implement additional services:
  • IDebuggable.SetCpuRegister
  • IInputCallbackSystem (IInputPollable.InputCallbacks)
  • IMemoryCallbackSystem (IDebuggable.MemoryCallbacks)
  • IRegionable
  • IRomInfo

[SergioMartin86]

Parallel to the licensing situation, there are a couple of technical tasks to adopt the new core:

• Adjust the BizHawk interface to allow selecting FourScore
• Test audio is still correctly emulated (not automatically tested in the source repository)
• Add better error handling in QuickerNES: i.e., throwing sensible exceptions as opposed to segfaulting.
• Make sure all features (search, hex editor, TASstudio, etc...) still work and existing movies sync.
• Make CIRAM write-able, like in NESHawk

Some discussions to be had

• [x]

The game Ivan 'Ironman' Super Off-Road supports FourScore. That means it reads 32 bits during the latch phase of controller input reading. And it seems it also uses this value for RNG generation. This is the case even if you use normal joypad inputs (only 8 bits provided). The original QuickNES passes all ones beyond bit 8, while I think NesHawk passes zeroes. Naturally, this causes desync between the two cores. I believe the NesHawk is correct since there should be no electrical signals after 8 bits during latching phase. I would like to fix this in the new core (namely, do what NesHawk does). However, this means that the Super OffRoad movie will desync on QuickNES from now on (and probably sync on NesHawk).

This was an incorrect assumption. Passing ones is the correct behaviour and it is exactly what NesHawk. IIRC, ultimately the reason for the desync is the game reading from uninitialized memory, which has no right/wrong initial value.

• [x]

I forgot to document this in the README file, but I removed all overheads (signatures, header name and size) from the save state format. This reduces save state size from 12792 to 12692, but makes them no longer cross-compatible. My tests hash the actual contents of the RAM and not the savestates files 1:1.

This is simply an improvement (i.e., a reduction in savestate size). Since we do not guarantee backwards savestate compatibility, it shouldn't be a problem.

If it's ok, I will create a new PR with this integration and close #3839

[YoshiRulz]

We don't guarantee movie sync or savestate compatibility when a core updates, so those won't be deal-breakers. As you know, QuickNES is our speed-focused core, and any accuracy improvements you can make are just a welcome bonus.

Despite my phrasing, there's no rush here. Focus on problems which affect you before worrying about the BizHawk interface code. And when the time comes, don't forget that the managed-unmanaged interface is also open to change.

[CasualPokePlayer]

Improve overall emulation performance for modern (x86) CPUs (portability to other systems not guaranteed)

Does this mean it wouldn't build for other CPU archs (e.g. ARM?).

Also, how does this end up affecting performance with older x86 CPUs, ones which would more need the speedup QuickNES provides for a casual user.

[SergioMartin86]

Improve overall emulation performance for modern (x86) CPUs (portability to other systems not guaranteed)

Does this mean it wouldn't build for other CPU archs (e.g. ARM?).

I'm not sure, I haven't tried it. Since ARM used big endianness, there might be problems. I wish I had a system to try this on.

Also, how does this end up affecting performance with older x86 CPUs, ones which would more need the speedup QuickNES provides for a casual user.

I don't have an old machine to test this on. I tried 2 server-grade computers and my own (a mid-range Ryzen) and all these systems got similar results.

[CasualPokePlayer]

ARM used big endianness

Not sure where you heard this, ARM is a little endian CPU (well, in practice it always is for any kind of ARM user)

[nattthebear]

Since waterbox only supports x86-64, other cores being x86-64 only isn't really a deal breaker.

[YoshiRulz]

Keep in mind we could simply disable Waterbox and unmanaged cores for an AArch64 build. But I agree it's not a concern here.

[SergioMartin86]

Just a heads up. I'm still polishing details with the core itself. As soon as I'm done I'll work on the Bizhawk interface to add FourScore support and access to the different memory domains.

[SergioMartin86]

Alright, so I'm done porting the new core into BizHawk (see: #3839). This is a self-sufficient update that could be merged right away.

On the other hand, I still haven't added an interface to enable FourScore. It's been 15 years since I last programmed in C#, so I'm a bit lost as to how to extend the interface. Can you please help me add that option? The idea would be to have a dropdown like in NesHawk:

But only options:

• Unplugged
• Nes Pad
• Fourscore (port 1)
• Fourscore (port 2, it differs in signature)

And then have these changes reflected in the inputs you can make in TAS studio.

[YoshiRulz]

Revisiting your checklist above, is anything still missing (which is crucial for botting)? I quickly tested memory peeking and that works.

I don't have an old machine to test this on. I tried 2 server-grade computers and my own (a mid-range Ryzen) and all these systems got similar results.

I have an Intel i5-2400. On 0857dd6, I'm averaging ~1400 fps. On 01f223e with the same setup, ~1450 fps. It may even be higher, but the fluctuations are too wide for me to tell by eye, and I can't be bothered logging it.

[SergioMartin86]

Revisiting your checklist above, is anything still missing (which is crucial for botting)? I quickly tested memory peeking and that works.

Yes, everything I need is there.

I have an Intel i5-2400. On 0857dd6, I'm averaging ~1400 fps. On 01f223e with the same setup, ~1450 fps. It may even be higher, but the fluctuations are too wide for me to tell by eye, and I can't be bothered logging it.

There are a couple reasons why the overall impact on fps might not be as high:

1. In my benchmarks, I had tested the core in isolation. When adding the overhead of the interface / C# interaction, some of these gains are diluted.

2. There is a big optimization that I couldn't implement in the Windows .dll. That is: aligning the CPU main function to 1024 bytes. This is a very long function that needs aligning for it not to cross cache lines, but unfortunately MSVC's C++ compiler does not support it.

These points apply regardless of whether you use a mid-end or server-grade CPU.

[CasualPokePlayer]

unfortunately MSVC's C++ compiler does not support it.

Does clang-cl support it? Building under clang-cl/clang where possible would generally be preferred.