> Opening an encrypted connection means one very large multiplication. On a 4.77 MHz 8088 it takes minutes.
I've done it.
It took a lot of loop unrolling and optimizations in order to get the TLS 1.2 handshake to complete before the server timed out the connection, but I've successfully gotten it to work, and with only 384 KB of RAM.
The implementation doesn't verify the server certificate (would certainly take too long), but it successfully performs an HTTPS request to Wikipedia as a proof-of-concept.
One of these days I'll clean up the code and post it here.
I‘ve recently tried implementing the Noise protocol on a 7.8 MHz 68000, while it runs in 10 seconds I don’t think there is a way to make it constant time without using addition and running an order of magnitude more slowly :(
MULU operations are not constant time but depend on popcount. That has an easy work around just also do the MULU of the bitwise inverse, both instructions sum to a constant cycle count.
The brick wall I hit is related to the Macintosh SE ram being shared between CPU and video system. Every few cycles the CPU stalls instruction fetching, which turns the both MULUs together take the same amount of time each time into there is slowdown depending on the popcount of the first instruction.
I don’t know if anyone has any solution for this, there is prefetching of one instruction so all should be well, but it seems like the cpu stalls the in progress instruction if the prefetch is stalled.
A 2048-bit RSA key is 256 bytes. A 256-bit symmetric key is 32 bytes and ECDH keys are roughly the same size. The state size of AES is 16 bytes and its S-box is 256 bytes. Efficient implementations use only a few KB of state. The vast majority of cryptographic algorithms just aren't that big, relatively speaking; although as you mention, they are very computationally intense. Hash states are in the dozens to low hundreds of bytes. For TLS implementation, the record buffers are probably going to use the most RAM; 16K each direction + additional overhead.
So, this is less a technical than an aesthetic question—why does it look like an old Macintosh? I think I would have thought of GEOS [0] before Macintosh. There's also Windows 1.0 and 2.0.
Why 3.5" floppy drive icons instead of a 5.25"? The images of the OS running on hardware [1] have mostly 5.25" drives.
TBH Windows 1.0 (and to a lesser extent Windows 2.0) looked awful compared to Macintosh which is probably why the author decided to go with that. Digital Research agreed since they also made GEM at the time look very mac-like (and got sued by Apple for it :-P).
Why do you think it is "AI slop"? Isn't the author allowed to write code with Claude?
Not every project that uses AI is immediately "AI slop".
> This is a hobby project. I rely on AI to speed up the work (including the writing and maintenance of the webpage and the markdown files you see here). If you spot a mistake, you're welcome to contribute a fix in the form of a PR.
The author is inviting your hand written assembly skills to help him reduce the "slop"
I'm not to most positive about AI generated stuff, especially in terms of text and images. But with code, it is a neat tool.
I think it is especially cool in building stuff to retro specs. It has allowed many to do stuff in days or weeks that previously could have been months. Projects that don't really have much value in terms of money but are just nice to have kind of things.
This project is a great example of this.
It does come back to that question though of who will pay for the code generation but that is something for someone else.
I'm more impressed by this than AI-generated images; a few tiny imperfections in the latter are not a big deal, and even humans often make mistakes with little effect, but code has a far higher bar of correctness to meet. The fact that AI can even generate working real-mode 16-bit code reasonably well and not turn into Electron-levels of inefficiency was most surprising.
Exactly this! Recently I saw a project that is heavily AI assisted to port Doom to the Neo Geo. That is hardware that works in a totally opposite fashion to how Doom runs. It is a 12Mhz 68K chip with no frame buffer. And yet, they are making it work and with surprising performance.
Considering how little open Neo Geo code is probably out there to train on, that these models can build to this is very impressive.
> Isn't the author allowed to write code with Claude?
Just to make it correctly: Author isn't writing code with Claude. Claude is writing code for the Author. Nothing wrong with that. But that's how it is.
It was originally coined to mean low-quality material that was obviously generated by AI, like pictures of humans with distorted features and the wrong number of fingers.
But a whole bunch of people have decided that anything generated by AI is "slop", regardless of quality.
It's absolutely obnoxious, especially when people label things as "slop" when AI was merely used for brainstorming and the final product does not contain any AI-generated material at all.
I think a big part of the 'slop' term should be associated with people who use it to either deceive others or just flood a place with low quality stuff.
It is a matter of opinion but many brandish the term around a little to freely. Some times justified, other times just folks trying to grab some power over others.
FWIW "slop" seems to have become a more general slang nowadays, i see people use it on Discord and Twitch to describe all sorts of stuff often unrelated to AI.
Yes, I'm old now and have learned all the foundational computer and hardware engineering topics the hard way over 30 years. I've earned my AI tokens of freedom. :)
AI code increases productivity and reduces understanding.
If it is a project like this, that's cool. If you are deploying the safety control system on a power plant, you had better have a damn good understanding!
os8088 is an operating system written with AI tools in x86 16-bit assembly with an optional C/C++ app porting toolchain.
It runs on anything with an x86 processor from the early 8088/8086 CPUs up to the latest CPUs. It supports CGA/Hercules + VGA. Sound Blaster, NE2000 network and MFM hard drive support is now available.
We've also ported many cool apps: MOD trackers, TexPad, MS Word 1.1a (in ASM and C), CP/M 2.2 emulator with a ton of apps and games, and several ported games from the early arcade days.
Since you're here let me ask a question i had the last time i saw this project: how does your AI handle the ginormous SPEC.md file?[0] (last time i saw it Github was still able to display it :-P).
Are you feeding the entirety of it to Claude (i guess)? Doesn't that eat pretty much all context - and considering that (AFAIK) the spec file has everything about the OS, doesn't available context space put some sort of "hard ceiling" to what you can add to the OS?
This SPEC.md is more of a memory dump that it chooses to use on some tasks. I was recently thinking of either:
a. splitting it into sub-spec files that can be referenced.
b. getting rid of it completely to prevent the LLM from hallucinating with potentially stale information.
So essentially like the original Mac in 1984. ;) 128KB of RAM is just too little to run the OS and applications at the same time with any kind of performance. But once the 512KB model came along, then things started to really swing.
It seems
Like projects like this (that include basic productivity tools) could potentially enable a small resurgence in sovereign computing. A 5 dollar esp32 is powerfulll enough to emulate 8086 architecture while running a tcp/ip stack, DVP display, and usb input peripherals.
With a simple OS like CP/M or others, a low cost computer you can actually trust to only run trusted code is possible again.
My take is that "sovereign computing" will go from something 0.001% of the population cares about to over 1% in the coming three decades, i.e. three orders of magnitude. It will depend on how long we continue in the current survtech course. There is also the question of if we will see mandatory backdoors in hardware. For example, Country X could legislate that all CPUs sold in their territory need to have a latent command-and-control area for law enforcement to use. If that happens, I'll start converting my savings into a physical stash of old reliable CPUs.
In any case, it seems that CPUs have a very long shelf life; it's still possible to buy 8086 processors[^1].
A gopher client would be easier and no AI needed as the protocol it's trivial to parse.
You have sites from gopher://magical.fish to gopher://floodgap.org and gopher://sdf.org
(and, as a plus, you can read finger services).
You can just transcript the feeliest to plain text. If you have an Inform6 compiler nearby, just compile the game with the 'big' flags to get the "complete" Z3 version. It has the same text as the v5 one, and it will run much faster under a 8088/8086.
> Opening an encrypted connection means one very large multiplication. On a 4.77 MHz 8088 it takes minutes.
I've done it.
It took a lot of loop unrolling and optimizations in order to get the TLS 1.2 handshake to complete before the server timed out the connection, but I've successfully gotten it to work, and with only 384 KB of RAM.
The implementation doesn't verify the server certificate (would certainly take too long), but it successfully performs an HTTPS request to Wikipedia as a proof-of-concept.
One of these days I'll clean up the code and post it here.
I‘ve recently tried implementing the Noise protocol on a 7.8 MHz 68000, while it runs in 10 seconds I don’t think there is a way to make it constant time without using addition and running an order of magnitude more slowly :(
MULU operations are not constant time but depend on popcount. That has an easy work around just also do the MULU of the bitwise inverse, both instructions sum to a constant cycle count.
The brick wall I hit is related to the Macintosh SE ram being shared between CPU and video system. Every few cycles the CPU stalls instruction fetching, which turns the both MULUs together take the same amount of time each time into there is slowdown depending on the popcount of the first instruction.
I don’t know if anyone has any solution for this, there is prefetching of one instruction so all should be well, but it seems like the cpu stalls the in progress instruction if the prefetch is stalled.
and with only 384 KB of RAM.
A 2048-bit RSA key is 256 bytes. A 256-bit symmetric key is 32 bytes and ECDH keys are roughly the same size. The state size of AES is 16 bytes and its S-box is 256 bytes. Efficient implementations use only a few KB of state. The vast majority of cryptographic algorithms just aren't that big, relatively speaking; although as you mention, they are very computationally intense. Hash states are in the dozens to low hundreds of bytes. For TLS implementation, the record buffers are probably going to use the most RAM; 16K each direction + additional overhead.
So, this is less a technical than an aesthetic question—why does it look like an old Macintosh? I think I would have thought of GEOS [0] before Macintosh. There's also Windows 1.0 and 2.0.
Why 3.5" floppy drive icons instead of a 5.25"? The images of the OS running on hardware [1] have mostly 5.25" drives.
[0] https://en.wikipedia.org/wiki/GEOS_(8-bit_operating_system) [1] https://os8088.com/hardware/
TBH Windows 1.0 (and to a lesser extent Windows 2.0) looked awful compared to Macintosh which is probably why the author decided to go with that. Digital Research agreed since they also made GEM at the time look very mac-like (and got sued by Apple for it :-P).
Most likely because of AI slop.
Why do you think it is "AI slop"? Isn't the author allowed to write code with Claude?
Not every project that uses AI is immediately "AI slop".
> This is a hobby project. I rely on AI to speed up the work (including the writing and maintenance of the webpage and the markdown files you see here). If you spot a mistake, you're welcome to contribute a fix in the form of a PR.
The author is inviting your hand written assembly skills to help him reduce the "slop"
I'm not to most positive about AI generated stuff, especially in terms of text and images. But with code, it is a neat tool.
I think it is especially cool in building stuff to retro specs. It has allowed many to do stuff in days or weeks that previously could have been months. Projects that don't really have much value in terms of money but are just nice to have kind of things.
This project is a great example of this.
It does come back to that question though of who will pay for the code generation but that is something for someone else.
I'm more impressed by this than AI-generated images; a few tiny imperfections in the latter are not a big deal, and even humans often make mistakes with little effect, but code has a far higher bar of correctness to meet. The fact that AI can even generate working real-mode 16-bit code reasonably well and not turn into Electron-levels of inefficiency was most surprising.
Exactly this! Recently I saw a project that is heavily AI assisted to port Doom to the Neo Geo. That is hardware that works in a totally opposite fashion to how Doom runs. It is a 12Mhz 68K chip with no frame buffer. And yet, they are making it work and with surprising performance.
Considering how little open Neo Geo code is probably out there to train on, that these models can build to this is very impressive.
> Isn't the author allowed to write code with Claude?
Just to make it correctly: Author isn't writing code with Claude. Claude is writing code for the Author. Nothing wrong with that. But that's how it is.
OP wasn't talking about code but aesthetics.
> Why do you think it is "AI slop"?
Probably because the web page is. It is almost unreadable because of the style.
The term "AI slop" has lost all meaning.
It was originally coined to mean low-quality material that was obviously generated by AI, like pictures of humans with distorted features and the wrong number of fingers.
But a whole bunch of people have decided that anything generated by AI is "slop", regardless of quality.
It's absolutely obnoxious, especially when people label things as "slop" when AI was merely used for brainstorming and the final product does not contain any AI-generated material at all.
I think a big part of the 'slop' term should be associated with people who use it to either deceive others or just flood a place with low quality stuff.
It is a matter of opinion but many brandish the term around a little to freely. Some times justified, other times just folks trying to grab some power over others.
FWIW "slop" seems to have become a more general slang nowadays, i see people use it on Discord and Twitch to describe all sorts of stuff often unrelated to AI.
Yay, I guess? It's impressive that AI can build something like this, but do you really understand how all the components work?
AI is really good an taking what we already know and producing something that works, but what about new innovations?
With all that said, this is still pretty cool.
Yes, I'm old now and have learned all the foundational computer and hardware engineering topics the hard way over 30 years. I've earned my AI tokens of freedom. :)
Probably also learned some stuff making this that you wouldn't have learned if you never made it.
AI code increases productivity and reduces understanding.
If it is a project like this, that's cool. If you are deploying the safety control system on a power plant, you had better have a damn good understanding!
os8088 is an operating system written with AI tools in x86 16-bit assembly with an optional C/C++ app porting toolchain.
It runs on anything with an x86 processor from the early 8088/8086 CPUs up to the latest CPUs. It supports CGA/Hercules + VGA. Sound Blaster, NE2000 network and MFM hard drive support is now available.
We've also ported many cool apps: MOD trackers, TexPad, MS Word 1.1a (in ASM and C), CP/M 2.2 emulator with a ton of apps and games, and several ported games from the early arcade days.
Run it in the browser at: https://os8088.com/demo
Yes, the website has a lot of AI generated content. I'm working on a redesign and tooling to edit and rewrite the content by hand.
Since you're here let me ask a question i had the last time i saw this project: how does your AI handle the ginormous SPEC.md file?[0] (last time i saw it Github was still able to display it :-P).
Are you feeding the entirety of it to Claude (i guess)? Doesn't that eat pretty much all context - and considering that (AFAIK) the spec file has everything about the OS, doesn't available context space put some sort of "hard ceiling" to what you can add to the OS?
[0] https://github.com/jggonz/os8088/blob/main/SPEC.md
This SPEC.md is more of a memory dump that it chooses to use on some tasks. I was recently thinking of either:
a. splitting it into sub-spec files that can be referenced. b. getting rid of it completely to prevent the LLM from hallucinating with potentially stale information.
Interesting project. Have you been able to try it on actual hardware yet? What’s the minimum RAM?
Yes, some people have contributed screenshots: os8088.com/hardware
256kb is the official minimum amount of RAM. 128KB should work but that's just going to let you run the kernel and some very basic built in apps.
So essentially like the original Mac in 1984. ;) 128KB of RAM is just too little to run the OS and applications at the same time with any kind of performance. But once the 512KB model came along, then things started to really swing.
Yes, it has been really interesting running into the same blockers that the engineers building early operating systems must have ran into as well.
I was able to boot the 1.44MB floppy image on my PS/2, but the mouse doesn't work.
I have serial mouse support right now (auto detected on COM1/COM2), but PS/2 mouse support is coming.
Someone was even able to get it running on a PC Transporter on an Apple IIGS. One of these: https://68kmla.org/bb/threads/setting-up-a-pc-trasporter-on-...
It seems Like projects like this (that include basic productivity tools) could potentially enable a small resurgence in sovereign computing. A 5 dollar esp32 is powerfulll enough to emulate 8086 architecture while running a tcp/ip stack, DVP display, and usb input peripherals.
With a simple OS like CP/M or others, a low cost computer you can actually trust to only run trusted code is possible again.
My take is that "sovereign computing" will go from something 0.001% of the population cares about to over 1% in the coming three decades, i.e. three orders of magnitude. It will depend on how long we continue in the current survtech course. There is also the question of if we will see mandatory backdoors in hardware. For example, Country X could legislate that all CPUs sold in their territory need to have a latent command-and-control area for law enforcement to use. If that happens, I'll start converting my savings into a physical stash of old reliable CPUs.
In any case, it seems that CPUs have a very long shelf life; it's still possible to buy 8086 processors[^1].
[^1]: https://www.digikey.com/en/products/detail/rochester-electro...
Default esp32 still comes with built-in binary blobs for the radio though iirc
It took me a moment to realise it's actually word 1.1a, since the source was related.
"Vibe-porting" has now officially become a thing, and I look forward to what other weird and fun ideas people will get to making because of AI.
Thank you for doing this. So cool. Its a form of time travel, getting to live the past.
A gopher client would be easier and no AI needed as the protocol it's trivial to parse. You have sites from gopher://magical.fish to gopher://floodgap.org and gopher://sdf.org (and, as a plus, you can read finger services).
Any working gopher to www proxy?
Using gopher client to load http data.
Also, Tristam Island for the Z-Machine:
https://github.com/hlabrand/tristam-island
You can just transcript the feeliest to plain text. If you have an Inform6 compiler nearby, just compile the game with the 'big' flags to get the "complete" Z3 version. It has the same text as the v5 one, and it will run much faster under a 8088/8086.
For a Zorkian adventure, just get Spiritwrak.