ELF 2K ROM for 1802 Membership Card

This document last edited Mar 28 2020, updated Jan 21 2021 (c) 2021 Herb Johnson except for content by Lok "codedoctor" and others. Thanks to Bob Armstrong of STG and Michael Riley for their work on and with the ELF2K ROM software.

How to get the ELF2K ROM

Before Jan 2021, the last release of the ELF2K PROM was V.88. The ELF2K ROM hex file is on the sparetimegizmos.com Web site. Please read the site as below. Also, an archive was provided to the cosmacelf groups.io group in their files area under "STG Elf2K", part of the "full release" ZIP file under "elf2k". In both cases I'm talking about a v88.hex file which must be burned into an EPROM.

In late 2020, Mike Riley started working on elf/OS again, and he and Bob Armstrong worked on revising the ELF2K PROM. As of Jan 2021, there may be more recent versions available. Check with the above Web sites and with Mike Riley's elf OS Web site for later versions. The procedures on this Web page depend on specific code-addresses in the V88 hex file. - Herb


The ELF 2000 aka ELF2K, was a hardware and software product of Spare Time Gizmos produced around 2006. It includes a collection of code from Michael H Riley of ElfOS. Elf2K is a single ROM with a serial monitor to operate that software thru a serial port. Visit the Web sites noted for more information, but the ELF2K hardware product is not available as of 2018, the software is under terms as described. The Elf2K ROM has become a popular means for COSMAC owners to operate a variety of ELF-like 1802 COSMAC hardware systems.

"Codedoctor" Lok posted in the May 8 2018 cosmacelf Yahoo email list, his work on the 1802 Membership Card (Rev J) to adapt the Spare Time Gizmos ELF2K ROM to the card's EF3 serial port, by modifying a few op-coded. With his permission, here's what he described. It's based on previous work by Al Williams, also published in the forum's files. [Edits in brackets by Herb] - Herb Johnson

Adaptations of ELF2K ROM for 1802 MC

Notes by Al Williams, comments in italics by Herb Johnson.

Recently, I worked on getting the ELF 2K ROM [v88] running on my 1802 Membership Card. Al Williams documented most of what I needed in an excellent PDF in the Files section [as Membership 2K.pdf ]. In it, he reports that the ELF 2K ROM and the 1802 MC differ in how they use the EF3 for serial connection. Basically its [logic is] flipped, and in order to use the ELF 2K ROM in the MC, you need to wire up a small circuit to invert the EF3 signal.

He also documents possible changes to the ELF 2K ROM to do this via software, by switching the following OP codes:

Op code [change] 36 [to 3E] : 7C1C, 7C20, 7C2A, 7C9B, 7CCF
Op code [change] 3E [to 36] : 08C0, 3082, 6C11, 7C1E, 7C25, 7CA2, 7CD1

I wanted to use the ELF 2K ROM in my MC, and didn't want to make any hardware mods to it, so I decided to try modifying the ROM. One thing is the ROM checksum would need to be fixed, so the ELF doesn't error out.

Method 1:

I converted the ROM HEX to binary using HEX2BIN. Then I loaded up into HxD, my favorite hex editor. Found the locations above [in the binary], and flipped 36 to 3E and vice versa.

