wrote:wrote:Also, thanks for posting those drivers.
I take it that they worked for you?
Unfortunately I won't get a chance to test them for at least a few days, as I just moved and my computer is currently in pieces on the floor of my new apartment.
All SCI interpreters have to support vectors, because the priority and control maps are stored as vectors, even though the image data may be stored as pixels.
Ah yes, that's right. I actually wrote an SCI interpreter once. Should've thought of that.
I am sure MobyGames is unreliable as far as the Amiga release years are concerned. It lists KQ4's Amiga version as released in 1988, when the Amiga version's own copyright string reads 1990. I think they wouldn't have put "(C) 1990 Sierra On-Line, Inc." in the game's logo screen if they really released in 1988...
KQ4 slipped quite a lot. I checked the old game catalogs and the 10th anniversary edition lists KQ4/Amiga as 2nd qtr, a reprint of the same catalog then lists it as 4th qtr. And a "Sierra Magazine" for Spring 1990 again mentions 2nd qtr. So it's slipped at least 2 years. (Wow!)
> On a VGA, yes. On a CGA, since the palette selection bit in port 0x3d9
> is inactive if the monochrome bit is set in port 0x3d8 (which it is in
> mode 5), you get a low-intensity cyan/red/gray with a blue background.
Is this cga driver file available somewhere? And did it produce
the c/r/gray palette on a real cga system as well?
> but because I had written a Tandy DAC emulator
Did you hook int1a and use the soundblaster interface then?
Tried the same for dosbox, but am not sure about frequency
translation, maybe you still have the program available.
wrote:It's also possible that you had your Sound Blaster set to IRQ 5; SQ3's SNDBLAST.DRV only works with IRQ 7.
I don't have SQ3's original SNDBLAST.DRV, but I used KQ1SCI's and it seems to behave in the same way - it crashed when I set DOSBox's SB to IRQ5 (and DOSBox crashed with it). Using the BLASTER2.DRV driver I mentioned earlier didn't cause the crash and both KQ1SCI and SQ3 worked fine with IRQ5. Now that I think of it, I didn't encounter this problem in any other Sierra game except KQ1SCI when I used a real SB set on IRQ5 in the past. Are there any other Sierra games that use this problematic driver except KQ1SCI and SQ3?
Incidentally, both SNDBLAST.DRVs from spacequest.net work with IRQ5, even though only one of them is supposed to according to what's written on that page.
wrote:wrote:For some reason, I have a driver called BLASTER2.DRV in my 1.0P copy, and it works fine in 1.0P and in 1.018. I haven't seen this driver anywhere else, did you encounter it?
That one could be downloaded from Sierra's BBS. It wasn't shipped with the game.
Oh, so it's really an official Sierra driver? I figured it was a custom made driver, just like your MTBLAST.DRVs, because I never seen it anywhere else. Like I said above, it works even with IRQ5, and it's also compatible with KQ1SCI, so it's a superior driver to the original SNDBLAST.DRV.
wrote:wrote:Apparently, neither emulator has a proper support for this device (in DOSBox it even causes the game to freeze right after Roger jumps from his pod).
Correct.
So, that's another thing for the devs 😀
wrote:wrote:Are you sure that's the palette produced by using CGA320C.DRV in this version of KQ4SCI?
On a VGA, yes. On a CGA, since the palette selection bit in port 0x3d9 is inactive if the monochrome bit is set in port 0x3d8 (which it is in mode 5), you get a low-intensity cyan/red/gray with a blue background. See picture.
I was also able to achieve the palette that your picture shows with v1.006.003 if I used the driver CGA320B.DRV (and on VGA it looked like Great Hierophant's picture), so I believe this early version of KQ4SCI simply includes the CGA320B.DRV but it's named CGA320C.DRV. So, perhaps if you'll use CGA320C.DRV from later versions of KQ4SCI, v1.000.111 will also look like other SCI games look with this driver?
wrote:Not if you're using DosBox, while I used MESS to take that screenshot. The driver is the same; DosBox honors the palette select bit of port 0x3d9 even when the monochrome bit of port 0x3d8 is set; MESS doesn't, neither does the real CGA as far as I have observed.
Like I said above, all SCI games look like that with the CGA320B.DRV driver under MESS. But it doesn't make sense that this is how they're supposed to look on a real CGA - this driver was designed so these games will look like AGI games (i.e., red/brown/green/blue) on a CGA, so how come they look like that only on VGAs?
BTW, if the palette that MESS displays when using the CGA320B.DRV driver is really how it should look on a real CGA, then that's another thing that should be fixed in DOSBox's CGA emulation.
wrote:wrote:so they didn't actually "add" SB support, they just added the driver.
That's what SB support usually means.
Let me rephrase that - Sierra didn't improve the samples of SQ3 for the 1.018 release, nor did they add any new samples, they just added the driver. Correct?
BTW, SQ3 was the first Sierra game that included sampled speech, right?
wrote:Some spelling corrections,
Do you mean like with the "Lite Speed" thing?
the ADL driver was improved (compare how the first note sounds in 1.018 and 1.0P), and the game waits for the title screen music to finish before starting the "pod fly-by" sequence.
This "waiting" is not controlled by the ADL.DRV, though. Even if the driver is taken from 1.018, 1.0P still doesn't "wait".
wrote:wrote:I remember there was also version 1.052, what's the deal with that?
German version.
Someone who calles himself HWM made this exhaustive list about the different versions of the Sierra games, and he claims that SQ3 1.052 is a German/English version rather than a pure German version. But what's weirder than that, he puts this specific version of SQ3 in the same interperter category with QFG2 (what he calles SCI01 😁), and he also puts LSL3 v1.050 and KQ1SCI in this category. I thought that the only SCI1 game that uses a parser is QFG2.
wrote:But yes, I have tried it --- not because I have a real Tandy SL/TL, but because I had written a Tandy DAC emulator, originally written for the original SimCity game, which works nice with SQ3's TANDY.DRV as well (to my surprise, I have to admit) --- just the samples, of course, not the PSG music.
Do you still have this emulator? Perhaps it can be incorporated into DOSBox (like wd implied above), so it can start supporting this Tandy SL/TL.
Can you attach it here by the way? I'd like to listen to the SQ3 sample as there were originally intended to be heard.
By the way, your timer-bug patch for SQ1VGA contains SNDBLAST.DRV, and if I'm not mistaken, your other patches doesn't. What's this specific SNDBLAST.DRV is supposed to fix?
wrote:> On a VGA, yes. On a CGA, since the palette selection bit in port 0x3d9 > is inactive if the monochrome bit is set in port 0x3d […]
> On a VGA, yes. On a CGA, since the palette selection bit in port 0x3d9
> is inactive if the monochrome bit is set in port 0x3d8 (which it is in
> mode 5), you get a low-intensity cyan/red/gray with a blue background.Is this cga driver file available somewhere? And did it produce
the c/r/gray palette on a real cga system as well?
From what I know, this older CGA320C.DRV works just like the CGA320B.DRV driver, so use it instead, unless I'm wrong (I attached it).
wrote:o, perhaps if you'll use CGA320C.DRV from later versions of KQ4SCI, v1.000.111 will also look like other SCI games look with this driver?
Well, just try it...
wrote:this driver was designed so these games will look like AGI games (i.e., red/brown/green/blue) on a CGA
I don't think it was "designed" either way --- they just hacked together something. The early CGA320BW.DRV also tries to change the background color, which is definitely not possible on a real CGA in mode 6. So forget about this "designed for" stuff --- having suffered through patching Sierra's code, I think it's fair to say that Sierra never "designed" anything code-wise; they just bounced some code into their keyboards, and if it sorta-kinda worked, they'd just release it and fix it later (which they did with the later CGA320C drivers).
wrote:Sierra didn't improve the samples of SQ3 for the 1.018 release, nor did they add any new samples, they just added the driver. Correct?
Um-hm.
wrote:Do you mean like with the "Lite Speed" thing?
I've never ever seen a version of SQ3 that says "Lite Speed". It's just something people who "remember" something keep bringing up.
wrote:This "waiting" is not controlled by the ADL.DRV, though.
No, it's controlled by the script code, of course.
wrote:and he claims that SQ3 1.052 is a German/English version rather than a pure German version.
It certainly is. All of Sierra's early foreign versions are bilingual, so I don't point that out each time.
wrote:he puts this specific version of SQ3 in the same interperter category with QFG2 (what he calles SCI01 ), and he also puts LSL3 v1.050 and KQ1SCI in this category
He's probably going off the FreeSCI homepage, which is wrong and hasn't been updated in ages.
wrote:Do you still have this emulator?
Yes. Maybe I'll upload it later; I don't have it on this computer.
wrote:I'd like to listen to the SQ3 sample as there were originally intended to be heard.
It doesn't sound any different... why would you think so? Or do you just want to have a fuzzy feeling hearing the same sample you heard with SNDBLAST.DRV from the "TANDY.DRV"?
wrote:By the way, your timer-bug patch for SQ1VGA contains SNDBLAST.DRV, and if I'm not mistaken, your other patches doesn't. What's this specific SNDBLAST.DRV is supposed to fix?
It just has the GoSierra-type modifications already applied.
wrote:this older CGA320C.DRV works just like the CGA320B.DRV drive
I've never seen an original, non-pirated release that actually included a CGA320B.DRV. My guess is that some hacker just collected all drivers he found, including the two different CGA320C.DRVs, and dumped them into the Jones/KQ5 directory, renaming the older CGA320C to CGA320B.
wrote:Did you hook int1a and use the soundblaster interface then?
Tried the same for dosbox, but am not sure about frequency
translation
Playback sampling rate = 3579545 / DX, according to Ralph Brown's Interrupt List. At least that's the formula I use. If you have a reason to believe that this is not correct, then I'm wrong and therefore have nothing to bring to the table either.
wrote:wrote:Do you mean like with the "Lite Speed" thing?
I've never ever seen a version of SQ3 that says "Lite Speed". It's just something people who "remember" something keep bringing up.
No, it isn't. I just found that I still have this version (5.25" floppies only -- haven't got the rest of the package). First time I played it, I was just a kid and didn't understand what they meant by it.
I'll try to get a screenshot of it once I find a way to get it off the only PC I have that has a 5.25" floppy drive.
According to this page:
http://www.spacequest.net/sq3/funfacts/
An early release of Space Quest 3 is somewhat different. One obvious difference is that the Aluminum Mallard's cockpit computer had the option "Lite Speed" instead of "Light Speed" as seen in later versions.
How they heck could you not understand Light Speed? Isn't it obvious? heh.
wrote:How they heck could you not understand Light Speed? Isn't it obvious? heh.
I would've understood "light speed", but "lite speed" is not obvious to an 8 year old who's only just learning English.
wrote:No, it isn't. I just found that I still have this version (5.25" floppies only -- haven't got the rest of the package). First time I played it, I was just a kid and didn't understand what they meant by it.
I'll believe it when I see it. Looking forward to your screenshot... make sure you also tell us the game's version number (select "About" from the menu bar).
> So, that's another thing for the devs
Why don't you fix it yourself and commit a patch?
> BTW, if the palette that MESS displays when using the CGA320B.DRV
> driver is really how it should look on a real CGA, then that's
> another thing that should be fixed in DOSBox's CGA emulation.
Up to now i haven't seen any information that proves that
dosbox displays the wrong palette.
cga320b is the same as cga320c besides some text string.
> Playback sampling rate = 3579545 / DX, according to Ralph Brown's
> Interrupt List. At least that's the formula I use. If you have a
> reason to believe that this is not correct, then I'm wrong and
> therefore have nothing to bring to the table either.
Dunno, i used the values from the intlist as well but i don't
know how it should sound, i assume it's correct.
Not to get off the subject, but I have a question. CGA monitors generally underscanned the image, leaving black borders on the sides of the image. In text modes, the CGA allowed the programer to change the border color, but I have never seen a provision in the graphics modes, at least for IBM's card. In most cases it wasn't a big deal because the background was black most of the time and who could tell where the border began and the background ended. But Sierra's AGI games used a blue background when shown on an RGB color monitor. Is the border also blue or is it black on a true IBM CGA connected to an RGB monitor?
wrote:wrote:o, perhaps if you'll use CGA320C.DRV from later versions of KQ4SCI, v1.000.111 will also look like other SCI games look with this driver?
Well, just try it...
Gladly, just tell me where to get this specific version.
wrote:wrote:By the way, your timer-bug patch for SQ1VGA contains SNDBLAST.DRV, and if I'm not mistaken, your other patches doesn't. What's this specific SNDBLAST.DRV is supposed to fix?
It just has the GoSierra-type modifications already applied.
Figured that. I just thought there may be something different in this case since you didn't add this driver to your other patches even though those games require it too.
wrote:I've never seen an original, non-pirated release that actually included a CGA320B.DRV. My guess is that some hacker just collected all drivers he found, including the two different CGA320C.DRVs, and dumped them into the Jones/KQ5 directory, renaming the older CGA320C to CGA320B.
Yeah, that make sense. maybe that's why Sierra's later Installation programs, the ones that actually require recognizable drivers (like v3.681), do not work if this driver is present because they don't recognize it. However, these installation programs also does not recognize BLASTER2.DRV, and according to what you said this one is an official Sierra driver.
wrote:> So, that's another thing for the devs
Why don't you fix it yourself and commit a patch?
I'd be happy too, but I've never even seen a real Tandy. This fix does not seem that important anyway, at least not for the Sierra games.
wrote:Up to now i haven't seen any information that proves that
dosbox displays the wrong palette.
cga320b is the same as cga320c besides some text string.
Note that only versions 0.90 or later display this palette. Versions 0.89 and earlier behave just like DOSBox. From what I know, MESS's CGA emulation was improved from 0.89 to 0.90 (before 0.90, MESS also showed the palette of the regular CGA320C.DRV wrong; I wrote about it in a post in page 8 of this thread; just scroll down and look for the SQ3 screenshots 😀)
By the way, when I switched to fullscreen in DOSBox's composite mode I noticed that there's a certain "fuzziness" to the image, while in MESS the image is more sharp. I'm not talking about color palette differences or the blurriness of the text, just the general appearance of the image. Compare these screenshots, while ignoring the color differences: (I hope it's noticeable in these screenshots, cause like I said, I only noticed it in full screen)
DOSBox CVS (aep October 16)
MESS 0.101
wrote:By the way, when I switched to fullscreen in DOSBox's composite mode I noticed that there's a certain "fuzziness" to the image, while in MESS the image is more sharp. I'm not talking about color palette differences or the blurriness of the text, just the general appearance of the image. Compare these screenshots, while ignoring the color differences: (I hope it's noticeable in these screenshots, cause like I said, I only noticed it in full screen)
The fuzziness is supposed to be there. It is inherent to the way composite mode works. This was only recently introduced in DOSBox. Check out Qbix' KQ1 screenshots on the very first page of this thread.
About SQ3: the 5.25" version I have is a standard 1.0P. I found the source of my childhood confusion, though. The "lite speed" I read about is in a very dodgy unofficial hintbook (consisting of a few typewritten, then photocopied pages, albeit with some really nice cover art), bought from an equally dodgy software store in Kuala Belait, Negara Brunei Darussalam (where I was living at the time). The hintbook (more of a walkthrough, actually) is riddled with typos and grammatical errors. The sentence in question is one of the more readable ones anyway: "I recommmend (sic) you use the "lite speed" whenever he (sic) is availible (sic) as he (sic) will save you a lot of time".
wrote:just tell me where to get this specific version.
abandonware-france.org
wrote:I just thought there may be something different in this case since you didn't add this driver to your other patches even though those games require it too.
I just haven't uploaded the others yet.
wrote:However, these installation programs also does not recognize BLASTER2.DRV
It doesn't recognize JR.DRV, TANDY.DRV, CSM1.DRV either (at least not with that name), presumably because those later games that have the color install program don't include these drivers.
wrote:Kuala Belait, Negara Brunei Darussalam (where I was living at the time)
The rumor seems to be quite widespread though, so does everyone shop at this Koala Niagara Barefoot Jerusalem store? 😉
> Note that only versions 0.90 or later display this palette. Versions 0.89 and
> earlier behave just like DOSBox. From what I know, MESS's CGA
> emulation was improved from 0.89 to 0.90 (before 0.90, MESS also
> showed the palette of the regular CGA320C.DRV wrong; I wrote about
> it in a post in page 8 of this thread; just scroll down and look for the
> SQ3 screenshots)
Just because MESS improved the CGA emulation doesn't mean it
is correct now. I still have NO prove that dosbox is wrong.
I compared King's Quest IV in DosBox (I used a CVS version circa mid october) and on my CGA card, and DosBox does use the wrong colors for this; it should be blue-white-red-cyan, DosBox displays as blue-brown-red-green. A screenshot is below from a CGA card (this was done with a digital camera, so it's not too great but at least it can be seen somewhat clearly). Comparing the CGA320C.DRV to CGA320B.DRV I couldn't see any difference in DosBox or on the CGA card.
Not to get off the subject, but I have a question. CGA monitors generally underscanned the image, leaving black borders on the sides of the image. In text modes, the CGA allowed the programer to change the border color, but I have never seen a provision in the graphics modes, at least for IBM's card. In most cases it wasn't a big deal because the background was black most of the time and who could tell where the border began and the background ended. But Sierra's AGI games used a blue background when shown on an RGB color monitor. Is the border also blue or is it black on a true IBM CGA connected to an RGB monitor?
The border is blue to match the background; similar to the screenshot below.
By the way, when I switched to fullscreen in DOSBox's composite mode I noticed that there's a certain "fuzziness" to the image, while in MESS the image is more sharp. I'm not talking about color palette differences or the blurriness of the text, just the general appearance of the image. Compare these screenshots, while ignoring the color differences: (I hope it's noticeable in these screenshots, cause like I said, I only noticed it in full screen)
As was mentioned, an amount of fuzziness is intentional; CGA composite mode just looked like that. But could it also be the algorithm used to scale to full screen? With MESS at least, depending on what settings I use the full screen graphics can be either reallly fuzzy or very sharp. Are you comparing two different scaling algorithms with DosBox/Mess ? Between the two shots shown at least the DosBox CVS one looks much closer to a real CGA.
For Sierra SCI install programs, if it doesn't recognize a driver name you can edit (or add a) install.hlp file; a snippet of such a file would look like:
\\std.drv
IBM PC or Compatible Internal Speaker
\\ VIDEO DRIVERS
\\vga320.drv
VGA or MCGA - 320x200 256 Colors
\\vga320.hlp
This selection works with any card and monitor
that claims VGA compatibility. You must have a VGA
card and a VGA or multisync monitor. This selection
will allow 256 colors with 320 x 200 pixel resolution.
\\vga320bw.drv
VGA or MCGA - 320x200 Grey Scale
\\vga320bw.hlp
This selection works with any card that claims
VGA compatibility and a monochrome VGA monitor.
You must have a VGA card and a VGA monitor.
This selection will allow 256 shades of grey with
320 x 200 pixel resolution.
\\ega320.drv
EGA/VGA - 320x200 16 Colors
\\ega320.hlp
This selection works with any adaptor that claims
hardware compatibility with an IBM Enhanced Graphics
Adaptor.
\\ega640.drv
EGA/VGA - 640x200 16 Colors
\\ega640.hlp
This selection works with any adaptor that claims
hardware compatibility with an IBM Enhanced Graphics
Adaptor.
.
.
.
and so on for each driver needed....
Editing/adding this file has worked for me in my minimal hacking...also with drivers I had to download from Sierra an additional text file was included; I think it was something of the format drivername.hlp, which was basically the same thing as the install.hlp file and allowed the install program to recognize the new driver.
Thanks for the screenshot, changed it so the B/W bit
alone selects the alternative palette.
The screenshot answered my border question. I can say in the 320 graphic modes, if you change the background color you change the border to the same color as well. In the 640 graphic modes, since you can't change the background color (its always black), the border will always be black too.
wrote:wrote:o, perhaps if you'll use CGA320C.DRV from later versions of KQ4SCI, v1.000.111 will also look like other SCI games look with this driver?
Well, just try it...
I did, and apparently it does work - when I replaced v1.000.111's CGA320C.DRV with v1.006.003's, the familiar white/red/cyan palette of CGA320C.DRV was displayed. However, I did find color differences between the two versions in this palette, even though they were using the same driver. Compare (note how some things which are red in the upper picture, are actually black on the bottom picture):
v1.006.003
v1.000.111
I don't know why this difference is there, but it probably has nothing to do with the driver.
By the way, seeing that the river is red when using the newer CGA320C.DRV, makes me think that the one from KQ4 v1.000.111 is actually better, because when it's used at least the river is blue.
I noticed that v1.000.111 has RESOURCE.009, while v1.006.003's last RESOURCE file is 008, making the total size of the game smaller. Does the earlier version really use the 9th resource?
wrote:As was mentioned, an amount of fuzziness is intentional; CGA composite mode just looked like that. But could it also be the algorithm used to scale to full screen?
What do you mean by that? Do you mean only in MESS or also in DOSBox?
With MESS at least, depending on what settings I use the full screen graphics can be either reallly fuzzy or very sharp.
Can you tell me what exactly did you change in MESSUI.INI to achieve this effect?
Are you comparing two different scaling algorithms with DosBox/Mess ? Between the two shots shown at least the DosBox CVS one looks much closer to a real CGA.
No, because I didn't think it'll make a difference. Besides, I wouldn't really know what to change in DOSBOX.CONF and MESSUI.INI. I think I just used default settings.
I noticed another weird behavior in DOSBox, this time in VGA mode. It appears that in some games, like Spellcasting for example, DOSBox displays the game in "widescreen" - the screen's aspect ratio is wrong and there are black bars in the top and bottom of the picture, just like in a DVD widescreen movie (note that these black bars cannot be captured in a screenshot in DOSBox because they're not really part of the picture). When the same game is loaded with CGA graphics, the aspect ratio is correct. Here are screenshot for comparison from Spellcasting 201, taken when machine=vga (it happens in all DOSBox versions, btw):
That spellcaster widescreen issue may be because the games are running in something like 640x200 and you don't have aspect-correct stretching enabled.
