Rare SCI Games

[Daventry]

Hi Threepwang
Check your personal email. There is a link to the version you need.

[Threepwang]

@Kawa
Thank you for this explanation. Only here I can get an answer to this kind of question! KGetTime is an amazing feature that I didn't know about. I wonder why this function is only in the first interpreter...

@Collector
I understand now, it makes sense. I have two 0.000.566 sets, but one is dated by your tool from 94 and the other from 96. So I deduce that the one from 94 is version 1.000, while the one from 96 is version 1.001. I use your tool regularly, it is very rich in information on each edition 

*Thanks to @Daventry I have obtained version 1.102. I'm really happy!!

Thanks to all three of you! 

[Kawa]

I wonder why this function is only in the first interpreter...

It's literally not. The specific version of GetTime that only returns one second resolution times with only twelve hours is in SCI0. The version that can also return two seconds twenty-four hour times and dates is in all other later versions, including the later 32-bit high-resolution ones.

Just because it may come up some time:

• Every value in SCI is a 16-bit word (yes even in the 32-bit versions) so GetTime's return value must also be.
• (GetTime 1) returns a packed value where the first/lowest six bits are the seconds (0-63), the middle six are the minutes, and the last/highest four bits are the hours (0-15). This is why it's limited to twelve hours. This is the only option in SCI0.
• (GetTime 2) has five bits for the seconds, and five for hours, so the seconds only go from 0 to 31, which lets you cover a full minute in two-second increments. The hours likewise can now go up to 24.
• (GetTime 3) returns the date as five bits day of the month, four bits month, and seven bits year (0-127), minus 1980.
• Because every function call and such is inherently variadic, SCI0 GetTime ignores any parameter given and just always gives you a 12-hour time, while every other version of SCI will have GetTime assume 1 if you call it without any parameters.
  

To quote the official changelog anno December 9 1989:

Code: [Select]

; print current 12 hour time as in 01:30:22 (assume PM)
 (= tm (GetTime SYSTIME1))
(Printf "%02d:%02d:%02d"
(>> tm 12)
(& (>> tm 6) 63)
(& tm 63)
)

; print current 24 hour time as in 13:30:22
(= tm (GetTime SYSTIME2))
 (Printf "%02d:%02d:%02d"
(>> tm 11)
(& (>> tm 5) 63)
(* (& tm 63) 2)
)

; print current DATE as in 12/09/1989 (only good through 1999)
; years value is number of years since 1980
 (= tm (GetTime SYSDATE))
(Printf "%02d/%02d/19%02d"
(& (>> tm 5) 15)
(& tm 31)
(+ 80 (>> tm 9)) ; you must add 80 to return value
)


[Collector]

@Collector
I understand now, it makes sense. I have two 0.000.566 sets, but one is dated by your tool from 94 and the other from 96. So I deduce that the one from 94 is version 1.000, while the one from 96 is version 1.001. I use your tool regularly, it is very rich in information on each edition 

Note that the date is first derived from its database of known games and if not found then it gets the GetLastWriteTime of the MAP/DIR file based on the idea that the last compile time is probably close to the release date of that version. The tool will indicate if the date was estimated this way.

If I can get back to updating the tool I have it in mind to look for the date in the VERSION, QA, README, etc. files first, then the known game list, then MAP/DIR file date.

[Collector]

I deduce that the one from 94 is version 1.000, while the one from 96 is version 1.001.

No need to guess the version. As I said before you can check it in game.

[Threepwang]

@Collector
Indeed, it's easier

I would like to take this opportunity to ask another question. I would like to know if EcoQuest 1, Game version 1.10, Interpreter version 2.000.286, is a CD version? Does this edition exist or is it a lost version?

SCIWiki: http://sciwiki.sierrahelp.com//index.php?title=EcoQuest:_The_Search_for_Cetus

I have fully translated the CD version 1.1, interpreter version 1.001.064, but I am currently updating, it as there are still bugs inherent to the game, some of which may be difficult to fix. That's why I'm wondering about version 1.10 which is more recent. Thank you for your insight.

[Collector]

I am not sure about that one. That entry comes from HWM's list. He has it listed as a SCI1.1 game, but the interpreter version is SCI2. I'd be very interested in seeing this one to see what is going on with it. The interpreter version would suggest that it is likely MPC, but not absolutely. If you track it down, let me know.

[Kawa]

Huh. An SCI 1.1 game with a 2.0 version number.

Ain't that somethin'.

But then again, the SCI 1.0 releases all had extra funky versions so I don't know what I expected.

[Collector]

It has been a while since HWM has been around. Wish we could ask him what is up with it.

[OmerMor]

According to ScummVm's detection tables, this is a floppy version and it's real:
https://github.com/scummvm/scummvm/blob/ab666139e2904a57c1db30d8f020137acbd1a5a7/engines/sci/detection_tables.h#L618-L624

Code: [Select]

// Eco Quest - English DOS Floppy (reported by misterhands in bug #6599)
// Game v1.10, interpreter 2.000.286, INT #6.12.92
{"ecoquest", "Floppy", {
{"resource.map", 0, "acb10c12bf15ffa7d0fac36124b20c8e", 4890},
{"resource.000", 0, "89cf7c8eed99afd0a9f4188170b81ebe", 3428654},
AD_LISTEND},
Common::EN_ANY, Common::kPlatformDOS, 0, GUIO_STD16 },

[Collector]

But, shouldn't this be referred to as SCI2, or am I missing something?

[Kawa]

If SCI0 is every terp with version 0.000.blank, SCI10 is versions 1.000.blank, SCI11 is 1.100.blank, SCI2 is 2.000.blank, SCI21 is 2.100.blank, and SCI3 is 3.000.blank, it'd be easy to say this should be referred to as SCI2.

But it's not that easy, I think, and it may confuse one to believe EcoQuest 1 had a 32-bit release, since SCI 2.000 and later refers to a 32-bit interpreter in all but this one case and I can't see how or why this would be an SCI32 game.

And of course it's not as straightforward as I implied at the start of this post. I left out SCI01 because that's version S.OLD.blank. And EcoQuest specifically has 1.ECO.blank, as seen on that wiki page. We don't call those versions "SCIE" any more than we call QFG3's "SCIL" or SQ4's "SCIS" -- we call them SCI10 and SCI11, right?

So I say this one SCI 2.000.286 is probably an outlier that should still be counted as SCI11 until someone actually finds a copy and confirms otherwise by

(Feel free to read all mentions of SCIxy above as SCI x.y, as you prefer.)

[Collector]

Except there are SCI2+ games that only included a 16-bit executable, i.e. KQ7 or Shivers, both with the 2.100.002 interpreter. Isn't the 32-bit more of a matter of how it accesses the game's data rather than the bit depth of the EXE itself? Remember that many customers back then still commonly had Win3x machines. Then again, I guess they could have used the Win32s runtime.

[Kawa]

Yeah, somehow during the writing of that post I forgot the last bit: "and confirms otherwise by looking at the actual game data, which may or may not actually be entirely SCI11", which I think would be a bigger indicator than the executable's bittage.

[Collector]

Perhaps I should ask on some of the Facebook Sierra groups if anyone has this version.