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.

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.

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.

    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.

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!

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.

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

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...

[2] https://news.ycombinator.com/item?id=27187435

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? ;)

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.

[0] https://wiki.reactivemicro.com/Applesauce

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.

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.

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.

0: https://ajxs.me/blog/Hacking_the_Yamaha_DX9_To_Turn_It_Into_...

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 ..)

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.

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.

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 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.

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.

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 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 ;)

It just didn't have as big an impact on my young self as SQ II.

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.

The manual tells you to "save early, save often" for a reason.

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!

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".

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.

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.

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.

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.

You had probably multiples orders of magnitude less people that could even speak the language, let alone do something coherent with it.

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.

[1] https://en.wikipedia.org/wiki/No_Silver_Bullet

In the entire time we worked together over a few years, he refused to adapt to the rest of the team.

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

“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.

Nowadays with CICD, automated builds and other modern development practices it probably happens less often.

[1] https://tcrf.net

[2] https://www.retroreversing.com/games/symbols

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 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...)

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.

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.

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.

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.

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

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.

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?

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.

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 " 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.

I have checked other Sierra disks, and so far the SQ2 and KQ3 occurrences are the only ones I know of.

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.

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.

    SER# 312929011101963 (15 digits)
    SER# 3129289101202698 (16 digits)

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.

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!

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.

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://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.

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 ..

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, =)

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.

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.