Now I had to fix the ROM checksum. First, I needed to figure out how the ELF 2K ROM was calculating the checksum. I presumed the checksum was going to be stored at the end of the ROM, and using the nicely built-in functions in HxD for multiple checksum methods, I found the last 2 bytes in the ROM matched the result for the HxD checksum count methods. It is a basic [16-bit no-carry] addition checksum (not 2's complement which seems to be a common method).

I set the last 2 bytes to zero, calculated the "base" ROM checksum via HxD, did some basic arithmetic, and got it to where the file checksum came close to the encoded checksum in the last 2 bytes. I could never get them to match, and I guess there's a trick to doing it properly.

[According to BOOTS.ASM, which is STG's monitor and diagnostic program, The monitor also contains a near compliment of the 16-bit checksum in the two bytes before the two-byte checksum. That way the checksum value itself is not part of the total checksum calculation. For V.88 the four last bytes are 8ABD 7643. 8A+76 = 100H, BD+43 = 100H. - Herb]

I figured I could just find a byte that isn't being used for code, and modify that to "true up" the actual checksum and the last 2 bytes. I found a bunch of FFs near the end, and used one of them. 7FEF: change "FF" to "10". 7FFE: change "76 43" to "75 7B"

Now I had them matching, I burned it into a 27C256 EPROM, and fired it up. The 1802 Membership card display started off at 98, counted down, but then stopped at 88. POST code 88 is an SRAM error. Hmm. I thought about it for a second, then while staring at the front of the MC looking for inspiration, I noticed the S8 switch was set for "READ". Doh! If it were testing RAM by writing, this would surely cause this error. I tested it again, flipping S8 to "WRITE", and it went all the way to POST code 16 (which means it is waiting for the user to press ENTER in the terminal program)!

I connected it up [to USB and a PC terminal program] via my FTDI Breakout USB to TTL board, and the ELF 2K banner came up on my terminal!

Anyway, I looked out there to see if anyone had done this, and didn't find anything, so I figured I would try it.

Method 2:

In private correspondence, codedoctor described another method. In the hex file, change the EF3 instructions and change the checksum in each modified Intel hex record as follows below. Also see the following notes. A Web search will find descriptions of Intel hex record format. - Herb

Line #   Original Line & New Line   
------   -------------------------------------------     

777      :10308000F9023E86F9043F06F90830068FFE52F831    
  -->    :10308000F9023686F9043F06F90830068FFE52F839

1730     :106C1000023E15F9043F19F908ABF800BBD4E0AF08    
  -->    :106C1000023615F9043F19F908ABF800BBD4E0AF10

1986     :107C1000739C73F800BCACBBABC0F229361C3E1E93    
  -->    :107C1000739C73F800BCACBBABC0F2293E1C361E93

1987     :107C200036201CE2E23E221BE2E236278BF6F652B9    
  -->    :107C20003E201CE2E236221BE2E23E278BF6F652B1

1994     :107C9000FCBDF801AD9EBFF6FF01BE369BDD9FBE69    
  -->    :107C9000FCBDF801AD9EBFF6FF01BE3E9BDD9FBE61

1995     :107CA0009FF63ECBF980BFDD2FC4C48F3AA07ADDAA    
  -->    :107CA0009FF636CBF980BFDD2FC4C48F3AA07ADDB2

1997     :107CC000F68E3BCA73D4FF0360F0D530A6FC0036B5    
  -->    :107CC000F68E3BCA73D4FF0360F0D530A6FC003EAD

1998     :107CD000D53ED1FF00D5AEFF0C32DF8EC0FF4ED4B3    
  -->    :107CD000D536D1FF00D5AEFF0C32DF8EC0FF4ED4BB


2048     :107FF000FFC0FA8DFFFFFFFFFF0100068ABD764339    
  -->    :107FF000FFC0FA8DFFFFFFFFFF0100068ABD757B02

A bit less meaningful with this method, but probably easier for most people, and just requires a text editor. - "Codedoctor".

In Jan 2018, Peter Schmid pointed out a hex record was missing from the above, to make the fix "[change] 3E [to 36] : 08C0" and supplied it as follows:

 141     :1008C0003EC4F831D4FF4ED4FF66204546343D0087
   -->   :1008C00036C4F831D4FF4ED4FF66204546343D008F

Method 3:

In Jan 2018, Peter Schmid as noted above, also said: "There is no checksum error (Post Code 97) now, but [there is] Code 88 [unexpected RAM]. I have 64 KB RAM, is it possible that the RAM test goes beyond 0x7FFF? [Also] I've attached this patch file [to use with the Linux parch utility as described in this linked document]." Peter has his own blog entry on patching the ELF2K ROM. I also gave him clues about the Code 88 he found. I don't think ELF2K expects RAM above 7FFFH (32K) where the ROM is. - Herb

Herb Johnson
New Jersey, USA
follow this link to email @ me

Copyright © 2021 Herb Johnson except for content as per sources or authors described herein.