since I started coding for the VB, I came across a couple of oddities. Most of them are eventually described well in the wonderful docs of Guy Perfect. It seems like mednafen is still the most widespread emulator out there (retroarch using the same codebase to my knowledge) so I found it worthwile commenting on two bugs in mednafen.
I filed them in the forum and got into contact with some interessted devs. So hopefully those will get resolved.
1) Mednafen’s timing for the 20us timer is widely off (runs at about 80% of original speed)
2) Mednafen redirects writes to WAVE ram such that even writes to ‘illegal’ offsets will result in proper register access in mednafen but not on real hardware (that took me a while to notice for my audio engine).
Attached you can find an example code for both.
1) it runs a timer at $31c times 20 us which turns out to be in sync to screen refresh with all current mednafen versions I tested. You can tell by the fact that the ‘dark’ area in the bright bar wanders as slow as possible across the screen as I fire an IRQ time, dim the LED brightness, wait in some busyloop and return LEDs back to former state.
On real hardware the best timer value is $3e5 (see screenshot). We would expect it to be $3e7 (= 1000 * 20us = 0.02s -.> 50Hz screen refresh rate). It can vary on real hardware though, since the column table data contains the duration for a certain screen column which will affect the effective screen refresh rate.
You can press UP/DOWN on the keypad to change the timer
2) You can hear two tones with different pitches in mednafen. They are two different WAVE patterns.
The first one is written to WAVE RAM at offsets 0,4,8,… the second one at 1,5,9.. (2,6,… or 3,7,… yield the same behavior). The real hardware only accepts writes to the lowest byte and hence you will not hear the higher tone on real hardware.
This debug.vb is also a nice test once you get a new retroarch/mednafen version to check if it is corrected already.
In addition to some obvious erroneous timer value for the 20us timer in the emulator, there is also some additional behavior here that we try to tackle and that turns out not to be fully understood yet. Likely some special behavior for very short (0, or 1) timer settings. Feel free to add opinions or discussion here.
The 2nd bug will likely annoy developers only, the first one also affects a couple of games that tune things to the 20us timer and are hence too slow (often for music then). The 100 us timers are doing okay.
No replies yet.