Category: Software Development

Another Player Enters the Game

While searching for TANDY Color Computer external font solutions, I found information on a similar solution that was created for the Dragon 200e. As a TANO Dragon owner (basically, an imported Dragon Data Dragon 64), I was aware of the Dragon line, but the 200 (and 200e) were new to me.

Having owned a Color Computer first, I want to be careful not to malign the Dragon systems. Both share a base architecture, being 6809/6847 based, with cartridge ports that are physically and electrically compatible. The Dragon, though, sports extra features like composite video output, a Centronics parallel printer port, and an actual hardware (6551) based RS232 port. Concerning base functionality, BASIC variants and keyboard layouts do differ. The Dragon 200 (and 200e) mirror the Dragon 64, but offer an updated exterior, and the 200e includes localized character fonts for the Spanish market.

Since the 200e lowercase board was an OEM item, I wasn’t lucky enough to find much information on the unit, but I did find that John Whitworth of DragonPlus Electronics offers a reproduction kit of the original design, available here: Lower Case Text Upgrade for Dragon 32/64/200 – Kit Version (2023) – DragonPlus Electronics. He also shared a copy of the 32 fonts you can burn into a 27C256 (16 fonts) or 27C512 (all 32 fonts) here: Dragon Lower Case Daughterboard Downloads – DragonPlus Electronics.

Initial Results

Since I already created some utilities for font extraction and visualization, I applied them to the font pack on DragonPlus’ web site, and the results were… gibberish. Since the file was an actual ROM binary image, there was no pesky file format to parse, but the output of my text view of the font data showed nothing of value. On a hunch, I wondered if, unlike the lowerkit solution, where each font glyph bitmap is stored in consecutive location, this solution spread them across the binary image. This is why software engineers sometimes need to understand the hardware. If the designers put the row counter on the upper address lines of the EPROM, consecutive bytes of a font glyph would appear every 128 or 256 bytes. A quick rework of my textual display program showed little at 128 byte offsets, but 256 byte offsets yielded recognizable font data:

Byte: 0000 FF '********'
Byte: 0100 FF '********'
Byte: 0200 FF '********'
Byte: 0300 E3 '***   **'
Byte: 0400 DD '** *** *'
Byte: 0500 D9 '** **  *'
Byte: 0600 D5 '** * * *'
Byte: 0700 DB '** ** **'
Byte: 0800 DF '** *****'
Byte: 0900 E3 '***   **'
Byte: 0A00 FF '********'
Byte: 0B00 FF '********'
Byte: 0C00 FF '********'
Byte: 0D00 FF '********'
Byte: 0E00 FF '********'
Byte: 0F00 FF '********'
Byte: 0001 00 '        '
Byte: 0101 00 '        '
Byte: 0201 00 '        '
Byte: 0301 00 '        '
Byte: 0401 00 '        '
Byte: 0501 0C '    **  '
Byte: 0601 02 '      * '
Byte: 0701 1E '   **** '
Byte: 0801 22 '  *   * '
Byte: 0901 1D '   *** *'
Byte: 0A01 00 '        '
Byte: 0B01 00 '        '
Byte: 0C01 FF '********'
Byte: 0D01 FF '********'
Byte: 0E01 FF '********'
Byte: 0F01 FF '********'
Byte: 0002 00 '        '
Byte: 0102 00 '        '
Byte: 0202 00 '        '
Byte: 0302 20 '  *     '
Byte: 0402 20 '  *     '
Byte: 0502 3C '  ****  '
Byte: 0602 22 '  *   * '
Byte: 0702 22 '  *   * '
Byte: 0802 22 '  *   * '
Byte: 0902 5C ' * ***  '
Byte: 0A02 00 '        '
Byte: 0B02 00 '        '
Byte: 0C02 FF '********'
Byte: 0D02 44 ' *   *  '
Byte: 0E02 FF '********'
Byte: 0F02 FF '********'

