Does anyone here own Quattro Sports (Aladdin or standard), and if so, is BMX Simulator playable using the standard controller(s) or does it need a custom controller?
NESemdev-related: Using your emulator, it's only playable if you set $4016 serial reads 8-15 to a 3rd joypad, and reads 16-23 to 0 (similar, but not exactly as the Four Score).
hap wrote:
Does anyone here own Quattro Sports (Aladdin or standard), and if so, is BMX Simulator playable using the standard controller(s) or does it need a custom controller?
NESemdev-related: Using your emulator, it's only playable if you set $4016 serial reads 8-15 to a 3rd joypad, and reads 16-23 to 0 (similar, but not exactly as the Four Score).
I just tested it, and yes it can use a standard controller. When it boots, you can only choose 1 or 2 players. When you have a four score hooked up, with the switch set to 4 players, the 3 player game becomes accessible.
I checked it out via emu, and see what you mean. Also, when I tried to select BMX Simulator, it took me to the soccer game; vice versa as well (Nintendulator, Nestopia, VirtuaNES).
Thanks.
I find it odd that BMX simulator refuses to work on emulators, perhaps it's triggering an undocumented feature/glitch then. I'm pretty sure it's a good dump: it happens with all available Quattro Sports dumps, and the European Super Sports Challenge.
Quote:
Also, when I tried to select BMX Simulator, it took me to the soccer game; vice versa as well (Nintendulator, Nestopia, VirtuaNES).
This only happens on Aladdin deck enhancer carts of mapper 232. Don't take my guessing for granted, but I think that the 64K block bits are reversed (bits 3,4 of $8000-$BFFF).
Figured it out: it relies on the fact that the NES controller state is updated instantly when strobed, as opposed to emulators updating input typically once per frame.
hap, are you saying that it relies on the statistical improbability of controller button presses occurring exactly at VBL, that is, it ignores button presses that occur at the moment of VBL?
On the titlescreen, it strobes twice per frame, on constant intervals: once at the end of scanline 4, once at the start of scanline 172 (scanline 0 being the pre-render scanline). I think it looks at the difference between those 2 to see a button press (0->1).
If the user presses a button between strobe 2 and 1 (eg. somewhere in vblank), it won't register it as valid. So, controls at the titlescreen feel kind of unresponsive. In-game controls are fine.
I've tried to exectute updating procedure after strobing joypad instead of updating in main emulation loop once per frame and it really works fine... Title screen now handle joypad normally and allow to start game normally...
Yeah, that's the way to properly support it. The host CPU can get very busy though if you don't add a limit (eg. max 4 updates per frame), and I doubt libraries like DirectInput can keep up with a high frequency.
Something totally else is that such an implementation will mess up your emulator movie support (lucky for me I'm not there yet).
Couldn't an emulator simply poll host input at the beginning of the frame but delay feeding it until the middle of the frame, or poll the host input a second time if the joypad is strobed after some point in the frame? The first approach would avoid complicating movie recording.
That 1st approach is fine for this game, and would make its input feel responsive (unlike the ~70% chance on a NES), any other game we find relying on this could possibly fail just like BMX Simulator fails on vblank input updates (and then it's probable the other game would work fine when updating input in vblank).
*edit*
Next to movie support, another annoyance with this is that emulators generally emulate one frame as fast as possible, and then wait until it's time to do the next one. With this, you'd have to update timing in the middle of the frame.
Assuming hardly any game relies on this, I've currently settled with a simple Sleep(1) (making BMX Simulator less responsive than on the NES).
Here's what I had in mind, which doesn't require any changes to the general emulator structure or movie handling:
Code:
int host_input;
int next_input;
// called when $4016.1 changes from 1 to 0
void strobe_joypad( int time )
{
if ( time > 341 * 40 )
host_input = next_input; // update input if past scanline 40
joypad_latch = host_input;
}
void emulate_frame()
{
// movie recording/playback occurs here
next_input = read_host_input();
run_cpu( 29780 );
host_input = next_input;
}
I used to rely on Windows input events for this, but since it turned out to be not-so-compatible with certain input devices, I had to start over. Here's one idea I came up with:
Code:
int time_stamp = 0;
int host_input;
int next_input;
void strobe_joypad( int frame_part )
{
if (time_stamp <= frame_part) // settled for a frame divided into five parts
{
time_stamp = frame_part;
host_input = next_input;
}
joypad_latch = host_input;
}
void emulate_frame()
{
next_input = read_host_input();
if (time_stamp)
time_stamp -= 1;
run_cpu( 29780 );
}
It's a dynamic approach where the time to feed it input data is auto-adjusted. Works fine on all games I've tried so far, including the BMX game. It may not work so well with games that jump all over the place with different $4016/$4017 writes though.
Marty, sorry for my somewhat rude "tip" on the Nestopia board about BMX Simulator being re-broken in Nestopia 1.33b (user name pentium5dot1, thread name "BMX Simulator regression in Nestopia 1.33b"). I would like to check that you tested your revised input code in 1.33b with BMX Simulator on a keyboard. I will proceed to post a proper bug report when I get a chance; feel free to delete the original thread that I named above.
Someone managed to
Spot another game with the same problem.