• EPROM2764 - Hacked

    12/06/2023 at 09:33 4 comments

    Programming 2764 EPROM with a Mega2560, SD card reader and 5-12V Buck converter

    If you have ever wondered what it would be like to have a real retro -computer-nerd experience, then maybe programming EPROMs will fit the bill for you. Since the late 60's there were many and varied EPROMs sold, with different specs, but had better and easier programming procedures as time went on. Many had mysterious 3 lots of power rails early on (+5V, -5V and +12V), and with even more arcane requirements for Burning. The other factor was various manufacturers required different voltages on different pins and different timings for the same size memories. (Why "Burning"? Because many early EPROMs required 21V or 25V as a programming voltage, and it also had a great mental image of applying this voltage to a precious chip and BURNING the bits in, exciting!!! And conveyed the risk of what would happen if we got it wrong!!!).

    When I wanted to add an 8kb EPROM to my SYM-1 project I was not optimistic this would be easy. However, boldly going where no other hackers had gone before me, I struck out to simplify things and make it possible to do some EPROM programming with minimal new purchases.  I found out all one needed was a Mega 2560, a 28pin Socket (preferably ZIF, but not essential), a Mega 2560 shield, an SD card adapter, 5-12V buck converter (or some other static 12V power supply), and a single throw double pole switch. Some LED indicators can be added for the nervous Hackers who like to test things and feel comfortable things are happening properly. Essentially (and amazingly) things that can be found in the average spare parts (reuse?) bin these days.

    Below is the type of 2764 I have found has worked. Now, a warning, these things are produced in batches and I may have just been extremely lucky and found this system works on the only one or two chips in the known universe. However I have ordered from three different sources and they all work, so I feel confident some people will experience some success, in fact most people will experience total success. The EPROMs I have programmed 2 years ago are still working fine and have no errors. If you do not need 8Kb, then tie a few address lines low and just use part of it (they are so cheap, who cares?). You get the convenience of low cost Hacking, and a workable solution.

    **** Download the EPROM Burning Program ****

    And the physical setup looks like this with the Mega 2560 below, shield on top with 28Pin ZIF socket, 5-12.5V buck converter (adjustable to 12.5V) and a single throw double contact switch (plus a few optional indicators LEDs).

    The wiring gets a bit messy on the shield board, but can be done. If you want to use one of the shields with a prototyping board (see the one above where I have added the indicator LEDs, it came with the Mega2560 prototyping shield. Search eBay with "Arduino Mega 2560 Prototype PCB Shield with LEDs Reset Switch + Mini Breadboard") then the pins can be connected (note a double width dual in line socket would need to be added to the RHS board of the shield to facilitate the plugin wires) with the usual prototyping "plug and play" connectors. The big advantage of this idea is that  many ROMs/EPROMS and even EEPROMs could be accommodated by moving the wires around and writing your own software building/improving on my work.   

    Looking at the connections I found to work to Burn the 8kb EPROMs, so we are are looking to Burn 2764's

       Port  MegaPin Vpp   1         28 Vcc      Port Mega PIN
        K    12      A12   2         27 !PGM     K     15
        A    29      A7    3         26 NC       Vcc
        A    28      A6    4     ...
    Read more »

  • Extensions to SYM-1 Monitor: Saving and Loading, S3 and L3

    03/05/2022 at 10:18 0 comments

    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...

    Read more »

  • SYM-1 to USB Serial

    01/30/2022 at 02:50 2 comments

    The 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 »