The graphical operating system that could have been for the IBM XT.
A MacOS-like desktop for the Intel 8086, written entirely in real-mode assembly (with Claude). Verified to run on real hardware, with FAT12/16 support, ported apps, games, Sound Blaster support and upcoming Hard Drive support.
If you've built a large % of your personality and ego and self-worth around your ability to be a magic wizard with the machine and now it's seemingly easy to automate, how do you think that feels? Of course some people react this way. I encountered personalities of this type who decry IDEs, let alone agentic authoring. I had an asshole team lead at Google who used to smirk at people doing auto-import finding for Java or using e.g. rename refactorings, etc.
I can understand some of the viewpoint around LLMs. But I don't agree with it fully and just find it too useful to be able to get all the things I wanted to do for the last 30+ years done.
And I also think that some of the people who are threatened and angry and who have really deep systems level engineering skills and knowledge actually are in a unique position to benefit most from these tools as they will actually understand and intervene better and produce higher quality. Most of these "really neat vibe coded" projects stall at a certain point where the prompter no longer understands the beast they've created. People with deep knowledge and experience will hit that wall much later.
Anyways, I think we're at a juncture where what is worth caring about and focusing on in computers is going to have to have a radical overhaul. It's tough to separate the gatekeeping/elitism from genuine critique.
Beveled-buttons Minesweeper (first appeared in Win 3.11 IIRC) running on a preemptive 8086 OS with a bootleg System 1/2/3 interface looks absolutely cursed.
You'd still need a Wordstar-like app and a VisiCalc-like app (pref. Lotus 123-like).
VGA adapter means you have to wait until 1987 to run this, otherwise you'd deal with CGA's non-square pixels. EGA support would only be possible in Oct 1984.
> The graphical operating system that could have been for the IBM XT
Visi On[1] was a graphical operating system for the IBM PC that actually existed as a commercial product, though definitely not a very successful one. It was made by VisiCorp, the same company that created VisiCalc (the first spreadsheet for a personal computer).
It was demoed at COMDEX in 1982, before the Apple Lisa was released. It came out after the Lisa but slightly before the Macintosh.
Fun fact: Bill Gates saw the demo at COMDEX, and at first he was skeptical that it was really running on an IBM PC. But ultimately he was so impressed he decided[2] to start developing a product called Microsoft Windows.
It’s almost as impressive as the “GOS” written for Atari 8-bit running on 6502 at 1.79 MHz. Visually it’s almost identical but has a nicer font. The specs are somewhat similar with 16 task slots, calculator app and task manager, serial mouse support (ST mouse) and Atari’s hardware sprites helping with some of the graphics. The XOR window frame is the same idea. Amazingly, Atari GOS runs in 128K of RAM! One has to admire the work and inventiveness in these projects. See description and videos here:
I don't know why it seems reluctant to disclose AI use, because this is one of the best advertisements of Claude I've seen, and I say this as someone who has been sitting on the fence on the subject and saw a lot of slop in the past few years. If I was working in Anthropic's marketing department, this is the sort of thing I'd point to as a demo of its abilities.
That said, it's not like something of this nature was thought impossible; many embedded OSes running on even slower and more limited machines (e.g. 8051) had preemptive multitasking and a primitive GUI. It just took several decades for someone with the idea, tokens, and motivation to actually do it.
> Twelve task slots, 1,536 bytes of stack each, and a timer interrupt that takes the CPU away from whatever is running 18.2065 times a second. No task is asked to cooperate and no task can refuse.
If you don't have protected mode, can't any program just rewrite the interrupt handler? It's not a bad system, but it sounds easy to break.
This looked great, I started reading things, and then I just kept reading and reading the voluminous description details, and it was an immediate indication to me that the whole thing was built up by Claude. Confirmed in the repo. I closed the tab.
I appreciate the topic, interest, and ambition, but if a human couldn’t be bothered to create and document it, I can’t be bothered to spend my time reading about it.
I mean this is cool, it's wholly / mostly AI gen, so it takes the wow away which I think is what foklks are reacting strongly to here.
Sadly this sort of thing is much easier now - thanks to the tooling. I speak from personal experience, I'd written some stub 32bit os' myself (by hand, pre-ai) and it is very fun. But you quickly run into walls that stop further development that aren't fun. I enjoyed poking at VGA registers, the 512 byte boot sector into real mode into protected mode dance. Setting up the global descriptor tables/page tables and the PIC/8042 controller.
But...then you get into protected mode you get a prompt up some very basic memory management and then TERMIOS...boring. Boring. Defining all the posix syscalls, boring. Building test harnesses ... boring.
Oh I need a DMA controller now because PIO is slow, FUN!!!
I've taken my toy os to basically Linux 2.0 level in a few weekends by throwing tokens at boring things and when I got to the end it was a little bit empty because although the kernel of the system was all me, and it very much was built on the skeleton I arranged I didn't understand bits now that while boring were important. And the magic ... was lost.
I'm working on a new version now where my rule is I hand type every line of code and I co-plan with the AI and write from my head. It's so slow going but the fun is in the problem solving and the design and by hand writing you keep enough of it in hand it feels yours and real.
Anyway this is a cool project, I hope the author enjoyed it and learned something, but this is the new normal now, powerful tooling means things that were novel are tokens away and so they lose some of the magic accordingly.
Sorry the question, i watched shortly your videos, i see you vibe-coding it in an emulator.. but did you try it in a real hardware? With real floppy disks?
LLM writes a better ASM then a C compiler? From running the demo in the browser, it seems so performance-wise and size-wise, but the ultimate test should be performed on a real hardware that I have no direct access to.
Anyone can validate the performance on a real PC of the era? If it's confirmed, LLMs may be one of the ways of creating highly optimizing compilers in the future.
I've built custom exotic architectures in Verilog with their own bespoke ISAs and weird assembler and found LLMs entirely competent at writing for them, and even building compilers to target it.
I don't think you can call it Mac-like without proportional fonts. Fonts and QuickDraw (particularly the region manager) were really Mac/Lisa's biggest innovations.
I think someone vibecoded a bad System 7 replacement that had at least some QuickDraw in it.
In this case, actually doing those things would probably make it insufferably slow on a real PC though at least at vibe-coding quality.
The real implications here (also looking at the WinWord port to win64, which I suspect had some AI involvement as well) is that current agentic AI completely changes what a hobbiest can do over a weekend, as long as AI slop code is acceptable to meet one's project goals.
---
It's certainly affecting things I've worked on... there'll be a much better version of ld-decode soon using Claude Fable which is faster and has better filtering (and an audio noise-reduction post-processor that actually works) and I'm pretty sure you could get much of ELKS working from scratch in one weekend at this point. whispers something about doing a UNIX-like on a pi pico 2 (or two), since he can't do it because reasons...
36 comments
[ 3.6 ms ] story [ 40.7 ms ] threadA MacOS-like desktop for the Intel 8086, written entirely in real-mode assembly (with Claude). Verified to run on real hardware, with FAT12/16 support, ported apps, games, Sound Blaster support and upcoming Hard Drive support.
More like hand-prompted...
I can understand some of the viewpoint around LLMs. But I don't agree with it fully and just find it too useful to be able to get all the things I wanted to do for the last 30+ years done.
And I also think that some of the people who are threatened and angry and who have really deep systems level engineering skills and knowledge actually are in a unique position to benefit most from these tools as they will actually understand and intervene better and produce higher quality. Most of these "really neat vibe coded" projects stall at a certain point where the prompter no longer understands the beast they've created. People with deep knowledge and experience will hit that wall much later.
Anyways, I think we're at a juncture where what is worth caring about and focusing on in computers is going to have to have a radical overhaul. It's tough to separate the gatekeeping/elitism from genuine critique.
VGA adapter means you have to wait until 1987 to run this, otherwise you'd deal with CGA's non-square pixels. EGA support would only be possible in Oct 1984.
I have a Pocket 8086 - I would love to give this a try next weekend.
[0] http://runtimeterror.com/pages/iv/images/b869a0cf44a7e7cbc40...
Visi On[1] was a graphical operating system for the IBM PC that actually existed as a commercial product, though definitely not a very successful one. It was made by VisiCorp, the same company that created VisiCalc (the first spreadsheet for a personal computer).
It was demoed at COMDEX in 1982, before the Apple Lisa was released. It came out after the Lisa but slightly before the Macintosh.
Here's their promotional video from 1983: https://www.youtube.com/watch?v=kc4wFeVvKTI
Fun fact: Bill Gates saw the demo at COMDEX, and at first he was skeptical that it was really running on an IBM PC. But ultimately he was so impressed he decided[2] to start developing a product called Microsoft Windows.
---
[1] https://en.wikipedia.org/wiki/Visi_On
[2] https://en.wikipedia.org/wiki/Windows_1.0
https://en.wikipedia.org/wiki/DESQview#DESQview/X
It’s almost as impressive as the “GOS” written for Atari 8-bit running on 6502 at 1.79 MHz. Visually it’s almost identical but has a nicer font. The specs are somewhat similar with 16 task slots, calculator app and task manager, serial mouse support (ST mouse) and Atari’s hardware sprites helping with some of the graphics. The XOR window frame is the same idea. Amazingly, Atari GOS runs in 128K of RAM! One has to admire the work and inventiveness in these projects. See description and videos here:
https://atari8.co.uk/gui/
That said, it's not like something of this nature was thought impossible; many embedded OSes running on even slower and more limited machines (e.g. 8051) had preemptive multitasking and a primitive GUI. It just took several decades for someone with the idea, tokens, and motivation to actually do it.
> Pre-emptive multitasking on an 8086
> Twelve task slots, 1,536 bytes of stack each, and a timer interrupt that takes the CPU away from whatever is running 18.2065 times a second. No task is asked to cooperate and no task can refuse.
If you don't have protected mode, can't any program just rewrite the interrupt handler? It's not a bad system, but it sounds easy to break.
I appreciate the topic, interest, and ambition, but if a human couldn’t be bothered to create and document it, I can’t be bothered to spend my time reading about it.
i'm going to try an run it from free bios rom space on a NuXT similar to Basic in rom:
https://www.vogons.org/viewtopic.php?t=67340
Sadly this sort of thing is much easier now - thanks to the tooling. I speak from personal experience, I'd written some stub 32bit os' myself (by hand, pre-ai) and it is very fun. But you quickly run into walls that stop further development that aren't fun. I enjoyed poking at VGA registers, the 512 byte boot sector into real mode into protected mode dance. Setting up the global descriptor tables/page tables and the PIC/8042 controller.
But...then you get into protected mode you get a prompt up some very basic memory management and then TERMIOS...boring. Boring. Defining all the posix syscalls, boring. Building test harnesses ... boring.
Oh I need a DMA controller now because PIO is slow, FUN!!!
I've taken my toy os to basically Linux 2.0 level in a few weekends by throwing tokens at boring things and when I got to the end it was a little bit empty because although the kernel of the system was all me, and it very much was built on the skeleton I arranged I didn't understand bits now that while boring were important. And the magic ... was lost.
I'm working on a new version now where my rule is I hand type every line of code and I co-plan with the AI and write from my head. It's so slow going but the fun is in the problem solving and the design and by hand writing you keep enough of it in hand it feels yours and real.
Anyway this is a cool project, I hope the author enjoyed it and learned something, but this is the new normal now, powerful tooling means things that were novel are tokens away and so they lose some of the magic accordingly.
No? It's the exact opposite for me. This is a great demo of how AI can do efficient software if you prompt it the right way.
Anyone can validate the performance on a real PC of the era? If it's confirmed, LLMs may be one of the ways of creating highly optimizing compilers in the future.
It's a weird world we live in now.
I think someone vibecoded a bad System 7 replacement that had at least some QuickDraw in it.
In this case, actually doing those things would probably make it insufferably slow on a real PC though at least at vibe-coding quality.
The real implications here (also looking at the WinWord port to win64, which I suspect had some AI involvement as well) is that current agentic AI completely changes what a hobbiest can do over a weekend, as long as AI slop code is acceptable to meet one's project goals.
---
It's certainly affecting things I've worked on... there'll be a much better version of ld-decode soon using Claude Fable which is faster and has better filtering (and an audio noise-reduction post-processor that actually works) and I'm pretty sure you could get much of ELKS working from scratch in one weekend at this point. whispers something about doing a UNIX-like on a pi pico 2 (or two), since he can't do it because reasons...