Bird's nest...

[mr_me]

I suggest Mattel's Keyboard Component character set.

[+Lathe26]

I suggest supporting every character in the Unicode 10.0 standard. There are only 136690 characters to support, including emojis. :-P

[JohnPCAE]

Those C64 fonts are definitely something I can work with. I've been looking at arcade fonts but it helps to draw from more sources.

 

Is there a bitmap available somewhere that contains the entire Keyboard Component character set? I agree that including it is a must.

[mr_me]

Keyboard Component character set:

The exclamation mark is character 33 and 32 is a space.

[JohnPCAE]

It's a bit blurry but I think I can work with it. Does it include everything from 0..255?

 

This is what I get after some resizing:

 

 

[JohnPCAE]

Current state of the bitmap. I' m concerned about the lack of characters in the Keyboard component font before the space character. After drawing the blocks I now understand what's going on there: they're following a simple binary pattern from 0 to 63, once with solid areas and once with dots.

fonts.bmp

Edited July 14, 2017 by JohnPCAE

[carlsson]

Yeah, it looks like 2x3 semi graphics as used by various Teletext, Videotex etc systems which suggests the Keyboard Component might've been meant to be Videotex compatible. The development of such services begun in 1978-ish, so it fits in the time frame. The other dot patterns I presume are Braille, meant for blind people whose TV sets would emit enough static electricity for every "on" pixel that they could use their fingers to read on the screen. :-)

[mr_me]

Yes, the Intellivision was originally planned for Videotex bringing data into the home; ie. news, sports scores, and weather. North America was behind Europe with this stuff in the early 1980s. I never thought of braille but it could be. I'm pretty sure the stock market program that wasn't released used those "braille" characters to plot graphs.

 

edit: The Keyboard Component has 256 characters including ASCII control codes. In ASCII the first 32 characters are control codes.

 

Here's another view of the characters not including the control codes. There are another 32 characters, you can see them in the KC "Owners's Book". But I'm not sure how to access them in basic.

Edited July 14, 2017 by mr_me

[carlsson]

On second thought, it probably isn't meant to be Braille as it would display the glyphs in a very odd order: A n/a C n/a B I F n/a E n/a D n/a H J G ... etc

[mr_me]

Here are the other 32 using a code ie. "chr$(27);chr$(16);chr$(64+x)"

[JohnPCAE]

The blocks and dots are following the same binary pattern from 0 to 63, with the bits arranged like this:

 

0 1

2 3

4 5

 

Are those extra 32 characters the control characters from 0 to 31?

[mr_me]

No they're not. In fact ascii code 31 generates an accent grave character seen in the first image.

[JohnPCAE]

Hmm. Which codes do they represent? If space is 32 then the last dot pattern should be 255. Another question I have revolves around character alignment. I have to be able to accurately place each glyph in the 8x8 box. That's pretty easy with the block and dot patterns, but it's hard with the letters. The letter patterns in the large image seem to have a different alignment than the box patterns, for instance: the letters on the right side seem to span bounding box boundaries.

[mr_me]

The large image is actually two images spliced together. They don't line up.

 

Edit: 255 should be that last 2x3 dot pattern.

Edited July 14, 2017 by mr_me

[JohnPCAE]

Ok. I placed the extra 32 characters after the dot patterns. I'm guessing they're special escape codes that lie outside the 0-255 range. Last question: do the 0-31 control characters have glyphs?

[+Lathe26]

The dot pattern is a superset of Braille. There are some dot patterns that are not assigned in Braille. Still, it's pretty cool that they added that.

[mr_me]

The first image was generated by printing chr$(x) starting with x=1 without any spacing. Only chr$(31) left a character.

[JohnPCAE]

This is where I am now. I made some small tweaks to the earlier glyphs (e.g. I had missed a lowercase Greek letter) and made certain glyphs look a little better. I also added a few glyphs before the KC font that allow for drawing rounded boxes, and a pointer glyph for drawing rounded balloon windows.

 

Any thoughts on what else we want included? A futuristic font? A western font? A stencil font? If we limit t to 0-9, A-Z, and a-z, there is room for all three with room to spare.

fonts.bmp

Edited July 14, 2017 by JohnPCAE

[JohnPCAE]

As promised, here are my current Eagle files and Arduino code for my video overlay project. It only has the first half of the CGA font as I haven't implemented anything else yet. It's just proof-of-concept code that outputs the static pattern in the screenshots, but it works. As for the board, I've done a lot of validating and I'm pretty confident that it will give a clean crisp signal (at least, it does when using the included Arduino code).

