Jump to content
IGNORED

Bird's nest...


Recommended Posts

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.

  • Like 1
Link to comment
Share on other sites

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 by JohnPCAE
Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

post-43287-0-11579800-1500035037_thumb.png

Edited by mr_me
  • Like 1
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 by JohnPCAE
Link to comment
Share on other sites

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

Link to comment
Share on other sites

  • 2 weeks later...

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
Link to comment
Share on other sites

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 by JohnPCAE
Link to comment
Share on other sites

  • 3 weeks later...

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.

  • Like 1
Link to comment
Share on other sites

  • 1 month later...

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 by JohnPCAE
  • Like 1
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...