Nice work! I have dabbled with reverse engineering the SCI video drivers in the past and worked out the general layout but didn't know what all the functions were for. This is a really good reference for if anyone wants to write a future driver. I was previously thinking of making a driver to support the 640x400 monochrome mode from the Olivetti M24 as mentioned here. I have an old Toshiba T1000SE laptop which supposedly supports this mode on its monochrome LCD screen and could potentially have a better dithered mode than the stock 640x200 monochrome mode. Unfortunately I can't get the machine to switch on any more but if I ever get it working again then I might come back to this.

I suppose a 160x200 CGA composite mode would also be possible (looking like the AGI games) but text would probably be unreadable!

jhhoward wrote on 2020-09-04, 13:18:

I was previously thinking of making a driver to support the 640x400 monochrome mode from the Olivetti M24 as mentioned here. I have an old Toshiba T1000SE laptop which supposedly supports this mode on its monochrome LCD screen and could potentially have a better dithered mode than the stock 640x200 monochrome mode.

The same code base would also be useful for an alternative Hercules driver with 640x400 pixels and interlacing. The four monochrome pixels would result in 16 unique patterns with five average brightness levels.

jhhoward wrote on 2020-09-04, 13:18:

I suppose a 160x200 CGA composite mode would also be possible (looking like the AGI games) but text would probably be unreadable!

It would definitely be possible, but the text would indeed be unreadable.

There is now a second driver in the repository, namely for the Sigma Designs Color 400. Its 320x200 pixel 16-color mode is very similar to that of the Plantronics ColorPlus.
The second CGA page for the additional bits per pixel is handled a bit differently, but that is the only significant difference.

jhhoward wrote on 2020-09-04, 13:18:

Nice work! I have dabbled with reverse engineering the SCI video drivers in the past and worked out the general layout but didn't know what all the functions were for. This is a really good reference for if anyone wants to write a future driver. I was previously thinking of making a driver to support the 640x400 monochrome mode from the Olivetti M24 as mentioned here. I have an old Toshiba T1000SE laptop which supposedly supports this mode on its monochrome LCD screen and could potentially have a better dithered mode than the stock 640x200 monochrome mode. Unfortunately I can't get the machine to switch on any more but if I ever get it working again then I might come back to this.

I suppose a 160x200 CGA composite mode would also be possible (looking like the AGI games) but text would probably be unreadable!

Someone actually wrote an Olivetti M24 640x400 monochrome mode SCI driver, years ago! I believe it was some Swedish guy. If I remember correctly, he offered it as shareware at first, but released it as freeware later. I remember finding it while browsing the internet. I had it on a 3.5" floppy that unfortunately became corrupt. I remember trying to find that driver again, but I couldn't find it any more. 😞

However, I do remember being disappointed about the fact that I didn't notice any improvement in picture quality over the 640x200 CGA monochrome driver that Sierra shipped with their SCI games. At least that was the case with Quest for Glory I. Perhaps the dithering algorithm in that driver just wasn't well optimized?

digger wrote on 2020-09-04, 20:48:

Someone actually wrote an Olivetti M24 640x400 monochrome mode SCI driver, years ago! I believe it was some Swedish guy.

Anders Olsson. 😀

The Olivetti/AT&T driver you're referring to is included in an archive of files that he sent me several years ago:
http://www.symphoniae.com/elw/sierrautil.zip

Interesting!

Now that I think about it, the memory models of the M24 640x400 monochrome mode and the 320x200 16-color Plantronics mode are actually quite similar.
The second and third line in every group of four lines are swapped, but you would still get a somewhat sensible picture. Let me try something...
EDIT: I must be running into some sort of bug somewhere. Using the same driver code with mode 40h will just fill the screen with complete garbage.

Cloudschatze wrote on 2020-09-04, 21:11:

Anders Olsson. :) […]
Show full quote

digger wrote on 2020-09-04, 20:48:

Someone actually wrote an Olivetti M24 640x400 monochrome mode SCI driver, years ago! I believe it was some Swedish guy.

Anders Olsson. 😀

The Olivetti/AT&T driver you're referring to is included in an archive of files that he sent me several years ago:
http://www.symphoniae.com/elw/sierrautil.zip

Yes! 😄 AT320, that is indeed the driver I thought had been lost to time. Thanks for sharing!

However, like I said earlier, I remember not noticing any improvement in quality with this driver over the CGA 320x200 monochrome driver, at least in Quest for Glory I. But perhaps others here can try it again, testing it with more Sierra SCI games?

Really cool to see this open source driver!

Going back to the discussion about scrolling screens not playing nice with certain drivers, is there any way to improve the existing SCI drivers (hercules monochrome, CGA monochrome, and CGA 4 colour drivers) to support or at least ignore scrolling screens? Right now they all seem to crash games that use them like KQ1SCI, SQ4EGA, KQ5EGA, LSL5EGA, LSL1SCI EGA, SQ1SCI EGA, MUFTEGA, PQ3EGA, and Castle of Dr Brain EGA. Playing around with these games with some of the older drivers and they work nicely but they just freeze up the system/DOSBox when a scrolling screen call is made. Is something like this feasible?

Yes, there is a way to fake the scroll function.

You basically have to append an entry to the jump table and append a wrapper function that updates the screen.
I have already done that for the PC1512 driver and described the modifications in the relevant thread.

