Title: Altair Assembler Part 2
Date: July 26 2020
Tags: altair programming
========================================

Writing an assembler that is a far bigger program than I've written previously
has exposed some problems in my development style and workflow that I've had to
overcome.

Since starting to write programs for the Altair, I've gone from pen and paper to
a text editor on my laptop.  I was still hand assembling and entering octal
using the front panel switches.  That worked well for small enough programs, up
to a few hundred bytes, but was problematic for anything bigger.

Typically, I would write programs as efficiently as I could (for my level of
skill and experience, which isn't much).  I'd keep as much data as possible in
registers and use JMPs instead of CALLs in order to reduce the need for memory
access.  I'd write code with the full knowledge of the code around it and
leverage that whenever I could.  This resulted it programs that ran mostly from
start to finish with few subroutines.  They were more monolithic.

Scope creep also became a problem for me.  Writing one big program in an
infinite length file of a text editor led me to keep trying to add more stuff.
This mostly resulted in frustration from the amount of time it was taking to
enter the programs via the front panel, and reentering most of it when I found
I've forgotten some code near the beginning.

Front panel entry was also time consuming in itself, and resulted in data entry
errors that were taking longer to debug than the new code I was actually trying
to test.


# Solutions #

I've made several changes to my development process.  I tend to make rules for
myself out of some ideal "right way" to do something or some idea of purity.  I
was trying to limit myself to options available in 1976 or so when the Altair
came out and only to code that I've written myself.  I guess, when it's not fun
anymore, I need to loosen the rules.

For the first thing, I actually went back to paper.  Not exactly a step all the
way backward.  I am writing on a reMarkable[0] tablet.  It offers some modern
features like easily and cleanly erasing mistakes, as well as selecting and
sliding blocks of text down to insert addition lines.  It's tied to the physical
idea of a single page, though, so doesn't scroll infinitely.  For me, that has
helped keep code shorter.

To compliment the "paper" development, and help myself write the larger
assembler program, I've changed my programming style from efficient monolith to
small, structured subroutines.  I've devised a somewhat consistent means of
parameter passing, using registers as much as possible, and returns, including
errors.  I have to touch memory more to push parameter and return pointers, but
the benefits are worth it.

Having many subroutines means I can write a small chunk of code and test it in
isolation.  I've written a small test program that I can plug a subroutine into
and tweak for testing.  I've found this had improved progress greatly by giving
me small successes and a growing library of subroutines that I know work.

I still found that data entry via the front panel was too time consuming and
error prone.  I would spend hours entering code and debugging simple mistakes
just to spend a minute testing the actual new code only to find a bug that
necessitated adding code which would mean re-assembling and re-entering a lot of
bytes creating new data entry errors.  It was slow, tedious, frustrating, and
demotivating.

I already had a solution for this.  I wrote a bootloader[1] that could be
entered first and used to load other programs.  I was going to write a full
monitor to use a permanent loader but took a shortcut and wrote a script to
convert my bootloader to binary and load it into the Altair clone's PROM.  This
eliminated any data entry from the front panel.


# The New Process #

So my process looks like this:

 * Write a subroutine by hand on the reMarkable and test by walking through the
   code.
 * Type the subroutine into a test program on my laptop.
 * Hand assemble the test program.
 * Fire up the Altair and run the bootloader from PROM.
 * Connect my laptop via serial, and upload the test program.  This is
   effectively cat-ing the assembled octal numbers.
 * Run it and if there is an error, go back to the test program on my laptop
   and correct it.  Reassembling by hand.
 * Re-upload to the Altair and test again.

As subroutines finish being developed, I'm adding them to a growing assembler
program.  This way, as features are added to the assembler, I know the code
works and I just have to tweak the main routine and make sure I update addresses
correctly.  Only having an assembler is going to fix that last issue.


# The Newer Process #

I started writing this post in February and never got around to finishing it.
When I had time at the computer, I used it writing more of the assembler.  Then
by Spring, I turned to other hobbies.

Right now, I don't bother with the test program as I'm deep enough into the
assembler to need a lot of prerequisites set up to run the next step.  I'm just
adding to the existing assembler program and adding the new functionality to the
main routine.

This way, all the subroutines are in place and addressed correctly and once they
are working I know I can use them to further build up the functionality of the
assember.

I still have some major issues to figure out but have a lot of code written and
working.  Iterating can go pretty quickly and has the coding has stayed fun and
engaging.


[0] https://remarkable.com/
[1] gopher://kagu-tsuchi.com:70/0/blog/articles/altair_bootloader.txt

You are viewing proxied material from kagu-tsuchi.com. The copyright of proxied material belongs to its original authors. Any comments or complaints in relation to proxied material should be directed to the original authors of the content concerned. Please see the disclaimer for more details.