It's double amazing because the demo is incredible for identifying these insanely challenging tricks and getting them to run on primitive hardware no one thought could display this level of colors or animation AND then a software emulation of the vintage IBM 5150 PC (and monitor) being so precise it's able to recreate this one-off insanity in cycle-accurate real-time with NO case-specific hacks. It blows my mind that either one of these actually exists. Both together is the stuff of heroic retro legends. I'm confident none of the 1970s designers of the 6845 chip would have ever believed their chip was capable of generating these graphics.

Like so many other high-concept or 'gimmick' games, it managed to get attention but failed on basic game play.

> "In July 2024, a new company called Tengen Games released its first game, “Zed and Zee,” for the Nintendo Entertainment System (NES) ... Tengen and its parent company, Atari Games, had disappeared 30 years ago after being crushed in court by Nintendo for doing exactly the same thing: manufacturing unauthorized cartridges for the NES."

The article doesn't address how Tengen is now able to produce unauthorized NES-compatible cartridges. Is Tengen paying Nintendo for a license? Did the patents expire? Did relevant legal precedents change? Another possibility might be that, while Atari's 80s legal actions established that intermediate infringement during reverse engineering could be fair use, Atari itself was precluded from relying on that fair use because its lawyers did naughty things. Maybe "new" Tengen reversed engineered it again from scratch without naughty lawyers?

[ Reply ]

> The patent on the lockout mechanism has expired and clean software implementations of the algorithm have been created. So the old legal protections no longer apply.

And while Nintendo still aggressively enforces their copyright on their old games, they probably don't care very much about unlicensed games being created for their very old hardware. It's just not commercially relevant to them.

I agree with you that, just on general principles, I don't know of any reason writing to a masked ROM chip would have any negative impact. While I didn't have a C64 back in the day (I do now though), I did have a Radio Shack Coco which had 16K of masked ROM for the BASIC interpreter (and another 8K of masked ROM if the optional disk controller cartridge was there). And the Coco never had anything like what Dave describes ("Although it’s impossible to write to ROM, Commodore left out the circuitry in the 1541"). The CPU could write to any address whether it held ROM, RAM, control registers or nothing at all. A masked ROM doesn't even have a write select pin. Some EPROMs have a write select but that requires other voltage etc. I used a lot of EPROMs back in the day because I worked at a company that leased hundreds of complete Coco systems to corporate customers each with it's own unique software on a custom cartridge. Each EPROM was burned by hand because it had proprietary customer data on it. The cost was no problem because one month's lease paid for the whole computer. :-)

Since I wrote the EPROM bank switching assembly language routines that drove the custom ROM cartridge hardware, I hammered EPROMS with writes all the time and it never hurt them (and we had hundreds of systems in all-day use). So that part doesn't make much sense to me unless there was something very unusual about the Commodore 1541 controller hardware (and to be fair, I understand the 1541 was weirdly complicated). EEPROMs could maybe have been effected but those were expensive and I can't imagine Commodore shipped electronically erasable chips in volume when much cheaper masked ROMs would suffice. So I suspect whatever Dave is talking about perhaps got garbled or conflated (as 30+ year-old memories do).

If it's garbled or conflated it could be based on the legendary (but real) undocumented HCF instruction (Halt and Catch Fire). And I know all about that because the Coco's 6809 was the original 8-bit home computer CPU that had that instruction. https://en.wikipedia.org/wiki/Halt_and_Catch_Fire_(computing.... But even HCF wouldn't actually damage your processor, although it could certainly warm it up if you left it running!

Further grasping at straws here... I guess every CPU does have some lifespan limit based on cycles and heat but it's really long. Unless something's very wrong with the chip or system design, that lifespan limit isn't usually a factor for a mass market computer. Another thing which might lead to confusion is that lots of computers over the years have had designs that were "thermally challenged" either through poor design, manufacturing errors or excess cost cutting. In those specific cases, it was possible to run really tight loops on the CPU which would, given some time, warm up the processor more than normal and cause a crash due to exceeding the T-limit (max operating temp) for too long. Some early computers also had RF design issues in how the traces on the motherboard were laid out. On these systems, if the RF shield wasn't grounded and you ran code hammering the address lines in certain ways, it could cause enough ringing to turn traces into little antennas spewing out noise and that could cause the computer to crash due to corrupted signals on the adjacent data lines. Once again, that was just a software crash, not permanent damage, and I never personally saw it happen except on prototypes and wire-wrap boards.

