@lynx1076

Yall. Its wozzing time

Running wozmon on a diy computer that I alone developed, debugged and produced is really something else. I dont know how much this applies to you guys but I think its time we all took a step back as junior devs and consider the stuff weve built. Im really amazed as to what we are all capable of when we put our minds to it. A few months ago I was a teen with a stupid idea, in way over my head. Now Im running 50 years old software on my very own machine, just as the computer gods intended.

Ive certainly got quite a journey ahead of me but Im excited to see whats coming my way.

Happy hacking yall

American layout…

But hey ITS WORKING
Next Stop: Wozmon on the nano65

Quick status update

Im racking up hours too quickly so heres a quick update on what Im doing:

• Built hardware to support PS2 keyboard
• Switched LCD to 4-bit mode
• Started to work on interpreting keyboard signals

Some of you might recognize the circuitry from Ben Eater’s video series. If you’re looking to implement this in your own project make sure to add some series resistors for the 74HC14 outputs as they may ring heavily distorting your interrupts.

We ballin’!
Last time I caught some heat for not using a project related pic so here are some exciting pictures of my messy desk and horrible wiring. I am excited to announce that flashing and dumping the memory is now a somewhat survivable experience even though its kind of slow.

Right now Im just looking to hook up a PS2 keyboard so we can get some interactive stuff going but its lookin good. I had loads of issues with the wiring and since I was doing an internship up until friday I havent had much time but Im free now so expect more frequent updates more monke (lookin at you @fsh ) and more fanatic rambling about a processor nobody cares about (I LOVE ASSEMBLY)

Finally got flashing to work. The speed is absolutely abysmal (~30s for dumping and flashing) but it works and since single bytes can be quickly edited without re-flashing everything I don’t mind

Memory dumps now implemented. It’s a bit sketchy but you know… “Nothing more permanent than a temporary fix”

It’s a bit slow all in all but I already increased the baudrate to 500k and I feel if I go any higher it’ll probably die like a hamster in a microwave.

Just doing a quick post since I am racking up some time. Haven’t been working a lot on the software as I’ve been really busy recently. Anyways the command to dump the entire memory is almost done. Right now I am just making it print some specific known bytes from the dump.

Tried running the nano65 at 2.5 MHz aaaannddd…

IT WORKS PERFECTLY!!!

I just ran a simple program that reads a byte from SRAM, adds 1 and then writes it back. This program loops infinitely so I could see if the CPU would go haywire and it actually didn’t. This means more intense programs like video games (oooh spoilers) could theoretically already run.

Memory manipulation while processor is running!!!

The memory can now be safely written to WHILE THE CPU IS RUNNING INSTRUCTIONS AT THE SAME ADDRESS! After adding a pull-up to the RWB pin (low means write so I’d have to assert the clock low before turning off the CPU) the SRAM and EEPROM can be written to/read from arbitrarily while the CPU is paused and all registers are preserved. Spot a bug while stepping through your code? Change the byte immediately before the CPU even sees it.

UI starting to look good and memory interaction is working splendidly

I also decided to finally change the font so we don’t all get eye cancer.

Next is just going to be some QOL features like the panel on the left I haven’t really used. Probably going to put some status info there like if a vector is being pulled and the current clock state. Also going to implement writing a whole binary file to the nano65’s memory and dumping the memory.

Once that’s all done I’ll treat myself to actually doing some projects with the nano65 to see if any other features might be nice.

“The debugger is very confusing. It exists, but it’s very confusing.
I don’t understand my debugger.
It’s a low-level debugger and if you’re not familiar with
a low-level debugger you don’t know what you’re talking about.”

• Terry A. Davis

THE HOST APP WORKS

It’s now possible to step through a 6502 program using the debugger software instead of manually sending commands via serial. The GUI doesn’t look as good as I’d like it to but that’s a bridge I’ll burn when I get to it. For now the CPU can be reset with the hardware reset button and the stp (step [count]) command allows stepping through individual clock cycles. This will soon be changed to step through individual instructions instead to allow easier debugging but I’ll leave the direct clock manipulation in just in case.

The screenshot clearly shows the W65C02S processor stepping through it’s reset cycle (the pseudo-reads were omitted since they are meaningless). The oscilloscope shows the external clock doing the 7 cycles until the reading of 0xFFFC is reached (bus is sampled on high clock so the positive edges count as clock ticks). Woah you read all that? Thx <3

From here on out it’s just a matter of implementing the rest of the commands on the host’s side and then doing some cool projects.

Well I decided to fully scrap the TUI afteralll since doing that would not let me compile for Windows and Linux easily and a GUI was going to be the end goal anyways. Using raylib and microui and it’s looking good (so far).

https://www.raylib.com/
https://github.com/rxi/microui

Can’t get ncurses to work because I’d have to patch together like 5 different libraries just to get input working somewhat and you guys deserve better than me generating half of this project using ai cause I’m too dumb to figure out a 40 year old library. Stumbled upon this gem of a library (haven’t even tried it yet but the trailer so fire I had to share).

Next update will hopefully be one about the hardware once I figure out this TUI-mess.

notcurses
https://www.youtube.com/watch?v=dcjkezf1ARY

Well I haven’t broken the firmware (yet) but the host software is really making me go through a lot. Setting up a “simple” ui using ncurses turned out to not be that simple afterall which might be due to the fact I decided to write this whole project in C. I’ll get back to logging once I have some decent program running on the nano65 so I can show off all the cool features of the arduBug. Since I don’t have much to show for all my work right now I’m just going to flex my C sloc on all the react kiddies ; ). Anyways that’s all for today folks (well I guess that’s just you, dear mod, reading this until I get verified). I’ve got to catch up on some sleep now
(-_-)zzZZz

Working on the debugger (arduBug). Basically a little tool that I’ll use to manipulate the W65C02 processor and any devices on the bus. Its working well firmware-wise so I’m working on the host to let me interact with the nano65 (the actual computer) on a more abstract level. If all goes well I’ll hook up the VIA soon and from there on all sorts of cool things will be possible. In the picture you can see the full setup (arduBug, motherboard, and storage board). The oscilloscope shows the internal clock (2.5 MHz; will likely be decreased to 2 MHz). The interesting thing is that the arduBug boots up and turns off the internal clock to overwrite it with it’s own clock source. I was now able to revert that setup from the host software via a serial command.