It's probably this discussion about DiskClick: https://news.ycombinator.com/item?id=39406098 (DiskClick: Ever wanted to hear old hard drive sounds - Feb 2024 - 81 comments). Also, the software was last updated 1 month ago.
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'm a moron. Somehow I read "width" and deleted the irrelevant parameter because people have different screen sizes and the site should auto-detect instead of using my one.
Comparisons between unsigned bytes can be done natively with JC, JNC and JZ, JNZ instructions. Things are more complicated with signed comparisons as there is no overflow flag. It is possible but requires more instructions.
Interestingly, while the 8086 and '186 had all the different jump instructions for signed and unsigned comparison, its microcode was limited to an 8080-like set of carry/zero flag tests. This made the BOUND instruction quite complicated and inefficient.
And to think that's where we come from. The Intel 8008, the ancestor of the x86 processor family, just has a 7-level call hardware stack only used by the unconditional and conditional call and return instructions. So, there is no push and pop instructions. As the only way to access a byte in memory was to store the address in the HL register pair (no absolute addressing mode) before the load or store instruction and as there was no way to disable hardware interrupts, it was almost impossible to write useful interrupt routines without some external hardware trick.
