In 2014, some of us at a small company with disposable income discovered that Winamp was on the market for a relatively small amount of money (as compared to our profits). We all had fond memories of it and we had a team capable of doing something interesting with it.

The problem was we couldn’t figure out anything interesting to do with it. We could think of a ton of things we could do, but we couldn’t think of a good business model around any of them—by which I mean profitable, not just eking by.

In the end, it just wasn’t worth our time. We were better off having half the company prototype new product ideas than sink our resources into this one.

The company that did eventually buy Winamp added an NFT marketplace to it.

It seems like Frantic got stuck at the step of nostalgia plus things he could do and didn’t think too hard about business models and profitability. Leveraging his house is a bad sign, because it implies he lacks the financial resources to do much with Commodore beyond buying the brand.

My guess? He’ll try to put together a new computer aimed at nostalgia seekers, it will underperform, and he’ll pivot to selling branded merchandise for a while until he eventually sells the brand at a loss.

The most interesting finding from this story (the comments section, really) was discovering that the Power Mac G3 began as a skunkworks project, without the knowledge of Jobs et al.

The 1B parameter version of Llama 3.2 showed even slower results at 0.0093 tokens per second, based on the partial model run with data stored on disk.

I mean, cool? They got a C interface library to compile using an older C standard, and the 1B model predictably runs like trash. It will take hours to do anything meaningful at that rate.

Mostly? What really sent me down a rabbit hole in reading this code was the syntax:

• The == assignment
• The argument lists <...>
• PRINTX instructions, etc.

The Altair 8800 uses an Intel 8080 processor. This syntax doesn’t match the instruction set for Altair or Intel, or even PDP-10 for that matter.

We have some hints about what may have happened. We know that Paul Allen wrote an Intel 8080 emulator designed to translate instructions to ones that a PDP-10 would understand.

We also know that Microsoft later released Macro-80 (M80) Assembly for Intel 8080 and Z80 architectures five years later. It turns out that M80 has <...> argument lists and .printx instructions.

So my suspicion is that Allen built some macro convenience functionality into his emulator, and that the language used is 95% Altair assembly with some macro functionality to support different kinds of Altair configurations and simplify some of the programming. Then they later evolved that into its own product offering and added Z80 support for it as well.

Building a Basic interpreter on top of a custom CPU emulator in a slightly-customized version of assembly in two months between 2.5 people and having it work correctly the first time on untested hardware is pretty damn impressive, whatever you think of Gates. It’s no wonder he’s so proud of it.

Assembly has variables. You can label locations in memory, then move them onto registers in order to perform operations.

I collect vintage laptops, and my wife makes bespoke kitten mittens. Our budget is $6.2 million.

What

Why does no one build one of these portables to play J2ME games?? There’s already five zillion handhelds that play traditional handheld games.

(Also that’s not how knack is used.)

That’s how it speaks to you, like KITT from Knight Rider.

Huh, I never knew that the version of Eliza many of us have tried out was based on the original author’s academic paper and not the original source code.

Yes. COBOL instructions map nearly directly (something like 1:4) to machine language instructions on the mainframe chipsets it was built for. It strongly encourages stateless procedures with its design, and has some other benefits that align closely with the financial sector. You can drop down to assembly as a hot spot optimization if you really need to.

The industry could replace COBOL, but its replacement would wind up looking a lot like COBOL at the code structure level, or a slightly nicer language would have an intermediate transpile step into COBOL or something similar. Probably no performance gains. Perhaps some usability gains. Not enough to sell it as a rewrite.

Reality is its use will probably outlive us all.