Category: Software

While I was putting together the Tek 492 memory board reader, I though it’d be a nice idea to add a small display. While the Arduino has USB serial I/O, the update rate is fairly pokey and an on-board display can provide more-or-less real time status.

Given that the reader was built for an early-80s memory board, I just had to use a pair of Litronix DL-1414 4-character LED displays from my parts heap. The DL-1414 datasheet [Update: link rot? try that] proudly proclaims:

The 0.112″ high characters of the DL1414T gives readability up to eight feet. The user can build a display that enhances readability over this distance by proper filter selection.

I think that distance is exceedingly optimistic.

However, I needed to see only a few feet to the benchtop. Even better, adding the displays required no additional hardware: the SPI-driven shift registers on the board already had address and data lines, plus a pair of unused bits for the write strobes. What’s not to like?

This schematic connects to the one you just clicked on; the two big blue bus lines are the same bus as in that schematic.

If you don’t have anything else riding the data bus, adding a pullup on the D7 bit that isn’t used by these displays will make all the bits float high; the DL-1414s seem to pull their inputs upward. That came in handy when I was debugging the EPROM-burning code, because reading data without an EPROM in the socket produced 0xff, just like an erased EPROM byte.

The two displays are the dark-red rectangle in the lower-right of the first picture, covered with a snippet of the Primary Red filter described there.

These closeups, without and with the filter, demonstrate why you really, really need a filter of some sort.

Using the displays is straightforward, given the hardware-assisted SPI code from there. You could actually do it with just the I/O pins on an Arduino board, but you wouldn’t be able to do anything else. If you don’t have any other SPI registers, you could get away with a pair of HC595 outputs:  7 data + 2 address + 2 strobes + 5 outputs left over for something else.

A few constants set the display size and a global buffer holds the characters:

#define LED_SIZE            4            // chars per LED
#define LED_DISPLAYS        2            // number of displays
#define LED_CHARS           (LED_DISPLAYS * LED_SIZE)

char LEDCharBuffer[LED_CHARS + 1];       // raw char buffer, can be used as a string

A routine to exercise the LEDs by scrolling all 64 characters they can display goes a little something like this:

Serial.println("Exercising LED display ...");

 Outbound.Controls |= CB_N_WRLED1_MASK | CB_N_WRLED0_MASK;        // set write strobes high
 digitalWrite(PIN_DISABLE_DO,LOW);                                // enable data outputs

 while (digitalRead(PIN_PB)) {

  digitalWrite(PIN_HEARTBEAT,HIGH);

  byte Character, Index;

  for (Character = 0x20; Character < 0x60; ++Character) {
   for (Index = 0; Index < LED_CHARS; ++Index) {
    LEDCharBuffer[Index] = Character + Index;
   }
   UpdateLEDs(LEDCharBuffer);
   delay(500);

   if (!digitalRead(PIN_PB)) {
    break;
   }
  }

  digitalWrite(PIN_HEARTBEAT,LOW);
 }

 WaitButtonUp();

A routine to plop a string (up to 8 characters!) on the LEDs looks like this:

void UpdateLEDs(char *pString) {
byte Index = 0;

 while (*pString && (Index < LED_CHARS)) {

  Outbound.DataOut = *pString;           // low 6 bits used by displays
  Outbound.Address = ~Index;             // low 2 bits used by displays, invert direction
  Outbound.Controls &= ~(Index < LED_SIZE ? CB_N_WRLED1_MASK : CB_N_WRLED0_MASK);

  RunShiftRegister();

  digitalWrite(PIN_DISABLE_DO,LOW);      // show the data!

  Outbound.Controls |= CB_N_WRLED1_MASK | CB_N_WRLED0_MASK;
  RunShiftRegister();

  digitalWrite(PIN_DISABLE_DO,HIGH);     // release the buffers

  ++pString;
  ++Index;
 }

You can use sprintf() to put whatever you like in that string:

void ShowStatus(word Address,byte Data) {

 sprintf(LEDCharBuffer,"%04X  %02X",Address,Data);
 UpdateLEDs(LEDCharBuffer);

}

Not, of course, that anybody would actually use DL-1414 displays in this day & age, but the general idea might come in handy for something more, mmmm, elegant…

I’m doing some work with a one-off ROM reader & EPROM programmer, so it’s once again time to mess around with Intel HEX files, raw binary images, and the like.

The key routine (which runs on an Arduino Decimila) to dump a ROM in HEX format goes like this, with all the constants & variables & functions doing the obvious things:

void DumpHC641(void) {

word Address,Offset;
byte DataRd,Checksum;

 for (Address = 0; Address < ROM_SIZE; Address += IHEX_BYTES) {
  sprintf(PrintBuffer,":%02X%04X00",IHEX_BYTES,(word)Address);           // emit line header
  Serial.print(PrintBuffer);
  Checksum = IHEX_BYTES + lowByte(Address) + highByte(Address) + 0x00;   // record type 0x00
  for (Offset = 0; Offset < IHEX_BYTES; ++Offset) {
   digitalWrite(PIN_HEARTBEAT,HIGH);
   DataRd = ReadHC641(Address + Offset);
   digitalWrite(PIN_HEARTBEAT,LOW);
   Checksum += DataRd;
   sprintf(PrintBuffer,"%02X",DataRd);                                   // data byte
   Serial.print(PrintBuffer);
  }
  Checksum = -Checksum;                                                  // two's complement
  sprintf(PrintBuffer,"%02X",Checksum);
  Serial.println(PrintBuffer);
 }
 Serial.println(":00000001FF");                                          // emit end-of-file line
}

So getting an Intel HEX file is just a matter of capturing the serial output, whacking off any debris on either side of the main event, and saving it.

The srec_cat program handles conversions among a myriad formats, most of which I can’t even pronounce. The few I use go a little something like this:

srec_cat mumble.hex -intel -o mumble.bin -binary
srec_cat mumble.bin -binary -o mumble.hex -intel
srec_cat mumble.bin -binary -o mumble.txt -hex_dump
srec_cat -generate 0x0000 0x2000 -constant 0x00 -o mumble.txt -intel

It’s sometimes handy to apply srec_cat to a group of similarly suffixed files, in which case some Bash string chopping comes in handy. For example, to convert some hex files into binary:

for f in 27HC641*hex ; do echo ${f%%hex} ; srec_cat "$f"  -intel -o "${f%%hex}"bin -binary ; done

Good old diff works fine on text files, but in this case it’s better to see which bytes have changed, rather than which lines (which don’t apply in the context of a binary file). The vbindiff program looks great on a portrait-mode display.

I don’t do much binary editing, but tweak serves my simple needs. Confusingly, members of this class of program are called “hex editors”, but they really work on binary files.

There’s also diff3, for those rare cases where you must mutually compare three text files. Makes my head spin every time…

All those programs are likely packages in your favorite Linux distro.