Close

SYM-1 Mega Filing System

rob-wardRob Ward wrote 09/16/2021 at 04:24 • 10 min read • Like

The Sym-1 was a SBC, built by Synertek from around 1979 when it started to become popular, and while the name does not roll off the tongue of people who become nostalgic about computers of this era, due to the quality of its design and build, it was a remarkably influential system. It, and its older brother, the KIM-1 from MOS Technology, attracted many very competent developers in the hacker community (well, even the Hollywood word NERD had just been invented by then, and of course, with 20-20 hindsight we can recognise these were genuine 100% Hackers at the time) who went on over time to develop a number of disk operating systems to free the Sym-1 from its native Audio Cassette interface.

The Sym-1 had a high-speed cassette interface and was quite reliable (well, as good as any cassette recorder could be, eg good brands such as Hitachi, were very reliable), but lacked the speed and indexed directory access of disc drives. Going over the literature around this time looking for clues on how to expand my Sym-1 board to this level of convenience, the articles are firmly set in the boundary where 8inch Floppy drives were being upstaged by 5.25inch Floppy drives. (Wikipedia: History of Floppy Drives) Having two floppy drives, one for system files and the other for data files was very fashionable. IDE Hard Drives with capacities around the 20-30Mbyte were also becoming available but were out of the price range for most hackers of the day. Never the less, the trend was becoming obvious. Full height Shugart SA800s would have to give way to the Shugart SA-400, and later, low profile half-height, double sided systems, such as made by Mitsubishi etc would ascend, and finally the 3.5inch rigid case, but floppy medium, would claim supremacy. However even back in 1980, it was easy to see the capacity plus speed of hard drives would win in the end.

So there are a couple of designs for IDE interfaces and DFSs for the Sym-1 and I have bought an IDE to SD-Card interface to maybe try to get one working. But for the moment the thought of recreating a full IDE interface was too daunting and not really meeting my aim to dabble back in the world of assembly language and bits/bytes at hard metal level.

An article that by Bob Applegate (of Corsham Technology) caught my eye during this research described using an Arduino and SD-Card combo to do a handshake parallel interface to a retro computer to enable saving, loading and managing files. I liked the statement that no error checking was built in as it was so reliable. It would be technically hard call for me to bit bash directly to an SD-Card, and the thought of trying to emulate any sort of MS-DOS was overwhelming. Though others have done this very successfully.

The Sym-1 was designed by Synertek and the Monitor program was 4kBytes and was big for its day (two to four times bigger than other evaluation board SBCs). The company also distributed a version of the 6502 Microsoft BASIC in a 8kByte ROM as well as a Resident Assembler and Editor (RAE) also in an 8kByte ROM. (Other languages such as Forth and Pascal were also mentioned, but not as well documented). These two main offerings were available in 2 by 4kB ROMs or a single 8kB ROM. After completing the 64kB RAM upgrade (again from Corsham Technology, see my other pages on this project) I was able to soft load both these images into Sym-1 memory and run them successfully. I was very keen on getting the RAE up and running as it was the main focus of the serious Hackers in the late 1970s that were adding disk storage to their Sym-1s. I had also used the MS BASIC extensively in the early 1980s, and after selling my Sym-1 to buy an Acorn BBC 32kB and used its BBC BASIC, I was never, ever seriously returning to MS BASIC, it was a mongrel. Admittedly BBC BASIC was a 16kB creation, but it just had so much more to offer. However the RAE  (complete with Macros and Conditional Assembly for a start...) for the SYM-1 was like a jewel frozen in time that I was keen to explore. Playing around with Arduino SBCs only fuelled this desire to bash bare metal.

There was a spare Arduino Mega 2560 lying around in my parts drawer and I had a WiFi and SD-Card interface to put on it. The thought of being able to communicate with the Sym-1 to the Mega to the WiFi was a very attractive goal (dream?). An 8bit port on the Sym-1, and one on the Mega were identified and connected up. The Sym-1 side used a 6522 PIA port and a second port on the same U28 chip provided 2 bits for the hand shaking signals. Likewise the Mega used one port and 2 bits of another port to provide its hand shake. At some stage it would be more elegant to use the 6522 CA0 and CA1 pins for the handshake seeing that is one feature they were originally designed include. Saving on I/O pins is not a high priority at the moment, however the KISS principle is.

