-
Extensions to SYM-1 Monitor: Saving and Loading, S3 and L3
03/05/2022 at 10:18 • 0 commentsThe 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...
Read more » -
SYM-1 to USB Serial
01/30/2022 at 02:50 • 2 commentsThe Sym-1 was created by Synertek in the age of Teletypes ASR-33 when they were pretty much the best "golden standard" interface available for some, and for others the cheapest was the ubiquitous Hex keyboard and display. Well it was 1978, or thereabouts, and real live hardware of any sort was hard to come by, and these guys wanted to reach out to what we would call "startups" everywhere to try and hopefully buy this exciting new technology. These were the Arduinos of the 1970-80s. Many big players like Apple, Commodore and Acorn got involved and sold many thousands (millions?) of computers based on the 6502 processor. But it also opened a fantastic world to a whole bunch of bedroom enthusiasts who just wanted to know what was going on and what these things could do. The board that preceded the Sym-1 (originally called the VIM-1), was the KIM-1 designed by Mostek. This was a huge success, and was loved by enthusiasts (no such terms as nerds, geeks or hackers back then) the world over The Synertek design was an upgraded model and a much more capable machine, though the underlying technology was the same.
CRT's (Cathode Ray Terminals) at that stage were only glimpsed through the closed doors of the main terminal rooms of a card punch room that the lowest rung research students got to batch process their wonderful creations.
Understandably just providing an RS-232 capability as well as 20mA current loop was considered a really advanced and versatile system. In one way the Sym-1 designers were ahead of their time as the RS-232 could be rigged up with a serial interface just using TTL 5V levels logic. (RS-232 usually involved 15V supplies of positive and negative polarity.) The thought of having a computer siting on the desktop right beside the terminal had not really sunk in, and the RS-232 voltages were used to minimise the effects of noise in long wire connections. 5V Serial is now often seen in the Arduino world for example.
It seemed logical to bit-bang a full USB interface on the Sym-1 to drag it into the 21st century and so the wide number of terminal apps in today's modern operating systems could be used with it. Using a USB FTDI Basic from Sparkfun seemed the way to go and was connected up. This proved not to work. After a bit of multi-meter work it was determined the polarities of the data streams were inverted. So while the RS-232 assumed a "hi" signal was -15V, the 5V logic assumed it was something above 4.5V. So the Sym-1 understood 5V logic but the signal would be inverted. The FTDI board provided a 5V rail and a GND, and a couple of BC548's and four resistors were rigged (hacked?) up as inverters.
This proved to work. How is this known? Here is a printout of the Sym-1 boards response when a 'Q' is typed after a reset (plus there is a Beep from the piezo transducer).
The Sym-1 has a dual login option. If the Serial Port responds first it auto detects the Baud rate and continues to work with it. Alternatively the onboard keyboard has "CR" (carriage return), and this then would assume control. The "." is one of the most modest startup messages ever.
The Baud rate is determined by timing the first character typed and setting the Baud rate from that. In this case it is the character ASCII 'Q'. It is probably one of the most understated boot up messages of all time, the Sym-1 responded with the "." to indicate a successful negotiation of a serial connection. Extremely modest! However, as we shall see, this self effacing group of programmers were an inspired group and wanted their design to incorporate as many really useful features and not just "glam".
So if you have a retro SBC lying around and it says it has an RS-232 interface then you will probably need to reduce the voltage swings to a 0V-5V range to get it to work with a modern USB-FDTI interface, but also invert the signal polarity as well.
If you would really like to go down a retro computer rabbit hole, then look up "RS-232" pin-out...
Read more » -
SYM-1 Memory Allocation
09/21/2021 at 04:25 • 0 commentsThe Sym-1 had a comprehensive expansion strategy with both I/O (3 6522 PIAs and a 6532 RIOT) and memory. The board was shipped with 1kB RAM and this could be expanded "on-board" to 8 2114 Static RAM chips to 4kB onboard. (It also allowed write protect of this extra RAM in 1kB blocks). There was also provided four 24pin ROM sockets. As shipped it had its monitor (Supermon 1.0) in a 4kB block from $8000 to $8FFF. The other three sockets were pre-wired to accept 2kB ROMs, or EPROMs.
To be able to do this configuration after shipping meant providing some ROM selection to be done in the factory but to also allow later configuration in the field. A system of address decoders (74LS145) were used that were open collector outputs and options to "OR" these together to be able to map ROMs from 2kB, 4kB and 8kB into the upper memory spaces. RAE and BASIC were both available as two 4kB ROMs or as single 8kB ROMs.
Here is an example memory map of the upper 32kB
$8000-8FFF SuperMon 4kB $9000-9FFF Supermon Expansion or Extensions 4kB $A000-AFFF Memory Mapped I/O and 128B of System RAM (Not usable as ROM) 4kB $B000-BFFF
$E000-EFFFResident Assembler and Editor (RAE)
(This has separated 4kB entries *, and note correction below )4kB
4kB$C000-DFFF Microsoft BASIC 8kB $F000-FFFF Extension area (must include ROM startup Vector) 4kB In the early 1980's the 2716 EPROM (2kB) was a popular and easy to use chip and was often used to expand the Sym-1 ROM memory. These days the 2764 EPROM (8kB) is about the same numerical price or cheaper in quantity, and of course much cheaper given inflation. However a 2764 has 28 pins and not 100% compatible with the 24pin onboard sockets, but a good proposition having 8kB capacity means RAE or BASIC or Supermon+extensions could fit into a single chip (and we could fill the upper 28kB with ROM if desired). The old 2364 masked ROMs had only 24 pins, but as soon as the EPROM version is chosen it has extra pins for program enable and provision of the programming voltage (eg 12.5V etc)To get around this a riser board was made that has a 24 pin plug below and a 28 pin DIL socket on top, with the leads routed to reproduce the pin-outs functionality of a 2364 masked ROM.
Because the pin-outs of a modern 2764 are about 85% identical to a 24pin 2364 only small changes needed to be made to re-route the various signals. This is outlined in another page here XXXXX. The trick after "burning" the EPROM is getting the memory map links set up so that the EPROM appears in the right memory locations. The information in the manual is very helpful and accurate, but organised that well to instantly make clear what needs to be done. Below is the array of connections (and PCB breaks) used to implement the system above.
The jumpers and PCB Breaks list:
C to 1 Allows RAE EPROM access to A11 ROM U22 E to 4 and G to 4 Allows Supermon +Extensions EPROM and
RAE Access to A12ROM U20 J to 10 and J to 9
(9&10 are switched to J)Adds CS for $9000 and $9800 Extensions ROM ROM U20 K to 11 CS for Extra ROM (not used here, eg BASIC at $C000) ROM U21 L to 46, L to 47,
L to 15 and L to 16CS for RAE EPROM, $B000-BFFF and $E000-EFFF ROM U22 Cut PCB at C // 2 disconnect S21 pin 18 from GND ROM U22 Cut PCB at E // 3 disconnect S02 pin 21 from GND ROM U20 Cut PCB at G // 5 or 6 disonnects S22 pin 21 from 5V ROM U22 This is essentially enabling the high address lines A11 and A12 for the bigger 8kB EPROMS and to also free the same lines from being tied to GND or 5V (for the original 2716 chip enable OE or CS pins).
* NB: RAE Addressing QUIRK There is a quirk in the Sym-1 ROM slots. Where A12 goes to the U20 Supermon chip correctly, there is a mistake for the U22 chip position that I chose for the RAE chip. It has the A12 line inverted. What this meant was I had to split the ROM image for RAE in half and reverse their position in the 8kB ROM. So $B000-BFFF was in the second half of the EPROM and $E000-EFFF...
Read more »