> I call BS on this claim

Unless you're Dave's drinking buddy and there's beer on the table, that specific wording may be just a little bit harsh. I mean, Dave has generated a huge volume of retro writing over a lot of years... and the dude definitely lived it first hand. Mistakes happen and I've certainly conflated or garbled some things from 30+ years ago but I doubt he's just making stuff up. I think he's writing from personal experience and relating the truth as he remembers it. That said, I think it's entirely reasonable to ask him for more clarification whenever something doesn't make sense. As retro-obsessive as he obviously is, like me, I'm sure he'd love to find out something he thought he knew is actually different.

If we're using emulation anyway, does the installed base over 40 years ago really matter? Of course, I'm biased on this point because, by happenstance, I ended up with the 6809-based Radio Shack Color Computer. Basically, my parents weren't going to pay much for a home computer for my late-teen self in 1980 (because what would you even do with a such a thing?) Even the minimal 4K RAM version was $600 but via a tiny ad in the back of a magazine, I found a non-corporate franchise Radio Shack store out of state selling them for about $450 delivered (no sales tax!). I mailed the check off hoping I wouldn't get scammed.

The computer showed up and it turns out random luck paid off because the 6809 was a fantastic CPU to learn assembler on. It was the most powerful 8-bit CPU because it was really a hybrid 8-bit/16-bit CPU, much like it's later big brother the 68000 (a 16-bit/32-bit hybrid). It had a bunch of 16-bit registers, indexed and program counter relative addressing modes (enabling position independent, re-entrant, pre-emptive multi-tasking code), software and user stacks, layered interrupts and a beautifully orthogonal instruction set (definitely inspired by the PDP with some nods to the IBM 360). And, damn, was it powerful! With the Unix-like, multi-tasking OS-9 operating system you could service up to 8 simultaneous users on serial terminals in real-time on a literal "toy computer" with a 1.8MHZ 6809 and 64K RAM.

For the first several years I was learning assembler, I had no idea how lucky I was. Much later when I eventually looked at the Z80 and 6502, I was shocked how primitive they were. Apple even initially chose the 6809 for the Macintosh and early Mac prototypes were 6809-based before they migrated to the 68000. Even better, Radio Shack sold an assembler in a ROM cartridge so low RAM wasn't a problem. A television for display and an audio cassette recorder to save your programs completed your "software development environment" :-).

Okay, it's true not a lot of people know much about the 6809 today - but back in the day all the cool kids definitely knew it was a powerhouse compared to Commodore, Apple and Atari 8-bits CPUs. However, I think more people today might object to dismissing the 68000 family. The 68K is still legendary for being fun to program in assembler. Sure, it was CISC but it was CISC in perhaps its most mature, pure and idealized form. And while RISC eventually replaced CISC architectures because RISC was more scalable when Moore's Law eventually delivered ever more gates in the 90s, the very CISC 68K was designed to be human legible, expressive and even joyful to program in assembler by hand. Sure, RISC architectures can be hand programmed, but they were clearly conceived for compiler written code and higher level languages.

Learning assembler today is anachronistic anyway, so why not go for the gusto and relive an ISA that legendary OG giants of software seriously described as 'elegant' and 'beautiful'?

I didn't have a C64 and my Radio Shack Coco had a less complex disk drive mechanism based around a standard Western Digital disk controller chip, but there were similar copy protections on some software titles.

While I'm sure someone did tell Dave this story, and that person may have believed it themselves, I suspect it's based on a mistaken extrapolation of a more innocent behavior. Way back in the day, we heard a similar report at my local user's group but a techie friend of mine looked into the offending software title and discovered a reality that was more benign. Basically, during manufacturing disk protections tend to put some non-standard formatting someplace on the original disk and then the software tries to read back the non-standard stuff to verify it's the original disk. These could be extra, missing or mis-numbered tracks or sectors. Some protections also put data on an extra track added beyond the last track. Coco disks had 35 "official" tracks in the specification but users quickly learned that these drives were manufactured as 40 track drives, of which some didn't pass QA tests seeking all the way to track 40 and were sold cheaper to Radio Shack. But I never saw a Radio Shack Coco drive that wouldn't seek to track 36, 37 and usually more. I eventually had four drives and all of them would reliably seek to track 41 or 42. In fact, hobbyists made mods for the disk operating system to add extra tracks to the official count. So, at least on the Coco, there were multiple disk protections that would seek the head "beyond the last track", not to damage the drive but because they knew the original disk had data there which all drives could read but no normal disk copy command would write.

