Hi all!

I've redesigned my video I/O project and now have a working NTSC video display supporting 40x25 monochrome text.

The parts count is very low thanks to the Atmel ATMega8 microcontroller. I'm finishing up the firmware and also developing a PAL version.

Check out the details on my web site under the IO Devices tab. If there is enough interest, I may consider offering this as a kit including an Express PCB circuit board and all the parts, including a pre-programmed ATMega8.

For those interested in using LCD's, this solution should be easily adapted to a 320x200 LCD display. Let me know if there's any interest in that area as well.

Thanks!

Daryl

http://sbc.rictor.org/

The Text Video Display is now complete. The prototype works great thanks to the ATmega8 microcontroller.

Check the complete details on my web site:
http://sbc.rictor.org/io/vid3.html

Thanks!

Daryl

How about a bitmapped color disp[ay, or if you get an old VGA style chip as well added in there, or a connector for a VGA card running through the atmel chip as a sort of bios? Thjat might prove to be an interesting project variation there. low cost VGA cards are that, and you can save a LOT of video design right there...

_________________
"My biggest dream in life? Building black plywood Habitrails"

Hi,

First post here in years - life keeps getting in the way

I'm currently taking an approach to video design similar in some ways, different in others - like you I'm using an atmel AVR Mega8, but rather than generating the video in the chip itself (I have some code on my website that spits out four channels of pal pixels ) I'm using it to save myself a dozen timers and glue logic.

I don't have the code yet (though it will be a modification of the above) nor the diagram in a form to be posted, though I will post it as and when...

I had two requirements: graphical output rather than text, and the memory to be in the processor memory space. A nice to have is that the video controller produces the phase0 reference at either 1M or 2M (1.5M is a bit dodgy )

Here's how it (will) work: the processor memory splits as RAM to 32k, ROM from 33k, with a little space in the middle for IO. The processor talks to the memory through 241 or similar memory buffers to a local bus also driven via resistors by 14 bits from the M8. The M8 samples the memory at 20k and upwards, once per microsecond to give 256 lines of 48 bytes each, for a total resolution of 384 by 256 dots. It loads the read byte into a piso (166) and controls the blanking as well. Dot clock is 8MHz to give a luminance bandwidth of 4MHz - well inside PAL limits, though it may need to go in as an RGBS feed rather than the composite input to avoid the colour filters.

I've stolen your sync/video mixer (er, if you don't mind).

Looks like about six chips for the whole thing, plus the processor, IO, and ROM.

Thoughts?

Neil

Your approach sounds simple and direct.


Actually, I devised it from several other designs, including the Apple 1.



It sounds solid to me. I've ordered an ATMega162 which can use external RAM up to 64k. I will use it to run a graphical display with only slight modification to my text display. I'm still working out the color aspects. I hope to be able to have at lease a color graphics display that connects to a PC monitor.

Keep us informed on your progress!

Daryl

The nice thing about this design is that the same clock would work for an infinite number of bit planes, just needs lots of RAM bolted on and something to arrange the write access paging.

Neil

Here is an update on the project.

I've re-organized the code and have made room for a total of 512 characters. I plan to offer the the entire 256 standard DOS character set (including box drawing characters) and also the inverted (black on white) characters.

Also, I've been asked to support a Commodore-specific font which is under development.

The fonts will be accessed 128 characters at a time (Lower 128, Upper 128, Lower Inverse 128, Upper inverse 128) through commands:
$F0 = lower 128 selected
$F1 = upper 128 selected
$F2 = normal (white on black)
$F3 = Inverse (black on white)

The Commodore font will be created in a similar manner.

I hope these changes will make this a more desireable project for those who need simple and inexpensive text video output.

Daryl

Congrats on your project. It is looking very clean. I like it.

I don't know anything about how the ATmega8's memory is organized. Is the font data stored in ROM? Is its RAM capacity large enough to store custom, downloadable fonts? That's the only feature I would consider 'missing' from it.