I wasn’t sure why the data was organized this way, as it makes it more difficult to create a font glyph, but I set that question aside for a bit. The main question was “why 256 byte spans”? Specifically, while the MC6847 supports a full 256 glyph font, the Dragon and the CoCo map semigraphics characters into the upper half of the space, which implies a font set need only be 128 characters in size. And, when I textualized the font data, it became clear font sets in the binary image only represented 128 characters. I also wondered a bit about non $FF values in the trailing 4 bytes of every font glyph, the 4 bytes that would never be visible on screen.

Since the original OEM design used a 4kB EPROM, I surmised font sets were 4kB in size, and I split the DragonPlus binary into 4kB chunks. I then extracted each 128 character font from the resulting files, resulting in 32 2kB font binaries. Finally, I used my font visualization solution from the lowerkit project (https://github.com/go4retro/lowerkit) to create some nice graphical views of the font data.

Secret Data

Of the remaining unanswered questions, I didn’t have enough information on why the font data was offset by 256 bytes when the fonts were 128 characters in length. But, the non $ff data starting at $0d00 in the various files does have an answer, and it somewhat explains why the binary is laid out in this manner.

If you’ll recall from a previous article, the easiest way to organize a font glyph bitmap for the MC6847 is to consider each one 16 bytes in size, even though only 12 bytes will be used. Doing so makes the electronics and the math easier. But, that leaves 4 bytes per character unused. On the lowerkit ROM image, those 4 bytes appear after every 12 bytes of font bitmap data. But, by laying out the Dragon font binary as shown above, all of the “spare” bytes are grouped in the last 1kB of each 4kB font set. Thus, starting at $0d00 in each file, there’s blank space.

Well, it should be blank space, but it turns out Eurohard SA (the group that engineered the Dragon 200e font localization daughterboard and brought the Dragon 200 and 200e to the Spanish market, put some non bitmap data there. While converting the ROMs, I asked in the World of Dragon forum if there was a copy of the original 200e font ROM binary to ensure my efforts were on the right path, and robcfg quickly linked to it. I checked in the supposed blank area of the original ROM image, and I found the following (visible via a hex editor):

(C)  1985  EUROHARD S.A.  -  DRAGON 200   AUTOR:  JORDI  PALET  MARTINEZ

Personally, I think the same thing could have been done by putting the data in the first byte of the 4 byte blank space of the first few characters, but the method Eurohard SA used made it easier to see in the file, perhaps as a deterrent to copy. In any event, it was interesting to find. John of DragonPlus Electronics continued the practice, identifying each font set in the same manner.

The DragonPlus Lowercase Mod Fonts

Below are the 16 font sets in DragonPlus’ font bitmap binary for the reproduction daughercard, arranged in 2 font groupings. As well, I extracted the non bitmap data from each font set.

Set 0

ORIGINAL MC6847 CHARACTER SET FOR COMPATIBILITY

ORIGINAL MC6847 CHARACTER SET FOR COMPATIBILITY

Set 1

DRAGON 32/64/200 COMPATIBLE CHARACTER SET WITH LOWER CASE - BASED ON 200E CHARACTER SET - MODIFIED BY DUBLE
DRAGON 32/64/200 COMPATIBLE CHARACTER SET WITH INVERSE CHARS - BASED ON 200E CHARACTER SET - MODIFIED BY DUBLE

Set 2

DRAGON 32/64/200 COMPATIBLE CHARACTER SET WITH INVERSE CHARACTERS - BASED ON 200E CHARACTER SET - MODIFIED BY DUBLE
DRAGON 32/64/200 COMPATIBLE CHARACTER SET WITH INVERSE CHARS - BASED ON 200E CHARACTER SET - MODIFIED BY DUBLE

Set 3

(C)  1985  EUROHARD S.A.  -  DRAGON 200   AUTOR:  JORDI  PALET  MARTINEZ - ORIGINAL DRAGON 200E CHARACTER SET
DRAGON 32/64/200 COMPATIBLE CHARACTER SET WITH INVERSE CHARS - BASED ON 200E CHARACTER SET - MODIFIED BY DUBLE

Set 4

ZX SPECTRUM CHARACTER SET WITH LOWER CASE - TAKEN FROM MAME ROM SET          ZX SPECTRUM CHARACTER SET WITH INVERSE CHARACTERS - TAKEN FROM MAME ROM SET AND MODIFIED BY DUBLE

Set 5

ZX SPECTRUM CHARACTER SET WITH INVERSE CHARACTERS - TAKEN FROM MAME ROM SET AND MODIFIED BY DUBLE
DRAGON 32/64/200 COMPATIBLE CHARACTER SET WITH INVERSE CHARACTERS - BASED ON 200E CHARACTER SET - MODIFIED BY DUBLE

Set 6

TI99/4A CHARACTER SET WITH SMALL CAPS FOR LOWER CASE. TAKEN FROM MAME ROM SET
TI99/4A CHARACTER SET WITH INVERSE CHARACTERS - TAKEN FROM MAME ROM SET AND MODIFIED BY DUBLE

Set 7

TI99/4A CHARACTER SET WITH INVERSE CHARACTERS - TAKEN FROM MAME ROM SET AND MODIFIED BY DUBLE
D32/64/200 COMPATIBLE WITH INVERSE CHARS - BASED ON 200E CHARSET - MODIFIED BY DUBLE

Set 8

CGA LIGHT CHARACTER SET WITH ACCENTS AND LOWER CASE - 200E COMPATIBLE. TAKEN FROM MAME ROM SET AND MODIFIED BY DUBLE
(C)  1985  EUROHARD S.A.  -  DRAGON 200   AUTOR:  JORDI  PALET  MARTINEZ

Set 9

CGA LIGHT CHARACTER SET WITH ACCENTS AND LOWER CASE - 200E COMPATIBLE. TAKEN FROM MAME ROM SET AND MODIFIED BY DUBLE
CGA LIGHT WITH INVERSE CHARS - TAKEN FROM MAME ROM SET AND MODIFIED BY DUBLE

Set 10

CGA LIGHT WITH LOWER CASE - 32/64/200 COMPATIBLE. TAKEN FROM MAME ROM SET AND MODIFIED BY DUBLE
CGA LIGHT WITH INVERSE CHARS - TAKEN FROM MAME ROM SET AND MODIFIED BY DUBLE

Set 11

CGA LIGHT WITH INVERSE CHARS - 32/64/200 COMPATIBLE. TAKEN FROM MAME ROM SET AND MODIFIED BY DUBLE
D32/64/200 COMPATIBLE WITH INVERSE CHARS - BASED ON 200E CHARSET - MODIFIED BY DUBLE

Set 12

CGA BOLD CHARACTER SET WITH ACCENTS AND LOWER CASE - 200E COMPATIBLE. TAKEN FROM MAME ROM SET AND MODIFIED BY DUBLE
(C)  1985  EUROHARD S.A.  -  DRAGON 200   AUTOR:  JORDI  PALET  MARTINEZ

Set 13

CGA BOLD CHARACTER SET WITH ACCENTS AND LOWER CASE - 200E COMPATIBLE. TAKEN FROM MAME ROM SET AND MODIFIED BY DUBLE
CGA BOLD WITH INVERSE CHARS - TAKEN FROM MAME ROM SET AND MODIFIED BY DUBLE

Set 14

CGA BOLD WITH LOWER CASE - 32/64/200 COMPATIBLE. TAKEN FROM MAME ROM SET AND MODIFIED BY DUBLE
CGA BOLD WITH INVERSE CHARS - TAKEN FROM MAME ROM SET AND MODIFIED BY DUBLE

Set 15

CGA BOLD WITH INVERSE CHARS - 32/64/200 COMPATIBLE. TAKEN FROM MAME ROM SET AND MODIFIED BY DUBLE
D32/64/200 COMPATIBLE WITH INVERSE CHARS - BASED ON 200E CHARSET - MODIFIED BY DUBLE

Some of the fonts are repeated in the binary image, probably to allow flexibility in choosing the combination most desired.

The SVG images of the fonts are at: https://github.com/go4retro/dragon200e-lowercase/tree/main/charsets/drawsvg and font binaries are at: https://github.com/go4retro/dragon200e-lowercase/tree/main/charsets/fixrom.

Pedantic Inconsistencies

Not that it matters, but John’s font binary contains what appear to be some font description inconsistencies.

• The second font in Set 1 claims it is a modified Dragon 200e set, but, except for the hidden text data, the font information is the same as the original Dragon 200e second font
• Likewise, though the second fonts in sets 2,3,5,and 7 claim to be modified, they appear to be the original second font from the Dragon 200e mod.
• The second font in set 13 claims to be a CGA bold font, but is actually another copy of the original Dragon 200e second font.

It’s possible the second font was modified, but then reverted, prior to the ROM merge. On the CGA font, that’s more confusing, and I’d appreciate validation of my efforts, which I’ve placed on GitHub at https://github.com/go4retro/dragon200e-lowercase.

Searching for Information

As I was trying to decipher how to leverage an external character font ROM with the MC6847, I searched for existing project/products in this space. My web searches first found Ed Snider’s (Zippster of ZippsterZone) reproduction of the Green Mountain Micro (GMM) “lowerkit” product from “back in the day”. Ed shared a bit of technical detail and project progress, but no schematics or additional information that might answer questions on how the circuit worked. I also found a reproduction of the lowercase daughterboard for the Dragon 200e (which also works for the Dragon 32/64) produced by DragonPlus Electronics. Like with Ed’s page, DragonPlus offered some technical information (build instructions) but no schematic. Still, I had a start.

After changing some search terms, I found a few downloads that purported to be for the “lowerkit” product on a TRS-80 Model 1 web site. Confused why files for a CoCo product were on a web archive for a different machine, I still downloaded the files, and searching for those same filenames found related files on a few other web archives. At the end, I found:

• http://cpmarchives.classiccmp.org//trs80/Software/Model%201/C/Character%20Development%20Program%20for%20Lowerkit%20ROMs%20(1981)(Dennis%20Bathory-Kitsz)[BAS].zip
• http://cpmarchives.classiccmp.org//trs80/Software/Model%201/C/Character%20Development%20Program%20for%20Lowerkit%20ROMs%20(1981)(Dennis%20Bathory-Kitsz)[a][BAS].zip
• http://cpmarchives.classiccmp.org//trs80/Software/Model%201/C/Character%20Development%20Program%20for%20Lowerkit%20ROMs%20(1981)(Dennis%20Bathory-Kitsz)[a2][BAS].zip
• http://cpmarchives.classiccmp.org//trs80/Software/Model%201/C/Character%20Development%20Program%20for%20Lowerkit%20ROMs%20(1981)(Dennis%20Bathory-Kitsz)[a3][BAS].zip
• http://cpmarchives.classiccmp.org//trs80/Software/Model%201/C/Character%20Development%20Program%20for%20Lowerkit%20ROMs%20(1981)(Dennis%20Bathory-Kitsz)[a4][BAS].zip
• http://cpmarchives.classiccmp.org//trs80/Software/Model%201/L/Lowerkit%20II%20ROM%20Development%20v2.0%20(1983)(Dennis%20Bathory-Kitsz-Green%20Mountain%20Micro)[BAS].zip
• http://cpmarchives.classiccmp.org/trs80/Software/Model%201/C/Char%20It%20(19xx)(Green%20Mountain%20Software)%5bBAS%5d.zip

Initial Results

Extracting all of the files, I found a number of binary files in the archives, but the size seemed too big (3kB), whereas the datasheet suggested a 2kB (12 address lines) EPROM.

Loading the files into a hex editor suggested font data, so I grabbed a quick file reading C program template from the Internet and modified it to spit out the data as a text-based bitmap file, with “*” for a set bit, and ‘ ‘ for a clear one.

Running chgmath.bin through my simple program provided encouraging results:

Byte: 0000 05 '     * *'
Byte: 0001 06 '     ** '
Byte: 0002 43 ' *    **'
Byte: 0003 48 ' *  *   '
Byte: 0004 47 ' *   ***'
Byte: 0005 4D ' *  ** *'
Byte: 0006 41 ' *     *'
Byte: 0007 54 ' * * *  '
Byte: 0008 01 '       *'
Byte: 0009 00 '        '
Byte: 000A 00 '        '
Byte: 000B 52 ' * *  * '
Byte: 000C 00 '        '
Byte: 000D 00 '        '
Byte: 000E 08 '    *   '
Byte: 000F 14 '   * *  '
Byte: 0010 14 '   * *  '
Byte: 0011 22 '  *   * '
Byte: 0012 22 '  *   * '
Byte: 0013 41 ' *     *'
Byte: 0014 7F ' *******'
Byte: 0015 00 '        '
Byte: 0016 00 '        '
Byte: 0017 00 '        '
Byte: 0018 00 '        '
Byte: 0019 00 '        '
Byte: 001A 00 '        '
Byte: 001B 00 '        '
Byte: 001C 7F ' *******'
Byte: 001D 41 ' *     *'
Byte: 001E 20 '  *     '
Byte: 001F 10 '   *    '
Byte: 0020 08 '    *   '
Byte: 0021 10 '   *    '
Byte: 0022 20 '  *     '
Byte: 0023 41 ' *     *'
Byte: 0024 7F ' *******'
Byte: 0025 00 '        '
Byte: 0026 00 '        '
Byte: 0027 00 '        '
Byte: 0028 00 '        '
Byte: 0029 00 '        '
Byte: 002A 00 '        '
Byte: 002B 00 '        '
Byte: 002C 06 '     ** '
Byte: 002D 09 '    *  *'
Byte: 002E 08 '    *   '
Byte: 002F 08 '    *   '
Byte: 0030 08 '    *   '
Byte: 0031 08 '    *   '
Byte: 0032 08 '    *   '
Byte: 0033 08 '    *   '
Byte: 0034 08 '    *   '
Byte: 0035 08 '    *   '
Byte: 0036 48 ' *  *   '
Byte: 0037 30 '  **    '
Byte: 0038 00 '        '
Byte: 0039 00 '        '
Byte: 003A 00 '        '
Byte: 003B 00 '        '
...

The first 2 bytes of each file were 0x05, 0x06, and the next few bytes looked like ASCII (and they are. The bytes above spell out CHGMAT, which looks like a 6 byte filename). There 4 more bytes that don’t look like font data, and then font glyph bitmap data in 16 byte chunks.

That answers one question about the datasheet schematic. The row counter address lines are the lowest 4 bits of the font ROM address. I thought they were, since it makes creating the ROM easier (all of the data for each character glyph’s bitmap resides in contiguous memory locations), but it “wastes” 4 bytes per font glyph (the lower 4 bits of the address will never go above 11, according to the datasheet, but the next bitmap will be 16 bytes above the previous one.

Looking at the rest of the files, some have odd data into bytes 12,13,14,15 of each character glyph, and there’s extra bytes in the file every so often, but I felt like I had made some progress. I decided to create a GitHub repository at https://github.com/go4retro/lowerkit and place my current progress in the charsets directory. I took a stab at trying to clean up the parsing functions and remove some of the extraneous data in the file, noticing that 4 extra bytes appeared every $102 bytes in the file. Theorizing those were some type of “sector” or “block” structure, I parsed them out of the font stream and the results looked even better, save for some oddities at the end of each file.

Deciphering the File Format

Since the files were in a TRS80 Model 1 archive, I reached out to the TANDY Discord server, relating the oddity about control characters appearing every $102 bytes in the file. George Phillips (of TRS80GP emulator fame) responded that the files was encoded in the TRSDOS /CMD format, and that his TRLD utility could parse the files. I grabbed the utility, followed his directions, and the resulting binary files appeared!

The only issue was that they didn’t appear alone. The TRLD utility extracted the data, but saved the ROM data in what appeared to be a larger memory dump, which makes sense, given how the file format works (it has blocks of data, which contain a load address and length, and they could appear anywhere. George’s utility takes the safe approach and parses the file into a blank memory map, and then saves it all to disk. However, since these font ROM file blocks are contiguous, there’s no need to save off the entire map.

To be fair, George noted it would do this, and suggested I could either look at the first block’s load address in the file (using the diagnostic dump parameter of the utility) and then strip off that many bytes from the file, or dig into the trld source and extract the parse engine to roll my own. While I was debating which to do, I found a blog posting about parsing CMD files from Jim Lawless, a friend from many years back, complete with source code.

Jim’s utility didn’t parse the data per se, but it did parse the structure, and the source was available, so I just lifted my functions from my quick utility and inserted them into this new source. The resulting output was clean, so I then added in an optional parameter to save off the binary data as a contiguous file, suitable for burning to an EPROM.

The LowerKit Fonts

To make it easier to compare fonts and allow a better way to show what’s in them, I modified one of my simple utilities to brute force create some SVG files, shown below. I apologize for nothing, it was simply a means to an end 🙂

CHGAPL

CHGEURO

CHKGREEK

CHGKATA

CHGKAT2

Internal name is KATA, just like the one above

CHGMATH

CHGSCR

CHGSMALL

CHGNEW

The SVG images of the fonts are at: https://github.com/go4retro/lowerkit/tree/main/charsets/drawsvg and font binaries are at: https://github.com/go4retro/lowerkit/tree/main/charsets/mkroms.

I extracted all of the binary files from the various archives, but it looks like some are duplicates:

• CHGAPL2 -> CHGAPL
• LITTLE2->SMALL

Discovering More Fonts!

While working on the font files themselves, I looked at the BAS files in the various archives, which appear to be Model 1 BASIC files. However, after perusing a few of them, I noticed it appeared they hold a copy of a font file within the BASIC program. I quickly copied out the BAS files, trimmed off everything except the BASIC ROM data, and compiled a second parser to make sense of this data. CHGEURO.BAS, for example, contains data looking like this:

XXXXXXX,XXXXX,XXXXXXX,XXX,XXXXXX,XX,XXXXX,XXXXX,XX,XXXXXXX,XXXXXXX,XXXXXXX ...

7 (and sometimes 8) bits of font data, a comma, next row, etc. Every so often, there’s 6 extra bytes of data that are not font bitmap data, so I had to decipher that. But, it was not hard, and that data above became this:

'       '
' *  *  '
'       '
' ****  '
'     * '
' ***** '
'*    * '
'*    * '
' **** *'
'       '
'       '
'       ' Ignoring 00, 79, 6B, 6E, 00, 88
'    *  '
'   *   '
'       '
' ****  '
'     * '
' ***** '
'*    * '
'*    * '
' **** *'
'       '
'       '
'       ' Ignoring 00, DE, 6B, 78, 00, 88

I have a feeling the extra data is internal BASIC linkage information, but it was easy to discard.

Most of the files match up to the font data files I parsed, but there were a few additional ones:

CHGDEVLR

CHGDEVL2

Fonts Left to Find

In the manual, it references:

• ASCII Shifted with Greek (I think that’s CHGGREEK above)
• ASCII Shifted with Kata Kana (CHGKATA)
• ASCII Shifted with APL Character Set (CHGAPL)
• Kata Kana Shifted with ASCII (CHGKAT2)
• ASCII Shifted with Cyrillic
• ASCII Shifted with Arabic
• ASCII Shifted with Hebrew
• ASCII Shifted with French Characters
• ASCII Shifted with European character variants (CHGEURO)
• ASCII Shifted with MAth symbols and operators (CHGMATH)

So, it looks like a few are left to find. Let me know if you own or have archived the Model 1 programs that would include these files, or if you have the ROM images (or ROMs, I can image them here)