1. Using a higher-level language/runtime that's more efficient for programmer productivity but that outputs less efficient code — nope, still using C.

2. Decreased effort on optimization. I'm sure this is a factor, but I also wonder how applicable it is here. In my day job, I may carelessly use an exponential algorithm or an inefficient data structure because it's quicker to just get the job done, but my impression is that the kernel is still going to pay a lot of attention to such things. Not quite as much as 30 years ago, probably, but kernel engineers aren't just using bubble sort all over the place now.

3. Increased functionality. The modularity of Linux, especially the kernel, mitigates this somewhat: sure, a 2025 kernel supports thousands more devices, file systems, etc than a 1995 one did, but you can compile most of those out. Still, my impression is that we end up with a kernel not just somewhat larger but many times the size of the old ones.

4. Tunables (or things that potentially could be tunable). This would actually be my best guess for where big easy wins could be had: code paths that allocate a 1 MB buffer when they could get by—and would have, years ago—with a few KB. On a system with GBs of RAM, larger allocations like that are probably advantageous but they can really crush an old system.

Likewise in userland: `ls` surely has more options now, but not _that_ many more, right?

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

Maybe you're thinking of DisplayWrite? See the second screenshot at https://www.dosdays.co.uk/topics/Software/ibm_displaywrite.p...

I was there in the 80s, and I remember this character being used margin/tab displaying purposes in at least one word processor program. It seems an obvious use, IBM literally used that symbol for that purpose on their typewriters. Does anyone else remember the name of the word processor program?

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