The Sym-1 SBC was at the cutting edge of the growth of the 8-bit micro computer. It had very good expansion capabilities for I/O but initially relied heavily on the Cassette Recorder as the medium for  saving and loading programs. When programs were in the order of 10 of thousands of bytes long this was a practical, and very economical solution of the day (C:1975-1980). However cassette tapes were not particularly reliable or fast. Worst of all they required considerable organisation to be finding and playing back the right tape for the right program.

The common experience of having a Disk Filing System was probably about 5-10 years off when the Sym-1 hit the shops C;1978. One of the more robust parts of its design was a comprehensive Monitor (Mon1.1) program that allowed the user to manually enter and edit programs in Hex format. It also allowed for 8kB language ROMs, such as Microsoft Basic and the Resident Assembler and Editor (RAE) to be onboard and in ROM. For many users to switch the computer on and have these major packages instantly available were game changers. These packages also very efficiently made extensive use of the subroutines built into the monitor program. The Sym-1 used a pressure-pad hexadecimal keyboard and 7-segment digital display. However a terminal could be hooked up to the board as well and which ever input, hex keyboard or TTY, was detected as active first, it took over the interactions with the user. This required the hexadecimal keyboard to generate standard ASCII tokens for commands and data, so this made swapping to a full ASCII keyboard and display just a matter of changing a few vectors on initialisation. It also meant it was seamless to have full ASCII interaction with BASIC and RAE as well.

One of the features that built into the monitor is vectoring of "unrecognised command" errors that are generated when undefined commands are entered. The monitor passes control through a vector before reporting them to the user. If the vector is taken over, unrecognised commands can be diverted to create new commands that have the same style, format and structure as the existing commands. The extensions then look and feel like they were always in the design. The commands to save and load data have S1 (Kim format) and S2 (SYM-1 high speed format) and using the latter as an example worked like this:

.S2 xxxx,aaaa,bbbb where xxxx was the index number of the program, aaaa and bbbb was the start address and end address respectively of a block of code to be saved. Notably this meta data was also saved as part of the tape data structure.

.L2 xxxx allowed the program with the index number xxxx to be loaded automatically back to its original address.

.L2 xxxx,aaaa allowed the loading/starting point in memory to be chosen.

xxxx can be any four hexadecimal digits. So ASCII style names can be used eg 8kB Microsoft BASIC might be saved and loaded as BA51 ie BASI and CE55 could be CHESS( se below)

This was a natural extension to the Mega Filing System, so the S3/L3 commands were created. It meant binary chunks of memory contents could be saved as files and reloaded to the original address or a new address. To do this the first two bytes of all saved files contain the default 16bit address they were saved from, and in many cases, most likely to be reloaded back to that address. This means a saved file will always be seen by the Mega 2560 as two bytes bigger than the memory block used to create it. Why do this? Well a long term goal is to be able create a library function where unknown commands are also looked up as files and can be executed by simply typing their filename. The program would be loaded at the default address, and execution begun at the start of the file. This would allow extension of commands and memory re-use (eg sequences of programs could be run in the same memory space, others might be semi permanent etc). A related goal was have all filing transactions run in raw binary and not have the overhead of trapping trigger characters in ASCII streams etc and sending everything in hexadecimal pairs in ASCII. Going to the trouble to compute lengths of files where ever possible and only using ASCII streams for displaying purposes. 

One of the challenges was how to create a file index or a name? I chose to simply turn the 16 bit number into 4 hexadecimal ASCII characters and use that as the name. This requires the age old hacker skills of creatively using 0123456789ABCDEF to create memorable four character names (with a bit more than 64000 possibilities, it should be sufficient for the average 6502 hacker).  Below is an example of a 16 byte file saved from $200-20F and called C0DD (ie C-Zero-DD).

This may be best shown by a self explanatory run through a demo (user input purple, explanation in green):

It also means larger binary images can be conveniently loaded such as Microsoft basic:

This 8k image loaded in under 3 seconds and would have been quicker without the loading progress indicators. So about 24kBits/Sec.

Or loading and then running the famous Micro_Chess from the Kim-1 stable

This is pretty powerful stuff.... but more remains to be done.

To return to the Sym-1 a 6502phoenix main page.