Survey of Video Generation Possibilities

[Chuckt]

There are some solutions for video because there are prebuilt video projects from other vendors like the Gameduino, Mod-VGA (based on the Gameduino II), the Ascii Video project, the propeller, VGA output on an STM32 Cortex M3, FTDI's Embedded Video Engine (Eve) chip which the Gameduino II is based off of, and uVGA II. There are websites that explain video signals and if you want to make a more powerful graphics engine, you can look on Mouser for Multimedia I.C.'s.

There are some TTL video projects on Kickstarter and Hackaday but I wasn't impressed with their video quality to start tinkering with them.

[brad]

I think I may have mentioned this before but I am a little worried that as the years go by, hobbyists (like us) will tend to move toward high end graphics chips and displays rather than keeping things nice and simple with 'old school' low resolution style graphics.

I think it's great fun to be able to figure out how to generate graphics yourself rather than relying on a chip to do it all for you and I also think there is something quite special in the retro style large font characters on a screen rather than high resolution text etc. that you would find on a computer these days.

This is the kind of thing I like:

[Chuckt]

The problem is showing Atari games to people these days and expecting them to be happy. Even the Wii U was criticized for not having good enough graphics.

The problem is being relevant which means you need to have speed and keep up with the latest technology.
That is kind of hard to do with through hole components. If you want a fast chip, you usually have to go with surface mount components and I suppose that multimedia I.C.'s that use HDMI are probably all surface mount.

We have a new HDMI television and it only came with one composite input so if you have more than one game system, you have to have converters or HDMI connections for them.

[Garth]

The higher inductance of thru-hole's longer IC pins and bigger lead frames would probably prevent operation at the high frequencies involved in modern hi-res video.

I'm with you on the simplicity aspect though. Many on the forums seem to be interested in re-creating the game machines of the past, possibly with big performance improvements, so they put a lot of attention on video. I have absolutely no interest in games or GUIs, and I'll do my CAD on the PC; so my own interest in video is mild enough that I'll only get into it if it's really simple. It's pretty much limited to workbench-type techincal applications. I haven't even done anything with my circuit for raster graphics on an analog oscilloscope, but it's there if the need arises. Farther down in the topic, NightmareTony commented, "Garth, am now officially way the heck impressed by the sheer simplicity of your XY circuit. The arcade ones had always been fairly complex as heck...."

[Chuckt]

The higher inductance of thru-hole's longer IC pins and bigger lead frames would probably prevent operation at the high frequencies involved in modern hi-res video.

I'm with you on the simplicity aspect though. Many on the forums seem to be interested in re-creating the game machines of the past, possibly with big performance improvements, so they put a lot of attention on video. I have absolutely no interest in games or GUIs, and I'll do my CAD on the PC; so my own interest in video is mild enough that I'll only get into it if it's really simple. It's pretty much limited to workbench-type techincal applications. "

I think hobby E.E. will survive without me but a lot of it seems to be centered around Arduino these days for electronics and the Raspberry Pi for programming and or electronics. These two items are great for beginners but I don't know how feasible they will be for learning advanced programming.

There are schools with PC's in them for elementary school.

What I see is that every PC in the 80's had BASIC and those days of learning are gone so I think there needs to be something relevant to replace it with and the only answers I see are the ones I mentioned. I think there should be another option but being relevant is the only way to get people's interest but I don't think you will get people breadboarding the Raspberry Pi so in that respect, hobby E.E. is lost.

[brad]

Thanks for the link Garth, that converter circuit is fantastic. Just like many other circuits, there would be numerous ways to achieve the same result however doing it simply is what causes you to really need to think about the circuit.

I do hope that the hobbyist E.E. is not going to be a thing of the past - it would be very very sad if that were to happen.

[Chuckt]

Demoscene Board

A USB programmable board which allows you to write graphics & music demos and play them over a VGA monitor and audio jack. There are limited system resources and the goal is to write code and fit spectacular graphics effects with songs. You can write code in either ASM or C. One of the categories for the demo party is the Layerone Demoscene Board. The goal is to fit cool graphics and audio demos and to wow the audience!

Layerone Demoscene Board

- PIC24FJ256DA206
- 32Mhz, 16-bit
- 96Mhz GFX Core (CLUT, Fonts)
- 96K SRAM
- 256K FLASH
- USB/OTG
- XC16 Compiler, Assembler, Linker

- USB or EXT power (5-15V)
- 4-6 GPIO (configurable to UART, SPI, I2C)
- VGA Port: up to 16bit 5-6-5 DAC, 1-8bpp, up to 640x480
- Audio Jack: 8bit Audio DAC

-Open source
-Programming: USB Bootloader (ds30 Loader) or PIC programmer (PICKIT3, REALICE, etc)
-Windows, Mac & Linux (using Mono)





http://hackaday.io/project/3877-layeron ... cene-board

