(I'd consider it myself but I'm about 2400 miles away.)
(I'd consider it myself but I'm about 2400 miles away.)
Whatever your thing will run on, will it still work in another 30 years? Our hardware is so flaky that everyone in the industry is depreciating at 3-5 years or less. Sure, platforms can stay the same, hardware-wise, but you'd be really lucky if you can still run the same software that you did before.
And yes, you can run an emulator, but who's going to maintain the underlying platform? Is it going to be connected to the internet and be part of the next gargantuan IoT DDOS attack.
What those guys is need is another Comodore 64, brand new. It has proven it works, why change it?
We need to take a serious look at this stuff: this is what we should be doing. Not writing yet another freaking web server, but stuff that can still be operational in 30 years.
Are you responsible for a production deployment of any kind? "I'm doing fine until something goes wrong" is not doing fine.
Unfortunately, merely stockpiling Commodore hardware is not a great long-term plan; the failures will be correlated. Even the ones just sitting on the shelf are decaying.
"And yes, you can run an emulator, but who's going to maintain the underlying platform? Is it going to be connected to the internet and be part of the next gargantuan IoT DDOS attack."
Why would it be?
You seem to be really, really stretching for reasons why this is a bad idea.
This is so very true, I can't think of any device that will offer them any kind of improvement over the brand new C64 scenario.
What device that is installed today will still be working 30 years from now? Maybe some appliances without moving parts? Some raspberry PIs?
I couldn't even setup an iPhone 5C without giving it a connection to the internet.
On top of that there are about a dozen FPGA boards with a wide variety of C64 cores that will also give you more or less (depending on version) cycle compatibility with the C64 and varous degrees of availability of ports.
I think you underestimate how long hardware compatible with these systems will be available vs. the effort that would be involved in keeping an emulated setup working across migrating hardware and OS models and ensure the hardware interface they need keeps working for each new generation.
Organ builders have solved the problem: https://de.wikipedia.org/wiki/Orgellandschaft_Ostfriesland
You can buy entire newly built motherboards for the C64, as well as tons of spare parts and a number of FPGA reimplementations.
All/most of which are basically static, with no fans, and at least for the stuff that depends on original chips, it's pretty much indestructible.
E.g. just consider the dust, and the heat produced by most modern PCs vs. a fan-less c64 where the internals rarely get very hot. And where the components for the most part are near indestructible as confirmed by 7-8 year old me repeatedly pulling them out of their sockets helped by screwdrivers and reseating them and occasionally bending pins, without and kind of regard for static electricity; I also carried out "experiments" like moving chips between my C64, Amiga 500 and 1541 with little disregard for just how pin compatible they were. I amazingly never destroyed any of them.
In terms of the disks, you can still buy suitable floppies for backups, and you can also buy 1541 replacements that use SD cards or compact flash.
30 years from now, I bet you'll still be able to buy "C64s" in some form, while to keep a system based on a current PC it'd be hard not to get sucked into an upgrade cycle.
And you can stockpile those for not much money right now. And while they, too, will have correlated failures over the course of decades as they decay, at least it starts the clock back at 0 again.
You are aware that the C64 expansion port is actually the 6510-CPUs address and data-bus?
To properly emulate this cycle accurate in an emulator you'd have to attach about 30 I/O pins to your PC which you can update at a rate of 1MHz, with basically no latency between reads and writes, to connect external circuitry.