Month: November 2024

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.