overlay_video.zip

[JohnPCAE]

Dammit. I missed a change to my schematic that I had on my breadboard. It would affect how video would look when the intensity bit was off. Attached is the corrected schematic and board...

overlay_video.zip

[JohnPCAE]

I had to make a tiny tweak to a couple resistor positions to handle a spacing issue and I had to add another R-C combo to nail down the filtering, but this should be the final version of the video output stage.

overlay_video_1_4.zip

Edited July 30, 2017 by JohnPCAE

[JohnPCAE]

Small update...I'm looking at switching to a 32-bit version of the Arduino (Zero, M0, or M0 Pro) as this solves a lot of problems all at once. It runs at 48 MHz, has 32k SRAM, and 256k Flash. This allows space for a lot more fonts, allows a complete character buffer including room for color, and has more processor headroom. The downside is that it's a 3.3V device, so level-shifting is necessary. I picked up a couple level-shifter shields from Digistump for testing, but I haven't settled on which Arduino is the best choice.

Edited August 6, 2017 by JohnPCAE

[JohnPCAE]

A little code update. I've never been happy with how much time the Arduino was spending pushing character data out to the board (about 40% of a frame). I figured out how to get an assembly dump of the generated executable and found a way to make some optimizations. This code pushes it out in about 32% of the time for a frame, leaving more potential time for the Arduino to perform other work. The assembler optimizations are AVR32 specific (Arduino Uno) and won't work with the newer ARM-based Arduinos.

 

This code also sets up other pins for a test I'm preparing to run with applying different colors to text: my test involves populating a small SRAM chip with the outputs for each color, much like the Inty color chip does (minus the frame-synchronization stuff since I don't need it). Then I can have the Arduino set the entire color for all of the text on a frame to be one of the 16 Inty colors. It's only a test to see how to tweak outputs to see if colorization is possible.

overlay_video_1_4a.zip

Edited August 10, 2017 by JohnPCAE

[JohnPCAE]

I've made some progress in colorizing text. I added a small circuit that lets the Arduino populate a small SRAM chip with the levels to produce at each 70ns timeslice. It basically does what the AY-3-8915 color chip does, minus the frame-synchronization stuff. I'm accurately reproducing the Inty color palette, though there are a few issues:

 

- If I output solid pixels (e.g. character 8 from the CGA font), the color looks pretty good, but the effect on normal text appears to be pretty minimal. I think this has to do with insufficient NTSC bandwidth. There is an effect on text but it's really subtle.

- The intensity of my output is too low, resulting in darker colors. I'll experiment with adding an amplification stage at the end to see if I can improve it.

 

One very interesting thing I found is that the AY-3-8915 datasheet appears to be incorrect. It lists the timeslice values for color 1 (blue) as 5, 13, 9, 1. This results in the wrong hue (way too green). Changing the timeslice values to 9, 13, 5, 1 gives the correct hue.

[JohnPCAE]

I'm slowly inching forward on colorizing text. I'm getting fully colorized text using a combination of a prototype board and a small amount of breadboard circuitry. It turns out that clock stabilization is really critical, but I might have finally figured it out. I just ordered a new revision of my testing board to see if it can replicate what I'm getting now, which looks quite good.

 

As for the palette, the hue appears to be very accurate, but its a little dimmer than what the Inty puts out. From looking at it on the scope, the waveforms I'm outputting range from 0-4V or so, and that's probably the reason. Right now I'm powering the monochrome stage from the Inty itself and the color stage from an Arduino, as powering both from the Inty wasn't resulting in a stable display. It could easily be a function of a limit to what the Inty can power on the cartridge port as well as the fact that my cartridge tap board uses really thin traces for power and ground. At some point I'll have to make a new cart tap board anyway once I start on the input stage, but I might also try experimenting with a separate power supply. I'll have to find something that's stable and gives clean 5VDC without costing a fortune, something I haven't really looked into yet.

 

As for the monochrome stage, I'm still using my design with 8 pixel bits and one intensity bit, but I have the intensity bit set always to 1 for now. I have a design on my laptop that does away with the intensity bit but adds a second FIFO to store color information. This lets me have 8 pixel bits and 10 color bits. Building an input stage to feed this will be a real challenge; some questions to answer are how configurable it should be (10 bits for foreground only? 5 FG and 5 BG?) Hardware scrolling is also not possible with the current monochrome stage as the timing is hardwired with 4 NAND chips, but it would be nice to be able to shift the overlay.

Edited September 26, 2017 by JohnPCAE