What would have caused this weird glitch on an 8088 XT?

[mbd30]

I've been wondering about this for years, and I'm finally making a post about it.

 

In the late 80's we got an 8088 XT IBM PC compatible. As a kid, I programmed a lot of stuff in GW-BASIC. Now here's the weird part. Whenever I pressed the '5' key on the number pad, it promptly broke GW-BASIC and dumped me to the DOS prompt. I remember when I played BASIC games that involved using the direction keys, I had to be careful not to touch the '5' because that happened.

 

Anyone else experience anything like this? What would cause it?

 

 

[John_L]

A bug in the program (GW-BASIC) called it. When you code, at least old school non event driven code, you have to account for every possibility. I don't know the code you're speaking about, but, being a basic game, it had 3 choices for reading the keyboard, INKEY$, or some rom call, or it's own routine reading the keyboard matrix. For a game that let you control some character, choice 3 was probably what was being used because you don't have to consider the repeat key function which prints a character, delays, then starts repeating. By writing their own code, or calling a BIOS routine, they could react to the input and loop back around to the keyboard routine.

 

What probably happened was the coder was using his own routine to read the keyboard matrix registers directly, and through some fault of GW BASIC's code, the Numpad 5 key caused the GW-BASIC code to not have had a check for that key, so at that level of code (machine code), it likely "fell through" to the routine below it. That routine below it might have been a subroutine that was called, and when you call a subroutine, at the end of the routine you return from it with an RTS opcode. Since the routine that GW-BASIC fell through to wasn't ever called, when it hit the RTS, it returned from the last call it had, which was the invoking of GW-BASIC, so DOS took it as a que to return to DOS.

 

I'm not saying that's what happened, but it's one possible explanation for why that happened. Usually when a program dumps you to a DOS prompt, that's what happened, the program got off track and encountered a return without a call which would return you to DOS. There's probably 100 other explanations as to why it was happening, but without disassembling GW-BASIC, I couldn't say for sure.