The initial aim was to use RAE to write the filing system, however this proved difficult due to the primitive nature of the RAE editor (no WYSIWYG there at all, just line numbers and the backspace key and a very convoluted line editor) and the fact that RAE loading and saving was mainly set up to use audio cassette tape machines. Hunting eBay and local op-shops for an old recorder proved fruitless, and writing a cassette tape emulator on an Arduino just seemed a dead end.  Why not just just go for it? So thinking big and using the online 6502 Assembler (Online 6502 Assembler, Masswerk) fairly quick progress was made. This is a truly excellent bit of software. 

The basics of a filing system that covered my immediate needs was to be able to Save RAE files (create), Load RAE files (retrieve), list a Directory of files (inspect entries), and Delete files from the directory. Some very simple safeguards and error reporting was also required to avoid mistakes, and the system locking up. So when saving a file, it was prudent to check if the file already existed and warn the user that continuing would cause an "overwriting" of an existing file, likewise when deleting a file a similar warning should be given that a file was about to be destroyed. Trying to load a file that did not exist, or delete a file that did not exist also needed to be alerted to the user. While it would be fun to go down the rabbit hole of sub-directories and navigating them, the simplicity of a sound working system would do for the moment. High on the list of further improvements would be dumping a file showing both hex and ASCII, as well as being able to save a binary file from anywhere in memory, and mirror that with loading a binary file anywhere into memory. Running programs by filename would be excellent as well.

So at the moment the Mega FS 2.3 is working and meeting my minimal requirements, hence this write up. Here are a few screen grabs to illustrate it in action. Latest Version 1.9 has ANSII ESC colours integrated as well, some on the 6502 side (yellow/purple start up banner) and some on the Mega2560 (directory listing cyan/red, user inputs are purple, explanations are green).

The above shows the entry into RAE from the Sym-1 monitor command. The monitor prompts with a simple ".", very modest!! Entry to the RAE begins at $B000, and the extension MegaFS code is triggered by a CTRL-C to the monitor and .G 9000. This links in three RAE Disk Commands, quietly embedded into the original RAE program as vector locations for future expansion to a disk based filing system. After all these folk were very forward thinking and designed versatile systems, so why not? None of the Apple II style detecting characters in the screen and keyboard streams to trigger its DOS commands. Changing these vectors after the main program was initialised allows them to be automatically redirected to use my extension code. (RAE commands generally only require the first two letters of a word, the rest is skipped over eg EN and ENTER are the same command, the TER is redundant).

DC (Disk Command) : There are two variations to the DC command. The LI variation is shown above "DC LI" and it simply returns a listing of the file names and their sizes on the SD-Card. The Arduino SD library is used extensively in this design, and basically does all the heavy lifting in managing the files on the SD-Card. Amazing stuff!!! Folders are identified but are not accessible. The listing is formatted into three columns but not sorted in anyway.

Entering the EPROM at $9000 not only sets up the vectors into the extension code, but also resets the work spaces for RAE to better utilise the 32kB RAM. The Sym-1 could originally be expanded on-board by adding 4kB of RAM (eight of 2114s, 1k by 4 bits), and the ROM startup values of RAE reflect this, so need redefining when 32kB is available.

LO <filename>: This LOads a file from the SD-Card into the program space of the RAE. It loads just the program so that programs could be sequentially loaded and assembled if required later on ie merged.

EN <filename>: This ENters a file into the SD-Card directory, in other words "saves" a file.

The above graphic shows a program called LOOP1.RAE being LOaded. This tiny program begins a $200 and ends at $235, so the length is $36 bytes. The program is listed to the VDU with the PRint command. To illustrate the safety prompts, the file is then saved back under its original name, and a "YN?" prompt ensues to alert the user an overwrite is about to occur. Pressing "N" aborts the save, and as we can see, responding with a "Y" allows the overwrite to proceed. Finally, if the filename does not exist, the save proceeds without any prompting.

Now we will have a look at the second variation on a DC command, DE (shorthand for DELETE) to allow us to tidy up the files on the SD Card from time to time. (NB This Version 1.18 or 1.8, ie no coloured file names etc)

The above shows the state of the Directory (DC LI) before a file, there is a deliberate incorrect attempt at the filename Loop.RAE to demonstrate reporting of non-existing filenames. LOOP1.RAE is identified and the process of deletion begun but aborted with N, and retrying LOOP1.RAE is then finally deleted, with a response of Y. A directory listing is then shown with the file deleted. It also uses simple feedback if a user tries to delete a file that does not exist, "N/A!", and if they correctly identify the file, that it is indeed what they want to delete, with the prompt "Y/N?". 

