I have just exchanged the CPU to an AMD D8088 and there is no difference, meaning that the hang is related to something other than the undocumented POP CS.

Could it be related to the BIOS, maybe ? How about using GlaBIOS or Super PC/Turbo XT BIOS ?

Qix existed as a PC booter, too.
http://nerdlypleasures.blogspot.com/2013/04/t … ng-machine.html

So maybe your copy was being "ported" to MS-DOS by a person who had a PC clone with a non-100% IBM compatible PC BIOS ?

It's just a wild guess, of course.

Something like this happened once with some text-adventure, though, I vaguely remember.
The inofficial (?) DOS port didn't work on an IBM compatible PC.

If you just wanna play that kind of game then there's one called Antix or Antixonix, which may have been written in Eastern Europe so may be more favorable to Russian clone CPUs.

edit: I believe it's actually shareware, but can't find a clean vogons friendly site to link it from.

I have tried Russian Antix yesterday, and it works. For Qix, I'll maybe order the original game, or get a img to play on a Gotech. There is
another variant called Styx, but it didn't work the first time. I'll give Styx another go and see if setting CGA through vinstall works.

For the BIOS, I haven't decided whether to change it or to keep it to original. Perhaps, I should install a Gotech to get other games working
too, especially if they only work on DOS 2x.

tjenjic386 wrote on 2024-03-11, 10:46:

At some point I was trying to run Qix through a debugger and trace the execution, but then the screen reverts to the debugger
with endless scrolling.

I'm not sure exactly what you mean by endless scrolling - did something go wrong with the debugger, or did it just keep executing instructions? In the latter case, I guess that what we perceive as a program hanging generally doesn't involve execution of instructions literally stopping, it's normally just stuck in some kind of loop where it's not processing input or not updating output. If there was some kind of debugger problem due to the way the game works, perhaps you could try debugging over a serial connection where you run a small stub on the 5150 and the debugger runs on another machine.

When doing single step using for a certain amount of instructions, the screen of the debugger starts rolling vertically at some point and
the debugger stops executing with the keyboard not responding. The debugger is Microsoft Codeview 2.2.

tjenjic386 wrote on 2024-03-17, 00:17:

When doing single step using for a certain amount of instructions, the screen of the debugger starts rolling vertically at some point and
the debugger stops executing with the keyboard not responding. The debugger is Microsoft Codeview 2.2.

I looked up the documentation for Microsoft C/C++ 7 and it says "Microsoft CodeView versions 4.00 and later support remote debugging." There's probably a good chance that that version of CV wouldn't run on your machine, but maybe the remote debugging stub would - I couldn't find any information about what its requirements were. All I found was some information about what you have to do if you want to run CV on a 286 host; if it can run on a 286 host, maybe the target stub can run on your 5150?

It looks like setting it up might be challenging though - the documentation seems to talk about a lot of .ini file editing.

Another option would be to use Turbo Debugger. From checking manuals, versions 1.0 and 2.0 both support remote debugging. From a quick skim of the 2.0 manual I didn't find any CPU requirement but I did see mention of what to do if you're running DOS 2.0 which seems to be a good sign that it's requirements aren't that high. The 1.0 manual is Copyright 1988 so I suspect it isn't too new to support your machine! Also I didn't notice anything about having to edit .ini files 😁

I'm now using Turbo Debugger 1.0 and I must say that it's far better than CV. The remote debugging feature didn't help much
because the program is unable to load necessary files for startup (486 Zenith laptop connected to COM2). Most of the program
seems ok with each interrupt having no errors, but problems occur when it starts to load and execute 'main.dat' (qix.exe). By
modifying ax to 0x4b01, the interrupt returns without error, but the following code expects the executable to be in memory or
running, and then terminates it. A hard reset is needed each time it tries to execute main.dat, and the screen is blank. I'll give some
other tries to see what happens if I remove int 19h from 'main.dat' because when that executes, it starts to read the floppy drive A,
and if no disk is found, it resets the machine, or I'll investigate more on the Zenith.
A bit time consuming, but I'm getting somewhere 😀

tjenjic386 wrote on 2024-03-21, 02:42:

The remote debugging feature didn't help much
because the program is unable to load necessary files for startup

Does the debugger on the host want to load the executable into its own memory and view that rather than read from memory on the target? It seems like that wouldn't work very well if there was any self-modifying code!

I think there are lots of other debuggers out there you could try, e.g. https://www.bttr-software.de/products/insight/, or SoftICE by Numega (an old commercial one). Possibly others won't be any better for your use case, but I seem to remember SoftICE was always meant to be the best.

Good luck!

The debugger seems it was running from the targets memory. All of the output was displayed on the target machine. The only thing that didn't
work was changing the current directory to the games directory within the debugger.

Insight has been transferred and it successfully traces the program when main.dat loads. The failing instruction is when it performs
an in ax, dx operation with dx equals 40h. I wrote a small program that tests the addresses 41h, 42h (reads), and they return successfully.
But when it reads 40h, the machine hangs. When I got the machine, I replaced the oscillator crystal, but then decided to put the original
back. Some plastic from the potentiometer fell, but shouldn't be the problem because I haven't touched it, just fell off while I was puttting
the motherboard back. There is one contact that is a bit messy and not the best soldering with a bit of flux around it. Tried to fix that today
no results because the solder wouldn't go in. Then, I have done a mainboard test with checkit, and all tests pass. System benchmarking
didn't show any difference.

The oscillator crystal is solid on the board, the machine boots without errors and no abnormalities. I may try landmark system tester
tomorrow to see if it fails at anything. I think there is a small issue with the 8253 controller.

Yes the landmark sreports a faulty 8253 timer. Channels 0 at address 40h is a problem. Landmark freezes when doing a system board test. The interrupt and DMA are working.