Wozmon for x86-64
github.comRead the readme, consider myself a mostly-not-total-idiot. Would buy author a beer to add a whole two sentences to illuminate what wozman is. If it's just that niche and I'm ignorant feel free to ignore me.
Ben Eater has a number of very informative videos on Wozmon on YouTube - what it is, how it works and and getting it to work on a home built 6502 machine, literally stepping through the assembly:
Running Apple 1 software on a breadboard computer (Wozmon) https://www.youtube.com/watch?v=HlLCtjJzHVI
How Wozniak’s code for the Apple 1 works: https://www.youtube.com/watch?v=SpG8rgI7Hec
Adapting WozMon for the breadboard 6502 https://www.youtube.com/watch?v=7M8LvMtdcgY
This might be helpful… https://www.youtube.com/watch?v=SpG8rgI7Hec
I find it a little weird that these comments always come up on hackernews… if you type "wozmon" in your URL bar and hit enter to search, pretty much _all_ the results are pertinent and helpful.
The source code[1] has a better intro:
> A complete instruction by instruction rewrite of Steve Wozniak's system monitor from 1976 for the Apple-1
I found a nice intro to Wozmon here: https://www.sbprojects.net/projects/apple1/wozmon.php
To add to your suggestion for the README: if this is indeed an "instruction by instruction rewrite" then it would also be helpful to include a canonical link to the original 6502 source. (Found a version here: https://gist.github.com/nobuh/1161983)
[1] https://github.com/IanSeyler/wozmon_x86-64/blob/main/src/woz...
It's the boot ROM that came with the Apple I. It was pretty big for the time given that in those days, computers didn't come with flash, so you had to bootstrap programs with dip switches and the like. The Apple I came with wozmon on ROM, which provided a (VERY) minimal prompt to edit/view memory and run programs from it.
> so you had to bootstrap programs with dip switches and the like
For more on this, check out this amazing series of videos from deramp5113 about the Altair 8800: https://www.youtube.com/playlist?list=PLB3mwSROoJ4KLWM8KwK0c...
(Also available on archive.org: https://archive.org/search?query=altair+8800&sort=title&and%... )
Good point! I've added some text about wozmon to the README.
It's a monitor by Steve (woz)niak.
Self explanatory really!
I have this image of you spending years painstakingly rewriting this, just for Apple to release their ARM processors.
FWIW I have no idea what Wozmon is, just a sentence or two at the top for people not familiar with the original.
> I have this image of you spending years painstakingly rewriting this
Initial commit: 5 days ago
What a coincidence. I recently converted the 6502 version to Python and then worked with ChatGPT to convert the Python to C. (I'm not a C programmer.)
https://github.com/gabrielsroka/gabrielsroka.github.io/tree/...
To support running code you'll need to call mprotect(2) on the buffer to make it executable.
If you hit Ctrl-d on this code it will burn through that loop constantly with no input. You need to check fgets()'s return code, it will be NULL on error or eof.
Thank you. I saw a warning about that from the compiler. But like I said I'm not a C programmer. Feel free to submit a PR if you like.
I assume you're talking about Linux/Unix. I'm mostly a Windows guy.
I am knowledgeable about both. Unix guy at heart but used to work for MSFT on windows.
The Windows version of mprotect(2) is VirtualProtect. It would probably make more sense to allocate the buffer with VirtualAlloc with the correct flags, rather than modify a stack buffer. The Unix version of that would be to allocate with mmap(2).
Edit: https://github.com/gabrielsroka/gabrielsroka.github.io/pull/...
Interesting to see it written in higher-level languages!
I remember vapor locking on figuring out addresses in hand assembled 6809 machine code in middle school. It was amazing what Woz pulled off with this. I wish I knew that the apple ii plusses in the computer lab probably had something like wozmon on them.
Very cool.
When it mentions a bare metal kernel, I thought about the BareMetal OS by ReturnInfinity: https://github.com/ReturnInfinity/BareMetal-OS
Yes - it uses the BareMetal OS kernel. I also wrote that.
Awesome. Nice and easy to get working as well.
wozmon.sh run will start Wozmon in a QEMU virtual machine.
Does it also run without the virtual machine?
From the author's BareMetal exokernel repository:
> Key features
> [...]
> Physical and virtual hardware support with full virtualization, using x86 hardware virtualization whenever available (it is on most modern x86-64 CPU's). In principle BareMetal should run on any x86-64 hardware platform, even on a physical x86-64 computer, given appropriate drivers. Officially, we develop on QEMU and VirtualBox, which means that you can run BareMetal on both Linux, Microsoft Windows, and Apple macOS.
There's no indication of specific real-world testing, though.
Why would it not?
Should have been more specific, can I run it on Linux or Windows and mess with the memory content? So why not? Because of dependencies on BareMetal or having to overcome the isolation build into the operating system it runs on top of.
I understand what this is. What I don't understand is what is the purpose of doing it.
Having a monitor is easier than constantly reflashing for every little change. (back in the days of EPROMs, much easier)
It is wildly impractical to not have an OS and have to manually program your computer every time you boot it. But don't you want to try it?
That depends. Do you want to avoid the Thompson back door? Maybe a 6502 or an 1802 with flippety switches and blinken lights can be verified not to be compromised.
fun?
That was the primary reason - a fun weekend project converting 6502 Assembly to x86-64 line by line. The x86-64 version comes in at a 384-byte binary due to instructions being a bit longer.