what's the best way to get composite video?

Check out my text video display for one approach.

http://users.softcom.net/darylr/io/vid3.html

Cheers!

Daryl

If you have the memory space alloted for it, you can also use a technique that I first recall seeing in the Amiga Video Toaster -- digitized composite video.

Basically, it's like playing an audio sample at 12MHz sample rate instead of at 22.05kHz. 8-bit resolution ought to be plenty fast enough to encode composite syncs, color burst, and luma and chroma signals (DCTV for the Amiga did all this with even less resolution). The only disadvantage is the amount of memory you need to do it. BUT, you gotta admit, it is the absolute least-hardware solution you can take.

I have been strongly considering this route for the Kestrel, using not only digitized R, G, and B gun information for the VGA display, but also digitized HSYNC and VSYNC information too, thus eliminating the need for a dedicated CRTC chip, DMA/CRTC/CPU coordination logic, etc. But, my memory requirements increase a little bit, as a VGA display has 800x525 true pixels for what appears to be a 640x480 display to the user (420 000 "real" pixels versus 307 200 playfield pixels).

One of these days, somebody needs to write a comprehensive architecture-neutral text about all of the ways and means to get a hobyist-level minimum-hardware video display.

Because there's about 200 different ways to do it, some of them more likely to get good results without hours slaving over the 'scope than others, etc.

Well, I was thinking one possible way to do it without sucking up so much space in memory is to use a single DMA channel with which to fetch digitized composit video only when actually refreshing the on-screen information. Video timing would be generated by something like an Atmel or PIC chip. Communicating to the Atmel or PIC can be done using a serial port -- how often does one change video timing parameters? While not 100% least-hardware, I think that probably will deliver the biggest bang for the buck.

Not to beat a dead horse, but I'm working on a 160x100 resolution least-cost solution based on two ATmega32s -- one to generate 160x100, bitmapped, monochrome video, and another to generate color bytes in synchrony with the former. This is NOT the final video implementation for the Kestrel-2, but is intended to mate with a Kestrel-1 series design, and like the Kestrel-1, should let me become more familiar with VGA and its timing issues.

I might redesign the Kestrel-1 so that it has native, on-board video generation via these microcontroller arrangements.