The other thing to know is that all these floppy drives were inexpensive, mass-manufactured mechanical devices that had varying tolerances between individual units at the factory which only grew with wear over time, temperature, shipping and handling. Also the diskettes themselves weren't exactly made to exacting mil-spec standards. So, to read the disk the controller software would seek to the desired track and try to read the requested sector. It wasn't terribly unusual for a read to fail and time out due to the head moving a bit too slow or perhaps initially undershooting or overshooting the target track. So all controller software would move the head back (usually to track zero) and then try to step back to the desired track and do the read again. If it didn't work, it would repeat this several times hoping to get a good read before eventually failing with an error. When these rapid head resets and retries happened, the drive would make a loud and unusual "gronking" sound that was quite noticeable. And that was just with normal disks and no oddball disk formatting or trick-play head seeking.

When disk protections would fail to find the expected oddball tracks or sectors, they'd do the same reset/retry behavior with the same furious gronking. Except in the case of disk protections half the sectors on a track could be "special" (on the Coco there were 18 sectors on a track). At 3 or 5 retries each, that's a lot of loud head gronking for a long time as each sector is attempted and fails out in turn. Such was the case with the protected software title my friend disassembled. The erstwhile failed pirate at our user's group meeting (a middle schooler) was trying to start a copy of the game which had none of the "special" sectors present. While I doubt all that gronking was good for the disk mechanism, it wasn't intentionally malicious on the part of the software title. But you can see how the loud gronking sounds which only happened on a failed attempt to pirate a copy of a protected disk could cause people to make assumptions and leap to nefarious conclusions which would then be further embellished through the retelling.

Of course, I don't doubt that some hobbyist hacker or maybe solo software dev had nefarious thoughts and maybe even played around with how to do it and showed their friends a demo. But I never saw or heard any credible claims a commercial software title sold at scale ever shipped to consumers with the intent to destroy user hardware. Even in those days software was sold by publishers to distributors who then sold to retail stores, who sold to end users. A national wave of failed hardware reports associated with one title could mean blame and perhaps even legal liability for any and all of those parties. And disassembling the software sufficiently to prove it was doing this intentionally would have been much easier than making working pirated copies. To be so reckless, not only would the author have to be really dumb, so would the publisher and anyone who knew about it in advance.

The kicker is that, in those days, bulk duplication of diskettes (especially funkily formatted diskettes) wasn't all that reliable - meaning there was a pretty high probability that some non-zero percentage of your legit copies sometimes wouldn't read correctly for a paying customer due to varying manufacturing tolerances (or stray magnetic fields in shipping). And, of course, this failure to read could cause the copy protection to detect the legit disk as "pirated". Back in the 80s and 90s I worked for a successful software manufacturer and one of our products was a large, professional tool which eventually grew to occupy well over a dozen 3.5 inch floppy disks. When a disk wouldn't read for a customer it was a costly warranty issue to ship them a new disk set (and there was no consumer internet). As our software and disk count grew, we saw increasing disk failures. So we analyzed it and despite using the top disk duplicator in the U.S. and legit top-notch, direct-from-the-Sony-factory media - once our install was over a dozen diskettes, the statistical best case was almost every fourth customer would have at least one disk from their set fail to read. And this is without any funky formatting! Fortunately, CD-ROM became a thing shortly thereafter but the point is, the top disk duplicator in the country confirmed that "Yep, we do this better than anyone and your media is the best money can buy - and you're getting the expected field failure rate." So, selling hardware destroying time bombs would have been incredibly stupid, because statistically inevitable failures would certainly harm the hardware of more than one legitimate paying customer by mistake, and that would result in a very fast (but quite spectacular) fireball of infamy for any company dumb enough to try it.