Community
AGI Programming => AGI Development Tools => Topic started by: HWM on May 30, 2015, 07:41:26 PM
-
As mentioned in the "Original SCI syntax" thread, disks of AGI releases sometimes contain remnants of internal data.
Below are some fragments of the original AGI specs. Missing parts are marked as "@@@".
@@@
esult in the var.
div.v(VAR, VAR)
Parameters: destination, divisor
No alternate way to write it in the compiler.
Divide the first var by the second, leaving the quotient in the
first var.
lindirectv(VAR, VAR)
[Written as var1 @= var2]
Left indirect assignment of vars. Takes the value in var1 and uses it
as the var number in which to store the value of var2. In essence,
var1 is a 'pointer' to the var for the assignment. Thus,
%var var1 39
%var var2 56
var1 = 27;
@@@
rks
on white and the picture being overlayed is probably not all white.
As in draw.pic(), a call to show.pic() is necessary to bring the
new picture to the foreground screen.
show.pri.screen()
Show the priority screen, then wait for ENTER or ESC before returning
to the game. Generally implemented as a debug action.
------ View actions
load.view(VIEW)
Load the view whose number is given by the number.
load.view.f(var)
Load the view whose number is in the var.
discard.view(VI
@@@
t.motion(), start.cycling(), normal.cycle(), observe.blocks(),
observe.horizon(), on.anything(), release.priority(), release.loop(),
and observe.objects() on the object and sets its direction to 0.
unanimate.all()
Unanimate all animated objects. If you're going to draw a second picture
in a room (using draw.pic() without doing a new.room()) do this first
to make sure that you don't end up with a number of animated objects
which you don't want in the new picture. You'll have to do an
anima
@@@
T)
Erase the object from the screen. Erased objects do not move or
interact with drawn objects.
position(OBJECT, NUM, NUM)
Parameters: object, x coord, y coord.
Set the position of the object (the lower left corner of its baseline)
to the (x, y) coords given in the numbers. x is measured from the right
edge of the screen, y from the top. If part of the object will be off
the screen, if the object is above the horizon and must observe it, or
if the object's baseline is on a priority lin
@@@
error to that corresponding to an object's
current direction. A non-moving object (direction = 0) remains in
its last loop.
set.loop.f(OBJECT, VAR)
Set the object's loop to that in the var.
fix.loop(OBJECT)
Fix the object's loop. It will no longer adjust to the direction
in which the object is moving.
release.loop(OBJECT)
Undo a fix.loop(). The object will now face in the direction
appropriate to its direction.
set.cel(OBJECT, NUM)
Set the object's cel to that in the number. Cels
@@@
s is done by
animate.obj().
end.of.loop(OBJECT, FLAG)
Reset the flag. Increment the cel number at each animation cycle.
When the last cel of the loop is reached, stop cycling and set the flag.
reverse.cycle(OBJECT)
Cycle the object from the current cel number to cel 0. When cel 0
is reached, start again at the last cel of the current loop.
reverse.loop(OBJECT, FLAG)
Reset the flag. Decrement the cel number at each animation cycle.
When cel 0 is reached, stop cycling and set the fl
@@@
nd background colors for text. Not all combinations
will necessarily be supported on all machines. We will try to
approximate where we can, but no guarantees. The colors are:
0 black
1 dark blue
2 dark green
3 cyan
4 red
5 magenta
6 brown
7 light grey
8 dark grey
9 light blue
10 light green
11 light cyan
12 pink
13 light magenta
14 yellow
15 white
All combinations will (I believe) be supported on the Atari ST, Amiga,
and the NEC 9801.
On th
@@@
The number is the
number of figure eights to do. This will be a no-op on some hardware,
so don't depend on it.
------ Screen handling
[* 25 lines total
configure.screen(NUM, NUM, NUM)
Parameters: picture row, input row, status row.
This call, which should be done as soon as the game starts, sets
where the various components of the screen are placed. The first
number is the CHARACTER row number (starting at zero) for the upper
left corner of the picture, the second is the row n
@@@
ers: string number, message number.
Copy the message into the string given by the number.
get.string(NUM, MSGNUM, NUM, NUM)
Parameters: string number, message number, row, column.
Prints the message as a prompt at the given screen position, then
allows the user to enter the string for string number NUM. If the
row is >24, the message will be printed at the current cursor
position.
Since string 0 is the prompt, set the prompt by
%message 1 "> "
set.string(0, 1);
The code to le
@@@
ilable to all said() tests for the remainder
of the current logic scan.
get.num(MSGNUM, VAR)
Prompt the user with the message and get a (purportedly) numeric reply.
Put the number into var. If a non-numeric reply is typed, var will
be 0.
------ Input handling
prevent.input()
Clear the input line and do not accept input from the user. Input
is off at startup.
accept.input()
Display the input line and accept input from the user.
set.key(NUM, NUM, NUM)
Parameters: low byte
@@@
set.key(27, 0, c.pause); [ESC
set.key(18, 0, c.rgb.toggle); [^R
set.key(16, 0, c.new.prompt); [^P
set.key(joy.low.byte, button0, c.doit);
set.key(joy.low.byte, button1, c.useit);
set.key(joy.low.byte, button0.dbl, c.lookit);
set.key(joy.low.byte, button1.dbl, c.status);
The controller definitions are in 'sysdefs'. You may map up to
29 keys. More than one key may map to a single controller, but
a single key can't map to more than one controller.
****** Note that the key
@@@
-
Were these separate files or in the VOL files?
-
The way in which it is fragmented, and the mention of "disks", suggests to me that these fragments were from disk sectors that were previously used by a file that had been deleted. When a file is deleted, it just marks the sectors as free in the FAT, i.e. it does't actually wipe the data on those sectors. So if their master copy of LSL had originally had the AGI specs on it, but was then deleted in prep for distribution, and if copies of the disk were made by doing a full disk copy (rather than individual files), then all copies would have this on them. You'd need to break out a disk sector hex viewer to see it though.
Something like that is my guess while we're waiting for HWM.
-
Correct. Actually it's quite common for disks of older (1980's) PC releases to contain leftover data. I've encountered it a couple of times, although I only checked the AGI disks after it was discussed in the thread mentioned earlier. I checked some SCI disks too, but I don't think anything turned up there; maybe there were new mastering procedures in place by then.
The original thread mentioned another AGI release containing data as well, but I didn't have that one to check myself, so there's probably more out there.
EDIT: I've added the assembly code fragment as an attachment to this post. It consists of graphic subroutines, mainly for Hercules video. As opposed to the AGI specs, it's one big chunk, only the last part is missing some bits.
-
Unfortunately I don't have any of my original disks with me at the moment, otherwise I'd be quite eager to start looking over them. They're actually in storage on the other side of the world. I'm tempted to buy a few originals online again, just so I can do this.
You mentioned looking at SCI games. KQ4, LSL2, PQ2 and SQ3 are probably the best ones to take a look at, given they were the earliest. Perhaps they hadn't changed their process by that point. When thinking about where we might find original SCI source, I don't think this possibility has ever crossed my mind, i.e. look over the unused sectors on the original disks for data from deleted files. This might be a way of finding more snippets of real SCI source code. If for some reason in the creation of a particular game they wiped and reused a floppy to produce the packaged files for distribution, then it could have parts of anything still left on it. I think we'd need to focus on SCI games from the pre-CD days. My copy of QFG2 was still on floppies, so anything from 1988-1990 is probably best to take a look at the original disks of. It might be wishful thinking though. Perhaps the reason AGI specs and code was found is because its from earlier days before processes were tightened up.
As a question to everyone reading this, what original AGI and SCI games do we each have ready access to? I guess the biggest problem these days is having access to a floppy disk, and then crossing your fingers in hope that the disks aren't damaged. I've got a USB 3 1/2 inch floppy drive but nothing that can read the old 5 1/4 disks. Those old games usually came with both sets of disks though.
-
Yes, I am aware of how files were deleted in DOS. I just would not have expected them to use a developmental disk for the master copy for production, so file fragments did not occur to me.
I have all of the AGI and SCI games, at least one version of each and several of some games. I have also started imaging my floppies with a KryoFlux, which would probably be able to capture file fragments, at least with a KryoFlux stream image. I recently was able to make a viable image of my KQ2 Tandy booter and converted the stream image into a Transcopy image. I have a special build of DOSBox that can boot from a Transcopy image. This handled the copy protection as if it was the original disk on my Win7 machine. http://www.kryoflux.com/
-
Yeah, as long as it is copying everything that is on the disk, which I'd assume that a disk image would do, then it would be perfect for the investigation. You could load those disk images in to a normal modern day hex editor and search for interesting text. If you had all of them as disk images, there might be a way to search across all of them in one go, maybe using a tool like strings or grep. You could start by seeing if you can find a match for some of the text that HWM posted. That would validate the approach and maybe confirm the game that it appeared in.
I also find it a little strange that the sold copies of games could contain copies of sectors for deleted files. Maybe it was a one-off based on the circumstances of how that particular game was prepared. Maybe it was a single dev working late trying to get things done and he was struggling to find a completely clean floppy. Or maybe reusing floppies was a common thing. I know I reused a lot.
Edit: Thinking about it a bit more, we could probably take each disk image and extract out only the unused sectors and the unused parts of partially used sectors of each image. That way we know instantly that whatever we find, it isn't part of the distributed game files. The images would contain the boot sector and FAT sectors as well. The bootable Tandy one is probably a different story though.
-
Let me know if there is one that you would like to explore. Keep in mind that a KryoFlux stream image can be several 10s of MB in size for a single floppy. You could almost just do an old MS-DOS undelete, if not too much of it has been overwritten. But then we are talking about the era when users may have not had hard drives and may have been writing save files to the disk. This is one thing that the KryoFlux controller program can do, is to identify altered sectors from the original creation of the disk.
-
You mention that it can identify altered sectors. Is it just that it knows the sector has been altered? Or can it help with working out what was written to that sector in the past? That sounds pretty incredible if it were possible. I'm guessing not though. But why is the KryoFlux stream so large if the floppy is only 360 /720K? I'm not familiar with it, so not sure what exactly it is reading. Is it not just data but the different levels of magnetism or something like that?
I guess that wouldn't be much help for the copies that were sold. We'd need the original master floppy to analyze its past. The copies would presumably be clean copies but if they were a full disk copy then they would contain copies of sectors for deleted files. - Yeah, I wonder what would happen if we tried using undelete on some of those disks?
What is the process of converting a KryoFlux stream image to an actual disk image with byte data in it?
-
I just used a regular floppy drive and a tool called ImageDisk. This resulted in a binary copy of the full contents of the disk, so everything except for copy protection timing stuff / bad sectors, etc. Basically that's all you need in this case. I'm not that familiar with KryoFlux, but I'm pretty sure you'll just have to convert the KryoFlux stream image into a regular IMG file and after that you should be able to explore it (in readable format) using a hex editor. I assume you can use undelete, but I don't think it would work here, as the fragments probably don't have an entry in the FAT anymore.
I also find it a little strange that the sold copies of games could contain copies of sectors for deleted files. Maybe it was a one-off based on the circumstances of how that particular game was prepared. Maybe it was a single dev working late trying to get things done and he was struggling to find a completely clean floppy. Or maybe reusing floppies was a common thing. I know I reused a lot.
It really is quite common to see all kinds of unrelated data on officially sold copies, at least in PC games from the 80's. I backed up some of my oldest disks years ago and saw lots of removed content on retail disks, for instance there was this chess game that seemed to be mastered on a utility disk of a tape drive.
-
The KryoFlux stream files are raw. It captures the entire disk, all sectors, formatting, hidden tracks, etc. There are a couple of emulators that can use the the streams, but they are mostly for archival purposes. DTC, the program that comes with the KryoFlux can also create standard images like IMG, ADF, IPF, CBM, etc., depending on the platform of the disk. One of the main advantages is that you can use it from any modern PC, Mac, Linux or Amiga via USB. If you are interested you can take a look at the manual http://www.kryoflux.com/download/kryoflux_manual.pdf
Here is the box I put together to read both 3.5" and 5.25" disks from various platforms. http://sierrahelp.com/forums/viewtopic.php?f=86&t=4213#p55211
-
It really is quite common to see all kinds of unrelated data on officially sold copies, at least in PC games from the 80's. I backed up some of my oldest disks years ago and saw lots of removed content on retail disks, for instance there was this chess game that seemed to be mastered on a utility disk of a tape drive.
To say I've been somewhat distracted for most of last week by the implications of the above posts is probably an understatement. I think there's a bit of a goldmine here. HWM is right about unrelated data regularly appearing on officially sold copies. This isn't something that happened here and there. It appears to have happened nearly all the time. Having looked at a few examples, I no longer think that this data was from a deleted file that was previously on the floppy disks. My hunch is that these floppies were as clean as they get prior to the game files being copied on to them. I'm now thinking that the DOS copy tool of that era had some kind of buffer "over copy" bug in it, where it might have had data in its buffer from earlier I/O activity and that when it reached the end of file, it continued writing to the end of the sector (or perhaps the end of the cluster) with whatever happened to be in its buffer. This is the kind of pattern that appears a lot on the original disks. There is usually some sort of junk data beyond the end of the file that is using that cluster, and its not random junk. Sometimes it contains bits of files that have no business being on the floppy, other times it has DOS directory-entry tables where the entries contain details for files that can't possibly have ever been on the floppy disk because their starting cluster numbers are way beyond the size of a floppy.
It's all hinting at some kind of "over copy" bug. If such a bug existed in DOS, we could find bits of just about anything on any original game disk. It could take years to fully investigate and document what we find. If such a bug existed, it would mean that the 360K vs 720K disk versions of a game have different junk on them, and it would mean that different numbered releases of a game have different junk on them. So for every floppy game they released, multiply that by the number of released versions of that game, then multiply that by 2 (for 360/720 disk versions), and then I guess we multiply that by the number of different languages each game was released in. And this assumes that for each version that only one set of master floppies was produced, from which all customer copies were made. It is possible instead that they produced multiple sets of masters for efficiency reasons. Basically what I'm suggesting is that on any occasion that they ran their script to copy the built game files to a floppy, there's a good chance that something else was copied along with it, perhaps whatever they happened to have run or were viewing earlier that day. Given that such junk appears after the end of a file, then disk 1 of most games would be the best place to look since it has a lot more files on it.
Any thoughts on whether such a bug existed in DOS back then? I've tried Googling for this but haven't turned up anything yet. Lot's of people mention that data from deleted files can show up in free and partially used clusters, but I've found no mention yet of DOS itself copying additional junk data after the end of a file. Feel free to completely blast this theory to pieces if you know that such a bug can't have existed.
-
Some tool that they were using in place of XCOPY? When was XCOPY introduced?
-
The following "junk" data after the end of RESOURCE.006 on disk 6 of LSL2 720K version is the best clue of what DOS tool they used to prepare the master floppies:
Cluster# 339:
20 33 36 30 5C 72 360\r
65 73 6F 75 72 63 65 2E 30 30 35 20 20 20 20 61 esource.005 a
3A 0D 0A 63 6F 70 79 20 2A 2E 71 61 20 20 20 20 :..copy *.qa
20 20 20 20 20 20 20 20 20 20 20 20 61 3A 0D 0A a:..
76 6F 6C 61 62 65 6C 20 2F 6C 20 61 3A 4C 53 4C volabel /l a:LSL
32 20 44 69 73 6B 20 35 0D 0A 72 65 6D 20 07 0A 2 Disk 5..rem ..
0A 0A 0A 0A 20 20 20 20 20 20 20 20 20 20 20 20 ....
20 20 20 20 20 20 20 43 68 61 6E 67 65 20 44 72 Change Dr
69 76 65 20 41 3A 20 74 6F 20 44 69 73 6B 20 23 ive A: to Disk #
36 2E 0D 0A 70 61 75 73 65 0D 0A 63 6F 70 79 20 6...pause..copy
33 36 30 5C 72 65 73 6F 75 72 63 65 2E 30 30 36 360\resource.006
20 20 20 20 61 3A 0D 0A 63 6F 70 79 20 2A 2E 71 a:..copy *.q
61 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 a
20 61 3A 0D 0A 76 6F 6C 61 62 65 6C 20 2F 6C 20 a:..volabel /l
61 3A 4C 53 4C 32 20 44 69 73 6B 20 36 0D 0A 63 a:LSL2 Disk 6..c
64 20 20 20 2E 2E 0D 0A 72 65 6D 20 41 6C 6C 20 d ....rem All
64 6F 6E 65 2E 07 1A 0D 0A 20 20 20 20 20 20 20 done.....
20 20 20 20 20 20 20 62 3A 0D 0A 76 6F 6C 61 62 b:..volab
65 6C 20 2F 6C 20 62 3A 4C 53 4C 32 20 44 69 73 el /l b:LSL2 Dis
If I pull out only the ASCII text, including its formatting, then it looks like this:
360\resource.005 a:
copy *.qa a:
volabel /l a:LSL2 Disk 5
rem
Change Drive A: to Disk #6.
pause
copy 360\resource.006 a:
copy *.qa a:
volabel /l a:LSL2 Disk 6
cd ..
rem All done.
b:
volabel /l b:LSL2 Dis
The first line is obviously truncated and would have started with "copy ", as in the example of disk 6.
What we appear to be seeing here is the batch file that was used to create the LSL2 master floppies. It appears to prompt the developer to change the disk prior to writing the files for a particular game disk to the new floppy. This is the opposite of what we see when installing a game on to the hard disk. This batch file is clearly writing the files from a hard disk on to empty floppies, and then it sets the label of each disk as it goes. These labels match the labels on the original disks.
So assuming this really was used to create the LSL2 master disks, then it suggests that the DOS "COPY" tool was used to transfer the files to the master floppy.
Now the really revealing bit. This junk data was found on the 720K version of LSL2, but the batch file is executing commands to copy the 360K version. I'm guessing that the final two lines prior to the cluster ending is indicating that it then went on to start copying files to drive B:. So it's just copied the 360K version to drive A, and then it starts copying to drive B:. My assumption therefore is that drive B: was the 3 1/2 " floppy drive and that this is when it started writing the 720K version of the game.
So how could a fragment of the 360K batch script for preparing the master floppies have ended up on the 720K disk? I think this is good evidence for the "dirty buffer" "over copy" bug that I'm thinking may have existed. DOS would have read the batch file in to memory quite recently, just prior to copying files to the floppies. So we know it was loaded in to memory, and we know that part of it ended up on one of the floppies.
A couple of new bits of information to add to this discussion. I ran a few questions past an ex-Sierra employee about what he remembered of the process for preparation of the master floppies and how these were then used to create the customer copies. He said that the floppies used were stated to be blank and were almost always pre-formatted. He said that this doesn't necessarily rule out the possibility that a previously used floppy was reused in some cases though. He said that after the set of disks was produced, it was then loaded in to a machine called a Formaster (they had a room full of these) and the data for the disks was held in that machine's internal memory. The machine then used the data in its memory to write out the copies of the disks. The same master set of floppies would therefore in effect be used for all copies, until such time that a bug was found. At that point the bug would be fixed and a new set of disks produced and loaded in to the Formasters.
He also said that they primarily used the standard DOS but that some developers used DR-DOS and 4DOS after those came out. I've checked the timelines of the releases of those flavours of DOS and I doubt that they would have been using them in 1988 when LSL2 was produced. 4DOS was released in February 1989, and the initial public release of DR-DOS was in May 1988. I suppose they could have jumped on the DR-DOS bandwagon immediately but it seems unlikely. And given that this thread started with a discussion of AGI specs and AGI assembler code, the dates of those AGI disks would probably pre-date LSL2 and therefore before DR-DOS. HWM said he thought it might have been LSL1 that the AGI fragments were on but that he wasn't sure. That would have been 1987 if it was the case.
The original game disks from 1988 have identifiers such as "MSDOS3.3" and "IBM 3.2" in the boot sector. I suppose that all this implies is that those versions of DOS were used to pre-format the disk.
-
It seems I've overlooked the most interesting file of the bunch I had saved before. I don't think I've looked past all the pages of the memory map (first part of the file) before, because otherwise I'd probably remembered, as it's pretty spectacular: C code of the interpreter complete with comments, programmer initials and everything. Based on the total size of it (210kb) it's probably from a different release than the code shared earlier. Also there's part of a batch file in there, creating a playable copy of the game(?):
copy agi.exe %2
copy *.ovl %2
setstr gameID %1 %2agi.exe
copy ..\src\agi.doc %2
Not sure about the "over copy" bug. It might be a combination of both (buffer + deleted data), since the attached 210kb of data seems a bit too much to be buffered. Just copying with (X)COPY would have taken the same amount of time as doing a full DISKCOPY then, and I suppose that's something that would've been noticed at one point.
I'm familiar with copies of the FAT being shattered all over the disk, but I don't know what causes it. I remember this one time, one of my disks somehow failed (corrupt filenames, file sizes of gigabytes). I inspected the disk with a disk editor and saw multiple copies of the FAT (or at least part of it) of one of my hard disk partitions there, which really struck me as odd. Again, no idea what causes it, but you'll see it on a lot of disks.
To conclude for now, I was able to check some of the SCI disks. There was some LISP-like code on the Codename: ICEMAN disk, but after some research it turned out to be macro code from a DOS application called BRIEF. So just in case, this is not SCI code:
.
;**
(macro right_side
(
(int num_cols
shift
)
(inq_window_size NULL num_cols shift)
(move_abs 0 (+ num_cols shift))
)
)
)
)
-
Yeah, I can confirm that what you've shown is definitely a BRIEF macro. I've found two snippets like that on other disks. The first (on SQ3) was from a fragment of a file called BUFFERS.M and the fragment was as follows:
ark (atoi (substr button_text (+ (rindex button_text ";") 1))))
(_dialog_esc)
(returns TRUE)
)
)
)
)
You can see the full version of what this came from at the following location (someone seems to have put a circa 1988 install of BRIEF on this site):
http://koti.mbnet.fi/juhal87/juhallebackupit/taimiDOSclevy/BR/MACROS/BUFFERS.M
The other fragment was from Black Cauldron and appears as follows:
change_window DOWN)
(top_of_buffer)
(search_fwd ":exit" 0)
(move_rel 5 0)
(refresh)
)
)
;else
(= addStr useStr)
))))
(= addStr (substr addStr 1 (- (strlen addStr) 1)))
(= addStr (+ "\t" (+ addStr "\n")))
(returns addStr)
)
)
This doesn't appear to match any of the standard macros that come with BRIEF, at least from what I've been able to tell. So I'm wondering if it is one of their custom macros.
On the subject of custom BRIEF macros, I found this fragment of a directory cluster on KQ1SCI that appears to show the names of some of their custom BRIEF macros. I'm basing this on the fact that the filenames contain SCI and that the extensions of the files are .M and .CM, which are the source and compiled BRIEF macro extensions.
Cluster# 694: EOF, appears after the end of: INSTGAME.BAT
0200 20 43 4D 20 20 00 00 00 00 CM ....
0210 00 00 00 00 00 00 25 78 86 14 5A 0F B1 00 00 00 ......%x..Z..... :Exit.CM 177 06-Apr-1990 15:01:10 [cluster=3930]
0220 53 43 20 20 20 20 20 20 4D 20 20 20 00 00 00 00 SC M ....
0230 00 00 00 00 00 00 68 77 86 14 59 0F 53 02 00 00 ......hw..Y.S... SC.M 595 06-Apr-1990 14:59:16 [cluster=3929]
0240 53 43 45 52 52 20 20 20 43 4D 20 20 00 00 00 00 SCERR CM ....
0250 00 00 00 00 00 00 B1 99 58 13 D9 0E 0B 07 00 00 ........X....... SCERR.CM 1803 24-Oct-1989 19:13:34 [cluster=3801]
0260 53 43 45 52 52 20 20 20 4D 20 20 20 00 00 00 00 SCERR M ....
0270 00 00 00 00 00 00 F0 60 57 13 D6 0E 17 10 00 00 .......`W....... SCERR.M 4119 23-Oct-1989 12:07:32 [cluster=3798]
0280 53 43 49 20 20 20 20 20 43 4D 20 20 00 00 00 00 SCI CM ....
0290 00 00 00 00 00 00 22 6D 09 13 4B 0E 1D 06 00 00 ......"m..K..... SCI.CM 1565 09-Aug-1989 13:41:04 [cluster=3659]
02A0 53 43 49 20 20 20 20 20 4D 20 20 20 00 00 00 00 SCI M ....
02B0 00 00 00 00 00 00 C8 79 8E 12 FB 0D 57 14 00 00 .......y....W... SCI.M 5207 14-Apr-1989 15:14:16 [cluster=3579]
02C0 53 43 49 4B 45 59 53 20 43 4D 20 20 00 00 00 00 SCIKEYS CM ....
02D0 00 00 00 00 00 00 76 44 68 13 E4 0E D0 09 00 00 ......vDh....... SCIKEYS.CM 2512 08-Nov-1989 08:35:44 [cluster=3812]
02E0 53 43 49 4B 45 59 53 20 4D 20 20 20 00 00 00 00 SCIKEYS M ....
02F0 00 00 00 00 00 00 6F 44 68 13 E2 0E C7 0C 00 00 ......oDh....... SCIKEYS.M 3271 08-Nov-1989 08:35:30 [cluster=3810]
0300 53 45 41 52 43 48 20 20 43 4D 20 20 00 00 00 00 SEARCH CM ....
0310 00 00 00 00 00 00 EA 51 0F 11 E7 0A 8C 18 00 00 .......Q........ SEARCH.CM 6284 15-Aug-1988 10:15:20 [cluster=2791]
0320 53 45 41 52 43 48 20 20 4D 20 20 20 00 00 00 00 SEARCH M ....
0330 00 00 00 00 00 00 D7 66 8E 11 69 0D 13 42 00 00 .......f..i..B.. SEARCH.M 16915 14-Dec-1988 12:54:46 [cluster=3433]
0340 53 50 20 20 20 20 20 20 43 4D 20 20 00 00 00 00 SP CM ....
0350 00 00 00 00 00 00 A9 72 09 13 51 0E DE 0B 00 00 .......r..Q..... SP.CM 3038 09-Aug-1989 14:21:18 [cluster=3665]
0360 53 50 20 20 20 20 20 20 4D 20 20 20 00 00 00 00 SP M ....
0370 00 00 00 00 00 00 84 74 09 13 53 0E 98 13 00 00 .......t..S..... SP.M 5016 09-Aug-1989 14:36:08 [cluster=3667]
0380 53 54 41 52 54 55 50 20 43 4D 20 20 00 00 00 00 STARTUP CM ....
0390 00 00 00 00 00 00 F4 76 02 15 C8 10 2C 38 00 00 .......v....,8.. STARTUP.CM 14380 02-Aug-1990 14:55:40 [cluster=4296]
03A0 53 54 41 52 54 55 50 20 4D 20 20 20 00 00 00 00 STARTUP M ....
03B0 00 00 00 00 00 00 CA 52 4A 12 E4 0D 3E 1A 00 00 .......RJ...>... STARTUP.M 6718 10-Feb-1989 10:22:20 [cluster=3556]
I mentioned the BRIEF macro snippets to the ex-Sierra employee that I was talking to earlier in the week and he said that he wasn't surprised. His exact words were that it was "the editor of choice of ALL programmers at Sierra" (at least until Windows came along).
Looking at the LISP-like / C-like syntax of the BRIEF macro language, I can't help but wonder how much it influenced the development of the SCI language. Based on the discovery of the Black Cauldron BRIEF macro snippet, they were obviously using BRIEF in the AGI days as well. So I suppose they were quite familiar with this kind of LISP/C hybrid syntax.
I'll take a look at your attachment now. I'm really hoping at some point we'll find some genuine SCI source on one of these game disks. If there are .BAT file fragments and BRIEF macro fragments, then it seems to be possible that we could. Hopefully luck will go our way. The closest I've found so far is a directory cluster fragment with names of SCI source files (from KQ1SCI again):
02C0 6B 71 31 0D 0A 20 20 20 53 43 20 20 00 00 00 00 kq1.. SC ....
02D0 00 00 00 00 00 00 DD 6C 2C 15 B2 16 3D 37 00 00 .......l,...=7.. kq1.SC 14141 12-Sep-1990 13:38:58 [cluster=5810]
02E0 52 4D 32 37 30 20 20 20 53 43 20 20 00 00 00 00 RM270 SC ....
02F0 00 00 00 00 00 00 34 4B 43 15 63 1F E9 5F 00 00 ......4KC.c.._.. RM270.SC 24553 03-Oct-1990 09:25:40 [cluster=8035]
0300 52 4D 33 36 30 20 20 20 53 43 20 20 00 00 00 00 RM360 SC ....
0310 00 00 00 00 00 00 48 6D 2C 15 67 16 0E 81 00 00 ......Hm,.g..... RM360.SC 33038 12-Sep-1990 13:42:16 [cluster=5735]
0320 52 4D 34 35 30 20 20 20 53 43 20 20 00 00 00 00 RM450 SC ....
0330 00 00 00 00 00 00 B1 49 39 15 DC 14 8C 41 00 00 .......I9....A.. RM450.SC 16780 25-Sep-1990 09:13:34 [cluster=5340]
0340 52 4D 38 39 38 20 20 20 53 43 20 20 00 00 00 00 RM898 SC ....
0350 00 00 00 00 00 00 62 4D 2C 15 07 16 BC 0A 00 00 ......bM,....... RM898.SC 2748 12-Sep-1990 09:43:04 [cluster=5639]
0360 52 4D 32 36 30 20 20 20 53 43 20 20 00 00 00 00 RM260 SC ....
0370 00 00 00 00 00 00 57 76 27 15 32 16 E5 C5 00 00 ......Wv'.2..... RM260.SC 50661 07-Sep-1990 14:50:46 [cluster=5682]
0380 52 4D 33 34 30 20 20 20 53 43 20 20 00 00 00 00 RM340 SC ....
0390 00 00 00 00 00 00 84 76 27 15 4D 16 82 08 00 00 .......v'.M..... RM340.SC 2178 07-Sep-1990 14:52:08 [cluster=5709]
03A0 52 4D 33 37 30 20 20 20 53 43 20 20 00 00 00 00 RM370 SC ....
03B0 00 00 00 00 00 00 6B 78 27 15 E7 16 D2 3F 00 00 ......kx'....?.. RM370.SC 16338 07-Sep-1990 15:03:22 [cluster=5863]
03C0 52 4D 32 35 30 20 20 20 53 43 20 20 00 00 00 00 RM250 SC ....
03D0 00 00 00 00 00 00 9D 92 41 15 72 1F 49 A0 00 00 ........A.r.I... RM250.SC 41033 01-Oct-1990 18:20:58 [cluster=8050]
03E0 52 4D 32 30 30 20 20 20 53 43 20 20 00 00 00 00 RM200 SC ....
03F0 00 00 00 00 00 00 C8 7A 41 15 FF 06 42 6A 00 00 .......zA...Bj.. RM200.SC 27202 01-Oct-1990 15:22:16 [cluster=1791]
-
It seems I've overlooked the most interesting file of the bunch I had saved before. I don't think I've looked past all the pages of the memory map (first part of the file) before, because otherwise I'd probably remembered, as it's pretty spectacular: C code of the interpreter complete with comments, programmer initials and everything.
Wow! Yeah, this is amazing. Can you remember what game disk it game from? I'd be keen to locate it myself to see how this appeared on the disk.
Also there's part of a batch file in there, creating a playable copy of the game(?):
copy agi.exe %2
copy *.ovl %2
setstr gameID %1 %2agi.exe
copy ..\src\agi.doc %2
Very interesting. I'm not sure that this was for creating a releasable version of the game though, since that agi.doc file is presumably the AGI specs that you found fragments of earlier. But given that you did find fragments of the AGI specs on an original game disk then maybe these commands were run on the original disk that you found the spec fragments on. But then again, given that this snippet of a batch file existed on a disk, it might be related to the dirty buffer issue I've been proposing. If a batch file containing these commands was run maybe the same day as a game disk was built, then both this fragment of a batch file, and the fragments of the AGI specs, may still have been in a buffer somewhere.
Not sure about the "over copy" bug. It might be a combination of both (buffer + deleted data), since the attached 210kb of data seems a bit too much to be buffered.
Yeah, I agree with this. That interpreter code must have been from a deleted file. It's way too big, and also relatively unfragmented. It suggests that there was a run off clusters on the original disk that were marked as free but that contained that interpreter code. That would have been from a deleted file. Most of the disks I've looked at so far have very few clusters marked as "free" with anything interesting on them though. They're mostly fill of the 0xF6 format byte. There are a few exceptions to this, but those cases have small bits of non-text binary content that isn't immediately recognisable. They must have come from a deleted file also. The dirty buffer "feature" must account for a lot of the data at the end of "end of file" clusters, particularly where the very next cluster is cleanly formatted.
Apparently the "duplication department" at Sierra did re-use disks, particularly when a run of copies of a game had been made for which they found a bug shortly afterwards. Those would be put aside and reused, I assume with the Formasters again for the next run.
Just copying with (X)COPY would have taken the same amount of time as doing a full DISKCOPY then, and I suppose that's something that would've been noticed at one point.
For full disk copying, they used the Formaster devices. They were apparently similar to the KryoFlux in that they didn't care about the format of the disks they were copying. They would apparently simply copy the raw data, and from a few things I've read online, it seemed that such machines could copy whole floppies in as little as 20 seconds.
For preparing the master set of disks for loading in to the Formaster, it seems that this must have been a batch file that simply copied the files one by one to the floppy disks. This is based on the batch file fragment for LSL2 that was discussed earlier in this thread.
I'm familiar with copies of the FAT being shattered all over the disk, but I don't know what causes it. I remember this one time, one of my disks somehow failed (corrupt filenames, file sizes of gigabytes). I inspected the disk with a disk editor and saw multiple copies of the FAT (or at least part of it) of one of my hard disk partitions there, which really struck me as odd. Again, no idea what causes it, but you'll see it on a lot of disks.
One thing I know for certain is that floppies had at least two copies of the FAT on them, one after the other. This was in case one of them became faulty.
-
Yeah, I agree with this. That interpreter code must have been from a deleted file.
A backup disk? Some backup tools of the era produced a single big file that spanned a disk (or several disks).
-
Yeah, perhaps. Did such backup programs do any compression? I have noticed EXE file names in some of this junk data suggesting that a tool called Fast Back might have been on their hard disks.
-
Here are some of the directory entry cluster fragments that impy that FastBack was on their hard disks. Firstly from LSL2 disk 1 (720K version):
Cluster# 274: EOF, appears after the end of: LSL2.QA
00B0 00 .
00C0 44 56 20 20 20 20 20 20 20 20 20 10 00 00 00 00 DV .....
00D0 00 00 00 00 00 00 78 8E E1 10 6E 00 00 00 00 00 ......x...n..... DV <DIR> 01-Jul-1988 17:51:48 [cluster=110]
00E0 45 50 53 4F 4E 20 20 20 20 20 20 10 00 00 00 00 EPSON .....
00F0 00 00 00 00 00 00 DA A2 33 10 7A 00 00 00 00 00 ........3.z..... EPSON <DIR> 19-Jan-1988 20:22:52 [cluster=122]
0100 46 41 53 54 42 41 43 4B 20 20 20 10 00 00 00 00 FASTBACK .....
0110 00 00 00 00 00 00 6F 84 33 10 79 00 00 00 00 00 ......o.3.y..... FASTBACK <DIR> 19-Jan-1988 16:35:30 [cluster=121]
0120 4B 51 34 20 20 20 20 20 20 20 20 10 00 00 00 00 KQ4 .....
0130 00 00 00 00 00 00 F5 71 27 11 79 01 00 00 00 00 .......q'.y..... KQ4 <DIR> 07-Sep-1988 14:15:42 [cluster=377]
0140 4C 4C 32 20 20 20 20 20 20 20 20 10 00 00 00 00 LL2 .....
0150 00 00 00 00 00 00 B8 3D 51 10 41 00 00 00 00 00 .......=Q.A..... LL2 <DIR> 17-Feb-1988 07:45:48 [cluster=65]
0160 4D 4F 55 53 45 20 20 20 20 20 20 10 00 00 00 00 MOUSE .....
0170 00 00 00 00 00 00 F1 BA 33 10 63 00 00 00 00 00 ........3.c..... MOUSE <DIR> 19-Jan-1988 23:23:34 [cluster=99]
0180 53 59 53 54 45 4D 20 20 20 20 20 10 00 00 00 00 SYSTEM .....
0190 00 00 00 00 00 00 A4 5B 34 11 93 22 00 00 00 00 .......[4..".... SYSTEM <DIR> 20-Sep-1988 11:29:08 [cluster=8851]
01A0 53 59 53 54 45 4D 20 20 42 41 4B 10 00 00 00 00 SYSTEM BAK.....
01B0 00 00 00 00 00 00 EF 43 C8 10 4E 00 00 00 00 00 .......C..N..... SYSTEM.BAK <DIR> 08-Jun-1988 08:31:30 [cluster=78]
01C0 54 45 4C 45 43 4F 4D 4D 20 20 20 10 00 00 00 00 TELECOMM .....
01D0 00 00 00 00 00 00 D7 A4 33 10 6C 00 00 00 00 00 ........3.l..... TELECOMM <DIR> 19-Jan-1988 20:38:46 [cluster=108]
01E0 54 4F 4F 4C 53 20 20 20 20 20 20 10 00 00 00 00 TOOLS .....
01F0 00 00 00 00 00 00 0F A5 33 10 4A 00 00 00 00 00 ........3.J..... TOOLS <DIR> 19-Jan-1988 20:40:30 [cluster=74]
The assumption here is that a directory containing such sub-directories is unlikely to have been on a floppy (both KQ4 and LSL2 on the same floppy? And FastBack as well?). And besides, the SYSTEM directory starts at a cluster that is way too big to be on a floppy disk.
And this one from KQ4 disk 1 (720K version):
Cluster# 575: EOF, appears after the end of: CGA320C.DRV
0140 43 4F 4D 20 00 00 00 00 COM ....
0150 00 00 00 00 00 00 14 7E 49 10 50 01 B8 A1 00 00 .......~I.P..... ??????.?.COM 41400 09-Feb-1988 15:48:40 [cluster=336]
0160 50 54 20 20 20 20 20 20 4C 41 53 20 00 00 00 00 PT LAS ....
0170 00 00 00 00 00 00 9A 8C 8D 11 1F 02 04 00 00 00 ................ PT.LAS 4 13-Dec-1988 17:36:52 [cluster=543]
0180 46 42 20 20 20 20 20 20 45 58 45 20 00 00 00 00 FB EXE ....
0190 00 00 00 00 00 00 73 AD 44 10 66 01 0C 02 03 00 ......s.D.f..... FB.EXE 197132 04-Feb-1988 21:43:38 [cluster=358]
01A0 53 54 41 52 54 55 50 20 46 42 20 20 00 00 00 00 STARTUP FB ....
01B0 00 00 00 00 00 00 DD 80 02 11 20 02 81 02 00 00 .......... ..... STARTUP.FB 641 02-Aug-1988 16:06:58 [cluster=544]
01C0 43 4F 4E 46 33 38 34 20 53 59 53 20 00 00 00 00 CONF384 SYS ....
01D0 00 00 00 00 00 00 62 81 F3 10 22 02 28 00 00 00 ......b...".(... CONF384.SYS 40 19-Jul-1988 16:11:04 [cluster=546]
01E0 57 48 41 54 20 20 20 20 45 58 45 20 00 00 00 00 WHAT EXE ....
01F0 00 00 00 00 00 00 00 00 FF 0E 23 02 62 0C 00 00 ..........#.b... WHAT.EXE 3170 31-Jul-1987 00:00:00 [cluster=547]
Both FB.EXE and STARTUP.FB were apparently part of FastBack:
https://repositories.lib.utexas.edu/bitstream/handle/2152/12969/SNES_audio_disk_FILE.txt?sequence=6
There's a wikipedia page on it here:
https://en.wikipedia.org/wiki/FastBack
-
Replying here as I don't have a SHP account:
It is interesting to note in the KQ1 directory listing that Andrew posted on SHP that the room numbers implied by that listing are not the room numbers used in the final game. The final game has rooms 0 to 95 and a bunch of scripts in the high range.
-
The starting cluster numbers for those are another example where they can't actually have ever been on the floppy disk. So that must be a directory that was on the hard disk from which the game files were copied. It could be for a different game. We might be able to work out what game it was. The kq1.SC file is a strong clue that it was KQ1 though. Is it possible that different releases of the game used different script numbers? It is possible (but seems unlikely) that the number specified in the .SC file for the script is different than what the filename implies.
-
I've been running searches on Google for a few weeks now, trying to find something that explains the phenomenon I've been seeing in the unused parts of end-of-file clusters. It helps to know the proper terminology, and last night I finally found a document that mentioned the phrase "slack space". After doing a few searches with this, I started finding a lot more discussions about this part of a partially used sector. It is sometimes also referred to as "file slack".
My theory previously was that DOS was doing some sort of "over copying", filling the unused part of the cluster with whatever happened to be in its buffer beyond the end of the data that directly related to the file it was copying. About a week ago I started wondering instead whether DOS was copying the file from the hard-disk to the floppy disk in whole sectors, so for the last sector used by a file, I was starting to wonder whether it was copying the whole of the sector from the HD rather than only to the end of the file data. It occurred to me that maybe this was easier for it, and probably faster.
But if this were the case, then surely there must be references to something like this on the Internet.
Well this morning I found the following document that appears to describe behaviour similar to my first theory:
http://www.drtomoconnor.com/3100/3100lect08a.htm
Here's a copy-and-paste of the interesting paragraph:
Clusters vary in length depending on the operating system and size of the partition. Larger cluster sizes have more forensic value. With normal 512 byte sectors, if there is not enough data in the file to fill the last sector in the cluster, DOS/Windows makes up the difference by padding the remaining space with data from the memory buffers. When this happens (often with a rather unsophisticated criminal or on an older machine), the file slack to look for is something called RAM slack that potentially contains information from previous work sessions as well as whole, complete sentences in their original wording. If the computer has been left on for several days, the file slack areas will contain a tremendous amount of information. RAM slack technically refers to the last sector of a file, but that is only because of the way borrowing from memory works in this case. When a computer realizes it doesn't have enough RAM, it draws upon additional sectors to round out the block size for the last cluster, and then, another type of slack is created -- drive slack. Unlike RAM slack which comes from memory, drive slack may very well contain what was stored on the computer long before, not just from previous work sessions. If you are looking for things on a computer from a previous owner, drive slack is where to look.
Maybe the first theory was closer to the mark then but it doesn't seem to explain some of what I've been seeing. I'll lay out some examples when I get a chance.
Here's another web page discussing the terminology:
http://niiconsulting.com/checkmate/2006/06/file-slack-vs-ram-slack-vs-drive-slack/
-
I just read another page claiming that the slack between the end of a file and the end of the sector is usually RAM slack, and the slack beyond that to the end of the cluster is "drive slack". The latter would be whatever was already on the disk and the former would be from RAM at the time of the copy.
-
There's a good description of RAM slack on pages 752-753 of the following book:
https://books.google.co.uk/books?id=t0J2QcUtMKcC&pg=PA752#v=onepage&q&f=false
RAM slack is created from the buffers on Windows and DOS-based systems. Buffers can be thought of as plumbing used by the operating system, and the number of buffers on a Windows/DOS-based system is set in the CONFIG.SYS file, for example, buffers=30. The buffers reside in the random access memory (RAM) of the computer system, and the contents of the buffers can potentially contain any data or data fragments created, viewed, or printed during a computer work session. RAM slack is written to the first sector of the last cluster of the file. In Microsoft-based computers, sectors are small storage blocks that hold 512 bytes of data. Clusters are made up of varying numbers of sectors, depending of the size of the storage device and the operating system involved. RAM slack will always be in the first sector of the last cluster of the file, but RAM slack cannot contain more than 512 bytes of data. RAM slack is only a concern on Windows, Windows 95, Windows 98, and DOS-based systems because Dinows NT, Windows 2000 and Windows XP-based computer systems automatically scrub all relevant data contained in RAM slack.
And another good description here to complement the above, which gets even closer to describing my initial thoughts on what might be causing this:
https://books.google.co.uk/books?id=J8h8VWUmDuYC&pg=PA63#v=onepage&q&f=false
While all modern operating systems pad the written sector with null bytes, this was not always the case. MS-DOS and older DOS-based version of Microsoft Windows would pad the rest of the sector out with whatever contents of memory happened to be next to data being written. These data, between the end of allocated data and the beginning of previously allocted data, became known as RAM slack. Given this, RAM slack could potentially contain data that were never written to the disk, such as cryptographic keys or passphrases.
-
The following Dr Dobbs article mentions something very interesting:
http://www.drdobbs.com/beware-of-file-slack-attacks/184405835
Flaws in software that copies files has been known to read beyond the logical end of a file and up to the physical boundary of the final cluster by mistake, transferring file slack from one place to another when the slack should be ignored by software that manipulates logical files. Whenever slack is copied as part of a file copy, an unknown quantity of potentially sensitive data is at risk of theft. For this reason, tools exist that will wipe file slack automatically as files are created or copied.
The above description matches my second theory on how this data may have got in the end of the sector, which was that the DOS copy tool (or a particular version over it) might have been copying whole sectors from the HD to the floppy disk, including the final sector being copied in whole.
It is possible that the original Sierra game disks suffered from three different issues (all of which must have been common in the 80s):
- Deleted Files: Data present on the floppy disk already, from deleted files. I think this would be rare to find on an original Sierra game disk (since they probably used new disks a lot of the time), but possibly the AGI specs fragments example, and clearly the AGI interpreter code mentioned earlier in this thread, were examples of this type.
- RAM Slack: When the last sector used by a file is padded out with data that is in the buffer from earlier I/O activity. This must have been read in to the buffer at some point after the PC was most recently turned on. I guess we don't know how often they turned off their PCs in the Sierra office.
- Flaws in file copy tools: Where a file copy tool reads beyond the end of a file, up to the end of the sector or cluster, thereby copying over the slack with the file. It is possible that the additional slack that such a tool is copying with the file was originally the result of RAM slack or deleted files at some point in the past, potentially months or even years in the past.
The following is a report of a very similar observation to what we're seeing with the Sierra disks, except that in the example below, it is on the Microsoft C 5.1 disks from 1988, and the fragments are from emails. It is from an OS/2 site, but the author points out that it isn't clear what host OS was used to created the disks:
http://www.os2museum.com/wp/careful-with-that-buffer/
-
As mentioned in the "Original SCI syntax" thread, disks of AGI releases sometimes contain remnants of internal data.
Below are some fragments of the original AGI specs. Missing parts are marked as "@@@".
I have now verified that the AGI spec fragments came from the original LSL1, disk 1. The exact fragments that HWM posted appear in that order on the disk. The interesting bit is that they all appear in the second half of a cluster. For 720K disks, the cluster size is 2 sectors, i.e. 1024 bytes. So in every case where the AGI spec fragments appear, the cluster offset of the start of the AGI spec fragment is 0x200 (512). And in the cases where the "slack space" starts before the beginning of the second sector in the cluster, the slack in the first sector is always unrelated to the AGI fragment that appears in the second sector of the cluster, for example:
Cluster# 81: EOF, appears after the end of: _LL.BAT
0020 20 20 20 20 20 20 10 00 00 00 00 .....
0030 00 00 00 00 00 00 0F 50 EA 0E 80 19 00 00 00 00 .......P........
0040 47 52 41 46 20 20 20 20 4F 20 20 00 00 00 00 00 GRAF O .....
0050 00 00 00 00 00 00 43 45 9C 0E 95 19 1C 03 00 00 ......CE........
0060 43 50 43 20 20 20 20 20 4F 20 20 00 00 00 00 00 CPC O .....
0070 00 00 00 00 00 00 F7 72 D9 0E 96 19 02 02 00 00 .......r........
0080 52 45 4C 4F 43 20 20 20 4F 20 20 00 00 00 00 00 RELOC O .....
0090 00 00 00 00 00 00 22 71 0E 0D 97 19 BA 01 00 00 ......"q........
00A0 53 54 41 54 55 53 20 20 4F 20 20 00 00 00 00 00 STATUS O .....
00B0 00 00 00 00 00 00 F2 84 39 0D 98 19 50 02 00 00 ........9...P...
00C0 4C 4F 41 44 50 52 4F 47 4F 20 20 00 00 00 00 00 LOADPROGO .....
00D0 00 00 00 00 00 00 E5 85 33 0B 99 19 F0 03 00 00 ........3.......
00E0 44 49 52 20 20 20 20 20 4F 20 20 00 00 00 00 00 DIR O .....
00F0 00 00 00 00 00 00 E6 85 33 0B 9A 19 CE 01 00 00 ........3.......
0100 57 52 54 42 4F 4F 54 20 4F 20 20 00 00 00 00 00 WRTBOOT O .....
0110 00 00 00 00 00 00 E8 85 33 0B 9B 19 0D 04 00 00 ........3.......
0120 44 4F 53 4C 4F 41 44 20 4F 20 20 00 00 00 00 00 DOSLOAD O .....
0130 00 00 00 00 00 00 FC 40 DE 0E 9C 19 10 04 00 00 .......@........
0140 42 4F 4F 54 20 20 20 20 53 20 20 00 00 00 00 00 BOOT S .....
0150 00 00 00 00 00 00 19 52 3E 0D 9D 19 96 1D 00 00 .......R>.......
0160 43 4F 4C 4F 52 20 20 20 53 20 20 00 00 00 00 00 COLOR S .....
0170 00 00 00 00 00 00 D0 85 33 0B A6 19 BE 01 00 00 ........3.......
0180 52 45 41 44 44 49 53 4B 4F 20 20 00 00 00 00 00 READDISKO .....
0190 00 00 00 00 00 00 EC 85 33 0B A9 19 0B 01 00 00 ........3.......
01A0 4D 45 53 53 41 47 45 20 53 20 20 00 00 00 00 00 MESSAGE S .....
01B0 00 00 00 00 00 00 21 71 90 0E AA 19 83 10 00 00 ......!q........
01C0 4C 4F 41 44 20 20 20 20 53 20 20 00 00 00 00 00 LOAD S .....
01D0 00 00 00 00 00 00 3C 52 3E 0D AD 19 34 17 00 00 ......<R>...4...
01E0 4C 4F 41 44 50 52 4F 47 53 20 20 00 00 00 00 00 LOADPROGS .....
01F0 00 00 00 00 00 00 D7 85 33 0B B1 19 AB 14 00 00 ........3.......
0200 73 20 69 73 20 64 6F 6E 65 20 62 79 0D 0A 09 61 s is done by...a
0210 6E 69 6D 61 74 65 2E 6F 62 6A 28 29 2E 0D 0A 0D nimate.obj()....
0220 0A 65 6E 64 2E 6F 66 2E 6C 6F 6F 70 28 4F 42 4A .end.of.loop(OBJ
0230 45 43 54 2C 20 46 4C 41 47 29 0D 0A 09 52 65 73 ECT, FLAG)...Res
0240 65 74 20 74 68 65 20 66 6C 61 67 2E 20 20 49 6E et the flag. In
0250 63 72 65 6D 65 6E 74 20 74 68 65 20 63 65 6C 09 crement the cel.
0260 6E 75 6D 62 65 72 20 61 74 20 65 61 63 68 20 61 number at each a
0270 6E 69 6D 61 74 69 6F 6E 20 63 79 63 6C 65 2E 0D nimation cycle..
0280 0A 09 57 68 65 6E 20 74 68 65 20 6C 61 73 74 20 ..When the last
0290 63 65 6C 20 6F 66 20 74 68 65 20 6C 6F 6F 70 20 cel of the loop
02A0 69 73 20 72 65 61 63 68 65 64 2C 20 73 74 6F 70 is reached, stop
02B0 20 63 79 63 6C 69 6E 67 20 61 6E 64 20 73 65 74 cycling and set
02C0 20 74 68 65 20 66 6C 61 67 2E 0D 0A 0D 0A 72 65 the flag.....re
02D0 76 65 72 73 65 2E 63 79 63 6C 65 28 4F 42 4A 45 verse.cycle(OBJE
02E0 43 54 29 0D 0A 09 43 79 63 6C 65 20 74 68 65 20 CT)...Cycle the
02F0 6F 62 6A 65 63 74 20 66 72 6F 6D 20 74 68 65 20 object from the
0300 63 75 72 72 65 6E 74 20 63 65 6C 20 6E 75 6D 62 current cel numb
0310 65 72 20 74 6F 20 63 65 6C 20 30 2E 20 20 57 68 er to cel 0. Wh
0320 65 6E 20 63 65 6C 20 30 0D 0A 09 69 73 20 72 65 en cel 0...is re
0330 61 63 68 65 64 2C 20 73 74 61 72 74 20 61 67 61 ached, start aga
0340 69 6E 20 61 74 20 74 68 65 20 6C 61 73 74 20 63 in at the last c
0350 65 6C 20 6F 66 20 74 68 65 20 63 75 72 72 65 6E el of the curren
0360 74 20 6C 6F 6F 70 2E 0D 0A 09 0D 0A 72 65 76 65 t loop......reve
0370 72 73 65 2E 6C 6F 6F 70 28 4F 42 4A 45 43 54 2C rse.loop(OBJECT,
0380 20 46 4C 41 47 29 0D 0A 09 52 65 73 65 74 20 74 FLAG)...Reset t
0390 68 65 20 66 6C 61 67 2E 20 20 44 65 63 72 65 6D he flag. Decrem
03A0 65 6E 74 20 74 68 65 20 63 65 6C 20 6E 75 6D 62 ent the cel numb
03B0 65 72 20 61 74 20 65 61 63 68 20 61 6E 69 6D 61 er at each anima
03C0 74 69 6F 6E 20 63 79 63 6C 65 2E 0D 0A 09 57 68 tion cycle....Wh
03D0 65 6E 09 63 65 6C 20 30 20 69 73 20 72 65 61 63 en.cel 0 is reac
03E0 68 65 64 2C 20 73 74 6F 70 20 63 79 63 6C 69 6E hed, stop cyclin
03F0 67 20 61 6E 64 20 73 65 74 20 74 68 65 20 66 6C g and set the fl
These observations appear to confirm what was claimed regarding slack space, i.e. that the final sector used by a file is filled to the end of that sector with "ram slack", and any remaining sectors in the same cluster are filled with "drive slack" (i.e. deleted file content already on the disk). In the case of the second type of slack, I still have a feeling that it wasn't actually on the floppy disk, but was instead "drive slack" on the hard disk from which it was copied, and that a flaw in the copy tool copied the "file slack" (both "ram" and "drive" slack) along with the file, up to the end of the last cluster used by the file, on to the floppy.
One thing that I find very strange is that all the literature in the computer forensics domain claim that "ram slack" is the result of randomly selected RAM contents. It implies that DOS somehow randomly chose what part of RAM to "fill" the rest of the sector with. I've even found references that implied that DOS had to do this in order to function properly. I find both of those suggestions very difficult to believe. Most of us here are programmers, so we can imagine that randomly selecting memory contents to "pad" the rest of a sector with is actually an overhead to the file writing process rather than an unavoidable necessity. It seems far more likely that DOS's memory buffers dealt with sectors as a whole and that the final sector was simply written out as a sector-sized chunk from the memory buffer and that if the last part happened to have data from an earlier read file, then that would be written out with the final sector. It is possible that this additional "slack" was described as being random, simply because anything could be in the memory buffer from earlier reads, and that perhaps through assumptions made by people reading that, it became described as "randomly selected" memory contents. I actually find it quite worrying that the computer forensics literature on this is often coming out of the legal domain and what they are stating seems to be a misunderstanding of what is probably happening. I'm considering running a few tests using DOS 3.2 and DOS 3.3 on a couple of PC emulators to see if I can reproduce the generation of slack space, in an attempt to understand what was happening.
I was also planning to send a few questions Tim Patterson's way to see what his thoughts on this are. He wrote the original version of DOS. It may be that the whole slack space thing was introduced after his time, but I'm fairly sure it was there by DOS 3. All of the Sierra original disk examples I've seen are on floppy disks that were formatted with either version 3.2 or 3.3, and one that was formatted by Norton Utilities (which gives no indication about the DOS version).
What does all this have to do with AGI and SCI? It's the process of understanding how slack originated. I'm hoping that we might be able to find more original SCI source code on original game disks. We've already found fragments of BRIEF macros, which we know that they used. One of the macros even appears to be one of their custom BRIEF macros. So if this can appear in the slack space of a file's final cluster, and AGI specs, then it is certainly possible that SCI source code could appear in there.
As a final note, I read a few days ago on another site somebody asking the question of whether CDROMs from the DOS and earlier Windows days also suffered from slack space. It's quite possible I suppose. It is worth checking out.
-
I have sorted the various fragments of the source code found in the unused sectors of my Space Quest II Version 2.0D 720K into separate files based on what the first line comment said. It's not a complete interpreter source, obviously, but I found it enlightening that the PS/2 models 25 and 30 with their MCGA graphics adapter apparently caused Sierra much trouble (see EQUIPCHK.ASM).
-
Hey thanks. That's great. - Is Space Quest II Version 2.0D 720K where the AGI interpreter source code fragments mentioned earlier originally came from? I remember asking the question of where it came from but can't remember if it was answered.
-
I'm not sure if this has been discussed before (probably has been but I'm guessing in a long lost forum somewhere), but I've been wondering what version of the AGI interpreter the above source code fragments would have come from. NewRisingSun says above that the attached ZIP of source fragments came from SQ2 version 2.0D. According to HWM's interpreter list, that version of the game used interpreter version 2.936.
http://agisci.altervista.org/SVLIST094.TXT
2.936 - King's Quest 3 2.14 [3/15/88] *
Space Quest 2 2.0D *
Space Quest 2 2.0F *
According to the AGI specs, version 2.936 had either 175 or 177 commands (different sites have a different number for this, but it doesn't really matter for this discussion). I don't think that the AGI source code fragments from the SQ2 v2.0D 720K disks is for version 2.936 of the interpreter though. Command 175 is discard.sound, but I can't find any evidence of that command in these source code fragments. There is a SOUND.C and a SOUND.H file, and inside SOUND.C there are functions to cover loading sounds, playing sounds, and stopping sounds, but nothing for discarding. I think it would be in that file if this were the 2.936 version. PushScript and PopScript exist though, so that means commands 171 and 172 are there. The source code for hold.key is not present but there is a HOLDKEY mentioned in the memory map, so I think we can say that command 173 was present. - I don't think command 174 is present though. Nothing related to it that I can find, in fact the priority base appears to be referenced as a constant in the code. Interpreter versions 2.915 and 2.917 (and possibly others around them) had 173 commands. I suppose that is the most likely version that the source relates to then.
Prior to the introduction of discard.sound, there were only discard.pic, discard.view, and discard.view.v. For both the pic and view discard commands, they have matching codes in the script event buffer that is used as part of the saved game restoration. A safe bet would be that discard.sound also had an action code in the script event buffer. A guess would be that it would be the next number after the code for overlay.pic. To be certain I guess I'll have to write a small test logic that uses discard.sound and see what appears in the saved game under 2.936.
Edit: I've just performed that check with a discard.sound running on 2.936. Nothing was added to the script events according to the saved game file that was produced. I can see the load.sound but not the discard.sound. I added both as part of the same logic compile.
-
This is information that I think is complementary. About Space Quest 2, version 2.0C game interprete 2.917 and 2.915 were never released. I have searched for a very long time without ever finding an answer so far. See this blog: https://www.goodolddays.net/game/id%2C435/Space-Quest-II-Vohauls-Revenge.html
"We don't really have version 2.0C nor was it ever available."
I take this opportunity to salute the memorable work of @NewRisingSun. I keep all your patches as references. Thank you very much.
-
Is Space Quest II Version 2.0D 720K where the AGI interpreter source code fragments mentioned earlier originally came from? I remember asking the question of where it came from but can't remember if it was answered.
Six years later and I've finally been able to see and verify this myself. Back in 2016, I was living in the UK, and my original SQ2 disks were stored in a box on the other side of the world. I now have my original disks again, and they are version 2.0D. Today I dumped a disk image of both disks and can confirm that one of them has the original AGI interpreter source code fragments on it.
I think I bought SQ2 in 1989, and it wasn't long after that that I started trying to work out the game formats. Can't believe I didn't see this AGI interpreter source code back then. I guess I was looking specifically at the data files themselves and didn't think to look at the disk sectors.
-
I was looking over the AGI interpreter source code on the SQ2 original disks again, as you do, and started thinking about the contributors mentioned in the change history comments. Obviously Jeff Stephenson is the biggest contributor, according to the comments, but two other people are mentioned.
JAS = Jeff Stephenson
The other two sets of initials mentioned are DCI and PMK.
I did a double take when I saw PMK. Surely it couldn't be Peter M Kelly?! ;D
The only candidate that I can find is Paul Krasno. He is listed as an Interpreter/Development System developer for King's Quest 4. The four developers listed in the AGI version are: Jeff Stephenson, Robert Heitman, Chris Iden, and Paul Krasno. I don't think Paul is mentioned in the credits for any other game. I assume his middle initial is M then.
And I assume that DCI is Chris Iden, and that he goes by his middle name.
As far as I can see, the earliest date mentioned in a change history comment is 17/02/87 from JAS, and the latest is "87 Sept pmk". The early date probably reflects when they started keeping a change history comment in the files, and the later date might be close to when the source code was copied onto the master disk used for SQ2. The AGI interpreter file on the SQ2 2.0D original disks is dated 18th March 1988.
-
I doubt that it could be. Beside being a fad developer, Peter is from Aus. BTW, he joined this board a while back during your absence, but has not posted here for some time.
-
Yes, I was joking about it being Peter Kelly. I just thought it was amusing that there was someone at SOL with the same initials ;D
Yeah, I remember when Peter joined. You'll see in the posts that I welcomed him at the time. I think we were chatting about some new ideas he had for AGI.
-
Huh, I only check in on this forum very occasionally and happened to just notice this post!
I can confirm it wasn't me, I was only 7 years old at that time :) I would have absolutely *loved* to have worked there back in the day.
-
I can confirm it wasn't me, I was only 7 years old at that time :) I would have absolutely *loved* to have worked there back in the day.
Yeah, Sierra was also where I wanted to work "when I grow up". I guess that might have been true for most of us, assuming we were still at school when we were introduced to these games. Sadly things had moved on by the time I was out of school and University.
The best time to work there would have been between 1983-1989, the AGI years ;D. Nothing against SCI, obviously, but by that stage, the teams had started to become fairly big, so gone were the days when only a few people worked on each game. I think it was quite cool that people like the MacNeill brothers created Goldrush, and the Murry siblings created Manhunter. I'm sure the Ewing brothers could have created something back then ;D.
-
Back to the topic of original AGI interpreter code fragments, I have noticed that one of the KQ3 original game disks also has fragments of AGI interpreter source code on it. Nowhere near as much as the SQ2 2.0D 720K disk 1 though, but it is a fairly continuous run of several files, mainly ASM code. I can see a couple of overlaps, e.g. the IOBJSBRS.ASM file, but apart from that, it is mostly new, and mostly Hercules graphics related ASM code (e.g. HOBJSBRS.ASM, HGRAPHX.ASM and HJMPTBL.ASM), which I think was missing from the code extracted from the SQ2 disk.
Kind of makes me want to complete an exhaustive search of all the remaining permutations of original AGI game disks. This would have to include not only every AGI game, but also every released version of every AGI game, including all disks of both the 360K and 720K versions of each game version. Not sure how many disks that will end up being, but probably quite a few I would imagine.
(Edit: Not sure if this concept of deleted file content remaining behind on the master floppy disk applies to other systems, such as Amiga, Atari, Apple, etc, but might be worth looking there are well)
-
Cool find Lance!
I really wish you'd be able to extend your search to all versions in all the platforms... :)
-
Six years later and I've finally been able to see and verify this myself. Back in 2016, I was living in the UK, and my original SQ2 disks were stored in a box on the other side of the world. I now have my original disks again, and they are version 2.0D. Today I dumped a disk image of both disks and can confirm that one of them has the original AGI interpreter source code fragments on it.
I think I bought SQ2 in 1989, and it wasn't long after that that I started trying to work out the game formats. Can't believe I didn't see this AGI interpreter source code back then. I guess I was looking specifically at the data files themselves and didn't think to look at the disk sectors.
Hi lance.ewing!
I thought I had version 2.0D, but no, it's version 2.0F. So the most common one. :-\ Could you give me a copy of your 2.0D version, because I plan to translate this game into French and I like to have all the existing versions to compare them. An installed version if possible, as I don't have a floppy drive. It would be very kind of you. :)
One curious thing is that the GOG version uses the Interpreter 2.917 of version 2.0C. While it is version 2.0F.
You know what they say about Sierra heroes: "There Can Be Only One".
My best.
-
Hi Threepwang! Well, not sure how common knowledge this is, but most of the Sierra game versions are available on archive.org, including version 2.0D of Space Quest 2. My disks unfortunately had some bad sectors, but the archive.org disk images seem to be good.
Let me find the links...
https://archive.org/details/002579-SpaceQuest2VohaulsRevenge
You can download the two disks by going to these URLs:
https://archive.org/download/002579-SpaceQuest2VohaulsRevenge/002579_space_quest_2.7z/002579_space_quest_2%2Fdisk1.img
https://archive.org/download/002579-SpaceQuest2VohaulsRevenge/002579_space_quest_2.7z/002579_space_quest_2%2Fdisk2.img
No idea who put them there.
I found no less than three different versions of KQ4 AGI on archive.org (2.0, 2.2, and 2.3), and that used to be the rare AGI game! It allowed be to test my "skip the starting question" patch in AGILE. I confirmed the patch worked in all three of those KQ4 AGI versions.
Edit: You can copy the individual files out of the disk images using dosbox. Simply mount the disk images as drives, e.g. imgmount a c:\disks\sq2_disk01.img -t floppy
-
Hi Threepwang! Well, not sure how common knowledge this is, but most of the Sierra game versions are available on archive.org, including version 2.0D of Space Quest 2. My disks unfortunately had some bad sectors, but the archive.org disk images seem to be good.
Let me find the links...
https://archive.org/details/002579-SpaceQuest2VohaulsRevenge
You can download the two disks by going to these URLs:
https://archive.org/download/002579-SpaceQuest2VohaulsRevenge/002579_space_quest_2.7z/002579_space_quest_2%2Fdisk1.img
https://archive.org/download/002579-SpaceQuest2VohaulsRevenge/002579_space_quest_2.7z/002579_space_quest_2%2Fdisk2.img
No idea who put them there.
I found no less than three different versions of KQ4 AGI on archive.org (2.0, 2.2, and 2.3), and that used to be the rare AGI game! It allowed be to test my "skip the starting question" patch in AGILE. I confirmed the patch worked in all three of those KQ4 AGI versions.
Edit: You can copy the individual files out of the disk images using dosbox. Simply mount the disk images as drives, e.g. imgmount a c:\disks\sq2_disk01.img -t floppy
Oh that's great, thanks for responding so quickly. OK, that's a wrap! ;)
Can you confirm that version 2.0C cannot be found? Because I'm still in doubt.