Graphical sophistication should be a hybrid between a VIC-20, Atari 2600, and an Atari 800 -- the two chips used together can provide for a 256 color palette, with a color resolution of 8x1 monochrome pixels. The monochrome video generator should also be able to support raster interrupts in some capacity. Combined with the raster interrupts, the vertical magnification control also lets you soft-stripe or hardware-stripe with other monochrome video chips used in parallel (e.g., if you have two monochrome video chips plus one color generator chip, you should be able to get 160x200 monochrome pixels with 8x2 color resolution; if you're crafty enough, you can use raster interrupts to reprogram which vertical display window each chip renders in on the same field, thus providing even higher vertical resolutions at the expense of CPU performance).

I realized a few days ago that, once I finish the ordeal, I could perhaps sell boards as kits as well, as well as pre-programmed microcontrollers who don't want a daughter card lying around. I'll look into this possibility once I have working hardware though. Until then, it's just an idea.

Just to round out the set, because I just know someone will want to make at least a few games for this platform, I'll probably also rig up another ATmega of some kind to serve as a sound synthesis chip as well. The Kestrel-1 would essentially be a game machine at that point.

No, because in order to use that, I need a PCB, then I need to order the VGA chips, which require massive quantities, then there's the SDRAM chips that they couple with, then there's the . . .

It'll very quickly amount to more than $28. It's better to somehow *fake* a PCI bus transaction and work with that. Except now you're getting into the cost of a PCI slot connector, level translation, etc. It all becomes very expensive in one capacity or another.

Literally, THE cheapest solution is to use a cheap FPGA to do all the grunt-work of managing the display. However, I can't afford an FPGA development environment. The last time I researched purchasing even modest FPGA chips (alone! Not including the programming environment needed to work with them), it was going to cost me $100 to $125 per chip. Ouch! But because it can be tailored specifically to the circuit I'm building, the bus interface doesn't need 16 levels of translation/conversion/mapping like the other solutions do, thus saving board space. Then there's the fact that it seems like you need 8KB of code just to initialize the VGA, only to have a *FIXED* display -- there are no visual effects supported by VGA at all -- and most don't even offer raster compare interrupts.

So . . .

http://elm-chan.org/works/crtc/report.html

someone used an FPGA here on this one.

If we can get it set in quantity, perhaps offering as a generic board with an 8 bit port for every SBCer out here to interface to?

http://www.xilinx.com/xlnx/xebiz/produc ... SP/XC95108
The Xilinx website shows the pricer per chip around 10-20 dollars.

http://direct.xilinx.com/bvdocs/publications/ds300.pdf
the USB programmer is about $150 dollars.


If anyone cars to do design and sales of such a device, I can definitely use for work worst comes to worst, design for work then release out here. Lets see how it goes....anyone who makes one, I will be musing at least 12 units....

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

In quantities, yes. Not in quantities of 1 though. I already contacted several distributors about this time last year, which is when I was looking to make the Kestrel with a dedicated stack-architecture processor of my own design. I remember asking for a price, and they told me the same rhetoric -- $10 to $20 per chip. "What kind of quantity?" 1000 or more.

Right.

Now, that being said, even in units of 1, a $150 price-tag for a good-sized FPGA can still end up *saving* you money after you consider the PCB space you're saving by replacing all that discrete logic. I'm not complaining that FPGAs are expensive in the absolute -- I'm just saying that they're too expensive for me and right now. Believe me, I am chomping at the bit to be able to work with them, and slowly, prices are coming down. It's just a matter of time.



Right -- $150 for programmer, plus another $180 or so for the Windows license to load the software with (I haven't yet looked at the link you gave me, because I'm at work, but I will when I get home to see if they offer Linux software as well). That's $330 for me to plunk down assuming they don't also have a Linux toolchain as well.

I will continue with my ATmega-based solution for the time being. ATmega32s are available as DIP packages, and therefore are wirewrap friendly. I *WILL* eventually get into FPGAs, but only when I can justify the cost.

Last year I bought a dev board from Xess. You can get a 200k gate Xilinx Spartan-II FPGA with all the goodies for $149.

I wanted to work on building a VGA driver but have not started yet.

This is a definite option for experimenting.

Here is a link to the board:
https://xess.com/prod034.php3

The digikey price for a Spartan-II chip is $35.40 (Qty of 1)

http://www.digikey.com/scripts/DkSearch ... 01&Site=US

Daryl

VERY promising there. Development system is bang for the buck qand the chip price is fairly reasonable. Since ExpressPCB does 4 layer FP components, there is definitely a good one there. If they have an RGB at NTSC frequencies core setup, I am so very there.

For a design for everyone, let me throw in a wish list:

8 bit port with signals compatible to 65C22 (use the register/data addressing fields trick used in the TMS34010 where the first byte is the register specifier and the second byte is data.)

Graphic primitives command set. Doesnt have to follow PC standards. Make yer own! Some ideas towards commands:

SetGraphicsResolution(x,y)
SetColorPlanes()
DrawLine(x1,y1,x2,y2,color)
PlaceGraphic(GraphicNum,Xloc,Yloc,XSize,YSize)
CheckCollisons(GraphicNum1,GraphicNum2)

An eprom space for graphics to be references from the FPGA. Test patterns, game graphics, you name it. This way, you dont have to spend precious ROM space on your 6502 uploading graphics into it. Have this rom up to 27C801 which gives 1 meg by 8 of graphics fun

I2C commandable for those wanting to use it that way
USB, tis a must as well.

Do you think it could be done to the point of less than $150 per board?

Wait, if the main board is purchasable for $150, if you roll it down to expresspcb...hmmm....

For work, we can be counted on an order of 12, and I would seek one for myself at home.

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

I think I'm not really following this, but why not get an old graphics
card(s) and salvage the chip(s)

or just put a 16 bit ISA connector in and plug in an old graphics card?

For composite video I think I'd just use a Commodore VIC chip, but then I managed to snag a couple while they were still available, so that might only work for me. <g>

Again, you can also use digitized composite. If you store your pixels as 16 bit words, you can have 6-bits dedicated to luminance, and 5 bits each to the I and Q color burst phases. Or, just store the raw DAC output sequence in RAM and spit it out an 8-bit R-2R DAC. You literally are not going to get any simpler than that. Monochrome is trivial, though color support may involve some math as you need to figure out the composition of the chroma and luma signals.

The C64DTV does it with a 4-bit luma and 4-bit chroma DACs, so a 5-bit DAC is all that is really required for this type of stuff.



I don't understand.



Umm...not sure I understand this either. What do you mean by "references from the FPGA?" Why not just use a huge addressing capacity instead? Something like the VIC-II chip's ability to address only 16K of video memory, but most of those bits are programmable but fixed based on various VIC-II registers? (E.g., sprite address pointer bytes, for example, or character map pointer, or character font pointer, etc)



I'll leave that for a microcontroller to deal with -- that has no place belonging inside the FPGA itself, unless that was its sole purpose.



In mass quantities, perhaps. Not in singles.

**LOTS** of reasons.

1) Availability. As in, significantly diminishing, and increasingly unreliable, supply.

