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)
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.
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.
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.
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.
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.
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.
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:
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 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.
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.
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.
> ...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.
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.
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? ;)
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.
> 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.
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 have the original release of Leander. There are no holes in the disks. The code on the disk doesn't write anything besides hiscores. There is a protection routine exactly where he says there is, however what it does is check for a long track. It waits for the index pin, reads lots of data from the track, then looks to find two sync marks in the data it read, and they're at least a certain distance away from each other. No lasers, no holes, no writing. Standard long track protection. Here's the whole routine: https://pastebin.com/c1wnaJBP
If you watch the original video, the person OP is talking about referred to an arbitrary hole that they added themselves/the disk producers added. The index hole is a normal feature of floppy disks that are "flippy" (usable on both sides).
In addition, OP wasn't talking about the index hole, which was only used on a few platforms. They're referring to the index PIN, which is one of the signal wires that comes out of the floppy device.
The index pin gives you information on what sector is currently under the head, but after reading the code OP posted and the Amiga documentation, you're correct that this was specifically referencing the index hole in the CIA's flags. So my apologies, you were correct and I'm eating crow.
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.
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.
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.
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!
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 ..)
I can find the A3000 firmware ROM online[0], but unfortunately I can't seem to find the service manual/schematics anywhere. Reverse-engineering firmware from the late-80s onward is a completely different kind of animal though. It's much, much more time consuming due to the much more complex hardware, and the fact that it wasn't written by hand in 8-bit assembler. Having said that, I'm always looking for cool synth reverse-engineering ideas! I'll have to keep this one in mind!
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.
Can't remember to save my life if it was a TX 802 or an A-Series Sampler to be honest. Probably the latter because I fully remember the grating loading times.
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.
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.
I remember playing SQ2 on a "laptop" my dad brought home from work. It had 4 shades of dark blue and shimmered like crazy when anything moved. What a cool experience.
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
SQ2 is only “hard” because of all the inane unwinnable situations it puts you in. Didn’t help an alien at the beginning of the game? His friends are going to murder right near the end. Forget to search your locker at the second screen of the game? Unwinnable. That’s not even mentioning the long pixel walking maze the game makes you do twice.
SQ3 was actually fun and fair. I don’t remember a way to make the game unwinnable, it let you backtrack to get items or mercy killed you on the spot.
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.
That's amazing you guys got through that game so quick with no outside help. They did sell hint books that started off blank with a marker to uncover the hint. I got one for most games I played. As a rule I'd get stuck on some part for more than an hour, come back a day later, and still be stuck, then I'd uncover a hint. Generally using it a half dozen times to get through a game.
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.
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'm not sure how my dad (Mechanical Engineer) would have figured this out, but I think he ran the DOS equivalent of `strings(1)` to dump the list of strings in old Sierra games (I want to say KQIV), to find hints about what might be possible. I wonder if he remembers. It was probably much cheaper than whatever Sierra hint hotline I wanted to call at the time.
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..
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.
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?
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.
> 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...).
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!"
> I forgot how slow you walk.. ugh.
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.
> 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.
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.
LMAO I have no idea how much money it cost but I do remember my parents yelling at me for it. I'm pretty sure they charged by the minute. I wonder how many 8 year olds like me called them and how they talked about that in the break room. Super funny to think about as an adult.
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!
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.
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.
That scene at the end, where they land in the car park of the "Redwood" building in Oakhurst where the Sierra offices were, was one of my favourite parts. Like many of you I'm sure, I dreamed of one day working for Sierra in that building.
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
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 ;)
I think my PC still had EGA when I first played SQ4. I don't think there was a separate EGA version as such. I think it was the VGA version but I believe the interpreter supported a dithered mode that used the EGA palette but was dithered to try to match the VGA colours.
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.
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 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 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.
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.
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.
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.
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.
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.
Thanks for this comment. The parent comment came off quite ageist. As though the person in question struggled to keep up with the times. In reality, human dynamics play a big role in software quality. I wonder, could it be that the younger developer who recently became a lead both changed the team dynamics, and has not yet fully mastered the art of motivating fellow team members?
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.
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.
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.
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.
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.
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.
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.
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!
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...)
And there are easy ways to resolve this such as multi stage builds ( https://docs.docker.com/build/building/multi-stage/ ) - but mistakes still happen from time to time when people aren't aware that the current view of the docker image contains all of the previous layers too.
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.
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.
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.
> 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:
Great article. Great nostalgia. I wonder, do you still enjoy playing the games, now that you have thoroughly reverse engineered them? Also, what other insights have you gleaned? Also, have you read Not All Fairy Tales Have Happy Endings, by Ken Williams?
Yeah, I do still enjoy them. I have been having to play through a few of them again recently in order to test my own AGI interpreter (https://agi.sierra.games). For example, I've recently been playing King's Quest IV on my phone using AGILE.
I bought Ken's book a while back. As Ken has mentioned in reference to that book, his memories of things aren't as clear as they used to be. It's a long time ago. Still a great read though. I enjoyed it.
I have also read "The Sierra Adventure" by Shawn Mills. That's another great book, in fact it has some quotes from various people that I hadn't seen anywhere else. I loved some of the inside story from Doug MacNeill in regards to the original King's Quest project.
I've actually been working on my own book in relation to Sierra, AGI, the AGI games, the tools, the fan-made games... all things AGI I guess. Its probably still a few years away from release though. I keep getting distracted by things like writing the web based AGI interpreter.
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.
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.
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 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.
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.
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.
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.
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.
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.
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.
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)
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.
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 ..
Why shift one bit at a time, like you would on a CPU like the 6502 with no multi-bit shift instructions? Was this hand-ported from some system without those?
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.
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!
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.
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.
I wonder if they kept track of these in a CSV or something. Was the idea a customer could call in with their serial number and report a problem, which could be traced to a batch number or something? Anyway, just a curiosity I noticed.
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.
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.
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.
Once an Android app for the startup I was working on had a suspiciously large apk size. One of our engineers dug in and realized that our packaging script copied the .git directory in with the static files.
All it took to see the source was to cd into the unzipped apk directory and do a "git reset --hard ."
Yes, certainly, and any gaps could be filled in with what the NAGI project provides: https://github.com/sonneveld/nagi. NAGI is a fan-made AGI interpreter created by Nick Sonneveld. He disassembled the Sierra's original AGI interpreter and then used that to create equivalent C source code. It is interesting to compare what he came up with to the actual original AGI interpreter source code from the SQ2 disk. Nick had to make up appropriate names for things, as he obviously didn't have the memory map, but it is easy to see the equivalent functions etc when you compare equivalent modules.
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.
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.
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.
It is at about 1:47 into the video. It is the same machine shown in that LOGiN magazine article. This one appears to only support the 5 1/4 inch floppies, since I think the 3 1/2 inch disks weren't around at the time, so they must have got a newer machine later on.
Ken's title for the video claims it was from 1983, but from my research, I think that a September 1982 date is more likely. The whole thing is an amazing video actually. Well worth watching. Incredible that it actually survived and is now preserved on Youtube.
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.
