Community

SCI Programming => SCI Development Tools => Topic started by: OmerMor on June 17, 2016, 07:41:20 PM

Title: Sierra's Internal SCI Tools
Post by: OmerMor on June 17, 2016, 07:41:20 PM
Hi,
here's my collection of Sierra's internal SCI tools (https://drive.google.com/file/d/0B5j-_ZMS8_UoUFFGTVVUbTY3cVU/view?usp=sharing&resourcekey=0-vvoJXsoV55WI33BoER8baw) (I have some AGI tools as well - stay tuned).
It's far from complete, but it spans from as early as 1987 to as late as 1996.
Some of the tools are available in several versions. For these, I suffixed their name with an underscore (_) and their version or their date (in case no version was available), e.g. SC_4.100.EXE.
Some of the tools had a protection that only allowed them to be run from a specific network share. I removed that protection.

Here're the descriptions for the tools that have it:
AMIGAPAL.EXE -
ATOS.EXE     - AGI to SCI source code translator
AUDADD.EXE   - Add audio header
AUDAIFF.EXE  -
AUDBITS.EXE  -
AUDCHANS.EXE - AUDCHANS converts stereo audio files to mono or visa-versa or reports the number of channels that audio files currently have.
AUDCHECK.EXE -
AUDCOMP.EXE  - Audio compress
AUDDCOMP.EXE - AUDDCOMP is used to decompress audio volumes during install.
AUDDISK.EXE  - Flag AUD files for disk-resident playback
AUDMAP.EXE   -
AUDMEM.EXE   - Flag AUD files for memory-resident playback
AUDPCM.EXE   - Decompress AUD to SOL files
AUDPLAY.EXE  - Audio player
AUDRATE.EXE  - Change or report rate of AUD files
AUDSCRAM.EXE - Audio scrambler
AUDSOL.EXE   -
AUDSTRIP.EXE - Strip audio header
AUDSYNC.EXE  - Remove sync editor info
AUDUCOMP.EXE - Audio decompress
AUDUSCRM.EXE - Audio unscrambler
AUDWAVE.EXE  - Rewrite AUD files in Microsoft's WAVE format
BASE36.EXE   - BASE36 converts message components into base-36 filenames or vice-versa.
BASENAME.EXE -
BETAW.EXE    -
BIT2CEL.EXE  - Convert 16 color bitmap to 16 color cel
BIT2LBM.EXE  -
BLAST.EXE    - Sound Blaster Record/Playback Utility
BUILDADL.EXE - Builds 3.PAT for use with Sierra's ADL (128 patch) driver.
BUILDGEN.EXE - Builds 4.PAT for use with Sierra's GSMIDI driver.
BUILDTDY.EXE - TANDY PATCH EDITOR
CE.EXE       - Cursor Editor
CEL2BIT.EXE  -
CEL2LBM.EXE  - Converts 256 Color Cel to LBM file
CEL2NEW.EXE  -
CEL2PCX.EXE  - Converts Cel to PCX file
CEL2RE.EXE   - Converts 256 Color Cel to Targa 16 file (.T16) for RE
CEL2TGA.EXE  - Converts 256 Color Cel to Targa 16 file (.T16)
CHKVIEW.EXE  - Checks integrity of view files
CVTPAL.EXE   -
CVTSCI.EXE   - Converts SC scripts to new syntax
DC.EXE       - Word derivative Compiler
DIMWIT.EXE   -
DIMWITSX.EXE -
DROPTGA.EXE  -
FE.EXE       - Font Editor
FIXCEL.EXE   - Correct 256 color cel file(s)
FIXVIEW.EXE  - Correct 256 color view file(s)
FIXVIEWS.EXE - Correct all 256 color view files
FORCEPAL.EXE -
GETTGA.EXE   -
GETTGA16.EXE -
INC_IT.EXE   - Increments the ASCII version number in 'version_file'.
INCVER.EXE   - Increment version number
LBM2BIT.EXE  -
LBM2CEL.EXE  - Converts LBM file to Cel file
LBM2PAL.EXE  - Creates new palette file from LBM file
LBM2VIEW.EXE - Converts LBM file back to 256 color view file
MACPIC.EXE   -
MACVIEW.EXE  -
MAKCDVOL.EXE -
MAKECEL.EXE  -
MAKEMAPS.EXE - MAKEMAPS reads individual audio and sync files creating RESOURCE.AUD and room-specific *.MAP resource files.
MAKEP16.EXE  - Converts 256 Color Pic to 16 color pic (controls & priority)
MAKEPIC.EXE  - Makes an SCI32 P56 file from 2 pcx files
MAKEV.EXE    - Converts any view to use colors in new.pal
MAKEV16.EXE  - Converts 256 Color View to 16 color view
MAKEV256.EXE -
MAKEV64.EXE  - Converts 256 Color View to standard 64 color view
MAKEV72.EXE  - Converts 256 Color View to standard 72 color view
MAKEVAUD.EXE -
MAKEVOLS.EXE -
MAKEVSEQ.EXE -
MATCHV.EXE   -
MC.EXE       - Message Compiler
ME.EXE       - SCI Message Editor
ME_ALT.EXE   - (Music Editor? Original name was ME)
MEAUDFIL.EXE - Message Audio File Utility
MECNV3_4.EXE - Message Editor Conversion v.3 to v.4
MEDUMP.EXE   - Message File Dumper
MESCRIPT.EXE -
MESSAGES.EXE -
MEXLTDIF.EXE - Message File Translation Differencer
MOVIE.EXE    -
MOVIE256.EXE -
MSCIV.EXE    -
MTEST.EXE    - Music Test
NEWPAL.EXE   - Creates new palette file from LBM file
NIGHTPAL.EXE - Creates nighttime palette from file
NO255.EXE    -
NORM.EXE     - This program normalizes audio files.
ONELINE.EXE  -
PAL.EXE      - Allows you to redefine the standard palette in pic file(s)
PAL2NEW.EXE  -
PAL2OLD.EXE  - Conversion of New Pallete to Old
PALPIC.EXE   - Allows you to redefine the standard palette in pic file(s)
PALVIEW.EXE  - Allows you to redefine the standard palette in view file(s)
PCX2CEL.EXE  - Converts PCX to Cel file
PCX2VIEW.EXE - Converts PCX file back to 256 color view file
PE.EXE       - Picture Editor (16 colors)
PE256.EXE    - Picture Editor (256 colors)
PIC2CEL.EXE  - Program converts 256 color PICTOR files to 256 color cels
PIC2NEW.EXE  -
PIC2PCX.EXE  - Converts Pic to PCX file
PICTEST.EXE  -
PMAKEVOL.EXE -
PSCIDH.EXE   -
PSCIDHV.EXE  -
PUTTGA.EXE   -
RAW2MST.EXE  -
RE.EXE       -
READPAL.EXE  -
REDOPIC.EXE  -
RENRESRC.EXE - Resource File Renamer
RESBUILD.EXE -
RESBUST.EXE  -
RESDIR.EXE   -
RESMIX.EXE   -
RMESSAGE.EXE - SCI message translator
SC.EXE       - Script Compiler
SCI.EXE      - Script Interpreter (debug)
SCID.EXE     -
SCIDH.EXE    -
SCIH.EXE     -
SCIP.EXE     -
SCITESTR.EXE - Script Interpreter (debug, menu bars enabled)
SCIUB.EXE    -
SCIV.EXE     -
SCIWH.EXE    -
SCPP.BAT     - front-end batch file for SCPPRINT.EXE
SCPPRINT.EXE - a pretty printer for SCRIPT code
SE.EXE       - Sound Editor
SIERRA.EXE   - Script Interpreter (no debug)
SIERRAH.EXE  -
SIERRAM.EXE  - Script Interpreter (no debug, menu bars enabled)
SIERRAWH.EXE -
SMF.EXE      -
SMIDI.EXE    -
SND_EDIT.EXE - SMF SOUND FILE EDITOR
STAMPVER.EXE -
STAMPVOL.EXE -
SYNCONLY.EXE -
TC.EXE       -
TESTPAL.EXE  -
TGA2MST.EXE  -
TGAPIC.EXE   -
V16LBM.EXE   - Converts 16 color views to Lbm files
V16TO72.EXE  - Converts 16 Color View to standard 72 color view
V256LBM.EXE  - Converts 'Full Color' views to Lbm files
VC.EXE       - Vocabulary Compiler
VCPP.EXE     -
VE.EXE       - View Editor (16 colors)
VE256.EXE    - View Editor (256 colors)
VIEW2LBM.EXE - Converts 256 color views to Lbm files
VIEW2NEW.EXE -
VIEW2OLD.EXE - Conversion of New View Format to Old View Format
VIEW2PCX.EXE - Converts 256 color view to PCX file
VIEWCHK.EXE  - View File Comparison Utility
VIEWMARK.EXE -
VIEWPAL.EXE  - Allows you to redefine the standard palette in view file(s)
VOLCHECK.EXE -
WE.EXE       -
WHATSON.EXE  -
XE.EXE       -
XE_RAVE.EXE  -
XEBATCH.EXE  -
XMESSAGE.EXE - SCI message extractor


I hope there'll be a community effort to document the tools more thoroughly.

Enjoy!  8)
Title: Re: Sierra's Internal SCI Tools
Post by: lskovlun on June 17, 2016, 08:52:23 PM
My my, you have been busy. The interp called SCIUB looks like it's got complete debug symbols (as do a number of other executables).
Title: Re: Sierra's Internal SCI Tools
Post by: MusicallyInspired on June 17, 2016, 08:56:10 PM
Can't wait to download this when I get home! I love this stuff.
Title: Re: Sierra's Internal SCI Tools
Post by: Collector on June 17, 2016, 08:58:05 PM
I will certainly be going through them. I want to put the tools and any documentation on the Wikis. Nice to see that the files in this batch still have the original dates. Do you know if there are any of these that are server bound like the pic and view editors of the last batch?
Title: Re: Sierra's Internal SCI Tools
Post by: lskovlun on June 17, 2016, 09:06:01 PM
I will certainly be going through them. I want to put the tools and any documentation on the Wikis. Nice to see that the files in this batch still have the original dates. Do you know if there are any of these that are server bound like the pic and view editors of the last batch?
That seems to be what Omer refers to when writing
Quote
Some of the tools had a protection that only allowed them to be run from a specific network share. I removed that protection.
Whether he's got rid of all of them, I can't say.
Title: Re: Sierra's Internal SCI Tools
Post by: Collector on June 17, 2016, 10:04:14 PM
I guess I just skimmed over the opening statement and went right to the list itself.
Title: Re: Sierra's Internal SCI Tools
Post by: troflip on June 17, 2016, 10:06:28 PM
Some of the tools had a protection that only allowed them to be run from a specific network share. I removed that protection.