I really like the way the TMS9980 series of video chips generates its video display. It really does blur the distinction between text- and graphics-modes. The TMS9980 divides the screen into 256 dots by 192, producing a 32x24 character display (assuming an 8x8 font; with 6x8, you can get a true 40x24). Anyway, since 32 characters are possible on a line, it takes 8 lines of text contain 256 characters.

Well, 24/8 = 3, so the TMS9980 has a special mode that works by dividing the screen into 3 groups of 8 lines each. Each group draws from its own, unique character generator table. Thus, by filling the screen with three sets of ($00, $01, ..., $FF) patterns, you can then draw directly into the character generator maps to get monochrome bitmapped graphics.

In fact, in 'text mode,' the only difference in behavior is that it uses character map 0 for all three segments of the display. In all other aspects, it works the same as 'graphics mode.'

Now, this might be a bit much to implement in a homebrew piece of equipment, but by placing the character maps in RAM, and using a memory pointer to reference them (since the video chip needs that memory pointer anyway), then one can use a raster compare interrupt to achieve the same basic effects.

Just throwing out some ideas. I actually rather like this. Not as simple as a raw bitmapped display subsystem, but then, it has the benefit of a true character mode support, and we've always known character modes are more complex than raw bitmapped graphics display systems anyway.

The ATmega8 has 1024 bytes of RAM. I'm using 1000 for the character data and approx 8 bytes for stack use. The 16 bytes left over could be used for two user-defined characters but that would require further processing of the character data. If I did that, then I would not be able to send the video data to the shift register fast enough.

The same goes for placing custom font data in the 512 bytes of EEPROM. I would not be able to access it fast enough to maintain the shift rate.

Thats why I chose to put the font in the program memory.

I am now working on a graphical version using the ATmega162 (40 pin dip) which can address up to 64k of external RAM. I'll post the results here once the prototype is built.

Daryl

Daryl,

Are you planning on posting the code for the ATmega8 microcontroller on your site?

_________________
Steve

... not at the present time. However, I will probably have an Intel-Hex object file available in a few months.

I can discuss this further offline via my email address.
Daryl

The TMS99xx series was used in the TI994A home computer and the Colecovision and some arcade games such as Baby Pacman. The logic it works with is fairly simple. I dont like it because it has a failure rate. I figure that out of all the Vidiot boards for Babyt Pac I fixed, I've replaced that chip on maybe 5% of them.

Darrl: I'd be itnerested in a revamp of your graphical interface but using a regular 6502. Me itnerested in arcade game usage (me still the brat here)...
But darned awesome job on keeping it all so small....

_________________
"My biggest dream in life? Building black plywood Habitrails"

I suspect that it is not the chip which is failing; remember, these chips were used in TI-99/4A computers, both MSX models, etc. In other words, LOTS of these chips have been sold and distributed. Few (any?) have ever had any failure.

I would suspect failure to be attributed to the nature of a stand-up video game machine. You have little teenage brats slamming the machine around, especially when the game doesn't go their way. Then you realize that the machine is packed into a small room with ten or twenty other arcade game machines, each of which is all generating copious amounts of heat in their own right. Plus all the people packed together in the room, you can imagine how HOT it must get inside an arcade game machine.

In short, the chips die from thermal damage. Frankly, any chip would die from the same causes.

5% failure rate is not a terribly high rate. Not when you consider something like the 8520A chips in the Amiga, which are often found destroyed on 20% (!!) of bad Amiga and Commodore 128 boards. 5% is nothing. And that's in a temperature moderate environment under home computer conditions.

True,. Its also 5% of the repairs I see on the Baby Pac Vidiot board. The main problems I have is a dynamic RAM going out or acid damage destroying the program eprom sockets (54 2764s)

_________________
"My biggest dream in life? Building black plywood Habitrails"

Nice aritcle Daryl.