tty7

I just spent way too long trying to figure out why I couldn't receive data correctly. I still haven't figured it out for sure, but I'm pretty sure it has to do with the start and stop bits.
It should say examples/serialtest.gasm

Started to add a loader for the files onto the FPGA - still need to verify a bunch of settings and figure out the protocol, but the base serialport code is done.

I got the last bit of error handling polished, and the examples are part of the github release now.

Made it fully work on windows - It used to not work with backslashes in the path (oops I'm a linux user)

Made error handling more user friendly - Suggestion by Alex on Slack.

Here's one of the things that I fixed.

Fixed a really annoying bug that would've been annoying for first time users to debug.

Thanks to my 4 followers for following along with this project, but it's time to ship it! There's now a short (1 minute) demo video on YouTube, since I can't really have an online demo of my project.
https://youtu.be/B5GBNrQVszc?si=Fgf8VyLKP-yROzF4

Now that school has started, I don't have time to finish my nice demo before I ship it. Lots of time for this devlog wasn't counted, since it was spent with a pencil and paper trying to debug my division code. I don't have a good screenshot of the division code so here's the readme.

Remember how in the last devlog I thought I had division done? Yeah it's broken. I didn't test it thoroughly enough. After I get the division done, I'm going to be ready to do about another 10 mins of programming, record my demo, and ship it though.

The expected register state is [00, 00, 00, 00, 10, DB, 00, 06] by the way.

Division is done. That was hard but it was really exciting seeing it working.

It successfully did 50151 / 123 (and a few other divisions), getting the result of 407 remainder 90 (the reason you don't see that in the screenshot is because the screenshot is in hex, not decimal).

Rewrote defines, worked on a demo, also rewrote the symbol table.

In the last devlog, I said that most of the programming work was done. That was a lie. Now most of it is done, since I just completely rewrote the defines system, which still needs one part to be finished, relating to the symbol table. The defines system now uses a preprocessor for the assembly parser like I talked about earlier. This system will be much more reliable and powerful.

The symbol table has been integrated. There's not much left to do before shipping, just updating the docs and writing the demo (and maybe improving the formatting for the symbol table labels, since I'm not too happy with it right now).

Serial text in is now fully functional, there's actually a dialog for it so it's easy to use, performance optimizations, minor bugfixes, and much more. Defines were updated to (hopefully) in the future be able to be used for more than just addresses, but that would require a preprocessor for the parser. A couple of longstanding bugs were fixed, notably the status register not being updated for a few instructions. It's just more polished and close to being shipped. I'm mainly going to focus (for now) on getting debug symbols integrated into the disassembler, then I'm going to do a polishing pass and update the docs. After that, it's just going to be writing a demo program and shipping it!

That took way too much cumulative time (a lot of which wasn't logged, since it was spent running it in the debugger) to fix the live disassembly bug, but it's fixed now (also minor optimizations because that was the entire point of rewriting the live disassembly)!

I've been doing a lot of debugging (on many things, some of them are fixed now), and I still haven't figured out the problem with the disassembly. However, the framework for a lot of stuff is now in place, and I'm working on a couple of libraries that I can use for the demo code. The IO is now working, but I'm going to add input as well as output in the simulator because I feel like it (and I think I need it for the demo code).

Lots of stuff was worked on, but this is the most exciting. There's now rudimentary (still need to debug new lines) text out!

Welp that performance problem is looking kinda bad. I still haven't fully fixed it yet (the fix is in place but I'm still debugging it). Anyways I'm not at my computer right now so enjoy the screenshot of the commit messages.

The function causing the problems has been identified - It is indeed the actual disassembly, not the binary parsing. The amount of string processing that needs to be done with disassembly is very compute intensive. I don't remember if anything else was done, so that's it for today.

I got the jsr stuff fixed (I was just being an idiot), and symbol table generation is done, but this is way more important. I realized that when just holding down the step key on my keyboard it was pegging one core of my CPU without even running that fast. I tried to figure it out, and it hung cachegrind. The live disassembly apparently is copying WAY TOO MANY strings and is killing my computer. This is the report from cachegrind. I'm going to have to optimize that before I can keep working now...

Lots of stuff in progress right now, like debug symbols, subroutine disassembly, and a serial interface in the simulator. Nothing's done yet though.

Wow, the project is getting pretty close now. I added live disassembly, a way to see which operands are being compared, and a way to see the memory address of each element in memory. It's a lot more polished than it was, and much easier to use. I think that I'm just going to add a few more instructions, improve the disassembly, and update the documentation with everything that I've added, then ship it. I also need to write a good demo program for the ship. After all of that is done, I'm probably going to ship it. (This devlog was supposed to be posted last night, but it wouldn't let me since it hadn't updated the time yet)

The simulator looks so much better now. I also finally got around to fixing some of the bugs in the executor, and it's getting not too far from being shippable (but there's still a major feature for me to add before I'm ready to ship, so there's a while yet). I've also determined for sure that I want to have live disassembly of the memory around the program counter, since it will be a lot easier to understand that way.

