How WozMon works
Well you asked for it. After my last video there was a lot of interest in delving deeper into the Wozmon code and explaining how it works. So here you go! I walk through the code line-by-line explaining how it works and some of the tricks Woz used to get it to fit in the 250-byte constraint.
As always, thanks for your continued support and let me know if you see any issues with this video before I release it publicly. I may also do a shorter followup video talking about some of the changes I made to get it to work on the breadboard 6502 with serial interface. This video was getting long enough and I thought it better to just have a video focused on Wozmon itself.
Thanks again!
-Ben
Comments (17)
Late to get to watch this as I've been away; but I really wanted to say that I thought this was a *fantastic* video. Content like that is exactly why I'm proud and happy to sponsor you here. Thankyou for making and sharing this.
Another neat and very "Woz" choice that I don't recall being mentioned in the video is that SETADR loop. My first instinct would probably be just a simple LDA L, STA STL, STA XAML followed by LDA H, STA STH, STA XAMH. But by going to the trouble of making it a loop (even though it only cycles twice), Woz shaved off three bytes: One with the loop itself compared to the unrolled version, and two more by getting a "free" zero in X which he uses later at XAMNXT. Brilliant!
Thanks, Ben, this was a great deep-dive! I've had the privilege of writing plenty low-level OS code in assembly in my career, and I can assure your viewers that all of these tricks to make the code small and efficient are still in widespread use :-)
After watching this again, I'm confused about one point. In the prior video, you demoed how Examining a range of addresses (e.g., 0.9) leaves the first address (0x0000) as the "active" address, so that running with "R" will run from that address. However, the Block Examine code increments XAML in order to print out consecutive memory locations, which means it's pointing at the wrong location when you "R"un the code, which executes "JMP(XAML)". What am I missing?
On looking further, I think the manual is wrong here... after 0.A, XAML is 0x0A (and XAMH is still 0x00). If "R" jumps to that address (0x000A), it will try to execute the final byte of the entered program, which is 0x00, which is the BRK command. That should run the IRQ handler at 0xFFFE, which is... 0x0000 in Woz's ROM. So if I'm right, it's just a coincidence that R runs the program correctly in the previous video (which is also the example from the manual).
When examining 0200.027F, I see that all the bytes do not have the high bit set, and are just ASCII codes. Is this because the breadboard computer uses plain ASCII? Would running the original code would have produced 'B0 B2 B0 B0 AE B0 B2 B7' instead?
I think so, I had the same thought
Wozinak -> Wozniak
potato potatoe ;-)
A thorough explanation - thank you. I'm sure a lot of ppl would be looking forward to you writing a more complete multi-function monitor that's not constrained to a 256-byte "block".
I'm rewriting WozMon for the Atari 8-Bit line for the ABBUC software contest over the last few months and therefore am really happy to see your videos about it here! Will link to them in my documentation. I stumbled across the BVC NOTSTOR comment as well, but couldn't believe that Woz made an error here, so thanks for confirming my assumption :)
Super entertaining and educational! Thanks for the deep dive. :-)
How does ASL of BA equal 7B? seems to me it should be 74.
Good point, looks like another error in the comments. For the purposes of the code, 74 and 7B are functionally equivalent, as both have bit 6 = 1, and so the BIT command will set V.
Great video! In an effort to learn both the 6502 and Swift, my current project is implementing a 6502 emulator in Swift, and I'm using Wozmon as my first "full program" test case. I think your prior video had a lot to do with my decision. Watching you demo and explain Wozmon has already helped me identify a few issues with my implementation of the 6502 and my "Apple1PIA" BusDevice that emulates the Apple I keyboard & screen interface. A couple of notes: * around 23:51, you say that BIT "sets the Minus flag", and write an M on the card. The 6502 docs call this the Negative flag, represented by N. Not a big deal (and perhaps more intuitive, given the BPL, BMI instructions) * In the same section, you mention that the comment seems to be wrong, and you couldn't find this referenced online. Earlier today, I found a similar issue in the ECHO section at the end of Wozmon, where both the code comment and the explanation of the hardward in the text disagree with the code, and I couldn't find any reference to it online. I posted that to the Retrocomputing StackExchange: https://retrocomputing.stackexchange.com/questions/27265/error-in-apple-i-manuals-wozmon-listing-or-hardware-description
I disagree. This is EXACTLY the content that will win YouTube!
Also agree with your disagreement :>) - not sure what winning YouTube means, but Patreons and subscribers win for sure.