Recent content by digger

Ah yeah, AGI games used vector graphics. I didn't even consider that. Indeed, that might make for even more interesting results at 160x100.

Sticking more with the actual topic of this therad: what would also be an idea is to render such AGI games "zoomed", so without any loss of graphical detail, but with everything blown up 2x, with the monitor only showing part of the screen and using this hardware scrolling functionality to...

As an experiment, I took a screenshot from the original King's Quest I from the web, scaled it down with Gimp to half the vertical resolution with interpolation set to "None", and then scaled it back up to its original resolution, again with interpolation set to "None". It looks like the result...

I wonder how feasible it would be to implement an AGI interpreter that would run the earlier Sierra adventure games in this mode. At 160x200, those games had twice the vertical resolution of 160x100x16 CGA, but maybe they'd still be playable.

Hmmm, I found a possible answer here: Interesting. So if I understand correctly, IRQ sharing was employed here, and PS/2 mice apparently use IRQ 1 on the 8086-variant of the Model 30, as opposed to IRQ 12 in later PS/2 models. Ah yes, and these sources appear to confirm that...

I have a question about the 8086-based Model 30. How did it support PS/2 mice when P2/2 mice typically used IRQ12, which wasn't available on 8086 and 8088 systems? Does anybody have a clue? Maybe the use of IRQs in the mouse driver was optional? I remember reading somewhere that the Microsoft...

I think that was going okay when compiling PDPCLIB. That was not the problem I ran into, since there were Makefiles included that already included the "don't provide stdlib" compiler parameter. I just couldn't get it to build an object file that didn't have any 16-bit segment stuff in it. But...

Well, that that didn't work... I'm just going to try porting some driver sources from FreeBSD or Linux and see if I can provide or even implement any stdlib functions that those functions might need. Please let me know if you have any better suggestions. Thanks.

There's PDPCLIB, a Public Domain C runtime library written by Paul Edwards, which should support the Watcom toolchain, and it aparently had an update on SourceForge as recently as 2019, and that seems to fit the bill. It's supports DOS, and is 32-bit safe. I'm trying to build that.

Yes, that's what I had been doing: adding printf statements and comparing the outputs with a hex viewer. But it was still unclear why exactly it failed to load. That's what I ended up doing. And the good news: it worked! In fact, I got it working with both DJGPP and the Open Watcom (v2)...

Good one! Another puzzle piece. I didn't know that Watcom defaulted to its own proprietary calling convention. The C source and header files of the AIL/32 SDK and driver sources have the `cdecl` keyword in all function declarations and definitions. This includes `ail32.h`, which is the driver...

By the way, It's not easy finding on-line examples on how to easily call C functions from assembly code. Most of the examples I find on-line tell you how to do the opposite. I know that calling conventions need to be taken into account, and it appears to differ per assembly dialect and...

Thank you for your useful advice, @Svenska. To give everybody here a bit more context: The AIL/32 drivers are a protected mode variant of the AIL (version 2) drivers developed by John Miles in the '90s. These drivers are meant to be loadable modules for use in a 32-bit protected mode...

Hmmm... One thing I'm running into is that I can't declare forward function pointers, because C compilers are single-pass. For the first forward pointer, which is at the beginning at offset 0, I could calculate this, since it has to point to the memory address just after the copyright message...

Thanks, @pan069. I found about the _Packed keyword in the Watcom documentation. And I tested it by temporarily adding a struct that would normally be padded, and indeed, placing `_Packed` between `typedef` and `struct` indeed had the affect that structs of that defined type would be packed...