One of the problems with switching to a 64-bit version of Windows is that you can't run 16-bit DOS programs, due to the removal of NTVDM. While this is usually attributed to Microsoft cleaning legacy house, it's also due to a hardware limitation: the original x86-64 specification prohibited VM86 mode under long mode. Therefore, I've been making greater use of DOSBox in the few cases where I need to run such programs, since it integrates a little better than virtualization.
Unfortunately, one of the old programs I occasionally run is QBasic, and there's a long standing problem where Ctrl+Break doesn't work in QBasic under DOSBox.
I finally got annoyed enough about this to try to diagnose it myself. I'd had luck doing this previously, when I tracked down the bug where the keyboard would suddenly stop working if you pressed Ctrl+Esc. (I'm actually not a fan of the "fix it yourself it's open source" mentality, and I don't have any good memories of 16-bit real mode x86, but scuttle four Colonization games in a row and I will launch the debugger.) Now, I already had a suspicion as to what was causing this: there's an anomaly in the PC keyboard where certain scan codes change depending on modifier keys. One of them is Pause, which magically turns to Break when Ctrl is also pressed. This anomaly is often reflected in higher level APIs, and in Win32, this manifests as your window handler getting a WM_KEYDOWN message with VK_CANCEL instead of VK_PAUSE. Therefore, somewhere along the line, it's likely that this difference wasn't being emulated.
Sure enough, when I dug into the keyboard emulation code, it was always sending the scan codes for the pause key. That was easily fixed, but I noticed that Ctrl+Break was never arriving from the UI, either. Okay, we probably just need to check for the analogous SDL constant for VK_CANCEL, which appears to be SDLK_BREAK. Easily done. Except... that doesn't seem to be arriving either. In fact, no keyboard events are arriving at all when I press Ctrl+Break. Luckily, I built the SDL library in Debug configuration from source, so I can debug into it. Let's see, no WM_KEYDOWN handler, which means it's probably using DirectInput, so let's set a breakpoint on the DirectInput code... uh oh.(Read more....)
Version 1.9 of Altirra, my 8-bit emulator, is now available on its home page. Highlights are: many serial port / modem emulation fixes, many new debugger features including conditional breakpoints and trace expressions, improved PAL color emulation and high artifacting support, new cartridge mapping modes, PCLink support for SDX host filesystem mapping, and emulation accuracy fixes to CPU/ANTIC/GTIA. The Acid800 test suite has also been updated to version 0.9.
Oh, and I'm absolutely not posting this just to keep the ginormous comment thread in the 1.8 release entry from growing out of control.