nano65
Hardware
By
@lynx1076
- 8 Devlogs
- 20 Total hours
Educational W65C02 based modular computer
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).
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.
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.