TUI's are hard. Getting my simulator to work is even harder. Why not combine the two? (cries in depression) In all seriousness, the tui is starting to look nicer, but I still have a lot of work to do so that I'm happy with it. I tested the code that I wrote last time, and it is working. However, I also tested the subroutine code that I suspected was broken, and it was. I need to fix that logic, and I still haven't gotten around to finishing carry logic in the executor. It's getting a lot closer, though.

That was so much more painful than I thought it would be - I got the assembler rewritten, but I don't have the time, patience, or energy to make sure it's working correctly now. Once this whole .org thing is over and I can actually output complete images, I can get back to working on the simulator instead of the assembler, which was supposed to be done. Attached is a picture of my pain (look at the error count)

Not much has been done, but small update: the function to fix the issues I was having with .orgs has been written, as well as the code to calculate where to insert when there's a .org without an address. Now I just need to rewrite just about the entire assembler to use them, but after that .orgs should work and I should be able to focus on the simulator again.

I think I'm going to call it for at least an hour - turns out I was completely right in my last devlog about cursing myself. Making origin setting is going to necessitate rewriting several hundred lines of code, which I don't want to do but I will because otherwise the assembler can't actually really use orgs the way it's supposed to. Word setting works, and org setting works as long as it is in ascending order of addresses, which I would usually say is fine, but the reset vector goes at the very end of memory. Orgs apply to all code after them, and includes get added on to the end of the file. This means that I have to change every push and append to the output vector to an insert and I don't even know what else (I haven't looked yet) so that it can use the zeroed out sections in the space between code and other code segments. Oh I also made warnings and errors colored because why not.

There's now the beginnings of a simulator! The tui still needs a LOT of work, and there's a lot of debugging to do.
However, I know what the first feature needs to be: assembler directives. It was something I knew I would need to do when I wrote the assembler, but I avoided because I knew it was going to suck. Future me is now needing the feature, and I wish I did it already. I'm going to have to make the assembler output a full binary image. There also needs to be a way to tell the assembler where in memory to put a segment of code, and a way to put raw bytes in a location in memory. It shouldn't be too hard to implement, but by saying that I've now cursed myself.
There are also a few more instructions to finish up in the simulator's executor module (all of which have to do with me REALLY not wanting to make carrys work), but the project as a whole is starting to get shippable (I still have a lot more features to add, so I'm not close to shipping, the project is just starting to be actually usable).

Update on the hackatime ban: There was an oopsie on their end in a push to prod (real men test in prod) that caused me and several others to get falsely banned. On a more positive note, the binary parser is done and integrated into the executor, so the only actual simulation part left is to stop procrastinating and make carry logic actually work.

Side note: I looked at the commits and it looked like the oopsie was a typo where it changed from truststatus == red to truststatus != red or something like that that caused the ban. The typo was fixed in another commit 2 minutes later.

I've been working on the simulator, but my account got flagged on Hackatime???? No idea what's going on, but hopefully the false ban gets removed soon. No new finished parts yet, but I need to post a devlog to keep my hours. The executor part of the simulator is what I was mostly working on, but I've switched focus to the binary parser now.

I got pointers working at the cost of my sanity. At least, I'm calling them pointers. They're more like named memory locations, since they are constant and replaced at assemble time. I spent so much time debugging problems I had already solved or problems in the assembly I was testing it with because I had forgotten my own subroutine syntax. Oh well, it's so much easier to use now.

Branches with labels now working - It's time to build a simulator

The assembler works! Despite that, there's still a lot of work to do. I need to make branching work with labels because it's kind of useless otherwise, make a way to set the location of instructions in memory (and pad the file to a certain size), and write a simulator with debugging (uh oh). Working on branching is going to be my first priority.

Massively overhauled the includes system - multiple files can have the same subroutine names, and it just feels way more natural. Subroutines were also completely rewritten to not require hardware support anymore, and are instead implemented with jumps and the stack in the code itself, instead of the instruction decode unit having to do it. Overall, it's just much nicer to use.

I got includes working (finally) after much struggling with why dependencies of dependencies wouldn't work (I wasn't actually using the value, figures).

The parser is done! You have no idea how much pain this caused me, but it was still less than I thought it would be.

My hackatime is working, but the project isn't updating.

I finally finished writing up the specifications for what I'm going to be writing - There is now a Gold ISA and a Gold assembly language! Now I can finally get to real programming, not just markdown.

Started work on my first project for hack club - it's an assembler for an assembly language that I'm writing which targets an ISA that I'm also writing. So far the only work has been on documenting the ISA, since it's kind of impossible to write an assembler if the ISA that it targets doesn't exist yet. I still have no idea what to do for a logo, though. The ISA is meant to target the Alchitry Au V2 FPGA, which I'm planning on getting soon.