I've been putting a lot of time into coding. I've learned some things about writing an assembler:

Problem: If I put a label in a macro and call it multiple times, the same label will appear multiple times. On the second pass, it won't know which is the correct label to jump to.

Solution: Each time I call the macro add a unique number to the label. So I have a static variable in each macro which increments each time it's called. This number gets appended to every label in the macro.

Problem: My macros can overwrite labels. If I put a label right before a macro call, and the first thing the macro does is create a new label, it will overwrite the existing label.

Solution: Error checking in label creation. In my label function, if there's already a label then exit with an error.

Solution: Error checking in second pass. If a label isn't found, then exit with an error.

Problem: No right shift in the 74181.

Solution: Create a left rotate macro. There's a left shift, so I grab the carry-out bit and add it back. Then left rotate 7 times. This is like a right rotate by one. Then to get to right shift, I can do a logical AND with binary 0111 1111. This is the great thing about macros - I now have left rotate, right rotate, and right shift instructions. As I add to my function library, I only get faster and more efficient at programming.

Problem: Need 16-bit increment and decrement operations.

Solution: Macros! I've started writing simple functions for 16-bit operations. Specifically, this is for the stack. I'm working toward push and pop commands, but I need elegant 16-bit operations on the address pointer. But I found another problem along the way...

Problem: Memory access is messy. Especially for 16-bit numbers.

Solution: Standardize memory access with macros. I wrote three macros to access the memory - reading from a destination, writing to a destination, and writing a constant. I've extended this access to 16-bit numbers. I always need 16-bit numbers to be in the same order, so I decided LSB is in the lower address, and MSB is in the higher address. I also arbitrarily change the data ram hardware pointer before every access to ensure even if this is not efficient. I'll make it more efficient later.

Problem: Debug capabilities need to improve.

Solution: Add a macro which converts a byte to two ASCII characters. So I can send bytes out to the terminal to see if the computer is calculating things correctly. I make liberal use of printf to debug, so this is my simple way of doing that. I also want to add this functionality to the bootloader to do the READ memory function.

Problem: Software is not flashy. I don't have interesting pictures on my blog.

Solution: Seriously get started on my TTL hardware. This was a big goal of the project, so I really need to get away from the FPGA. It's just so easy to stick with an FPGA and I can simulate to help debug. But I've reached the point where I can load program easily to RAM and even create a ROM program easily to create test code for the TTL computer. And I have a good hardware and software simulation of it, so I can check my test programs too. I guess it's time to pull the trigger.