Hacker News Reader

Comment by mikepurvis | Hacker News Reader

Given that original hardware prevented that, I’m surprised it wouldn’t be a default-on option in emulator frontends.

It depends on the emulator, across pretty much every platform that uses a joystick or d-pad, but in my experience the default most commonly is no left+right input at the same time. (It's semantics as to whether the implementation is "allow left+right input" defaulted to off, or "prevent left+right input" defaulted to on.)

I'd also be interested to know what ends up happening if there are simultaneous presses— I assume last-one-wins would be the least surprising strategy for resolving it, but certainly several options are possible, and what is preferred might even be game-dependent.

Oh that’s neat. I’m struggling to think of bug prevention that’s similar on a PC. Orientation lock maybe?

The original hardware prevented it in the sense it's impossible to push both the left and right button at the same time on the Gameboy dpad, not through any software means.

Yes, I understood that it was "hardware" as in a fundamental constraint of the physical controller, but appreciate the clarification.

Certainly if it had been enforced by the console firmware, then it would be a no-brainer that emulators should do it.

Funny story about this actually is that a while ago I was retrofitting an old dance mat to be an XInput device via a Teensy, and I ran into a constraint where XInput's d-pad support only allowed one direction to be set at once, which obviously doesn't work for that use case. I ended up giving up and having the Teensy emulate a USB keyboard instead. (This was for use with Stepmania and Necrodancer on PC.)

Games of that era tended to hit the hardware directly for I/O, meaning that there is no firmware that can enforce any such thing. AFAIK the Game Boy boot ROM just verifies the Nintendo logo data, plays the chime, then boots the game, and after the game boots, the boot ROM completely disappears from the memory map.

Nintendo held onto this no os approach into the Wii era. Hence if you ran a japanese version game on a north American Wii you got the japanese Wii pause menu.

Meanwhile the PS3 and Xbox 360 had hypervisors.

Yeah, I remember that too— each game was shipping its own instance of the pause menu, so they would have subtly different behaviour, including around weird things like what the light on the disk drive did.

I imagine this kind of thing is also why the backcompat story for playing Wii games on a Wii U is so janky— you have to access them through the "vWii" environment, which I guess is basically just a kind of VM, so that it can provide a virtualized instance of the hardware that the game ROMs/discs are expecting to talk to.

Well, the Wii did have an OS, that would receive updates over time. IOS was managed sort of shitty, though. Since older games would be linked with specific versions of IOS, they had to literally keep multiple versions of the OS around on NAND. They would occasionally stub out specific slots (usually those used by the System Menu, or by internal-only discs, or even slots they never used but that pirates did use).

Agreed, however, that all PPC code running during a game came from code on the disc, even "OS" things like the Home menu. The IOS code largely gatekept the advanced Wii features as compared to the GC

Reply on news.ycombinator.com