Hacker News Reader

Comment by elvis70 | Hacker News Reader

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)

View on HN

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.

https://forums.nesdev.org/viewtopic.php?t=17324

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.

DynaMike from that page deserves special mention for accidentally including some browser history with... you guess... https://tcrf.net/DynaMike

    a time when literally every byte cost money

Possibly overpedantic; please forgive me if so!

Every chip cost money, right? If your game shipped on a single 1mbit EEPROM, it cost the same amount of money whether it was 90% full or 99.99% full. There was of course a cost incentive not to go over 1mbit, or to get your size down enough to fit onto a 512kbit EEPROM.

See the 'ideal gas' comment at https://news.ycombinator.com/item?id=40460650

This has happened quite a few times:

https://tcrf.net/Category:Games_with_uncompiled_source_code

It's usually more common on CD games with the directory/file being unlisted, but it's always interesting to find partial source code bakes into ROMs. Last I heard/understood, it was usually as some sort of white space padding; in the case of CD-ROMs and an artifact of the sector-copying mechanism in disk duplicators.

Also, the bytes cost money, but if you have a 32K ROM (because the next lowest size is 16K) and only 28K of data, it's not costing anything extra to fill that space.

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

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.

The hardware you're talking about you can buy today. It's used by retro computing geeks working in SW preservation. Pretty sure it also existed back in the day. The point wasn't to make copying impossible, it was to make it impossible for home users.

Hence the cracking scene: home users would get pirated version of the games, with the copy protection removed from the code.

P.S: if I'm not mistaken in some cases original, legit, disks were physically damaged on purpose (for example with a hole being physically punched at a precise location) and then the copy-protection would try to write something at that spot and re-read it. If the write/re-read succeeded, they knew the floppy was good and hence they knew it couldn't be an original disk.

That doesn't make sense, no? Most of these disks had their read-write tab blocked and so the floppy drive would just operate in read-only mode anyways.

> That doesn't make sense, no? Most of these disks had their read-write tab blocked and so the floppy drive would just operate in read-only mode anyways.

You are right that that doesn't make sense so I may be remembering incorrectly.

I'm nearly sure the disk physically had holes, on purpose, though. So maybe the copy-protection was simply trying a regular read, expecting it to fail... And if it didn't throw an error, then it'd know it was a copy.

I remember downloading some kind of commercial digital forensic software that, came with cracking instructions: A PDF or image with measurements for where to drill a hole into your disk and at what size :D Never tried it, so I don’t know if it would have worked, but I’ll always remember it.

I can give you an example of someone claiming there were holes in the disk, Jon Burton, but they're a goddamn liar: https://www.youtube.com/watch?v=Qaq9vlfoGnA

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

Here's a page that more accurately describes floppy disk protection methods (and also explains what a long track is): https://diskpreservation.com/dp.php?pg=protection

>It waits for the index pin

you mean index hole?

>no holes

https://s3.amazonaws.com/com.c64os.resources/weblog/howdoes1...

so maybe no laser holes, but there IS a hole :-)

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.

So you're doubly wrong, in this case.

How does the floppy infer when to signal on the index PIN?

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.

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

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

I'm not aware of any direct copier, most disk duplicators that were sold to regular people were just a bunch of floppy drives with regular disk copy software.

These days, there is the delightfully named Greaseweazle (https://github.com/keirf/greaseweazle) and similar devices to _read_ disks at a magnetic level, but I'm not sure if there is something to _write_ disks. I don't see any reason why such a thing couldn't exist, I'm just not aware of it.

Tech Tangent has a good in-depth video about imaging disks for archival purposes if interested: https://www.youtube.com/watch?v=UxsRpMdmlGo

KryoFlux (https://kryoflux.com) reads and writes magnetic flux data.

> ...similar devices to _read_ disks at a magnetic level...

It's not, though. It's reading the disk after the drive's analog-to-digital converter has had its way with the analog flux transitions coming off the head. There's auto gain control circuits in there, and a pre-amplifier, and finally the ADC. Greaseweazel and its ilk are closer to the flux than just reading the disk in the conventional manner but it isn't actually sampling the raw flux reversals.

The Domesday Duplicator is closer to what I'm taking about. You can do software-defined manipulation of the sampled analog signal. In its case, it's a software-defined laserdisk player. (One could do the same w/ VHS, for example.)

I'll try to dig up a good Vintage Computer Festival talk from a guy who was recovering analog signals from old tapes and reconstructing the data by building a software-defined "tape drive" and using signal processing algorithms that would be applicable in the software-defined radio domain.

It occurs to me that such an analog duplicator wouldn't need fancy FPGAs and high-speed digital signal processing that didn't exist back then. It would "just" need very clean analog circuitry and decent motor control.

Edit:

Here we go. Video of the talk: https://www.youtube.com/watch?v=sKvwjYwvN2U

A comment I made about it: https://news.ycombinator.com/item?id=31939703

Edit 2:

It looks like the Applesauce[0] project does what I'm talking about. It's sampling analog signals from the drive, rather than the output of an old ADC. Very cool.

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

There's some discussion here[1] about analog recovery of floppy data and some past discussion[2] from HN.

[1] https://scarybeastsecurity.blogspot.com/2021/05/recovering-l...

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

Yeah it'd be interesting to have a full analog floppy reader/writer for data recovery. Might as well make it fast enough to read early hard drives (at least through early IDE) too.

Probably could stuff quite a bit more data using today's methods on a disk, too, even though in the scheme of things it'd be pretty pointless... but why should that stop someone? ;)

>but I'm not sure if there is something to _write_ disks.

Greaseweazle can also write arbitrary disk formats to disk.

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.

20 years ago I toyed with the idea that doing that should be trivial, but in reality it is not due to various synchronization issues.

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:

https://www.awp1.com/st.html

Or, if they were very small, they would just use multiple smaller scale devices that could do 2-4 copies at a time, like this:

https://pbs.twimg.com/media/Dgr_J-NUEAAHZ0I?format=jpg&name=...

Some of the expensive ones of these could do magnetic signal copying, but most just did sector-by-sector.

At least, that's my understanding. Bit before my time.

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.

https://www.cocopedia.com/wiki/index.php/Sands_of_Egypt

That was such a common technique that it's odd to talk about just one game in particular doing it.

Thanks for the explanation, that makes it much clearer.

This reminds me of the low-level disk cloning utilities crackers used to circumvent copy protection, and how they competed to build faster ones.

This was the second multiplayer game I ever played, when visiting a friend’s house, on his dad’s computer. The first, on the same computer, was a DOS version of Spacewar!

If I remember right, we’d reach a boss and the game would freeze, so we never managed to beat Double Dragon II.

Good memories.

Reply on news.ycombinator.com