Chris Fenton

There are no doubt some systems still running under emulation doing the same thing as they were 40 years ago. The software might even be maintained. But the truth for decades now. CP/M is dead. Long live CP/M!

It's just hobbyists now. One hacker ported his game to a Kaypro under CP/M a couple years ago: http://www.chrisfenton.com/dd9-kaypro-edition/

Much of the focus is on porting CP/M to whatever new or old Z80 system someone has built or found. Speaking of which... CP/Mish is an attempt to bring all the free software CP/M tools together. It is to CP/M as Linux is to UNIX, or FreeDOS is to MS-DOS. A mostly complete, improved, libre reimplementation: https://github.com/davidgiven/cpmish

RunCPM is a CP/M Z80 virtual machine under modern OSes for development etc. https://github.com/MockbaTheBorg/RunCPM

In terms of recent new programs, here are some pointers if you wanted to write something yourself:

Also written by the maintainer of the CP/Mish project (and not CP/M specific) is Cowgol. Alpha quality. But it's a self-hosted Pascal/Ada-like language with compiler. Runs on 8-bit systems, at least theoretically. It is written, of course, entirely in Cowgol: https://github.com/davidgiven/cowgol

Millfork is another new language which targets CP/M systems, among others. It's a whole-program optimizing cross-compiler for a language somewhat lower level than C, with properties that make it very nice to compile for 8-bit systems like no recursion, and no automatic…

The rationale is that most people will never approach those kind of number of P/E cycles

The flip side of that is most people could now have drives that don't cost all that much more, but last much longer. Most SLC tends to be rated for 100K cycles and 10 years of retention; assuming a roughly inverse correlation, at 10K or 1K cycles the retention goes up considerably to a century or more.

The consumer market is similar: Most people don't ever buy replacements for failed drives - they buy a newer computer.

That is true, but the long-term implications are more subtle; the fact is that most people don't backup, and quite a few of them keep the old drives (that were still working when they were replaced) around as "backup", with the implicit assumption that the data on them will likely still be there if they ever decide e.g. that they wanted to find an older version of some file they had. With flash memory, this assumption no longer holds.

On a longer timescale, we've been able to "recover data" from stone tablets, ancient scrolls and books, this being a very valuable source of historical information; and most if not all of that data was probably never considered to be worth archiving or preserving at the time. More recently, rare software has been recovered from old disks ( http://www.chrisfenton.com/cray-1-digital-archeology/ ). Only the default, robust nature of the media made this possible.

Despite modern technology increasing amount of storage available, and the…

> It's too bad it's always existing companies that get their source leaked. Just once I'd like to see "Archive of Digital Equipment Corporation source code leaked online". I can dream...

The problem is those companies are defunct, so their source repositories may not even exist anymore, let alone be online, e.g.:

http://www.chrisfenton.com/homebrew-cray-1a/

> After searching the internet exhaustively, I contacted the Computer History Musuem and they didn’t have any either. They also informed me that apparently SGI destroyed Cray’s old software archives before spinning them off again in the late 90’s.

I know at my employer, there's always pressure to half-ass things that aren't directly connected to some mechanism for making money. We recently migrated our company intranet site from one vendor to another, and the team that was running that project it as a "feature" that they would help us "clean up" by not assisting us migrating anything older than one year. Similarly, source control migrations (of which we've done several) often drop history, since it's usually way easier just to download the latest version and check it into the new system than figure out how to migrate the metadata. IIRC, Microsoft's TFS-VC to git migration tool will only migrate something like 180 days of history.

But only because hardware got much faster, with larger resources (memory, disk). I just did a Stupid Benchmark, compiling this code:

/*
* Standard 'C' demo... Say hello to the world
*
* Compile command: cc hello
*/
#include <stdio.h>

main()
{
printf("Hello world\n");
}

(I know, not completely valid ANSI C code). On my home system (32 bit 2.6GHz intel gobs of RAM yada yada) it took GCC 0.2 seconds to compile and link the program (as a static program---by default it did it in 0.05 seconds). On the system I grabbed the code from (an operating system for the 8-bit MC6809) it took 35 seconds. And that was on a simulated MC6809 running on said 2.6GHz system, which is still faster, at approximately 50MHz, than a real MC6809 system of 1MHz (I thing you could get a 2MHz MC6809, but not much faster than that).

Even a state-of-the-art computer in 1980 (say, a Cray supercomputer) would have a hard time keeping up with <a href="http://www.chrisfenton.com/homebrew-cray-1a/">hobbyist system of today</a>, and it's because of this increase in computing power that we've been able to have the "toy languages" of yesterday be useful languages today.

But given that CPU speeds have leveled off, the easy performance gains are pretty much gone these days.

A powder gun like the one used in Harp and a gas gun like Sharp both work in the same basic way – expanding gases. The lighter the gases molecular weight, the faster it expands in air. Gunpowder has a molecular weight of 22, slightly less than air at around 28, but ignited gunpowder is incredibly hot, so that’s why it expands so quickly. The hydrogen used in gas guns, however, has a molecular weight of two so expands extraordinarily quickly in air.

I couldn't understand from the article how the hydrogen was being used in a "gas gun". Since pure hydrogen doesn't ignite, wouldn't we care about the molecular weight of the oxidizer as well?

It turns out the "light gas" is important just for it's low molecular molecular weight. It's never ignited, and one could substitute Helium for Hydrogen if one wanted. The gas is a second stage in addition to, rather than instead of the gunpowder. It's like a spring-air gun, but instead of spring you use an explosive charge.

Here's Wikipedia: https://en.wikipedia.org/wiki/Light-gas_gun

And here's some PVC experimentation:
http://www.chrisfenton.com/2-stage-light-gas-gun/

Man, this guy has some great articles.

http://www.chrisfenton.com/cray-1-digital-archeology/

http://www.chrisfenton.com/cos-recovery/

I just wish he'd made higher resolution pictures.

He's also seriously hardcore (or maybe I feel out of depth because I'm a software guy):

> I built a robot that would manually move the head forward 1/5200th of an inch at a time (there are 400 data tracks per inch, so this gives me a whopping 13 steps per data track!), while a high-speed analog-to-digital converter would take the analog signal straight from the drive’s read amplifier and buffer it into an FPGA at a blistering 80 million samples-per-second (like I said earlier, the theme here was overkill…the data was only changing at ~10 MHz or so)

Related:
http://www.modularcircuits.com/blog/articles/the-cray-files/