Read 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:
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.
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)
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.
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.
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).
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.
> 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.
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.
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.
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.
