Cobbled together toolchain to build and test the demo programs and monitor

FIRST CUT WAS MANUAL ASSEMBLY - TOO TEDIOUS

At first I just wrote the instructions and then the hex values for each. Since the IBM 1130 has relative addressing for its short format instructions (single 16 bit word), each one has a displacement that is -128 to +127 words from the address following the one I am assembling. I have to calculate the distance, convert to hexadecimal, and then form twos complement for the negative displacements. 

I then transferred the words into a text file in IBM 1130 simulator load format, essentially four hex characters per line to load a word. An @ sign prefixes an address which changes the location where the next word will be placed. 

Every time I find a bug and make a change, I have to go through the code and recalculate any short instruction where it or the location it references have been moved. This is tedious. It then requires me to scan the load file I built and copy those changes into what is a long text file of four hex character lines. 

MOVED TO THE 1130 ASSEMBLER UNDER DMS TO ASSEMBLE THE CODE

By typing the instructions in the correct format for the assembler, which involves strict column positions for fields and other requirements, I could boot up DMS2 on the simulated IBM 1130 and assemble my code. The heavy lifting of calculating displacements was all done by the assembler, but I could just take the hex words listed next to the statement and transfer them to the text load file. Much easier.

Still, when I made changes, I had to manually locate any lines in the load file that were affected and adjust them from the new assembly listing. Still labor intensive but a step forward.

PYTHON CODE TO READ ASSEMBLER LISTINGS AND CREATE LOAD FILE

I whipped up some Python to read the printer output of the assembly job, which is a text based file produced by the IBM 1130 simulator. I grabbed the hex data words and output them into a new text file in the load format. I would look for the ORG assembler directive (origin) and grab the address to form the @xxxx lines in the file. 

I didn't want to recreate the assembler so I was not tracking how the address changed from statement to statement. I simply began a section from the ORG address and then snagged each word that the assembler formed from the statement.

I did run into some issue with some directives, which would fool my script into injecting a false word into the load file. EQU is a directive that makes a symbol table entry with some value, but does not reserve space or generate any words to go into memory. I had to skip past these. 

As well, the END directive outputs the supposed starting address that DMS2 should branch to when executing the code, but it is just an address not a value to put in memory. I had to skip it or I put spurious hex words in the load file. 

The most troublesome directive was the BSS - block started by symbol - which reserves space in memory. It would therefore be bumping up the address into which the next real hex word should be placed. One form is BSS 3 which means reserve three words here. I would have needed to keep a running shadow copy of the address that the assembler was using so that I could add 3 to it. 

Another form was BSS E 0 which means reserve one word if the next address is not an even number, otherwise do nothing. It is used to ensure that some double words are properly placed where the machine requires the first word to be on an even address A and the second word to be at A+1. If the double word in question was placed at an odd address, then the machine would pick up A for both words and never see the second word. 

In order to shadow the current address where the assembler believes the next statement will be placed, you need to know the sizes of every statement that came before from the last ORG. Too much work involved in that. 

I resolved to code with DC - define constant - so that BSS 3 would become three DC 0000 in a row. That gave me a load file output that put all the words in the right place, where the assembler intended them. Once I knew the limitations, however, I was able to quickly change, reassemble and process the listing to have a new load file I could load into the simulators memory.