Another command whish is very useful to analyse what is going on with files is to be able to dump the hexadecimal version of the file. This function has extended the Disk Command DC with a HD, or HexaDecimal command. Note that the filing system now saves a default loading address, using the first two bytes contained in the file. When the file is dumped to HexaDecimal this is shown before the data contained within the file. RAE ignores this information and loads the file to the memory location as set by its memory allocation pointers (usually $0200). Whereas the monitor can use it or change it to another location. The reason for this will be explained further in the pages on the Monitor saving and load (S3 xx,yy,z and L3 xx) extensions.

Conclusions:

This very simple system is a huge jump in convenience over implementing any sort of audio cassette filing system (whether a real recorder, or emulated by an Arduino). The Wi-Fi system of the Arduino lies dormant at the moment. The grand plan would be to have the hand shake serviced by none other than the King of the SBC's, a Raspberry Pi 4 that has WiFi and will also enable file sharing through handshak

 Latest Version 2.3 has ANSII ESC colours integrated as well, some on the 6502 side (yellow/purple start up banner) and some on the Mega2560 (directory listing cyan/red).e across the PIO. That way the RPi could run the terminal program, provide the online 6502 Assembler, save object files into the shared folder and they could be directly loaded into the Sym-1 with a Disk Command for directly loading binary files..... Sweet!!!

Here is an example of entering the monitor (a "." is the Monitor prompt), and shows going to RAE (G B000) and then exiting to run the linking program for the MFS system (G 9000). Then loading 8KB BASIC in under 2 seconds (L3 BA33), and running it (G C00). Purple characters are the keyboard entries and the lime green characters are my post edited explanations.

How sweet is that? I used Escape codes to give the colours in the MFS 2.3 header and the list of folder files.

For the project overview and support files Project Page Sym-1 A 6502 Phoenix!

Like

Discussions

Rob Ward wrote 06/08/2022 at 03:49 point

Ah no, it was not the article I was hoping to find, though it is an excellenty article itself. The article I was looking for definitely used parallel port 8bit wide data exchange and hand shaking, the search continues.

As for your Rockwell AIM65 I am sure it would definitely work to some degree. Most of the convenience with the Sym-1 is the ability to redefine the vectors for different commands that are embedded in the Mon1.1 and RAE. If the AIM65 has similar vectors then I feel you would enjhoy the smooth operation too. I think you should study the L3 and S3 extensions to the Mon1.1 as they could be called directly from machine code links and would provide basic interaction with the Mega/SD system.

The beauty of the system as it stands is that not much would be required to totally rewrite the Sym-1 side of things for AIM-65 and leave all the Mega/SD side of it untouched. I feel it would be possible and very desirable to have a universal "retro-DFS" system set up where heaps of sophisticated commands (eg world time, sub directories, library directories etc) could be accessed with little overhead from the any type of retro-computer (what ever the CPU) required.

I hope to pursue this dream with using a RPi-4 rather than the Mega2650 very soon.

Best wishes and thank you for your interest in this project.

Rob

  Are you sure? yes | no

Rob Ward wrote 03/05/2022 at 06:30 point

Check the new features Palle

  Are you sure? yes | no

Rob Ward wrote 03/05/2022 at 02:19 point

I think the project should adapt fairly easily to any 6502 SBC as it does not use any complicated coding. It is not an operating system, just accessing files eg Loading, saving, deleting, dumping in hex and listing the folder content of files. Using an 8bit wide transfer allows a big speed up in transfer rate compared to serial/uart systems, and the handshaking eliminates messy timing considerations of processing between and during byte transfers. It can load 8k BASIC into memory in about 3-4 seconds.

I hope to add some extra features like copying and/or renaming files next. I would probably need to write and explanation page to describe the features and how it works so that people like yourself can more quickly see how to adapt the code to your needs.

Stay in touch and maybe I could help you in particular and that could become a page to share with others?

Best Wishes, Rob Ward

  Are you sure? yes | no

OZ6YM, Palle wrote 02/04/2022 at 16:16 point

I wonder if it is this artikel you ask for:  https://willem.aandewiel.nl/index.php/kim_tapedevice

I have tried for long time to make a system like yours but for Rockwell AIM65, with no succes until now.
I hope your system will work on a AIM65 as well.

Good luck..
Palle, HAM: OZ6YM

  Are you sure? yes | no