-
-
Notifications
You must be signed in to change notification settings - Fork 154
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Keyboard input delay/locking/queuing in Gods (Bitmap Brothers) #3691
Comments
Can confirm that this happens since 0.81.1 (probably 0.81.0 as well) and in latest dev build, it does not occur in 0.80.1. |
By the way if one gets stuck in the intro, just use LOADFIX. It doesn't happen all the time for some strange reason. |
Paging @FeralChild64 for the keyboard regression. It's most likely caused by your grand keyboard refactor 😄 Also, this is 0.81.2 patch release-worthy material. |
If I see correctly, this game used to work correctly in 0.81.0 - but on the current [edit] And looks like reverting 0382ab6 makes the problem disappear. |
Maybe your improvements @FeralChild64 are OK, because Gods apparently doesn't handle fast typematic keystrokes on real hardware: https://www.vogons.org/viewtopic.php?t=76407 Could it be that 0.80's keyboard code was not as accurate as 0.81, but some buggy games had "accidental benefits"? Bitmap Brothers released "godsfix" patch, mentioned here: https://www.dosgames.com/forum/viewtopic.php?t=3524 But unfortunately the bitmapbrothers website is gone and wasn't archived by the Wayback machine 😞 I guess a typematic control tools is the best bet? |
Sorry, just to clarify - worked fine in 0.80.1, but not in 0.81.1. I haven't tested 0.81.0, but looks like others have and had the same issue? |
@interloper98 We'll see. The game reads the keyboard using INT 16. It constantly calls it with AH=0x01, and - if the key is there - calls it with AH=0x00 to get the scancode. |
@FatBarry oops, yes, I also meant 0.80.1 when I mentioned "0.80". Checking the release notes for 0.80.1, there are no keyboard changes between 0.80.0 and 0.80.1, so I'm guessing they are both OK in Gods. https://www.dosbox-staging.org/releases/release-notes/0.80.1/ |
Maybe the game was patched on The Bitmap Brothers Compilation (1995): https://www.mobygames.com/game/16762/the-bitmap-brothers-compilation/ https://archive.org/details/bitmap-brothers-compilation If i can't find patches for a game then i usually get the compilation CD version because they have the latest patches applied. |
Latest version that I was able to find: |
That's a smart strategy. |
Woah nice finds! Thanks :-) Tried both versions (Compilation and 1.01) without and then with the GODSFIX keyboard patch applied (it's a DOS self-extractor that overwrites the GODS.INI file), but unfortunately I still get the same results (Windows 11, AMD CPU). gods_jumpy_keyboard.mp4 |
@interloper98 I had the same issue as you show in your video in either version of DosBox. The bug that is described here happens ingame. |
But the patch seems to be for a different issue, so it isn't really surprising that it doesn't fix our regression 😄
|
Just exhausting out options that there is a software fix available which is good. |
Some extra notes @FeralChild64:
|
I already know this does not work like a real controller - and I can't easily make it work like a real controller, or our BIOS won't be able to talk to it. At least one reason is within the case CB_IRQ1: // keyboard int9
phys_writeb(physAddress+0x00,(uint8_t)0x50); // push ax
phys_writew(physAddress+0x01,(uint16_t)0x60e4); // in al, 0x60
phys_writew(physAddress+0x03,(uint16_t)0x4fb4); // mov ah, 0x4f
phys_writeb(physAddress+0x05,(uint8_t)0xf9); // stc
phys_writew(physAddress+0x06,(uint16_t)0x15cd); // int 15 From what I could observe in 86Box, the real BIOS does something more complicated here, it runs with keyboard controller set up in a different way, where the keyboard entry is only being enabled for the duration needed to read the keyboard input. I can probably change this, with some x86 manual opened in another window, but - frankly - I'm afraid to change this code, I have no idea what could break and in which way, I have almost no experience with x86 assembler, and I have no idea what dirty tricks games might use in connection with this code.
But which part?
Well, for me the Windows 3.11 problem was VERY visible. And finding games which did break took quite some time... If I revert to the old implementation, the register-level PS/2 mouse implementation will have to be gone. Not to mention I am rather short of time recently (see how slowly it takes me to rework the host OS locale synchronization) and the reversal would probably be by no means trivial. My problem is, that I have no idea yet what precisely confuses the game. It uses two legacy XT BIOS calls to check/read the keyboard status, so far I haven't found any difference in the behaviour of the BIOS. It uses the Intel 8255 chip to reset the keyboard - this wasn't emulated and still isn't. I can make the game working correctly again by removing a single
|
It looks like something (besides our IRQ1 assembler code) is also reading the port 0x60 - I just don't know yet if it is some DOSBox code, or a game code. |
Hopefully you're on to something! 😄 Btw, you already know x86 asm, you just don't realise 😏 It's one of the simplest assembly variants, and about 100x simpler than C++. It would take you reading a "Learn X in 15 minutes" article about it to get to intermediate level 😆 I learned it years before C, and even C was super complex in comparison. So poke x86 code with confidence 😎 |
Not really. I'm not really familiar with the CPU flags, addressing modes, I have no idea how exceptions work, several mnemonics are a mystery to me. And all these CPU modes, segment+address, ugh. |
@FeralChild64 DOS-era x86 asm, on the other hand, is simple and joyful. And primitive compared to 68k with its 1325 address modes 😅, so there's not too much to learn. Segment:address is dead simple, come on now 😄 You can write C++ code, that's a lot more complex task. Ignore protected mode completely, just focus on 8086 stuff. You then only need to familiarise yourself with some 386 instructions and the extended 32-bit registers, but that's it. Stay away from protected mode, privilige modes, paging, exceptions as if it were the plague or some STD 🤣 -- you're not writing an OS, neither a DOS extender. Very few people understood that advanced stuff back in the day. I happily coded in asm until the end of the 90s without understanding anything of that, and so did most coders. Here are some links I researched this morning because I also need to brush up my asm skills a little. But strictly DOS era; the modern 64-bit stuff is horrific...
Do this and you'll be a classic x86 asm guru in no time! 😎 Further oldskool x86 asm materials: |
How did you manage to fix this issue? I have this issue exactly, the one shown in interloper98's video. Almost impossible to select "ENTER PASSWORD". Everything else works as it should. Oh, and I tried both 0.80.1 and 0.81.1, and also other dosbox variants, but it's all the same everywhere (some other dosbox variants even have screen flickering in the menu)... |
Are you using the latest Dosbox-Staging Version?
Different version than latest?
No response
What Operating System are you using?
Windows 11
If Other OS, please describe
No response
Relevant hardware info
Gigabyte AORUS 17 XE4 (Core™ i7-12700H, RTX 3070 Ti)
Have you checked that no other similar issue already exists?
A clear and concise description of what the bug is.
The issue has only been identified when playing Gods (Bitmap Brothers). No issues identified with other games played so far.
As mentioned in Discord: https://discord.com/channels/514567252864008206/626653390830698516/1242998746153877534
Details:
Steps to reproduce the behaviour.
Explain how to reproduce
Download URL of affected game or software
No response
Your configuration
Provide a Log
No response
Code of Conduct & Contributing Guidelines
The text was updated successfully, but these errors were encountered: