Jump to content

Photo

Bird's nest...


48 replies to this topic

#26 mr_me OFFLINE  

mr_me

    Stargunner

  • 1,917 posts
  • Location:Ontario

Posted Thu Jul 13, 2017 5:39 AM

I suggest Mattel's Keyboard Component character set.

#27 Lathe26 OFFLINE  

Lathe26

    River Patroller

  • 2,902 posts

Posted Thu Jul 13, 2017 12:31 PM

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

#28 JohnPCAE OFFLINE  

JohnPCAE

    Moonsweeper

  • Topic Starter
  • 378 posts

Posted Thu Jul 13, 2017 6:01 PM

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.



#29 mr_me OFFLINE  

mr_me

    Stargunner

  • 1,917 posts
  • Location:Ontario

Posted Thu Jul 13, 2017 8:29 PM

Keyboard Component character set:

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

Attached Thumbnails

  • kc_chars.png


#30 JohnPCAE OFFLINE  

JohnPCAE

    Moonsweeper

  • Topic Starter
  • 378 posts

Posted Fri Jul 14, 2017 12:24 AM

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:

 

 

Attached Thumbnails

  • kbc.png


#31 JohnPCAE OFFLINE  

JohnPCAE

    Moonsweeper

  • Topic Starter
  • 378 posts

Posted Fri Jul 14, 2017 1:32 AM

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.

Attached Files


Edited by JohnPCAE, Fri Jul 14, 2017 1:35 AM.


#32 carlsson OFFLINE  

carlsson

    River Patroller

  • 4,716 posts
  • Location:Västerås, Sweden

Posted Fri Jul 14, 2017 2:51 AM

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. :-)



#33 mr_me OFFLINE  

mr_me

    Stargunner

  • 1,917 posts
  • Location:Ontario

Posted Fri Jul 14, 2017 5:55 AM

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.

Attached Thumbnails

  • kc_chars2.png

Edited by mr_me, Fri Jul 14, 2017 6:44 AM.


#34 carlsson OFFLINE  

carlsson

    River Patroller

  • 4,716 posts
  • Location:Västerås, Sweden

Posted Fri Jul 14, 2017 6:13 AM

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



#35 mr_me OFFLINE  

mr_me

    Stargunner

  • 1,917 posts
  • Location:Ontario

Posted Fri Jul 14, 2017 7:20 AM

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

Attached Thumbnails

  • kc_chars3.png


#36 JohnPCAE OFFLINE  

JohnPCAE

    Moonsweeper

  • Topic Starter
  • 378 posts

Posted Fri Jul 14, 2017 9:54 AM

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?



#37 mr_me OFFLINE  

mr_me

    Stargunner

  • 1,917 posts
  • Location:Ontario

Posted Fri Jul 14, 2017 10:02 AM

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

#38 JohnPCAE OFFLINE  

JohnPCAE

    Moonsweeper

  • Topic Starter
  • 378 posts

Posted Fri Jul 14, 2017 10:07 AM

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.



#39 mr_me OFFLINE  

mr_me

    Stargunner

  • 1,917 posts
  • Location:Ontario

Posted Fri Jul 14, 2017 10:17 AM

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

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

Edited by mr_me, Fri Jul 14, 2017 10:27 AM.


#40 JohnPCAE OFFLINE  

JohnPCAE

    Moonsweeper

  • Topic Starter
  • 378 posts

Posted Fri Jul 14, 2017 10:30 AM

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?



#41 Lathe26 OFFLINE  

Lathe26

    River Patroller

  • 2,902 posts

Posted Fri Jul 14, 2017 10:32 AM

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.



#42 mr_me OFFLINE  

mr_me

    Stargunner

  • 1,917 posts
  • Location:Ontario

Posted Fri Jul 14, 2017 10:38 AM

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

#43 JohnPCAE OFFLINE  

JohnPCAE

    Moonsweeper

  • Topic Starter
  • 378 posts

Posted Fri Jul 14, 2017 12:03 PM

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.

Attached Files


Edited by JohnPCAE, Fri Jul 14, 2017 12:03 PM.


#44 JohnPCAE OFFLINE  

JohnPCAE

    Moonsweeper

  • Topic Starter
  • 378 posts

Posted Sun Jul 16, 2017 1:52 PM

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).

Attached Files



#45 JohnPCAE OFFLINE  

JohnPCAE

    Moonsweeper

  • Topic Starter
  • 378 posts

Posted Mon Jul 17, 2017 8:22 AM

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...

Attached Files



#46 JohnPCAE OFFLINE  

JohnPCAE

    Moonsweeper

  • Topic Starter
  • 378 posts

Posted Sat Jul 29, 2017 11:00 PM

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.

Attached Files


Edited by JohnPCAE, Sat Jul 29, 2017 11:01 PM.


#47 JohnPCAE OFFLINE  

JohnPCAE

    Moonsweeper

  • Topic Starter
  • 378 posts

Posted Sun Aug 6, 2017 10:20 AM

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 by JohnPCAE, Sun Aug 6, 2017 10:23 AM.


#48 JohnPCAE OFFLINE  

JohnPCAE

    Moonsweeper

  • Topic Starter
  • 378 posts

Posted Thu Aug 10, 2017 12:41 PM

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.

Attached Files


Edited by JohnPCAE, Thu Aug 10, 2017 12:42 PM.


#49 JohnPCAE OFFLINE  

JohnPCAE

    Moonsweeper

  • Topic Starter
  • 378 posts

Posted Fri Aug 25, 2017 5:13 PM

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.






0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users