Data Section

Here's a look at the echo list file vs hex dump of the binary file for the data section.

The header is demarked as values of 0x80.

Addresses are marked as values of 0x40-0x4F. The data value follows. This is shown to be more complicated in the above example where the last item data is placed at 400 which is after the code. To fix this, bin2mif would need to keep track of this and do the writes.

The weird part is the address encoding. For the first locations, the address in the listing is in octal and the address in the hex window is in hex. That makes sense. However, for the final value the number is 400 in both windows - strange? Not really since the upper 2 bits of the second byte get discarded.

Code Section

Now, take a look at the code section. The mapping is the same here:

The first cut at the bin2mif program read in the binary data until it found the 4200 (oct) and snagged the following data. That worked fine for the contiguous section of code, but didn't work for section after the code which had to be manually copied in the In System Memory Editor:

It would be nice if the bin2mif utility could handle this. This transition is also marked in the same way:

Fixing bin2mif, then, involves detecting the same address bit and filling out the gap between the end of the previous data and the start of the next data section.

Another way would be to have a 4K Word array and fill it as data arrives. That's arguably the best way to handle this.

Re-Wrote bin2mif.py

Re-factored the bin2mif code to interpret the addresses. It worked with the echo code. Command line was:

python ..\bin2mif_2.py echo.bin > echo.mif

Tested with the sieve code and it worked:

Success!