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

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.

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

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

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

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:

https://tcrf.net/Category:Games_with_uncompiled_source_code

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.

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!

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

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

> 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

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?

Still not as bad as when a company I worked for managed to press and ship a ton of CDs that included a virus.

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

Always do sector-level imaging of old disks, at minimum, for archiving. ("Flux"-level images taken with something like Greaseweazel are even better.)

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

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

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

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?

[1]: https://github.com/lanceewing/agi/blob/main/src/CMGRAPHX.ASM...

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!

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

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

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

With memory map, partial source code and reverse engineering tools, it should be possible to recreate the whole thing.

> FormMaster duplication machine

Anyone got any links with more info about this device?

Fascinating! What a fortuitous mistake for historical preservation purposes. Also a good lesson in why media overwrites are important.

Medtronic did this on one of their heart monitor base stations.

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.