Looking for Video Output Solution (Hardware or Software)
Simon Ampleman
Posts: 19
Two years ago, I wanted to learn electronic by building a complete project.
I thought that building a NES is a good idea since it's old'n'slow hardware, includes sounds, video, input devices, memory... And moreover, there is a lot of documentation on the web for emulating this system....
One day, I found "The Black Art of Video Game Console Design"... I bought it, read it and understood·that everything would be possible except "outputting" the video data to the TV directly from the microcontroller with the same details as a Nintendo....Then, I saw on his website, that the new system would use the Propeller chip which is more fast than the older system. I bought·few propeller chip and started to develop and output test data on my TV... However, I was only able to output a few colors with a very low resolution, and using a lot of cpu....
I would like to know if someone has experience with video output with a simple chip connected to the Propeller...· I don't want to output 1024x768, 32 bits colors... only 256 x 224, 256 colors, let's say 30 to 40 fps for now...
I would like to use only one cog of the propeller to control this video chip and keep the remaining ones for other purpose...
Is there any internet online course, or tutorials on the web on this kind of subject...?
Thank you very much!
Simon
Post Edited (Simon Ampleman) : 8/27/2007 1:59:38 PM GMT
I thought that building a NES is a good idea since it's old'n'slow hardware, includes sounds, video, input devices, memory... And moreover, there is a lot of documentation on the web for emulating this system....
One day, I found "The Black Art of Video Game Console Design"... I bought it, read it and understood·that everything would be possible except "outputting" the video data to the TV directly from the microcontroller with the same details as a Nintendo....Then, I saw on his website, that the new system would use the Propeller chip which is more fast than the older system. I bought·few propeller chip and started to develop and output test data on my TV... However, I was only able to output a few colors with a very low resolution, and using a lot of cpu....
I would like to know if someone has experience with video output with a simple chip connected to the Propeller...· I don't want to output 1024x768, 32 bits colors... only 256 x 224, 256 colors, let's say 30 to 40 fps for now...
I would like to use only one cog of the propeller to control this video chip and keep the remaining ones for other purpose...
Is there any internet online course, or tutorials on the web on this kind of subject...?
Thank you very much!
Simon
Post Edited (Simon Ampleman) : 8/27/2007 1:59:38 PM GMT
Comments
It should have alot of the information you will be looking for.
www.parallax.com/detail.asp?product_id=70360
Oldbitcollector
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
The comments and code above are proof that a million monkeys with a million propeller chips *could* write Shakespeare!
I think there is a lot of options available, so I am trying to·find someone here that know modern chip that can do the work...
Thank you!
Simon
But on the other hand... Simon, you must understand that the mainstream of graphics controller development is in 3D now. They do VGA with 0,1% of their performance
Less 3D graphics is done in most PC south bridges - also "along the way".
VGA is the most simple thing in the world, what the Prop is missing is video memory, just memory...
The simplest approach for you might be to buy a second hand ISA-VGA card from ebay. they are around $5 plus shipping (this darn shipping with ebay...) But they are not "small", as you know
An also promising approach is to use a second Prop just for the video. I made a short calculation the other day:
You can use 3 COGs, each controls one "color plane" for R, G, and B. 4-color mode lets you output 2 bits each so you have true 64 colors/pixel which is not bad.
You can have 10kByte per plane = 40kPixels = 200x200 which comes very close to your minimal requirements.
Using a pixel clock of 8 MHz (for 200 px/line)) = 125 ns, outputting 4 Pixels = 8 bit@ 4-color-mode per WAITVID you have 500 ns for processing = 10 instructions/loop.
However 600x400 or even 800x600 is 6x to 12x as "hungry" and 24 bit colors multiply this by another 4.
Just from these numbers we have:
Prop now: very fine, but full 200x200 @ full 64 colors needs most of its resources
Needed: x 24 upto x 48 as much
Edit:
Adding external (=video) memory to the Prop will be tight wrt timing. Note someone has to STORE the things there during the same time you do video (but maybe the sync time will suffice for that). You will most likely need one external memory per plane = COG. As the idea is to increase pixels/line this is probably a dead alley, as the video loop will collapse at > 16 MHz = 5 instructions (DJNZ, WAITVID,ADD, INA) .
N.B. For the reader, who wonders how the drivers he knows of can do all this: They use "tiles", which means 4 different colours only per 16 pixel chunks, so they have a four-fold clearance!
Composite Video can additionally relax on its refresh of 30 Hz rather than the VGA's 60 Hz...
Post Edited (deSilva) : 8/26/2007 9:02:40 AM GMT
If you are looking for a solution to your problem with graphic output, keep your eyes peeled to this forum.
We are working on a solution at the moment, it is nearing completion and I am sure it will fit in with your design.
It features:-
256*192 Resolution
32K Colours
8*8 pixel tile map layout
16 Colours per tile from 16 Pallettes
64 Sprites
10 Bit wide data bus or serial 2 wire for low bandwidth operation.
Composite and S-Video output
DIP40 Layout make it easy to add to your own designs.
Oh, and it is based on the Propeller....
I can't and won't say any more than that at the moment, just keep a look out for when we release it.
Regards,
Coley
Coley: very nice! I want one! [noparse]:)[/noparse]
What will be the size of the sprites?
The sprites will align to the tiles I assume?
Loading the video memory (32kb) through a 10 MBit ISP - taking around 32 ms that is 30 Hz - should be acceptable. Of course I2C or RS232 will suck
I am more concerned with double buffering for medium fast animation. You should try for a flickerfree redraw by all means...
Post Edited (deSilva) : 8/26/2007 11:20:25 AM GMT
You have a choice of display modes [noparse]:)[/noparse]
Bitmap mode, 16 colour bitmap 256x192 ( palette of 32K colours )
Charactermap mode with HV flippable characters, up to 768 characters, and 16 palettes of 16 colours, each colour can be any from the 32K palette
Charactermap is 32 characters wide ( or 31 for X scrolling, when enabled which removes 32nd character from display for smooth scrolling ), and 24 or 28 ( or 23/27 for Y scrolling )
Then there's Sprites over the top of the lot, varying sizes, 8,16,24,32 pixel widths by any pixel height, memory permitting of course. each sprite is X / Y flippable, and has it's own palette of 16 colours.
All on a DIP40 prop.
As for Double buffering, you won't need to for character map mode, and I can update all 64 sprites + tilemap for complete screen + palettes, all inside the vblank thus there will be no sprite or background tearing... so yes, it's flickerless [noparse]:)[/noparse]
Baggers.
Composite video is generated by the on-board video encoder chip.
Regards,
Coley
And I see you are already becoming accustomed to marketing speak: ".. memory permitting...", ".. a few external components..."
I think you can in fact do many things with 64 32x32 sprites - when the memory allows it.
As you do not mention VGA, I assume you have no RGB output, but phase shifted NTSC color?
You are most likely aware that there are permanent complaints about PAL, as the 80 MHz clock is not close enough to the 4,433... MHz PAL clock?
Just an idea: The use of 480 pixel wide (7" car-) monitors is quite widespread. Quality on them will most likely improve with 240 pixels/line rather than 256...
(Edit: Though a living room PAL TV set might prefer 768/3 = 256....)
32k colors - so you managed to generate a 11-bit luma signal?
Or you could have dithered by overclocking to 16x16/2 colors =128 needing 8 bits luma only. This seem more plausible.. 11 bit luma is poppycock
Post Edited (deSilva) : 8/26/2007 1:22:58 PM GMT
Video is generated as 15Bit RGB and then encoded to composite and s-video by an additional encoder IC.
This does not currently support VGA, just composite NTSC and PAL.
We are not using the prop video registers to generate the video signal this is done externally and means we can get around the problem of dot crawl.
Just wait till Baggers shows off the demo's that he is currently coding, and as you've probably guessed already, it is a joint effort between the two of us.
Best regards,
Coley
I was confused by you saying: I thought you were referring to the Prop Video logic ("on-board" <> "on-chip")
I just edited to my former posting:
And here's to the persons who wonder why 192 lines?
It's 576/3! 576 being the number of PAL lines.
.. and it will look not so good on "Never The Same Colour" displays
Post Edited (deSilva) : 8/26/2007 1:54:13 PM GMT
Which rises another question: Interlaced or non-interlaced?
PAL writes 288 physical lines per "field" which is just 3/2 of the 192 logical lines, i.e. each second line is "doubled".
This should be compensated for during the next "field".
Sorry for asking stupidly, but this is a feature of your video encoder!?
Edit: ... and here is a descriptive name for the chip: PAL/9, or maybe NPAL32K "nineth PAL with 32 thousend colours"
Post Edited (deSilva) : 8/26/2007 2:30:26 PM GMT
It's interlaced or non-interlaced, interlaced is just sending the correct sync setup for the second field, but just drawing the 192 lines again, thus "doubling" the lines.
with 192 lines, there's a border on top and bottom, and sides. it was 256x192, for memory reasons, for bitmap mode. it can be 256x224 or 240 or 256 even for charmap modes.
Could you try to consider my concept?
It would mean:
(1) No black border, strict aspect ratio
(2) For the upper field send lines 1,1,2,3,3,4,5,5,...
(3) For the lower field send lines 1,2,2,3,4,4,5,...
Post Edited (deSilva) : 8/26/2007 2:58:08 PM GMT
My target for sprites is a little different though because I am looking to do 8 16x16 sprites ( though I might up it depending on performance). I do have a question though on the sprites. You say your code will do 64 32x32 sprites, is that 64 sprites on a single scanline or 64 total addressable with a scanline limit of sprites?
Post Edited (deSilva) : 8/26/2007 8:25:39 PM GMT
The background would be made up of tiles (like the old 8 bit computers or game systems) which would be scrollable in both X/Y directions.·There would also be a selection of 8 on screen sprites that can be placed over the tiled background.
The graphics drivers would achive similar things that are done with the demo programs that were programmed for the Hydra, but since these are written from the ground up I could release the source.
·
I just found the TMS320DM644 (also called "DaVinci") which sports High End features for $9,95 (but in volume most likely) www.ti.com/corp/docs/landing/davinci/faqs.html
The prices I've seen look to be about $30 each if you buy 1000 pieces. Where'd you see that number?
And anyway, it does seem to be a bit ironic to saddle a 320 of any variety with a propeller:
"With performance of up to 4800 million instructions per second (MIPS) at a clock rate of 600 MHz, the C64x+ core offers solutions to high-performance DSP programming challenges. The DSP core possesses the operational flexibility of high-speed controllers and the numerical capability of array processors. The C64x+ DSP core processor has 64 general-purpose registers of 32-bit word length and eight highly independent functional units—two multipliers for a 32-bit result and six arithmetic logic units (ALUs). The eight functional units include instructions to accelerate the performance in video and imaging applications. The DSP core can produce four 16-bit multiply-accumulates (MACs) per cycle for a total of 2400 million MACs per second (MMACS), or eight 8-bit MACs per cycle for a total of 4800 MMACS. For more details on the C64x+ DSP, see the TMS320C64x/C64x+ DSP CPU and Instruction Set Reference Guide (literature number SPRU732)."
Fred
and the sprite sizes aren't fixed to 32x32 or 16x16, they can be any variant of 8,16,24,32 in X size, and any pixel height.
but when I drill down to specific page and check the price, they are as I said: about $30 each for 1k units. Guess they want us to call them.