The CGA monochrome driver should not need any such modification, provided that you have the correct version.
IIRC, KQ1 comes with a CGA monochrome driver.

Benedikt wrote on 2020-09-22, 15:42:

Yes, there is a way to fake the scroll function. […]
Show full quote

Yes, there is a way to fake the scroll function.

You basically have to append an entry to the jump table and append a wrapper function that updates the screen.
I have already done that for the PC1512 driver and described the modifications in the relevant thread.

The CGA monochrome driver should not need any such modification, provided that you have the correct version.
IIRC, KQ1 comes with a CGA monochrome driver.

and ofcourse I missed that!!!
I will test!

Benedikt wrote on 2020-09-22, 15:42:

Yes, there is a way to fake the scroll function. […]
Show full quote

Yes, there is a way to fake the scroll function.

You basically have to append an entry to the jump table and append a wrapper function that updates the screen.
I have already done that for the PC1512 driver and described the modifications in the relevant thread.

The CGA monochrome driver should not need any such modification, provided that you have the correct version.
IIRC, KQ1 comes with a CGA monochrome driver.

I'm talking about the 4-colour CGA drivers. They work but crash on the screen scrolling calls. I don't suppose it'd be as simple as using those same directions to hexedit those drivers?

MusicallyInspired wrote on 2020-09-23, 22:24:

I'm talking about the 4-colour CGA drivers. They work but crash on the screen scrolling calls. I don't suppose it'd be as simple as using those same directions to hexedit those drivers?

Not quite but almost.
You'd have to do the same thing, semantically. The exact offsets within the file will obviously differ.
Basically, a disassembler listing of the driver and my source code as reference is all you need.
The only slightly tricky part is that you have to manually calculate the destination offset of the jump instruction in the wrapper function.

What tool do you recommend for disassembling Sierra DRV driver files? (I don't know what I'm doing, this is semi-brand new territory but I'm eager to try)

Pretty much any disassembler will do, because the DRV files are just raw binary files, but Sourcer 8 (abandonware) seems ideal.
It is a commenting disassembler that adds annotations for port numbers, BIOS calls etc.
Ghidra (the NSA's open sourced disassembler/decompiler) should also work. It is really cool, but not necessarily for this use case.
I'm sure that IDA Pro would also be fun to work with... if you're rich.

There's a freeware version of IDA.

Interesting. I was aware of the existence of a free-for-non-commercial-use version, but it seems to have become less limited than it used to be.
I guess they feel the FOSS competition from Ghidra. So yes, this version of IDA is adequate, as well.

Incidentally, I have been able to test the PCPLUS driver with KQ5EGA, in the meantime.
Everything works as intended!
That means that the list of presumably compatible titles grows quite a bit longer.

I thought the latest *free* versions of IDA dropped support for 16-bit DOS code (although it should still be available in the paid version, of course).

At least that's the case according to https://www.scummvm.org/news/20180331 - this page still has a link to the older free version of 5.0, so you can try that. I've used it myself for years and never needed more than the free version offers.

VileR wrote on 2020-09-25, 22:08:

I thought the latest *free* versions of IDA dropped support for 16-bit DOS code (although it should still be available in the paid version, of course).

Version 7 does apparently support 16-bit DOS code, but no DOS EXE files. It does not matter in this particular case, because SCI drivers are raw binary files, but it can otherwise be a bit annoying.
Ghidra is still a viable and most importantly free option, but it will not annotate port numbers or BIOS interrupts.

This, by the way, is a screenshot of KQ5 with the PCPLUS driver:

I can confirm that your Plantronics driver works with the Euro PC in CGA mode. Fantastic job, thanks!

(My self-built CGA-to-SCART adaptor has no brown-fix, so Roger Wilco is blonde in this photo).

You should add a "How to install" section to your GitHub page, I didn't know that it was so simple (copying the file into the game directory and install.exe will detect it automatically), I first thought that I need to replace one of the existing driver files with the new driver.

My version of King's Quest 4 has a different, more modern install.exe setup utilty (the colorful one, version 3.681 dated from 1993). How do I use the driver with that one? It seems that we need to edit the .hlp file(s)?

Benedikt wrote on 2020-09-04, 20:06:

The same code base would also be useful for an alternative Hercules driver with 640x400 pixels and interlacing. The four monochrome pixels would result in 16 unique patterns with five average brightness levels.

Such a Hercules driver would be very interesting as well!

RobertK wrote on 2020-10-15, 06:35:

You should add a "How to install" section to your GitHub page, I didn't know that it was so simple (copying the file into the game directory and install.exe will detect it automatically), I first thought that I need to replace one of the existing driver files with the new driver.

That sounds like a good idea.

RobertK wrote on 2020-10-15, 06:35:

My version of King's Quest 4 has a different, more modern install.exe setup utilty (the colorful one, version 3.681 dated from 1993). How do I use the driver with that one? It seems that we need to edit the .hlp file(s)?

When in doubt, you can always edit resource.cfg, manually. It is a self-explanatory text file.

Hi,

Thanks for all this,

I am interested to disassemble the PC1512 driver and optimize it, I may take a look and optimize these drivers as well, I see plenty of speed improvement that can be done 😀
(As You know, the PC1512 video is slow)
Is there any of these video mode supported by DOSBox ?

FreddyV