6502 : BEN2 : Streamline downloads

Intro

My assembly language programming ability is very minimal, in part because I don't actually write many programs.  In order to create a working program I proceed with writing and testing code in very small increments.  This allows me to identify problems without looking through lots of code.  However it also means I have to assemble many iterations of a program before it is completed.

Ben Eater's original 6502 system required you remove the computer ROM from the breadboard, flash the latest program in an EEPROM programmer and reinsert the ROM each time a change was made to a program.  It was a great method to get started, and wasn't too painful when copying Ben's programs and testing them, but only allowed me to write the simplest of programs.

In BEN2, I put the ROM into a ZIF (zero insertion force) chip holder which made the removal / insertion task much easier, and avoided disturbing wires.  An Arduino mega was attached to Ben's computer to allow monitoring of address/data lines as instructions were executed.  I incorporated some simple changes to the circuit which allowed me to use an Arduino sketch to program the ROM in situ.  This was a much better solution and I have been using it to write programs on BEN2 and its predecessors for a long time.

I now have a new mechanism using a simplified xmodem protocol to download binary files from the PC to BEN2 RAM using the ACIA serial adapter.  It gives me the opportunity to make further improvements.  In particular I want the process to be simpler, require less intervention and be a bit faster.

Use a script

The tools for building and downloading an executable were as follows:

1.  Edit assembly source program using Notepad++
2. Put all the following activites as batch file commands
3. Assemble the program using ca65
4. Link the program using ld65
5. Run my own C program "FormatHexProgram" to format the executable as an Arduino data statement.
6. Use the Arduino-cli tool to compile a sketch containing the executable as data
7. Use Arduino-cli to run the sketch which copies the executable to ROM

The new process utilising xmodem is already simpler:

1.  Edit assembly source program using Notepad++
2. Put all the following activites as batch file commands
3. Assemble the program using ca65
4. Link the program using ld65
5. Run my own C program "serial5" to transmit the executable from the PC to BEN2
6. Tell BEN2 to receive the program and store it in RAM at the specified address

Previously I called bash.exe in a batch file to execute linux commands in WSL.  Since ca65, ld65 and serial5 are all linux programs it is easy to invoke a shell script which then runs ca65, ld65, serial5.  I still prefer to use Notepad++ in Windows to create and edit source programs.  It is also convenient to put all the necessary parameters in a batch file and then call a shell script and pass across the values for processing. 

Use minicom

My 6502 + ACIA serial connection uses COM9 for terminal input / output.  Putty is a widely used terminal emulator which I have used for many purposes and I have been using it for my 6502 screen.  There is a slight irritation, when downloading to the 6502 using my serial5 program I have to "hangup" the putty session, then "restart session" afterwards.  I couldn't think of a way to automate this  pause/resume and the rest of my processing is in WSL so I thought I should try a linux alternative.

Minicom is a simple, free and widely used program and it is easy to configure it to use COM9.  Once it has been started it works in the same way as Putty so there seems no downside to changing over.

One bonus is that you can setup function keys F1-F10 in minicom using macros to play a sequence of keystrokes.  For example, I often use the "s2000" command in the 6502 monitor to run a program at address $2000.  I set up F1 with a macro to execute this command for me.

Share the COM port

When I tried running a serial5 download, with minicom running I found that it still worked.  Minicom doesn't mind sharing the COM port with a linux program.  In fact it does display the terminal bytes on the screen which is slightly messy.  Minicom uses Ctrl-A as its escape/command character; when sharing the port it wont interpret Ctrl-A as a command, it just sends it down the wire.  This protects the session from being corrupted by the binary data.

So now it is rather wonderful that I don't have to pause/resume the terminal, I can run the serial5 download without further action.

Of course I do have to make sure that the monitor is running and start the 6502 download with the x command.

Even more exciting, I can use the linux command line to type in command for the 6502.  The following screen shows a few linux command line inputs being executed on the 6502.  the "l" command is my favorite "sticky key" which checks that the screen is responding.  "m1000" displays a sequence of memory addresses. The "x" command starts a download.  This is wonderful; it means I can start the 6502 download from my script, I don't need to do it manually.  In fact, I just have to make sure the monitor is running when I assemble / download a new program to RAM.

An even more, more exciting option that I could experiment with is to add a write command to my monitor.  I could then use a WSL command something like
    "printf w <data.....> " /dev/ttys9"
which would store the data in RAM without any need for specialist download programs at all.

I haven't implemented this yet as my download process is working well, but the future may be wonderful.

Conclusion

I started this snippet of work as a tidy-up operation and it has developed very nicely.  I have a totally automatic process for building/downloading programs to RAM together with the ability to remotely enter commands from a script.  There is also a possibility to change / simplify my download process further with a new "w" monitor command.