http://hackaday.com/2014/10/08/hackaday ... nd-blink1/

[Dr Jefyll]

I think it's great fun to be able to figure out how to generate graphics yourself rather than relying on a chip to do it all for you

Hi everybody. I agree homebrew video is great fun, as well as being educational and even inspirational! If you haven't already, I highly recommend you check out a technique popularized by author Don Lancaster -- a technique he offhandedly refers to as Cheap Video. Pixel data is stored in the microcomputer's main memory, and -- implausibly enough -- it is the CPU itself which generates the ridiculously rapid sequence of ascending addresses necessary to fetch the bytes during each scan line. This involves some wily wiring, but saves money (and validates the "cheap" moniker) because there's no need for a DMA controller or for a separate memory system. Lancaster wrote about Cheap Video in the 1970s, and it's still applicable today -- albeit with the potential for drastically increased resolution due to the much faster silicon that's now available. Bitmapped and character-oriented displays are both design options.

I've built three microcomputers that use cheap video, and there's an article about it on my web site here. The principal tradeoff of Cheap Video is that, unless you are willing to drop frames, it utterly monopolizes the CPU except during the retrace intervals. The technique is marvelous and it's cheap but it's not magic. Pretty close, though!

cheers,
Jeff

[brad]

Hi Jeff welcome to the forum

Thanks very much for the link, I had a good read through. Correct me if I'm wrong but would you consider a microcontroller directly driving a LED matrix via data written in its own program memory as being along the same lines as the cheap video described in the link?

[Dr Jefyll]

Cheap video tricks the CPU into behaving like a 16-bit counter. During the active portion of each video scan line the CPU address bus continuously increments once per cycle and keeps doing so for as long as necessary. Such behavior would be unremarkable for a DMA controller, but for a CPU it's utterly weird. But useful!

The CPU thinks it is executing a long sequence of NOPs. That's why it keeps fetching byte after byte after byte...

NOP is what the wily wiring has jammed on the CPU data bus. The memory data bus carries the actual contents of the memory being addressed -- the data we need to fetch so it can be shifted out as video. (Notice the two data buses are temporarily separated, using a tristate buffer. On a microcontroller this won't be possible.)

I'm always eager to improve the material on my site, so I'll be grateful for any questions or suggestions you may have, cheap video related or otherwise.

-- Jeff

[brad]

Thanks for the clarification Jeff. I guess it would be quite difficult to open up the microcontroller and then modify the internal data bus connections!

[Garth]

I'm with you on the simplicity aspect though. Many on the forums seem to be interested in re-creating the game machines of the past, possibly with big performance improvements, so they put a lot of attention on video. I have absolutely no interest in games or GUIs, and I'll do my CAD on the PC; so my own interest in video is mild enough that I'll only get into it if it's really simple. It's pretty much limited to workbench-type technical applications. I haven't even done anything with my circuit for raster graphics on an analog oscilloscope, but it's there if the need arises. Farther down in the topic, NightmareTony commented, "Garth, am now officially way the heck impressed by the sheer simplicity of your XY circuit. The arcade ones had always been fairly complex as heck...."

I just got a small graphics LCD going, 128x64 dots, interfaced on SPI (through the 65SIB which extends SPI in several directions at once, making it more of a general-purpose interface bus). Here's a few seconds of demo video done for experiment purposes, using a random number generator to produce sets of 25 random segments then displaying the screen memory: http://wilsonminesco.com/6502primer/Dis ... 8Ademo.mp4 I might move up to a 240x128.

[brad]

That's fantastic Garth

What kind of refresh rate can you achieve with this?

[Garth]

That's fantastic Garth

What kind of refresh rate can you achieve with this?

The fastest I can currently re-do the entire frame is about eight times per second, bit-banging the serial interface on a 5MHz 6502 in Forth but with certain primitives ("primitives" being Forth words that are internally written in assembly). That doesn't leave time to produce any new data though, only keep re-feeding the existing data. With a more-refined set of routines, it could be made to refresh only the data that's new instead of doing the entire frame every time, and that would cut way down on the communication time.

The segments are specified by the X,Y values of the endpoints. What got me excited was noticing that I could calculate the dots between the endpoints similarly to direct digital synthesis (DDS) and a numerically controlled oscillator (NCO) which I've done in software a couple of times to generate sine waves for work projects, but you don't cycle it for the segment, nor do you have to look up a waveform in a table. The phase accumulator's high bits become the X or Y value itself, of the dots along the line. Then you only have one multiplication and one division to do to set it up, then only addition as you get each point between the ends.

There are options to turn the dots on, off, or XOR them with what was there previously.

[brad]

I remember doing some experiments with LED matrix's and was trying to figure out how to draw lines on the screen. It's simple enough to draw a vertical or horizontal line but things become quite a bit more tricky as soon as you want a diagonal line!

Are you looking to bring the frame rate up or is 8 frames a second all you would need for your purposes?