For example Classic Retro Motorola had an interesting register model where 8 bit registers A and B are ALSO simultaneously 16 bit register D, found on my favorite 6809 but also the 68hc11 microcontroller. This is mystifying to new programmers (so I wrote to register A which messed up register D what?)

The craziest thing about RISC-V register model is if you try to save a value to register x0 you will be very unhappy when you read zeros from x0 (because x0 is an infinite source of zeros on RV32I ...)

Likewise things get weird on retro CPUs where certain adds and moves can be written in assembly but can't be assembled by the assembler. I distinctly recall a test question where some new-at-the-time chip example was asking if you can inc its stack pointer or add hex 1 to its stack pointer or just pop it. It depends on the chip of course but generally the newer the chip the more generic its registers and rules.

https://secondboyet.com/articles/publishedarticles/theslithy...

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

Yeah, maybe, sorry if it came across like that. We use the term "I call BS on that!" very colloquially and loosely here, so I didn't think of it as being offensive. I could have worded that better, I agree.

> "Although it’s impossible to write to ROM, Commodore left out the circuitry in the 1541"

There is no "circuitry" to disable writing to ROM. ROM chips have no r/W pin, so no circuitry could attach to that. The only thing I could imagine is that they "forgot" the circuitry to disable the ROM's outputs when a write was issued. In that case, the CPU and the ROM write to the data bus at the same time. Which would totally garble whatever it is that is on the bus (which doesn't matter, since the write would be lost anyway), and maybe send a few more milliamps through the processor's (or the ROM's) data lines, but I doubt that this would be much more than what those pins are designed to handle in the first place.

One fact though is that the RAM chips they used back then were often very low quality (because they had trouble sourcing the amount they needed to keep up with the demand), and these RAM chips just broke at some point.... Watch any YouTube video about a C64 repair, and you will notice that everyone just complains about those chips. But that is a different issue and wouldn't explain the ROM chips breaking, or why the issue happens because of "writing to ROM"...

I also heard stories of programming graphics card registers in a fancy way to trigger high frequencies in the CRT coils that could, again if the CRT was vulnerable, potentially destroy the coil. But this also relied on very specific hardware to pull it off.

A generic attack on such a high volume home computer or floppy drive like the C1541 would definitely have made the rounds back then in the computer magazines.

And the myth that developers deliberately put in code to damage or even destroy the pirates' computers can also be ruled out almost entirely, as (at least in europe) even back then there was a strong legal protection against deliberately damaging other people's property. I distinctly remember reading about this being debunked in the largest German C64 magazine (64'er) by a lawyer....

Apple III Pascal had similar limitations, with separate 64K address spaces for p-code and data. On machines with more than 128 KB of RAM, there were assembly routines available for allocating additional memory and swapping data memory.

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.

See also groepaz's list: https://hitmen.c02.at/files/docs/c64/C64_Virus_List.txt

I don’t remember cpu therms being an issue until the mid late 90s - and then it was athlons. I could be wrong but I dont remember seeing CPU fans until the Pentium II cartridge but that is probably misremembering nostalgia.

80s was just robust against thermal - heck ataris had a giant aluminium shield over the mobo

> But if your program tried to write to ROM and did it often enough, you stressed both the CPU and ROM chip and could cause one or the other to overheat and fail.

I was very much into the C64 scene back in the early 90s and while I heard claims similar to that one (code that destroys chips or other components by overheating/stressing them) there was never any legitimate source of that. It was all just urban legends

Here’s a talk by Will Lindsay that might inspire https://youtu.be/D3ZlyJEQW0w?si=__vC9YxnRICjZyH2

Truly impressive machines, but vulnerable to the classic Sharp durability issues. I'm still hopeful I can bring it back :)

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.

Rendering this slightly differently from the regular Greek letter, would make sense, I guess. This may also explain the varying representations in the manuals: some would represent this like in common EBCDIC charts, as a delta, while others would refer to it as represented in the actual on-screen character set.

(There is also the rather common problem with special characters in manuals, where the font used for the chart doesn't comprehend the particular glyph, giving rise to alternative, often more abstract representations, as these symbols were drawn in later.)

I know very little about the project but I'd have guessed that ~100% DOS compatibility would've been achieved early on. There's just not very much to DOS! I'm sure there are reasons, of course, would be interested if anyone knows.

In fact, Psion did release a SIBO "emulator"* for DOS which seems to be basically a PC port. It's intended for developers, and hews to replicating the mobile devices rather than taking advantage of the PC hardware, but you can imagine polishing it a step further.

* https://home.hccnet.nl/joop.nijenhuis/psion/emul_0e.htm