Some PC-98 game can't control about dosbox-x HOT 21 CLOSED

@joncampbell123 I don't understand you said. In a word, it need support BIOS.ROM(N88-BASIC), is that right?

I just fixed the issue by providing enough of the keytable for the game to work correctly, though it's incomplete, at the fixed memory addresses the game keyboard handling assumes it should be.

Theoretically, the best fix is to patch the game not to replace the keyboard interrupt at all. It doesn't appear to do anything different from what the BIOS does when handling the keyboard interrupt.

from dosbox-x.

Initial assessment:

Game is using kbhit() (INT 21h AH=0x0BFF) to detect if there is any keyboard input at all, before reading it.

As observed when PC-98 mode was first introduced, INT 21h does NOT use INT 18h to detect keyboard input, but relies instead on memory address 0x528, the "key counter" to know if it should check for keyboard input.

In normal PC-98 mode in DOSBox-X, the DOSBox-X emulation correctly increments this value on keyboard input and INT 21h returns keyboard input as it should.

But inside this HDI image, a driver of some kind has replaced DOSBox-X's keyboard interrupt handler with it's own, and it is NOT incrementing the key counter (though it is writing to the circular keyboard buffer), therefore, the game never sees keyboard input because INT 21h never says so.

EDIT: No, actually the interrupt handler is incrementing the byte, but it's also somehow translated the spacebar to no input?

from dosbox-x.

Wait a minute, is this driver expecting to read the keyboard translation tables directly from ROM BIOS?

I have single stepped in the debugger to where the IRQ 1 handler is taking the keyboard input and translating it to ASCII to place in the keyboard buffer. It's using ES:DI which points directly at the ROM BIOS, where DOSBox-X only contains a lot of zeros.

No wonder keyboard input doesn't work.

from dosbox-x.

So apparently what that code is doing is taking the low 3 bits of the scan code and looking up a table in the ROM BIOS that converts the 3 bit value to a bitmask value i.e. [ 0 1 2 3 4 5 6 7 ] -> [0x01 0x02 0x04 0x08 0x10 0x20 0x40 0x80].

I noticed in one copy of BIOS.ROM that there is a table there of those bytes, although in my copy, it's actually 3 bytes farther ahead (so already this driver would probably fail on any ROM BIOS image older or newer??)

Why is it relying on a ROM BIOS table to do this??? Why not just do AL = 1 << (AL & 7)? I don't recall the SHL instruction being very slow at all on older computers.

Just after that the result of this lookup is used to set or clear a bit in the keyboard bitmap table.

from dosbox-x.

The second table it uses appears to be at 0xFD80:0000 for normal scan code to ASCII translation, which DOSBox-X also does not provide.

from dosbox-x.

The game is the one installing it's own keyboard handler. I can run it directly from the DOSBox-X shell (just don't run it from drive A). The custom handler appears even then.

[autoexec]
# Lines in this section will be run at startup.
# You can put your MOUNT lines here.
imgmount c: "Nut Berry.hdi" -t hdd -ide 1m
c:
cd nutberry
nut /HD

from dosbox-x.

Was this a game designed only for a specific range of PC-98 systems or maybe a specific machine? As far as I can tell it's assuming ROM BIOS addresses (because I didn't see any attempt to adjust or detect) and there are some BIOS.ROM images where those addresses don't match.

from dosbox-x.

Actually, it's only reading 0xFD80:0x0000 because DOSBox-X does not write anything yet to memory address 0x522 which is an offset into segment 0xFD80 of the keyboard conversion table (which can change according to shift state). So that failure is DOSBox-X's fault. But I'm still curious about the need for the table in ROM to lookup 1 << (AL & 7).

from dosbox-x.

The second problem is that even if DOSBox-X sets that pointer, the game clears it the instant SHIFT, CTRL, ALT, etc. are pressed because it also updates the pointer at 0x522, once again assuming a lookup table at 0xFD80:0xE28:

new offset = ES:[DI]
SHF = [memory byte at 0x53A]
ES = 0xFD80
DI = 0xE28 + (SHF * 2)

Which of course is zero, so if you hit any modifier keys you're back to all keyboard input ignored.

Once again that address doesn't appear to correlate with what I see in BIOS.ROM.

from dosbox-x.

I'm going to have to pull out the PC-98 laptop and see if these tables exist where the game thinks they should. In the meantime, if you can compile from source or find the latest nightly builds, the issue has been somewhat fixed as long as you do not touch any modifier keys (SHIFT, ALT, CTRL, etc). If you touch those keys, keyboard input will no longer work.

from dosbox-x.

Sigh, never mind. The HDI image changes that pointer to point to 0xFD80:0x0E00 which again contains nothing (is that where the table is supposed to exist?)

However if you instead IMGMOUNT as drive C: and run the game directly under the DOSBox-X shell, keyboard input should work.

from dosbox-x.

Well, 0xE00 is definitely the keyboard translation table.

But then if it's a lookup table, why is it also the offset table for shift status AND a binary to byte mask lookup table? Weird.

Although again, the game's assumption of that 0x01,0x02,0x04,0x08,etc. table is now about 9 bytes off on this one.

from dosbox-x.

No, wait, on the actual laptop; 522 is later set to 0x0B31 which also points to a translation table.

from dosbox-x.

No, DOSBox-X INT 18h is doing the setting of the pointer! 🤦

from dosbox-x.

However wrote this custom ISR in the game very obviously disassembled their machine's BIOS interrupt handler and copied it instruction for instruction 😆

It looks exactly like the BIOS keyboard ISR on this laptop, except the table addresses are different.

So, yeah, I fully expect this game to fail to handle keyboard input on anything other than the specific model of PC-9821 the developers wrote this on.

from dosbox-x.

I suppose another workaround is to patch the game not to hook the keyboard interrupt, since it's coded to act exactly like the BIOS one, and then it would fully work properly no matter what BIOS it's running under.

from dosbox-x.

According to the box image, the game claims to work on PC-9801VM which is quite older than a 9821, so I'm not sure your assumption that it doesn't work on older PC98 is correct.

https://gamefaqs.gamespot.com/pc98/372629-nut-berry/boxes/896433

from dosbox-x.

@joncampbell123
I don't understand you said. In a word, it need support BIOS.ROM(N88-BASIC), is that right?

from dosbox-x.

np2kai (an np2 fork) sets keytable of 8 shift types, normal, shift, caps, shift+caps, kana, kana+shift, grph, and ctrl.
https://github.com/AZO234/NP2kai/blob/c2ca4046860264cb307e768f529f180caee5e224/bios/bios.c#L510
https://github.com/AZO234/NP2kai/blob/c2ca4046860264cb307e768f529f180caee5e224/bios/keytable.res

from dosbox-x.

I'm also saying that the game's keyboard interrupt is unlikely to handle keyboard input correctly unless the PC-98 system it's running on has the same or similar BIOS as the one the developers wrote the game on.

from dosbox-x.

Thanks for your work,
You said "the best fix is to patch the game not to replace the keyboard interrupt at all", then can you do it?
I have tested VS build, it's O.K. MinGW build is unfinished now. I will try it after finishing. Test O.K.

from dosbox-x.