Expanding the MC6847: Deciphering the Interface, Part 2

As noted in a previous post, along with finding that Green Mountain Micro (GMM) had created a lowercase modification for the CoCo called “lowerkit”, Eurohard SA also created a lowercase update for the Dragon 200e for the Spanish market, which I think was planned or actually produced as an official part of the Dragon 200e design. Currently, DragonPlus Electronics offers a reproduction of this solution in their store. As I mentioned previously, I did not find a schematic of this solution, though I did find pictures of the PCB on the World of Dragon archives. Since the lowerkit effort had been successful, I decided to reverse engineer the PCB from the pics on the site.

Now, unlike the “lowerkit” option, this PCB used the datasheet recommended 74LS161 counter, and contained fewer components, which made the work easier

The header and the 6847 IC were easy, as was the 74LS161 counter. Based on a note on the DragonPlus web site talking about their effort to create the reproduction, I determined the EPROM was a 2532. Looking at the 74LS244 buffer IC in light of the “lowerkit” design, I surmised that this design used the output enable line on the EPROM to disable it from the VDG data bus, meaning only the data coming from the header data pins needed to be buffered/disabled. This saves an IC over the dual 74ls157 option on “lowerkit”

Also knowing that this design put the counter as the top 4 bits of the EPROM address bus, most of this design was easy to reconstruct. Because the design was tailored to the Dragon, which included a MC6883 Synchronous Address Multiplexer (SAM), none of the MC6847 address lines were bridged to the header except DA0 (as they are not connected to anything on the motherboard. The design took shape, with the exception of the 74LS00 quad NAND gate.

Having the IC in the photo hindered the effort, as there were no traces going into/out of the IC on the top. The reverse shows a few, though, and there a few adjacent pins that appear to be bridged. Working back from how I thought the design should behave, I was able to reconstruct the 74LS00 wiring:

On the 74LS00 (top left IC, reversed pinout on bottom photo), we can follow the trace on pin 1 (top right of IC) to A*/S (Alpha Semigraphics). Likewise, pin 3 ends up at INT*/EXT, which makes sense. If we are requesting alphanumeric glyphs, use the external ROM, otherwise, use the internal. On the other side, pin 13 is connected to A*/G, and pin 9 is connected to the EPROM output enable line (OE*). Finally, pin 8 is connected to the enable line on the 74ls244, which must be low for operation. That makes sense, as either the EPROM OE* should be low OR the buffer enable, but never at the same time. If you squint, you can jsut see that pins 9 and 10 are connected via a trace (the slightly silver part in between). The same thing shows up between 1 and 2, 3 and 4, and 12 and 13. 1/2, 9/10, and 12/13 are all inputs, meaning all 3 of those gates are being used as simple inverters (you can easily turn any NOR and NAND gate into a NOT gate by tying the inputs to the same signal). 3 is an output, and it being tied to 4 means that A*/S is being inverted and sent to a second NAND gate. But, that’s all we can see from the PCB photo. The rest requires inferring what logic is needed.

With pin 9 and 10 going to the EPROM OE* line, that means it should be low when we are wanting alphanumerics. And, we actually only want the EPROM when both A*/S and A*/G are low. But, we know both signals are being inverted for some reason. So, let’s take their inverted versions (A/S* and A/G*) which should both be 1 for external EPROM use. We also know that the inversion of A*/S (pin 3) is being fed to pin 4. Let’s assume the output of the other inversion (pin 11) goes to pin 5 (the other input of the second NAND gate. That means pin 6 will be low when the EPROM needs to be enabled, so OE* should be connected to pin 6. But, we only see it connected to pin 9 and then bridged to pin 10. That means it must connect to pin 6 under the IC:

The only remaining item is address line 7 on the EPROM. Since there are 128 characters in a font (the upper 128 spots are semigraphics), we expect and see the lowest 7 bits of the MC6847 data lines coming from the SAM go to the lowest 7 address lines of the EPROM. We know, because of the font ROM configuration, Address lines 8-11 go to the counter. That leaves address line 7 open. But, if we trace the EPROM pin 1 (address ine 7), we see it goes to the INT*/EXT line from the header. That means that changing the value of that pin on the MC6847 socket (which comes from the PIA) will shift between 2 ROM font sets. That solves the last remaining mystery. Adding in the capacitors, a simple jumper block to select inverse characters, and the design is complete.

However, just like the “lowerkit” design and it’s 2716 EPROM, the 2532 EPROM is hard to find and hard to program. As well, this design is quite a large PCB, making fitment a concern. We should update the design to make it both smaller and shift the EPROM to a newer part, which will no doubt hold more. The larger EPROM then demands some switches to select which font to use. DragonPlus Electronics came to the same conclusion, modifying the original design to take up less space, switching to surface mount parts in the process.

I felt like the design could be shrunk while still keeping through hole parts, though placement would be tight:

I made one “executive” decision on this update, which I am sure will anger some purists. While having free space all self contained in spot of the ROM, I don’t see any useful value for it beyond stowing some explanatory text or copyright, and it makes understanding the ROM data much more difficult. So, I placed the 4 counter address lines at the bottom, meaning each font glyph bitmap will occupy 16 consecutive addresses in the EPROM. Since the files will be Open Source, others can revert that change if it offends them.

Since I didn’t want to find and program a 2532 EPROM, I decided to just manufacture and test the updated PCB, which works perfectly fine:

I can probably squeeze the EPROM closer to the header to reduce PCB size, but the current PCB is 50mm by 58mm (1.95″ x 2.3″), so further optimizations short of moving to SMT is left as an exercise for the reader.

The Heresy! Here’s the Dragon 200e lowercase kit on a CoCo 1

As always, source files, artwork, designs, etc. are available at my GitHub repository: https://github.com/go4retro/dragon200e-lowercase

Expanding the MC6847: Deciphering Fonts, Part 2

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

MC6847 Font
MC6847
MC6847
ORIGINAL MC6847 CHARACTER SET FOR COMPATIBILITY

ORIGINAL MC6847 CHARACTER SET FOR COMPATIBILITY

Set 1

D32/64 compatible w. lower case – based on 200E character set
Original 200E character 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

Original 200E character set 1.
Original 200E character set 1.
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

Original 200E character set 0.
Original 200E character set 1.
(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

Spectrum w. lower case
Spectrum w. inverse characters.
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

Spectrum w. inverse characters
Original 200E character set 1.
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 w. lower case
TI99/4A w. inverse characters.
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 w. inverse characters
Original 200E character set 1.
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 for 200E – with accented chars etc.
Original 200E character set 0.
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 for 200E – with accented chars etc.
CGA Light for D32/64 w. inverse chars.
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 for D32/64 w. lower case
CGA Light for D32/64 w. inverse chars.
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 for D32/64 w. inverse chars
D32/64 compatible w. inv. Chars – based on 200E character set.
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 for 200E – with accented chars etc.
Original 200E character set 0.
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 for 200E – with accented chars etc.
Original 200E character set 1.
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 for D32/64 w. lower case
CGA Bold for D32/64 w. inverse chars.
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 for D32/64 w. inverse chars
D32/64 compatible w. inv. Chars – based on 200E character set.
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.

Expanding the MC6847: Deciphering the Interface

Having found some external fonts used with a MC6847 lowercase modification from “back in the day” (the lowerkit product from Green Mountain Micro) and converting them into ROM-burnable images, I determined a ROM font was composed of 12 bytes of font bitmap data, with 4 bytes of “padding” to align font data on 16 byte boundaries. This, in turn, helped me understand how the font ROM was connected to the MC6847. Specifically:

As I mentioned in a previous article, notice the External Character Generator ROM, with “Row A” and “Char. Add” going into the left side of the ROM. It makes sense that the 4 bit output of the Row Counter (shown elsewhere in the data sheet) and the value of the character desired at a specific screen location would be fed into the ROM address lines, but it doesn’t show if the 4 bits of the counter are the lowest 4 bits of the address or not. Well, given how the “lowerkit” fonts were arranged, the counter must be at the lowest 4 bits. It makes sense, as then the entire bitmap for a single character would be in consecutive memory locations, but it pays to be certain.

With that knowledge, I felt I had gone about as far as I could with poring over datasheets and understanding font bitmap files. It was time to build a circuit.

With the knowledge of the GMM “lowerkit” product in hand, I asked for assistance in the CoCo Mailing List, and Tim Lindner responded in the next message with a link to the product manual. Since the “lowerkit” manual not only helpfully included a full schematic but also included PCB artwork scans (We owe a debt of gratitude to hardware and software developers of the 1980s that put such technical detail in manuals!), it was possible to lay out a new PCB. And, so I did. Page 22 (30 in the PDF) showed a schematic, but it used an entirely different set of TTL ICs:

Page 22 (30 in the PDF) Interestingly, lowerkit’s design utilized a different configuration for the counter. There was still a counter involved (74LS93), and some of the logic I realized was to provide some additional features, but the 74LS73 and the 74LS93 together confused me. Still, it was a working design, and perhaps it was better then the datasheet option (In general, designs in a datasheet are workable, but may not be optimal).

With all of this, the bulk of the work was trivial. Lay out the schematic and then create a PCB, tracing over the shots of the PCB artwork to line things up. While, for a first attempt, it’s always best to use the exact same layout, there was 1 large issue with the original design. Lowerkit used a 24 pin EPROM to store the font bitmap data. 24 pin EPROMs (2516 or 2716, along with 2532 and 2732) are very difficult to source now and they are hard to program. 28 pin JEDEC standard pinout EPROMs are much easier to find (27C64-27C512) and they offer the option of larger storage. So, I extended the PCB a bit lower to support the 28 pin 27C256, which offered storage for 16 different font bitmap sets. However, this, in turn, forced me to make another small change, the switches on the right hand side, to select which font to use. Along the way, Ed Snider (who I previously mentioned had also created a reproduction of this unit some years back) opped up in the mailing list and shared the schematic for his initial reverse engineering effort. I checked my design against his schematic to ensure I didn’t miss anything.

You’d think, after 20 years of PCB design, I’d check the layout before sending off to jlcpcb.com, the PCB manufacturer I use. But no, it was late, I was “sure” all was correct, and I hurried the design off. Haste makes waste, as they say:

Notice the metal RF shield “wall” on the left side. Yep, my attempt to quickly extend the PCB to support a 28 pin EPROM caused a fitment issue. It’s OK, though, as this was just a prototype and I’m used to creating PCB socket “risers” from stacking IC sockets up to varying heights. Thus, this was a quick issue to solve.

After stuffing the PCB and mounting it in the 6847 socket (with my riser), turning on the machine yielded this:

That’s a nice looking font (this is the font called “NEW” in the ROM sets I found). But, I noticed something wrong. The first row of characters had the top lines cut off. A quick set of tests showed that the font data is fine (Notice the ‘E’ in the first row is chopped off, but the ‘E’ in the third line is fine). It has to be the schematic. Time to break out the logic analyzer.

While I have a very capable HP logic analyzer that can analyze dozens of signals, I surmised the issue here was with the counter and the weird 7473 flip flop circuit in the design, which only requires a few signals be watched. This meant my USB-based 16 channel unit would suffice to look at the signals at the beginning of the screen frame:

Hmmm, the counter never stops counting, and until the first negative pulse of the *RP (Row Preset) signal, the counter is counting from 0-15.

Let’s look back at the lowerkit schematic:

Don’t worry if you’re not good at reading schematic, I will walk you through it. We’re focused on the 74(LS)93 R signals (pins 2 and 3). Those clear the counter. So, when a frame starts, the flip flop is cleared (pin2 on the 7473) as the *FS signal goes low (CLR will keep the flip flop cleared the entire time *FS is low). When a flip flop is cleared, the Q output becomes 0. *Q (not Q) thus becomes 1. And, we see this on the analyzer output. *FS (first line, in red) goes low, and the !Q (line 7, pale orange) goes high at the same time. Now, looking at the schematic again, with the !Q high, the 74125 (the little triangle next to the 7493 R pins) buffer is disabled, meaning the signal going into it will not be sent on. That line is RP (Row Preset, but inverted via the inverter just above and to the left of the 7473 box). But, if the signal is not being sent on, what happens to the R inputs on the counter?

To answer that, let’s talk about buffers, like the 74(ls)125. When a buffer is enabled, the input is sent to the output. Makes sense. When disabled, the input is not sent to the output, and the output is put into a state called “high impedance”, or Hi-Z. Basically, the pin looks like a very high resistance resistor to the circuit, and it shouldn’t be considered a 1 or 0. But, in this case, when the buffer is disabled, we want the R pins to be high, as that keeps the counter at 0.

Often, when you need to “weakly” bias an input pin high, you tie it to 5V (or whatever voltage the circuit is using) through a 4.7K-10K resistor. This trickles just a tiny bit of power (5/10000 = .5mA) into the input put, “weakly” pulling it to ‘1’. When another signal tries to pull the pin low, it does so easily because the weak bias can’t overpower the much stronger signal. I checked, and there’s no bias resistor on this pin in the original PCB or the schematic. In reality, in many IC families, like the “Low Power Schottky” or “LS” family, input pins tend to “float” high, due to the way inputs are fabricated. But, it’s not guaranteed.

Still, if you put a 74ls93 there, it should have worked. And, it probably would have, had I used a 74ls93. But, as a general rule, I don’t buy 74lsXXX parts anymore. I tend to by High Speed CMOS TTL compatible (HCT) or Advanced High Speed CMOS TTL compatible (AHCT) parts, which is what I used here. And, surprise, 74HCT93 R input pins do not “float” high. They quickly settle to 0, which meant the counter was never being cleared while the flip flop was in the “cleared” status

A quick bias resistor to the R inputs helped matters immensely:

Notice the counter doing nothing until DA0 starts toggling? That’s expected behavior. The screen echoes this…

Yes, I should have used the exact parts specified by the original design, so ultimately this is my own problem. But, even if I had purchased LS TTL parts and the problem appeared, I’d not be too hasty to blame Dennis Bathory-Kitsz, the designer. The “proper” solution here (at least for this signal) was to output 1 IF (!Q=0 AND *RP=0) OR (!Q=1). You could rewrite that as R = Q*RP+!Q*!Q and then implement that with 3 NAND gates, but that just adds another IC to the design, increasing cost and creating more layout complexity. And, there may be other permutations, but I bet they all require another IC. Dennis had an extra 74ls125 buffer available after the rest of the design was finished, so he made use of it. It’s creative, and a quick bias resistor ensures the logic is sound. And, before you ask, “Why not always use bias resistors?”, note that such resistors don’t pull the inputs up as fast as a logic signal. For classic 1970’s and 1980’s systems, it’s often fast enough, but your mileage may vary.

As it is, the “failure” was most educational. By varying that starting value of the counter, you can “shift” how characters are displayed on the screen. That suggests lots of cool ideas, so we’ll keep that in mind as we continue to explore external character generation.

I took a bit of time to look at all the fonts Dennis created, by flipping through the ROMs via the DIP switches. Since there’s no harm in doing so while the VDG is using the ROM, you can put some characters on the screen and then see how each font set renders the text. I also looked at the design a bit more and realized data line 7 is not connected to the EPROM at all. The VDG always gets the high bit from the incoming data. Since D7 is also connected on the CoCo to the Alpha/Semigraphics signal, that means every external font bitmap has bit 7 cleared. I checked the fonts I assembled, and almost all of the high bits were clear, except for CHGSCR:

the last character in CHGNEW:

And CHGDEVL2, which appears to mirror CHGSCR.

The design uses DD7 (which is, as I noted, connected to the *Alpha/Semigraphics pin externally on the CoCo PCB, to select whether the internal or external ROMs should be used). It then uses 2 74ls157 4 bit A/B selector ICs to pick which data to send to the VDG, just like in the VDG diagram above. It uses 7 of those A/B inputs for the internal/external data, and 1 to pass a 1 or 0 out to various logic gates. Since the last A/B gate is used for this purpose, it’s not available for font data.

Looking at the schematic, there’s a few things that I’d consider changing. As noted, the VDG datasheet uses a preloadable 74*161 4 bit counter to handle the low address lines of the font ROM, and this design uses a 74*93 and 74*73, so I’d consider swapping that design. And, from pictures I saw online, later revisions of the “lowerkit” product did just that. Here’s Revision 1 (as illustrated in the manual, compared to LowerKit 3C Revision H (thanks to Al Hartman for his flickr stream where I found these examples):

Notice the 74ls161 on the second PCB? That would eliminate the issue I found, as the 7473 is gone from the design.

I also think Data line 7 from the ROM can be fed into the VDG, via the A/B selector ICs. The logic in the design to select a 1 or 0 from the A/B selector IC I think can be replaced with using the now spare 74ls125 buffer (which we no longer need for the counter logic) feeding DD7 into the various logic cells.

Finally, I’d replace the 74ls157 a/b selector with a 74ls244/245 8 bit buffer/transceiver. It turns out the EPROM already has a 8 bit buffer inside the EPROM (RAMs and ROMs have an output enable pin for just this purpose). Data Line 7 or the *A/S line could be used to enable the EPROM, and the inverted version of that signal could be used to enable the 8 bit buffer. That would reduce the parts count by yet 1 more IC.

But, as Dennis told me, he was an early creator in this space, and there wasn’t a lot of guidance out there at the time.

If you’d like to check out the schematic and the PCB design, it’s on the GitHub repository.

Expanding the MC6847: Deciphering Fonts

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:

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

CHGAPL Font

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)