2) Availability. It is unacceptable from a new product line point of view. If you're intending on going into production (a possibility for my Kestrel), then it is not practicable.

3) Compatibility. Now you need installable video drivers that are card specific.

4) Complexity. Ever program a VGA chip at the register level? It's damn near impossible to get anything right. The "best way" or "recommended way" is to let PC BIOS set the video mode, then read back the register values. However, this is not always reliable -- most SVGA chips have registers which are write-only to save silicon for their unique selling features.

5) Bus interface logic requirements. You are attempting to interface a 6502 to a chip that is specifically tailored for not only an Intel interface, but an IBM PC/AT interface in particular. That means, you must mimic the ISA's precise operational semantics. This imposes software and/or hardware overhead.

6) Lack of features. VGA cards for the PC are generally designed for static, overhead projection of graphics. There are NO features that caters to more advanced graphics capabilities (raster interrupts? What are those? Vertical sync interrupts? MAYBE, but not guaranteed -- see item 3 above. Sprites? What are those? Split-screen operation? Only to video offset 0, thus preventing anything more than 2 screens. Multiple resolutions on the same monitor? Why would anyone ever want to do such a thing? Blitter?! Confidential information -- here, sign this NDA, and maybe we'll give you the information you need, or maybe we'll just give you only a teaser [as has happened to Chuck Moore when he signed the NDA with ATI to gain access to their stuff]).

Need I continue?

This works for the PC because there is a massive bias towards raw CPU horsepower versus the video display bandwidth (my computer at home has a 66MHz FSB with a 32-bit bus, thus allowing 266MBps raw throughput to the video card, while the 1024x768x16.7M display mode I run it at requires a measily 135MBps average throughput. Thus, CPU can pretty much bit-bang all the features that traditionally required dedicated hardware support for, in real-time (indeed, my Atari 800, Amiga, and Commodore emulators all run easily with 50fps to 60fps performance on my 800MHz Athlon box)). Combine that kind of performance with the fact that the PC rarely updates the entire screen at 60fps, and you can see where this is leading.

In short, commercial VGA solutions are patently not hacker/homebrew friendly at the register level, and not 65xx-friendly at the programming level. You can acquire VGA controllers from OpenCores which are open source and well documented, are 1000% easier to program, etc., but they're still lacking in the more dynamic features that the older chips like VIC-II, TMS9918, GTIA, and AGNES & DENISE supported. Again, it is obviously optimized for processors that have bus bandwidths equal to or higher than video refresh rates. Sprite capability is limited to a lousy mouse pointer.

That's why there is still a niche "pseudo-market" for hacker-friendly video chips. Ask anyone on this board if they'd rather code for a VGA card or a VIC-II, and they'll almost always say VIC-II. There's a reason for it.