Out of curiosity, how did you do that? Use a hex editor on the binary and search for path names an modify them?

Maybe we can re-construct the complete original development environment, for those who not only want to play retro games, but also program in a retro IDE, lol...
Title: Re: Sierra's Internal SCI Tools
Post by: Collector on June 17, 2016, 11:51:40 PM
Probably the way Lars mentioned after Omer released the first bunch of tools.
Title: Re: Sierra's Internal SCI Tools
Post by: OmerMor on June 18, 2016, 04:35:56 AM
Out of curiosity, how did you do that? Use a hex editor on the binary and search for path names an modify them?

Maybe we can re-construct the complete original development environment, for those who not only want to play retro games, but also program in a retro IDE, lol...

I used a disassembler (IDA Pro) and the DosBox Debugger to learn what's going on.
Most of the executables are checking if the there's a file server named "DEVELOPMENT" in NetWare's file server name table (using Int 21/AX=EF04h (http://www.ctyme.com/intr/rb-3636.htm)).
I *think* they later validate the user is logged on to it.
Other executables check for the existence of the same executable on drive X:.

I simply replaced the call to this check with NOPs.

It's interesting to note that beside the DEVELOPMENT string, there are also PROGRAMMING, RESEARCH, CS and APPS. It appears they aren't in use, but I guess these are the names of Sierra's other file servers.

BTW, I just recently taught myself how to use IDA Pro, as part of my work on the INN Revival project. I needed that to disassemble the modem driver and the TSN Executive. It's fun (in a perverted way)!   :D
Title: Re: Sierra's Internal SCI Tools
Post by: OmerMor on June 18, 2016, 04:37:38 AM
Whether he's got rid of all of them, I can't say.

I hope I did. Let me know if you find any others and I'll rty to take care of that as well.
Title: Re: Sierra's Internal SCI Tools
Post by: OmerMor on June 18, 2016, 04:55:33 AM
The interp called SCIUB looks like it's got complete debug symbols (as do a number of other executables).

Cool.

On a somewhat related note, Sierra clearly had a naming convention for their interpreter file names.
We all know SCIDHUV.EXE, but there are many others.
SCI is usually the prefix, but sometimes it's MSCI* and PSCI*. And they also used SIERRA (no debugger) and BETA (requires dongle).
The suffix is a combination of letters from the following set: {W,D,H,U,V,P,B}.
I am sure each suffix letter has a meaning, but I don't know what it is yet.
Any ideas?

I just noticed all the EGA games use SCIDUV.EXE and not SCIDHUV.EXE, so I guess the 'H' stands for VGA graphics.
I also *suspect* the 'D' stands for stripped debugger.
Title: Re: Sierra's Internal SCI Tools
Post by: MusicallyInspired on June 18, 2016, 12:04:18 PM
Also, SCI0 games use simply SCIV. The addition of DU for SCI1 EGA games and DHU for SCI1/.1 VGA games is interesting. I remember realizing this quite a ways back. No idea what it meant, though. By SCI2 they went back to just SIERRA.
Title: Re: Sierra's Internal SCI Tools
Post by: Collector on June 18, 2016, 01:17:48 PM
The SCI 2 games also had SIERRAW for the Windows interpreter. LSL7 had SIER (DOS), SIERW (Win16) and SIERW5 (Win32).
Title: Re: Sierra's Internal SCI Tools
Post by: lskovlun on June 24, 2016, 03:21:58 PM
Any ideas?
V is for Volumes (the interps without it do not use RESOURCE.* files, but search for the individual resources in various specified directories).
EDITEDIT: P is for parser (they have special debug code in them).
EDIT: It is also interesting to note that the LSL3 interp found in the TOOLS package (0.000.572) has a non-volume counterpart, numbered 0.000.571. Back in the FreeSCI days we used the version numbers directly, always trying to figure out when a particular change took place. It looks like the system build procedure would build several interps in a row for different uses (volume, non-volume, vga, ega, etc.) and some version numbers can be inferred from that.
Title: Re: Sierra's Internal SCI Tools
Post by: claudehuggins on October 27, 2016, 08:37:05 PM
Man, sorry to reply to an old topic, but this somehow managed to slip past my radar and I am pretty darn excited to see it.

Maybe we can re-construct the complete original development environment, for those who not only want to play retro games, but also program in a retro IDE, lol...
Call me weird, but that sounds EXACTLY like my kind of jam. I'm all for this. Go big or go home.
Title: Re: Sierra's Internal SCI Tools
Post by: lance.ewing on October 28, 2016, 04:41:51 AM
Call me weird, but that sounds EXACTLY like my kind of jam. I'm all for this. Go big or go home.

troflip was probably half joking, but I've also thought the same thing a few times. A year or so ago, we even identified what "IDE" they were using back then and found a site online that appeared to have a version of it that roughly matched what Sierra would have been using. This was based on a partial match between a fragment in an unused part of an original game disk with one of the standard BRIEF macro files that comes with BRIEF, and based on the publish date of that particular version of BRIEF.

One thing I haven't heard of turning up yet though are the custom BRIEF macros that Sierra used. They clearly used a lot of them. They are referenced in some of the documentation that Omer released, and we've seen a few fragments from original disk slack space, but I don't think anyone has any full macro files.

The AGDS document included in the AGI Original Documentation thread mentioned BRIEF a number of times. Here is an interesting bit:

Code: [Select]
CG -- the game compiler.
This is the most used. Assuming you use BRIEF to edit the source code files,
call the compile macro (often assigned to the F9 key). It saves your file,
calls the CG game compiler, routes CG's output to your LGC subdirectory, and
if errors are found, displays them in the current window.

...and this bit as well:

Code: [Select]
MACROS
The BRIEF macros "allfiles.m" and "modify.m" allow you to modify all of
your source files at once. To use them, edit the file "\brief\macro\modify.m"
to do whatever you want done to your files. Compile it (use F9) until it iscorrect, and automatically loaded.
enter "allfiles."
Title: Re: Sierra's Internal SCI Tools
Post by: Kawa on October 28, 2016, 05:49:25 AM
Me, I just want compression and maybe multiple volume files. But I can't get MAKEVOLS to work.
Title: Re: Sierra's Internal SCI Tools
Post by: lskovlun on October 28, 2016, 08:31:08 AM
Me, I just want compression and maybe multiple volume files. But I can't get MAKEVOLS to work.
This reminds me of how the first decompressor I wrote for SCI1.1 abused a command-line tool from Logitech that happened to use the same compression library. Christoph's first comment to that was, predictably, "WTF?"
But it worked.
Title: Re: Sierra's Internal SCI Tools
Post by: NewRisingSun on October 28, 2016, 11:42:31 AM
Quote from: Kawa
Me, I just want compression and maybe multiple volume files. But I can't get MAKEVOLS to work.
I did get it to work to rebuild Space Quest I with compression. What exactly is your problem, and what version of MAKEVOLS are you using, and for what SCI version are you building?
Quote from: Iskovlun
This reminds me of how the first decompressor I wrote for SCI1.1 abused a command-line tool from Logitech that happened to use the same compression library. Christoph's first comment to that was, predictably, "WTF?" But it worked.
Ah, ye olde PKWare Data Compression Library. I first extracted it from SIERRA.EXE to create a linkable library version of it, then debugged it and wrote my own implementation of the decompressor using assembly language. Of course, with the C implementations available in open-source, that effort has become useless. I'm not positive though whether the compressor has ever been rewritten in Assembly or C as well, or whether an official linkable library has ever been leaked. PKWDCL seems to have been used quite widely --- not only did Sierra use it, but LucasArts would distribute Monkey Island 2 and Indiana Jones 4 using their own custom archive format (LFG) that compressed using the library. And many mid-90s floppy-based games used the INSTALIT installation package. Its built-in decompressor first used the old PAK compression from NoGate Consulting but later switched to PKWDCL in later versions. I know that from writing my own InstalIt .PVL archive extractor.
Title: Re: Sierra's Internal SCI Tools
Post by: Kawa on October 28, 2016, 11:47:35 AM
I did get it to work to rebuild Space Quest I with compression. What exactly is your problem, and what version of MAKEVOLS are you using, and for what SCI version are you building?
The one from OmerMor's SCI16 release, and the one from OmerMor's SCI16 release. The problem: I know now what RESOURCE.TXT should be, but MAKEVOLS wants a WHERE file. I have one of those, adjusted to the best of my knowledge but all I get is a blank RESOURCE.000 and RESOURCE.MAP. I'll try again so I can document the error after dinner, which is now.

Given the following:
WHERE
Code: [Select]
vocab=c:
script=c:
text=c:
heap=c:
message=c:
videoDrv=c:\vga320.drv
soundDrv=c:\std.drv
kbdDrv=c:\ibmkbd.drv
joyDrv= NO
mouse = YES
minHunk=1k
pic=.;c:\*.p56;c:
view=.;c:\*.v56;..\art\view\*.v56;c:
palette=.;c:
font=.;c:
sound=.;c:

RESOURCES.TXT
(Loosely based on http://symphoniae.com/nrs/sciprogramming/RESOURCE.TXT (http://symphoniae.com/nrs/sciprogramming/RESOURCE.TXT))
Code: [Select]
(volumes
volume 0
script 255
heap 255

script 0
script 10
script 11
script 14
script 15
script 20
script 21
script 24
script 26
script 100
)

Result
(Running this from DOSBox, where C: is my game's folder, with all resources extracted.)
Code: [Select]
MAKEVOLS 3.01 Copyright Sierra On-Line, Inc., Apr 27 1993. All rights reserved.

MAKEVOLS: (2) Object (volume) not found.
MAKEVOLS: (3) Object (umes) not found.
MAKEVOLS: (3) End of file while building (null).
resource.000 is 0 bytes long.
Bytes read: 0
Bytes written: 0
Compression: 100%
Sorting...

Resource.000: 0 bytes
Resource.map: 7 bytes

Removing particular script lines from resource.txt yields a shitton of Object (olume) not found. errors.
Title: Re: Sierra's Internal SCI Tools
Post by: OmerMor on October 28, 2016, 12:47:16 PM
One thing I haven't heard of turning up yet though are the custom BRIEF macros that Sierra used. They clearly used a lot of them. They are referenced in some of the documentation that Omer released, and we've seen a few fragments from original disk slack space, but I don't think anyone has any full macro files.

Here's an archive with BRIEF, some utilities, and compiled macros I managed to scrape off my stuff:
https://drive.google.com/file/d/0B5j-_ZMS8_UoYVJIVEtnZk5lbWc/view?usp=sharing&resourcekey=0-qPC6H-efAXoDFphQ7nquyQ (https://drive.google.com/file/d/0B5j-_ZMS8_UoYVJIVEtnZk5lbWc/view?usp=sharing&resourcekey=0-qPC6H-efAXoDFphQ7nquyQ)
Title: Re: Sierra's Internal SCI Tools
Post by: NewRisingSun on October 28, 2016, 01:40:34 PM
I have just rebuilt KQ6 floppy using the MAKEVOLS utility from OmerMor's SCI16 archive. The resulting RESOURCE.000 and RESOURCE.MAP are not byte-for-byte identical, as the MAKEVOL.EXE seems to be of a later version that inserts an additional 0x12 0x34 0x00 0x00 into RESOURCE.MAP. A few of the files also compress differently, indicating a different version of the PKWare Data Compression Library. But the result still works nicely with the original interpreter included with the game. Attached find my WHERE and RESOURCE.TXT file for KQ6 Floppy. I put my individual game resources are in a subdirectory named INPUT\ under the current directory from which MAKEVOLS is launched.
Title: Re: Sierra's Internal SCI Tools
Post by: Kawa on October 28, 2016, 02:10:13 PM
That works much better!
Title: Re: Sierra's Internal SCI Tools
Post by: NewRisingSun on October 28, 2016, 02:31:59 PM
MAKEVOLS is actually quite flexible, which in the case of SCI0/10 with multiple volumes is very useful. Basically, you can have as many lists as you want, with one list calling up another. For example, you could do the following (stylized example):
Code: [Select]
(CDROM ; all resources in one volume file
system
rm1
rm2
)

(360K
volume 0
system

volume 1
rm1

volume 2
rm2
)

(720K
volume 0
system

volume 1
rm1
rm2
)

(system
script 999
script 998
)

(rm1
script 1
pic 1
)

(rm2
script 2
pic 2
)
Anything that is not a recognized keyword is interpreted as a reference to a separate list. When MAKEVOLS is run without a list name, it just takes the first one in RESOURCE.TXT. If you specified "MAKEVOLS 360k" with the RESOURCE.TXT above, only the "360K" list would be built, which puts all resources associated with rm1 and rm2 in separate volumes 1 and 2, whereas "MAKEVOLS 720K" would put them in the same volume 1. That flexibility still exists in MAKEVOLS 3.01, though it is somewhat useless since that version of MAKEVOLS/SCI does not support multiple volumes anymore.

Some early versions of MAKEVOLS, but not 1.10 and not 3.xx, apparently specified the paths in RESOURCE.TXT as well using the "resource" keyword (from INN):
Code: [Select]
resource view     0x80 /app24/ll/view/%d.v56;/app24/appshare/view/%d.v56
It seems that the paths were moved out of RESOURCE.TXT into the WHERE file at some point in time, possibly because SCI.EXE (without V) requires a WHERE file anyway which could be reused.
Title: Re: Sierra's Internal SCI Tools
Post by: Kawa on October 28, 2016, 04:22:30 PM
Haha. "Unable to allocate inBuffer", try again, "unable to allocate work buffer" X3
Title: Re: Sierra's Internal SCI Tools
Post by: lskovlun on October 28, 2016, 05:59:48 PM
The resulting RESOURCE.000 and RESOURCE.MAP are not byte-for-byte identical, as the MAKEVOL.EXE seems to be of a later version that inserts an additional 0x12 0x34 0x00 0x00 into RESOURCE.MAP.
That very much sounds like it's meant for the version-stamping utility to find and change... the thing is that there is a version stamp in the resource map and the executable that must match, but they differ by 0x1234. I helped troflip handle this for the LSL6 interpreter, and I believe it has a base stamp of 360 (dec), so the resource map must have 360+0x1234=0x139c.