This game was such an insane strong part of my childhood that when I think about the present day many years later it feels like a dream. I try to imagine in my current life having the same sort of "connection" to a game and it just feels impossible. Everything around me feels like "just" a game, show, material object, whatever... but space quest 2,3,4 all feel like they are fundamentally part of my DNA, intertwined with it.
Double Dragon II: The Revenge for DOS from 1989 was distributed on two floppy disks, one of which contained the entire source code in a deleted archive file, invisible from the DIR command but easily recoverable: https://tcrf.net/Double_Dragon_II:_The_Revenge_(DOS)
This might be a silly question, but how does this even happen?
I would have thought they’d finalise the game, get a ‘master’ of sorts and then send it to a mass production facility - how would the deleted archive end up on the master? Did they accidentally copy it over, then remove it before shipping?
Edit: definitely should have read the comments here before adding my own!
Yeah, Duplication Houses usually duplicate the disk sector-by-sector, instead of on a file system level. (This makes a lot of sense, because it allowed the disk to contain any file system). But that also means that data that was still on the physical sectors of the disk got copied as well, regardless of whether the file system on the disk was still referencing that data.
>Yeah, Duplication Houses usually duplicate the disk sector-by-sector
I think they went even deeper. From the vintage computing nerds I saw on YouTuber, I think the duplication houses were replicating the raw magnetic flux off the disks as-is, since game studios were implementing some crafty low level anti-piracy measures on the golden disks to ensure that if you did sector level copies at home you wouldn't be able to run the game.
I wonder if anybody ever made an analog flux reversal-level disk copier out of consumer floppy drives. I'm not an electronics person but it sounds like it would something like a "dubbing" tape deck. Provided the reading and writing drives' spindle motors and heads were synchronized (which, presumably, could be done with an encoder on the reading drive) I would think it would be a fairly simple device. All the analog circuitry for reading and writing would be in an off-the-shelf floppy drive.
The hardware you're talking about you can buy today. It's used by retro computing geeks working in SW preservation. Pretty sure it also existed back in the day. The point wasn't to make copying impossible, it was to make it impossible for home users.
Hence the cracking scene: home users would get pirated version of the games, with the copy protection removed from the code.
P.S: if I'm not mistaken in some cases original, legit, disks were physically damaged on purpose (for example with a hole being physically punched at a precise location) and then the copy-protection would try to write something at that spot and re-read it. If the write/re-read succeeded, they knew the floppy was good and hence they knew it couldn't be an original disk.
That doesn't make sense, no? Most of these disks had their read-write tab blocked and so the floppy drive would just operate in read-only mode anyways.
That doesn't make sense, no? Most of these disks had their read-write tab blocked and so the floppy drive would just operate in read-only mode anyways.
You are right that that doesn't make sense so I may be remembering incorrectly.
I'm nearly sure the disk physically had holes, on purpose, though. So maybe the copy-protection was simply trying a regular read, expecting it to fail... And if it didn't throw an error, then it'd know it was a copy.
I remember downloading some kind of commercial digital forensic software that, came with cracking instructions: A PDF or image with measurements for where to drill a hole into your disk and at what size :D Never tried it, so I don’t know if it would have worked, but I’ll always remember it.
The hardware you're talking about you can buy today.
Only sort of. The Greaseweazel and its ilk are sampling digital data. They're "seeing" the data after the analog front-end on the drive has processed it.
I'm talking about something that's more like reading the raw magnetic flux reversals in the analog domain, amplifying the signal, and writing it to another disk w/o ever leaving the analog domain. Exactly like a dubbing tape deck.
Edit:
I wrote this in another comment up-thread but, for completeness:
The Applesauce[0] project seems to do what I'm talking about. It samples analog signals from the drive, rather than the output of an ADC in the drive. No doubt the clever architecture of the Disk II drives is what allows for this.
I'm not aware of any direct copier, most disk duplicators that were sold to regular people were just a bunch of floppy drives with regular disk copy software.
These days, there is the delightfully named Greaseweazle (https://github.com/keirf/greaseweazle) and similar devices to _read_ disks at a magnetic level, but I'm not sure if there is something to _write_ disks. I don't see any reason why such a thing couldn't exist, I'm just not aware of it.
Tech Tangent has a good in-depth video about imaging disks for archival purposes if interested: https://www.youtube.com/watch?v=UxsRpMdmlGo
...similar devices to _read_ disks at a magnetic level...
It's not, though. It's reading the disk after the drive's analog-to-digital converter has had its way with the analog flux transitions coming off the head. There's auto gain control circuits in there, and a pre-amplifier, and finally the ADC. Greaseweazel and its ilk are closer to the flux than just reading the disk in the conventional manner but it isn't actually sampling the raw flux reversals.
The Domesday Duplicator is closer to what I'm taking about. You can do software-defined manipulation of the sampled analog signal. In its case, it's a software-defined laserdisk player. (One could do the same w/ VHS, for example.)
I'll try to dig up a good Vintage Computer Festival talk from a guy who was recovering analog signals from old tapes and reconstructing the data by building a software-defined "tape drive" and using signal processing algorithms that would be applicable in the software-defined radio domain.
It occurs to me that such an analog duplicator wouldn't need fancy FPGAs and high-speed digital signal processing that didn't exist back then. It would "just" need very clean analog circuitry and decent motor control.
Edit:
Here we go. Video of the talk: https://www.youtube.com/watch?v=sKvwjYwvN2U
A comment I made about it: https://news.ycombinator.com/item?id=31939703
Edit 2:
It looks like the Applesauce[0] project does what I'm talking about. It's sampling analog signals from the drive, rather than the output of an old ADC. Very cool.
[0] https://wiki.reactivemicro.com/Applesauce
There's some discussion here[1] about analog recovery of floppy data and some past discussion[2] from HN.
[1] https://scarybeastsecurity.blogspot.com/2021/05/recovering-l...
Yeah it'd be interesting to have a full analog floppy reader/writer for data recovery. Might as well make it fast enough to read early hard drives (at least through early IDE) too.
Probably could stuff quite a bit more data using today's methods on a disk, too, even though in the scheme of things it'd be pretty pointless... but why should that stop someone? ;)
but I'm not sure if there is something to _write_ disks.
Greaseweazle can also write arbitrary disk formats to disk.
KryoFlux (https://kryoflux.com) reads and writes magnetic flux data.
I'd love to see the same for optical media. So many early sample and loop packs stored on weird ass mixed cd file systems with equally arcane DRM that are on the verge of disc rot.
The TRS-80 Color Computer's "Sands of Egypt" employed this very strategy. They planted a glitch on a certain sector of the disk. If memory serves, you could copy the disk, but doing so would "fix the glitch." The game checked for the presence of the glitch on the disk and wouldn't run without it.
That was such a common technique that it's odd to talk about just one game in particular doing it.
In some cases this would be a sort of DRM, sure. But it certainly wasn't universal. Most smaller-midsize distribution houses just used something like this:
Or, if they were very small, they would just use multiple smaller scale devices that could do 2-4 copies at a time, like this:
https://pbs.twimg.com/media/Dgr_J-NUEAAHZ0I?format=jpg&name=...
Some of the expensive ones of these could do magnetic signal copying, but most just did sector-by-sector.
At least, that's my understanding. Bit before my time.
That makes sense, I do remember some Commodore 64 games that even a Nibbler couldn't properly duplicate, and how some people modified their 1541 drives to have a different timing to work with some of that stuff.
Thanks for the explanation, that makes it much clearer.
This reminds me of the low-level disk cloning utilities crackers used to circumvent copy protection, and how they competed to build faster ones.
I always liked the cases where people have broken open ROMs only to find that the compilation process stuffed a bunch of directory and filenames in the silicon. It's funny to think that in a time when literally every byte cost money there's a fair number of carts that have people's FAT entries burned into them.
Well... every byte costs money, but it's really quantized. If your game doesn't fit in a power of 2, you have to pay more to get the bigger one (and maybe even a lot more if you also need to include a mapper, plus using a mapper means you've got to adjust your code and what not). But if you're using 75% of your quantized space, you don't need to be that picky.
It is quantized, but not necessarily to a power of two. RAM and flash sizes of 3x2^n are common even in contemporary microcontrollers, and it’s clearly possible to use fewer R chips then your bus decoder supports in the less integrated computers of yore.
And once you have a project with a fixed amount of ROM, either because the hardware is at a point in its life cycle where you can’t change it, or it’s third-party hardware and you have to use what you get, or because you’re already at your BoM budget, then your software will behave like an ideal gas - it will expand to fill the available ROM. This happens because until you run out of ROM, you will write your software in whatever way is easiest to get your job done. But then once you run out of ROM, you will go back and look for something that you can make smaller. Then you can add a few more features or whatever, until you run out of space again. This process will repeat until you’re done, but your ROM will always be nearly full.
Software complexity following an ideal gas law is an analogy that works in a ton of ways… time (you’ll keep adding stuff until you’re running close to a deadline at which point you have to actually decide what to cut), head count (complexity will rise to match the number of people working on it, since people aren’t just gonna sit idle), speed (it’ll get slower until it’s “noticeable” on the dev’s machine, at which point it gets optimized), etc etc etc.
I’ve tried to use this analogy to PM’s who have trouble understanding why adding more engineers to a project doesn’t make it go faster: the software expands to fill its container.
The last time I built a ROM (in the 90's) it had 7 free bytes of space. That was not a coincidence. It was larger than that and then optimized until it hit a nice power of two and then I stopped optimizing.
a time when literally every byte cost money
Every chip cost money, right? If your game shipped on a single 1mbit EEPROM, it cost the same amount of money whether it was 90% full or 99.99% full. There was of course a cost incentive not to go over 1mbit, or to get your size down enough to fit onto a 512kbit EEPROM.
See the 'ideal gas' comment at https://news.ycombinator.com/item?id=40460650
DynaMike from that page deserves special mention for accidentally including some browser history with... you guess... https://tcrf.net/DynaMike
This has happened quite a few times:
https://tcrf.net/Category:Games_with_uncompiled_source_code
It's usually more common on CD games with the directory/file being unlisted, but it's always interesting to find partial source code bakes into ROMs. Last I heard/understood, it was usually as some sort of white space padding; in the case of CD-ROMs and an artifact of the sector-copying mechanism in disk duplicators.
Also, the bytes cost money, but if you have a 32K ROM (because the next lowest size is 16K) and only 28K of data, it's not costing anything extra to fill that space.
This was the second multiplayer game I ever played, when visiting a friend’s house, on his dad’s computer. The first, on the same computer, was a DOS version of Spacewar!
If I remember right, we’d reach a boss and the game would freeze, so we never managed to beat Double Dragon II.
Good memories.
Still not as bad as when a company I worked for managed to press and ship a ton of CDs that included a virus.
Still could be worse. For example, the King's Quest 8 Master CD-ROM contained a copy of King's Quest 8.
???
Did you mean to type something different? Obviously the King's Quest 8 master will contain King's Quest 8.
That's the joke. It's a joke about the quality of King's Quest 8.
KQV was the best one. The later ones jumped the shark.
King's Quest 8 (Mask of Eternity) is a terrible game. King's Quest is an adventure game series. It is known for hand-drawn 2D character sprites moving over hand-drawn 2D backgrounds, collecting items and solving inventory puzzles.
This entry in the series tried to "modernize" it by adding in 3D graphics and RPG-like combat elements, which completely went against everything the series stood for. The 3D graphics were around N64 quality and aged very poorly.
It's considered to be a game that killed off the whole Adventure game genre.
That was Gabriel Knight 3 with the infamous 'cat hair moustache' puzzle right? ;)
It was a true catastrophe.
Ouch - no where near that bad but once I was working on a children's online game. The game was large (500MB or more), and this was still pretty early on in ADSL roll out - lot's of kids still had dial up. So we offered a CD with the game on for free.
After 800 of them arrived for me to start mailing out, they found a small issue with the game, which they patched - "don't worry the kids will just have to run the patch the first time they play" - I tested it, the patch was 800MB...
I didn't send any of the CDs out.
How the heck could a 500MB game have an 800MB patch? Sounds like someone had no idea what they were doing…
I just managed the website - I wasn't involved in the game, but it didn't seem to be that well managed from my outside perspective.
I think part of the issue was there was not system to 'patch' - so the far larger download in theory allowed them to add smaller patches to the game in the future, but that didn't happen as far as I remember.
I don't think we even ended up opening all the levels of the game as the uptake wasn't that great.
I worked at a game company in the 90s that shipped a strategy game with a bug where the AI would literally never attack the player. I think the cause was some last minute copy/paste while rushing to deliver the game to the publisher. It was discovered before the game hit the shelves, but the decision was made to ship it anyhow and release a patch, which had just become a somewhat reasonable practice with all those 33.6k modems out there.
Worked on a small game development project in university. It was meant to teach us project managment and coding skills. It took one whole trimester, 3 months or so, and we had a working game. The only deliverable we had not met was handing the mastered game over to the tutors. The Project manager reserved this responsibility for himself. He put the disc in a PC. Messed around with it. Handed it in. Got on his motorcycle and left the state.
Turns out he handed over a blank disc. We almost all failed, lots of students suddenly low on HD space had started purging their laptops of the files. The coders had to come in on semester break to put something together to hand in. There was one guy who backed up everything, out of a team of 30 or so people.
There was a game startup a long time ago that shipped the heavily instrumented debug build of an Xbox game instead of the certified gold master.
I don't think there's any particular secret sauce in the AGI engine, such that competitors would benefit from a leak. There are probably other examples I can't think of, but Hugo's House of Horrors was basically an AGI-style game made by one guy just a few years later.
Beyond the initial novelty of a graphical adventure, Sierra games worked because they put a ton of effort into creating those graphics and actually writing the game. The tech isn't nothing, but it's a small fraction of the end product.
I sometimes wonder if leaked source code has any value, especially code like that that doesn't contain secrets that could be taken advantage of by hackers (ex: keys, backdoors, ...).
The leak obviously doesn't come with any license, so you can't reuse that code for your own products, at least not if you don't want to get sued. So it means that in order to take advantage of the code for your own work, you need to read it, understand the techniques, and apply them to your own work in a way that doesn't smell like copyright infringement. More often than not, it is harder to do than going from scratch, and in cases it is advantageous, how often will you get a real competitive advantage?
Developers often write code from scratch even when they could use open source code that is well documented and with a permissive license. Reading code is often harder than writing it. Even just rebuilding it may be challenging.
It may facilitate piracy, but barely, games often got cracked and distributed within days, and the copy protection may not even be part of the source code.
If I'm not mistaken, Microsoft now owns all of the old Sierra IP (if I'm not mistaken, the chain of custody was: Sierra -> CUC -> Cendant -> Havas -> Vivendi Universal -> Activision Blizzard -> Microsoft) and I wouldn't expect Microsoft to sue over old source code to a 40-year old game engine with a graphics resolution of 160x200. In fact, given that they've been gradually opening source code for DOS from the same era, they might even be convinced to make an official release of it.
If they still have the full/ original source, which is a big if.
Information and useful example code were much harder to acquire in those days. Learning to build working software was immensely harder than today because there was nothing to build on. There was almost no meaningful open source on MS-DOS, and certainly no open source game engines.
In that environment a widespread leak of the AGI source might have been significant, at least as an inspiration that would have provided a blueprint of exactly how these most popular PC games of the era were made.
Sounds like the words of someone that grew up in the era of "not having to write ASM or C to get something done"
You had probably multiples orders of magnitude less people that could even speak the language, let alone do something coherent with it.
The learning rate of your internal neural net was still dialed up near max, vs. today, where it's rapidly decreasing and thus things you're exposed to aren't nearly as capable of shaping your internal weights.
My favourite part is no-one apparently discovered the source code sitting on the disk for an entire generation.
“Surprisingly, no one appeared to have noticed that this happened, not Sierra, not their competitors or their customers, and it was only discovered decades later, the first known discovery of it by online user NewRisingSun in October 2016.”
Reminds me of the recent breakthroughs in Tetris and Super Mario Bros. When I played these games as a kid, I would have thought they’d be forgotten relics decades later, impossible for anyone but the most dedicated hobbyist to stand up and run, let alone keep learning new things about them. The internet and emulators breathed new life into those earlier games and computing.
I guess your last sentence answers your question. I'm sure some people had found the deleted files, but because that would before the internet was ubiquitous, it was not generally known or recorded.
Yeah, this could well be true. I was using a Hex Editor a lot back in the late 80s and early 90s, and that involved many of the Sierra games. Most of the time I was looking at the files installed on a hard disk though, as I generally installed the game from the floppy to the hard disk first and assumed I had everything. I think it would have been rare for me to be viewing the whole floppy disk of a Sierra game sector by sector in a Hex Viewer, although I did do that a lot for some disks. I'm surprised I didn't spot this back in those days. I bought this version of Space Quest II back in 1989.
My memory of those times was that floppy disks were fragile enough, and software expensive enough, that you would take the original disks out only to install the game (or cough make a backup copy for a friend) and then carefully put them back in the box. So it's not too surprising to me that people weren't studying them closely enough to spot this.
Or it was recorded, but it was on fidonet or some bbs system that didn't make the transition to the WWW and no one old enough to remember actually remembers or cares anymore.
There are people who archive old software using modern tools like flux imaging to allow making perfect disk copies. It might be someone noticing data in free space while imaging one of these disks.
I love the change history comments. They show a high level of attention to detail and craftsmanship, at a time long before source control tools made this kind of thing obvious (and honestly, even after CVS/SVN/Git it still wasn't obvious to a lot of people).
This post also makes me think of the famous 'No Silver Bullet' essay[1], which in 1986 predicted that software would more or less continue to be written they way it was then, by programmers, painstakingly, one instruction after the other. The similarity of the game engine code (along with the comments) in the OP, to something I might have written today, bears this out, I think, almost 40 years (!) later.
To this day I see too many git commits like "fix" and "stuff".
No need for personal attacks.
When I became a lead dev, one of the first issues I had was a 55 y/o dev who begrudgingly adopted git but consistently included commits like: “Monday morning commit”, “changed some things”, “commit”. He also refused to delete issue template examples and included it all with his own additions.
In the entire time we worked together over a few years, he refused to adapt to the rest of the team.
I have younger devs who do the same thing. Some people just do not want a process at all and do not play well with others.
Kind of a tangent but I wonder how the serial numbers on the floppy disks were generated. They're clearly not sequential and the length differs between version 2.0D and 2.0F.
SER# 312929011101963 (15 digits)
SER# 3129289101202698 (16 digits)
I was also wondering about these numbers when putting the article together. The photo of the 2.0D disk is of my own personal copy of the game. I assume the number is unique to that disk, but I haven't spent any time at all researching that. I wonder if someone has.
They might have intentionally obfuscated it, maybe to conceal how many disks they produced (https://en.wikipedia.org/wiki/German_tank_problem ).
Just XOR'ing the real serial number with a secret key that has exactly as many bits as the (padded) serial number is entirely sufficient, though my experience tells me that at that time, folks tended to do more complicated (and ironically, much less secure, not that it matters much here) things. Basic cryptography literacy wasn't as common then, as unencrypted and unauthenticated communication was the norm, even on most networks.
as unencrypted and unauthenticated communication was the norm, even on most networks
That it worked at all was pretty amazing :)
I think you just nerdsniped me:
312929011101963 2.0D TFA
312929011100925 2.0D [1]
312928072902102 2.0D [2]
312928091704272 2.0D 5.25" [3]
3129289101202698 2.0F TFA
312922022211663 2.0F [4]
752923060122148 2.0F [5]
272929011600468 2.0F [6]
272929052600081 2.0F [7]
The 16 digits seems like a freak.
[1] https://archive.org/details/space-quest-ii-ms-dos-disk-1-of-...
[2] https://www.mocagh.org/loadpage.php?getgame=sierra3pack-alt
[3] https://www.sierrachest.com/gfx/games/SQ2/box/03_m1.jpg
[4] https://www.mobygames.com/game/128/space-quest-ii-chapter-ii...
[5] https://ia802300.us.archive.org/12/items/spacequest_ii_kfx/s...
[6] https://www.worthpoint.com/worthopedia/space-quest-ii-seirra...
[7] https://www.tradera.com/item/340851/630607300/space-quest-ii...
There were a couple posts on this yesterday too (although no discussion there either).
https://news.ycombinator.com/item?id=40438604
https://news.ycombinator.com/item?id=40437834
It's weird how stories sometimes take a few tries to catch on.
I was wondering the same thing. I was the first post, then saw the second one. I was quite surprised to see this third one really take off like this. Yeah, perhaps it does depend on the time of day? - A big thank you to smcameron for reposting.
It looks like third time's a charm. I for one think it's a feature to have stories competing for the reader's attention and just take their time to bubble up to the front page.
And this is quite an interesting story. Since the Sierra games' source code was never publicly released, it makes me think how radical id were to open source their games at the time, in the 90's.
Might depend on what time of day they are posted?
Back when release artifacts were hand crafted, these often contained leftovers that weren't meant to be shipped, like cut content [1] or debugging symbols [2]. When I stumbled upon debugging symbols hidden inside the data archive of the demo version of the video game I'm reverse-engineering, it was an unexpected but very helpful surprise.
Nowadays with CICD, automated builds and other modern development practices it probably happens less often.
[1] https://tcrf.net
CICD pipelines can also work the opposite direction. No one looks into several thousands of console output unless there is some error. Also the tests are likely to pass even with excessive content in the final release package.
So my intuition is rather opposite. It may happen more often. Or at least CICD makes it more likely to happen than manual building. There might be other factors too.
I'd say manual building has a chance of a slip-up every time it is done, whereas automated building has a chance that it will slip-up every time it is executed.
I have a suspicion that good practices like CI/CD are not as common a feature of games development as one might suspect.
I've been doing a lot of reverse-engineering of synthesiser ROMs lately. The Yamaha DX9 ROM has some fragments of the firmware's symbol table embedded in the empty space left in the binary[0], along with a big block of 6303 code that was probably from whatever development system they used. It's a really amazing feeling when you stumble upon things like this! I'm such a nerd about these things that I feel like some kind of software-archaeologist, getting a small glimpse into the past. Finding this sent me down a really deep rabbit hole trying to find out more information about what development tools Yamaha might have used. I never discovered anything definitive, but reading the documentation on contemporary devtools gave me a real appreciation for modern workflows!
0: https://ajxs.me/blog/Hacking_the_Yamaha_DX9_To_Turn_It_Into_...
I too like to reverse engineer synthesizer things, and I did it for the Yamaha A-samplers back in the day, producing a management tool that sped up the basic operations for Yamaha A-sampler disk users .. I used a BeBox to do a lot of raw i/o and analysis of raw disk sectors, as BeOS had some nice tools for filesystem hacking, and through this I managed to build a filesystem driver (for Windows) which worked well enough to get Yamaha's backing.
If you ever get the motivation to reverse engineer the Yamaha ROM's for the A-samplers, lets get in touch. I have a lot of interest in this realm ..
(EDIT: great work on the DX9/DX7 thing .. as an original user of both synths when they were released, this is really amusing ..)
Oh god the repressed memories. I believe there was a SCSI thingy to do some basic sysex (or whatever format they were using) and presets save/load from 68K macintoshes?
For the A-samplers? There are a number of tools out there for manipulating the A-sampler data with a PC - I wrote one of them (DiskY) which makes filesystem management over SCSI with a Windows PC a lot smoother/faster than using the onboard OS, and there is also b.Zone, which is an editor that uses MIDI CC and Sysex to do editing.
Together, they make the A-sampler .. almost .. usable. ;)
I would love to dig further into the A-sampler ROM and figure out a few more of its secrets. I'd especially like to know the exact reason why the A-samplers SCSI subsystem is .. so .. darn .. slow .. so maybe there's a chance to dig into this at some point.
Looking through the repo, some of the assembler [1] looks odd:
getShdwOfst:
xor bh,bh
mov bl,al
mov di,bx
shl di,1
shl di,1
shl d1,1
...
[1]: https://github.com/lanceewing/agi/blob/main/src/CMGRAPHX.ASM...
It was hand-written for a system without multi-bit shift instructions.
8086 shifts were 1 bit at a time (2 cycles for a register shift.) or using cl for the count (8 cycles + 4 cycles/bit for a register shift).
constant multi-bit shifts were added in the 80186.
8088 did not have a barrel shifter, so multi-bit shifts would have been expensive and non-interruptible over multiple clocks. Perhaps game devs just avoided them out of habit.
Not sure this would have counted as “losing it to the public domain” - accidentally leaking the sources doesn’t negate copyright (presumably just trade secrets stuff by Iqbal)
Yeah, sorry, that was a poor choice of words on my part. I have reworded the sentence slightly to hopefully avoid the legal implication.
ah yeah that's fair :D
This exact situation actually happened all the time. The cutting room floor lists about 500, in various states between just a little accidental included code to most of it:
Thanks for the link. I hadn't previously visited that site. Very interesting.
From a quick check, I can't see this particular Space Quest II disk's AGI interpreter uncompiled code mentioned in there yet. Do you agree?
I have noticed that the same thing happened with a King's Quest III disk, in fact it looks like it may have happened around the same time as the Space Quest II occurrence.
https://tcrf.net/Space_Quest_II:_Vohaul%27s_Revenge
This AGI code is mentioned at the bottom of the Space Quest II page. It's not technically "source code for the game" so it doesn't fit in the category I linked above.
Ah yes, the two modes of disk erase failure: 1) the "quick format" that just re-wrote the FAT and root directory, leaving data, and 2) the immediately recognizable 0xE5 (σ in the 437 codepage). I used to use the Norton disk editor tool (IIRC, part of Disk Doctor) to explore my drive from time-to-time and it was somewhat fun to try and piece back together deleted files. In some cases, it was actually because I had accidentally deleted something important and UNDELETE wasn't good enough to get it back.
In one hare-brained moment, I decided to see what would happen if I turned off the DIR attribute bits on all of the directory entries in the root of my drive to see what would happen in DOS. The stress of trying to find a boot disk to edit those attributes back left a few decades of PTSD, though I'm sure that taught me some valuable, subconscious lessons. Eventually I did recover from that mistake!
I blew away a boot sector once playing that game....
When I was young, I discovered the joy of writing TSR programs in assembly. TSR stands for "terminate and stay resident", basically background programs in DOS. It's somewhat similar to what you would call a "daemon" in Unix, though much more "free form" and low level.
One such early TSR of mine hooked the disk services interrupt (INT 13h I believe), which got invoked whenever you want to access the disk through the BIOS (so, almost always), and my program then output a little "click" over the speaker. The result was as if you took the already very audible seeking of spinning hard disks and made it really, really loud. It wasn't even my idea, just a fun premise to fiddle with hooking interrupt handlers.
I compiled/assembled the TSR, ran it, and typed "DIR". The expected clicking came out of the speaker with every disk access, which indeed sounded funny and great, but at the end of the directory listing, an error appeared. I typed "DIR" again, and now listing the directory failed entirely.
In a bout of incredible stupidity, I typed "CD \" to change to the root directory, and "DIR" again. Now I couldn't list my root directory. I reset my computer and... DOS did not boot anymore.
It suddenly became immediately clear what I had done. My interrupt handler, after outputting the click over the speaker, obviously had to call back into the old handler, to actually service the requested disk access. When saving and restoring the registers that instruct the original handler what disk access to perform, I must have messed up in a way that it, at least sufficiently often, converted a read access into a write access. I don't remember the details, probably just flipping a single bit would do that. But effectively I've overwritten every sector of my root directory (and the original working one) with junk.
So I had destroyed at least my root directory, and hence lost access to all my data.
With lots of work I probably could have pieced my root directory back together. Nowadays, I'd probably have taken it as an exciting challenge to write a program that heuristically does just that by itself. Back then, I'm pretty sure I just abandoned the file system and started over.
I sometimes wonder about the commercial impact of source code leaks. In this case, nobody noticed until the product was commercially irrelevant, but what might have happened if some competitor had noticed?
My guess is probably nothing. Having the interpreter source code is a liability for other companies in case of an infringement lawsuit. Are there good examples where a source code leak actually led to significant consequences for a company?
My hunch is that companies tend to be paranoid and vastly overestimate the commercial importance of their source code. Are there really that many realistic opportunities to copy secrets from one mature source tree to another and commercially benefit from it? These code bases are likely totally different, use different design patterns, different internal APIs, data models are different, maybe even different languages.
Anyone who has done integration work between two totally foreign-to-each-other code bases knows that the integration effort is often greater than just writing the code from scratch.
The biggest risk is probably someone getting their hands on the entire project, including code, art assets, build infrastructure, and just compiling an identical program to release under their own name. But that would be obvious and probably easy to prove/litigate.
Are there really that many realistic opportunities to copy secrets from one mature source tree to another and commercially benefit from it? These code bases are likely totally different, use different design patterns, different internal APIs, data models are different, maybe even different languages.
When you're stuck failing to make something work, it can be a large benefit to be able to look at how somebody else managed to make it work. Sometimes it's a bit you forgot to set on a register somewhere, sometimes it's a sequence of operations that tickles a hardware bug which can be avoided by doing things in a different order. On a higher level, sometimes the issue is that the A API is implemented as "return <error>" and only the corresponding W API is actually implemented. Or the trick to make the API work is to cast one of the many objects you already got into a non-intuitive poorly-documented interface, allowing you to call a method which returns yet another object which allows you to do what you actually want. And so on.
FormMaster duplication machine
Anyone got any links with more info about this device?
I found it very difficult to find references to it online. There is a reference in the "Hackers" book by Steven Levy to Sierra On-Line having one (he uses the name "Form Master"), and former Sierra employees have mentioned it as well but with the two words run together as FormMaster. As I couldn't find much more, I'm not sure which form of spelling is correct.
https://www.google.co.uk/books/edition/Hackers/JwKHDwAAQBAJ?...
There is a photograph in a September 1983 issue of a Japanese magazine called "LOGiN" of one of Sierra On-Line's disk copying machines but the article doesn't mention it by name. I wonder if it is the FormMaster/Form Master machine.
https://archive.org/details/login-september-1983/LOGiN%20-%2...
As an aside, that September 1983 magazine is the earliest clear reference to the development of King's Quest that I could find. It isn't mentioned by name but it is obvious that it is King's Quest that is being referred to.
Thank you for the links! I kind of expected a machine with 10+ floppy slots (: I think I just wasn't really aware of the year this machine was produced.
This article has a bunch of stuff asserted as facts that just aren't.
As mentioned in another comment, there was nothing technically advanced about AGI itself. If other studios wanted to get into adventure games they didn't need to steal AGI to do it. And no one with a functioning brain would have used a stolen game engine for a commercial game. Companies don't want to give away their code but in the case of adventure games it's not because they are worried about their competitors.
The other assertion that's off-base is that this would have been a sackable offense. No. Sierra still had legal protection against competitors using their game engine. This goof, while a little embarassing, had no real financial or security or any other damaging implications for the company. I doubt anyone would have gotten any more than a talking to about how to avoid it happening again.
Yeah, that is a fair point. I was a little too eager and dramatic with my wording. I have now removed the bit about it potentially being a sackable offence, as I feel you are probably right regarding that. Someone else in the comments made a similar point.
Your point about the legal protection against competitors is a good one too. I've tried to reword the bit that suggested it might be drastic. Let me know if you think it reads better now. Thanks.
Yep, I think it's better, FWIW.
Between 1987 and 1993, I prepared around nine master disks for two Mac apps. I always used a fresh floppy and had a long list of checks to ensure the disk was correct. Thankfully, all came out right, especially when some were used to make 100k disks. It's a good thing no one has to do this anymore!
They do, though its called "docker layers"
I have seen layers that were:
base
add tools
add source code
compile
delete source code
delete extra tools
(ship - why is the docker image so large? Oh well, storage is cheap...)
At least you can replace it quickly if you find it broken. Back then, we could only afford to make an update once. When you mailed out the update disk, you had to charge for it ($10 or so, disk, mailing container, printed instructions, postage, and label); if you sent out 100k bad disks, you had to eat $1M. If it was version 1.0, it went into a box and was shipped to distributors, retailers, and mail-order, and you might never even know who the end user was.
Always do sector-level imaging of old disks, at minimum, for archiving. ("Flux"-level images taken with something like Greaseweazel are even better.)
Precedence like:
"analog" (multi-bit samples) flux > digital (1bit samples) flux > track > sector > block > files.
Greaseweazle. Back in the day, there was Central Point's Copy II PC Deluxe Option Board, or the rarer Central Point's Copy II PC Enhanced Option Board able to copy physically-damaged-for-copy-protection media.
For copy protection, NevrLock and CrackAid. I still encounter DOS malware and a lack of proper cracking in some poor quality releases on the interwebs. For archival purposes, it's generally better to buy several physical copies of a game and Greaseweazle it and end up with at least 1 complete and unspoiled version.
I wonder if this is the only copy of that source code that survives? It's extremely common for source code from that era to be lost to time, especially from defunct companies. From a historical and preservation viewpoint this "blunder" may be a miracle.
It happened twice at Sierra, around the same time in fact. I have found part of the AGI interpreter source code on a King's Quest III disk (version 2.14, 720KB version, disk 1). There is nowhere near as much, but lucky for us, it happens to include a few complete files that were not on the SQ2 disk. So that increases the total amount of source a bit.
I have checked other Sierra disks, and so far the SQ2 and KQ3 occurrences are the only ones I know of.
With memory map, partial source code and reverse engineering tools, it should be possible to recreate the whole thing.
Fascinating! What a fortuitous mistake for historical preservation purposes. Also a good lesson in why media overwrites are important.
MWC was a C compiler from the Mark Williams company that was very popular in those days.
Since publishing the article, I discovered some fragments of not yet linked compiled AGI interpreter obj files from the slack space on a KQ3 disk that mentions the MWC version number used, which was MWC86 V2.3.8.
I also discovered a directory entry in the slack space of another sector on the same disk that has the name of the executable, MWC.EXE, the size and the timestamp:
MWC.EXE 18420 23-Oct-1985 15:17:32
These days a great modern equivalent is the excellent HxD Hex Editor written by Maël Hörz.
If you are on macOS, check out Hex Fiend: https://hexfiend.com
I'd pay for it if it wasn't free (and BSD licensed, to boot) anyway.
Back in the 80's I worked on a "multimedia engine" very similar to AGI, which had the requirement of not using MS-DOS - the customers who would use this engine for their titles, simply didn't want to pay an MS-DOS license.
The engine thus used BIOS calls, and I implemented enough basic disk i/o functionality that we could boot from the floppy, load the engine, and stream the bytecode straight from raw floppy sectors into the engine, which would then display vector graphics on either CGA or EGA monitors (the multi- in multimedia). This worked well enough for two titles to be released to a few tens of thousands of customers, who enjoyed them well enough.
A days before the clients started shipping the titles they'd built with my engine, I went back to look at the floppy disks for the "master engine" series, which would be the last update to the engine itself, just to be sure - and by then I needed a raw disk copying routine for another project, so I took a close look at the prior results to see if there were any major issues.
Sure enough, in the 'empty' sectors of the engine disks I'd produced, I'd managed to include things that looked suspiciously like a DOS FAT-based filesystem. This was because I'd simply reused the same floppy to produce beta versions of the engine disks, and someone had taken one of my old master beta disks and used it 'temporarily', to copy some files for themselves, on MS-DOS machines. Lucky I caught it - we really didn't need to include a resignation letter in the empty spaces of the multimedia titles.
Anyway, this story brought back fond memories of making a multimedia engine that didn't use MS-DOS .. and also, 40 years later, reminded me to always check the edge cases before you ship a master/gold release to customers who will ship it to tens of thousands of people .. I suppose the modern equivalent is to clean up the git repo before shipping, or have a procedure for vetting commits, lol. Okay, I gotta do that on some of my juniors' projects, brb ..
It did apparently happen with quite a few games, where the Master Disk wasn't a brand new disk but some random disk that someone formatted and sent over to duplication. There are other games where cut content or early source code was recovered that way because the duplication house didn't work on a file system level but duplicated the entire disk as-is.
This still happens at some firms every so often with source code and private signing key sets.
The issue is usually management making an arbitrary call on who is part of the development pipeline. Thus, for a time some contractors and partners may get a backup of the build tree or temporary repository access (if you catch the "new" users.)
It is harder than one would think to keep things confidential...
Cleaning up after one of these leaks is another set of problems, but usually at that point it is better to jump ship.
Best of luck, =)
The Famicom version of Air Fortress has a ridiculously large amount of stuff unintentionally making it into the ROM. There is some uncompiled ASM code in there, some MS-DOS directory listings, some text strings from one of the EXEs used to build the game, and even more.
The Japanese cartridge was 128+128KB large.
Then they built the US NES version. Most of the 128K of graphics data was duplicate graphics, or unused. There was about 36KB of actual unique graphics. They shrunk the graphics down to 32KB by removing an image of a planet from one of the endings, and shipped it on a 128+32KB cartridge instead of a 128+128KB cartridge.
Source: https://tcrf.net/Air_Fortress
Same feelings but specifically about Space Quest II.
I played SQ I way later in life, and SQ III didn't resonate as strongly with me. The rest were no longer EGA "text input" games either.
SQ II brings back memories. I learned some of my English with it, too. I remember the feeling of satisfaction when I discovered I could "rub berries" on Roger Wilco ;)
I loved SQ but it frustrated me so much. As a kid I could NOT get anywhere with it without one of those hint books with the red garbled text or calling the Sierra Hint Line (on my parents bill...).
All of the Sierra games, as much as I loved them, would just piss me off with dying constantly. Having to do a specific thing at a specific time or dying. You had to do SUCH specific things. I remember the park/lake scene and pulling people over driving in PQ being impossible until I found hints.
I'm not sure I ever beat a Sierra game outside of LSL. Maybe a KQ and potentially a QFG, but I definitely didn't beat a PQ. I LOVED PQ3. I think out of all of them that SQ was the one that really, really pissed me off, and scifi is my favorite genre, with no other scifi adventure games back then (other than beneath a steel sky which I also got nowhere with), total bummer.
Whenever I discovered LucasArts (DOTT I think was first), Legend of Kryndaria, Discworld, etc, it was such a breath of fresh air. There was a Black Cauldron game that I LOVED.
I remember all of these games so vividly. I don't think I remember many other games nowadays to that degree. Baba Yagas hut, the wizards house, cleaning the stables in qfg, Otto standing outside the bar.. Could very well be because I died so much and played scenes over and over..
edit: This made me want to give them a go again.. https://playclassic.games/games/point-n-click-adventure-dos-...
edit2: I forgot how slow you walk.. ugh. There are a LOT of modern Adventure games now on Steam. It's had a bit of a comeback and they're usually affordable games. I'm playing the Plague Doctor of Wippra right now. All of the Wadjet Eye games are really cool too.
Yes, Space Quest was fun overall but dying was not. I think it was LucasArts who started to make adventure games where you can't die.
My perhaps rose-tinted memory is that the deaths were pretty comic in Space Quest.
Some of the best parts of the SQ4 talkie are the sarcastic narrated death screens. And SQ5 has neat animations.
The manual tells you to "save early, save often" for a reason.
My subconscious has just dredged up the memory "you take a good long whiff of the acid, and .. whoah, talk about clean sinuses!". That might have been from the later remastered SQ I even?
Sounds like Space Quest 4. That one had a Nose/Smell and Mouth/Taste icon.
The narrator (Gary Owens) was also amazing in the CD version.
I enjoyed the death sequences too.
I was sure to have plenty of savegames before I tried anything, of course.
You can die in Monkey Island. Twice.
One is a Sierra Spoof complete with a Sierra death dialog. That one lets you continue: https://www.youtube.com/watch?v=A6F55am-rOY
The other has to do with the fact that Guybrush can hold his breath for 10 Minutes. And only ten minutes. https://www.youtube.com/watch?v=Ah5o3aAeZso
If I remember correctly that is the only real game over in any later Lucasfilm/LucasArts adventure game.
EDIT: I just remembered the jumping puzzle in Indy3 where you died all the time when jumping on the wrong tile. Or the Knight Statue that axed either Indy or his father. Or you got shot when you punched Hitler... You could also die in Manic Mansion and Zak McKracken.
Lucasfilm games killed you quite a lot. LucasArts stopped doing that.
Discworld MUD or some other game? The MUD is still alive and well!
They probably mean Discworld (1995)/Discworld II/Discworld Noir, which are all point-and-clicks.
You're probably right. I did not know about them, will have to check them out. Thanks!
They are great. 1 & 2 might have aged less well than Noir.
Some puzzles are quite nonsensical, true to adventure game standards of the day. Sierra gamers found it too easy, people new to the genre too hard.
Eric Idle as Rincewind is amazing though.
Interesting! When I played SQ II, it was a pirated copy and I had no hint book. Also, no access to the Sierra Hint Line from my country. And no Internet websites to google the answer, either. So I beat them all by myself. All of those games were pirated, and the hardest was SQ 4 which would randomly crash to desktop, and I wasn't sure if this was supposed to happen, or some badly cracked copy-protection thing, and to this day I still don't know.
Spanish is my native language, so the inspiration to try things like this was pretty cool: "mooom, how do you say "rub" in English? I think I'm supposed to rub these berries on the dude!"
Oh, yes. Those early adventures didn't let you teleport to the next screen either, you had to very slowly walk all the way. I used to use savegames for fast teleporting: "ok, this didn't work, I want to go back to that other screen but it's so far, let's restore my savegame".
Space Quest 4 was one of the only times in my childhood that I found a legit error in a game. There is one part in the space mall with the ice rink where you can go into an arcade. You get a quest to do something, but if you then try to click on one of the arcade cabinets it will cause the game to throw an error.
I remember it because I actually called Sierra to tell them about it. The person on the other end even fired up the game and verified it, then told me vaguely that the solution to the puzzle was something else. I'm guessing the tech support weren't allowed to give hints because they had a paid tip line.
Wait, I'm pretty sure that's the crash to desktop I'm remembering! It was definitely in the arcade. I tried randomly clicking to avoid the Time Police (or whatever those androids were called) and the game would error out. I was never sure if it was an error or copy-protection. I remember winning the game, but don't remember what I did to bypass this (remember: no access to any hint line).
So it was an actual bug, and not copy-protection after all? Wow.
It wasn't obvious that you had to _administer field sobriety test_??
SQ III had a hilarious Sierra HQ part.
Oh, don't get me wrong, I liked The Pirates of Pestulon. It's also the last EGA SQ to my recollection. Call me weird but the limited palette of EGA graphics appeals to me.
It just didn't have as big an impact on my young self as SQ II.
Scumsoft Software and Elmo Pug, the fat dude that walked around whipping the programmers. Scumsoft Software was of course Sierra On-Line, and Elmo Pug was Ken Williams. They did get away with it, Ken Williams approved :D
The sierra adventure games presented an overly simplistic world view and then the devs subverted that. It still amazes me today.
Leisure Suit Larry III, released around the same time as SQ III, also has a very similar fourth-wall-break at the end of the game. The Sierra team must have had Blazing Saddles on their minds in the late '80s.
I actually attribute my high typing speed to the practice I got with OPEN DOOR, TAKE KEYCARD, CLOSE LOCKER, LOOK CAULDRON. Police Quest, King's Quest, Space Quest. Good memories.
Haha, I remember this with Leisure Suit Larry 1. When you knock on the door at Lefty's Bar, a guy opens a hatch in the door and asks "What's the password?". Then you need to type "ken sent me" and press enter. I was 7-8 years old at the time, and it was hard for me to type "ken sent me" in the 5 or 10 seconds you have to give him the password. Sometimes I asked my dad to help me out, so he could write it for me hehe. But we found a trick after a while, you could just set the game to SLOWEST at that part, and you had much more time to enter the password. Good times!
I am almost certain that I played an EGA version of SQ IV, even if there was also a "VGA optional" version.
Wow, are you sure? I thought SQ IV was VGA only; I certainly played it in VGA.
Regardless of whether an EGA version existed, the style of the sprites was already different. The sprites from SQ I, II & III belong to an earlier era -- hard to describe, but if you remember them you must know what I mean. More abstract & pixelated, designed for low-res and low-color displays.
They bring back memories! I don't want to wax nostalgic -- but I will anyway. I've come to think the more primitive/abstract the graphics, the more they engage the imagination. Similar to Scott McCloud's concept of "closure" from Understanding Comics, maybe? While playing SQ II, I could believe the world was enormous even when it was actually quite limited. In the jungle of planet Labion, I believed I was exploring a vast wilderness. Games with more realistic graphics -- even when they are sandbox games -- don't give me the same feeling anymore. Of course, I'm also older and more jaded, so there's that too ;)
Space Quest III was my first Sierra game and it definitely has that hold. But so many of their games from that period really were so special, Police Quest II, LSL III, Hero's Quest in particular I ended up playing roughly together.
There was something really magical about those text driven EGA Sierra games. To me it was a goldilocks level of emotional/creative connection between Infocom and the later point and click VGA variants.
I bought Space Quest II and III on the same day, back in 1989. I think it was on a Saturday morning, and by the end of the next day, I'd already finished Space Quest III. But Space Quest II took a lot longer, more like 2 months to finish. Having lived the game for longer, my memories of SQ2 are fonder.
That's wild. Never played II but I do know it's regarded as a classic.
What do you feel the difference was for you? Just did a quick google and this person puts both on the level of the hardest Sierra games: https://www.youtube.com/watch?v=W-1XyI72hvY
I can't remember what the specific puzzles in Space Quest II were that I got stuck on. I think the first one was probably still down on the planet. And I can't say for certain now why I was able to finish SQ3 so quickly. I guess things just seemed to flow. I certainly finished SQ3 quicker than any other Sierra game I played, by quite some margin. The others took at least a few weeks, if not months.
This was obviously back in the days before the Internet, and I hadn't yet discovered BBS boards either, so it was just me and my brother trying to work it out.
I feel that for music. During my teenage years I used to listen to the same songs over and over on my walkman. I still remember 99% lyrics to the whole albums. The music used to have such a strong connection.
Nowadays there are 1000+ songs in my playlist I can't even recollect 20% lyrics nor there is a chance in hell that I would listen to every single song on the entire album let alone every single song by tthe same artist.
It's like if I don't like the first 10 seconds, it's hide song and Spotify makes sure I never have to listen to that again. Even though some of my all time favorites are songs I hated at first but then there was no hide song button.
Sorry I digress but yeah the connections you make in childhood are really something. I just hope it's my age and not the technology responsible for this and the youth of today feel the same connection too.
I still try to find time to sit down and listen to an album from start to finish - it's kind of like the musical equivalent of spending an hour in a gallery exhibition of a single artist's work.
I started with 6 but then went back and played 1-5 and yeah, definitely part of my core person.
Actually SQ also is intertwined with one of my favorite “early internet” stories.
There used to be (back when websites were primarily hosted by geocities and bored college students) a fan site for space quest. I reached out to the owner of one of the biggest SQ sites and shared my love of the titles and love of the site (via email of course). I was about 14 at the time. He reached back out and told me he had copies of the original games he could send me for something like $40. This was all of the original games in their original boxes on floppy. Even then I was a bit worried about just sending some dude across the country $40 for something with the hope they’d actually come through (this was like… 1997) but he absolutely did. A couple short weeks later and all the games arrived exactly how he described them. I was over the moon. True believer overnight. I think it’s like the solar core of whatever optimism I hold onto anymore.
Jess, if you’re out there, you’re a real one. Hope I connect with you again someday.
Both Jess and his website are still out there: https://wiw.org/~jess/roger2.html
I have the same feeling about the first games I played "seriously". You know, some games you know of and have played as a kid, but some game was the first game that you consciously invested time in to finish it. For me it was some super weird Shrek-themed clone of MarioKart on the Nintendo GameBoy Advance. As a kid I really didn't see it as a MarioKart clone, just a fun game I wanted to finish entirely.
I absolutely forgot about it and only recently saw some YouTube video about what a weird game that was. Seeing that game again with its soundtracks and weird sound effects and clunky mechanics really triggered that exact feeling of a "connection" that you speak of.
I have very similar feelings. My dad worked at a steel mill and was friends with a 'computer guy' at the mill who gave him a copy of SQ2 for me to play at home. I played that game relentlessly but was pretty young so I was confused by a lot of it.
Anytime I was really stuck, I would ask dad to ask the 'computer guy' how to get past a certain point and I seem to remember he would kindly provide hints, but not outright solutions.
It's probably been 35 years since, but I even remember with some detail a dream I had related to that game. It really had a big impact on me.
I was just delighted that "free little dude" worked on rescuing the creature early on in that game. It's also the first game I've ever played of the sort (as like a ten-year-old) and I spent weeks and weeks with it.
Same, this was the 1st game I had on the first PC we had at home. And I didn’t even know English so I played through all of it using an English-Spanish dictionary and lots of patience.