Simple NTSC
CardboardGuru
Posts: 443
Hi Guys,
I was having some trouble getting graphics to display properly (and sometimes to display at all) for my Donkey Kong remake. That's what comes of tinkering with things you don't understand. So I've taken the last couple of days out to properly understand how NTSC works, and how the video hardware on the Propellor/Hydra works.
In doing so I've created a program which is just about the simplest implementation of software to output NTSC. It's written to be read as a tutorial. I've tried to explain in detail whats happening where and what all the constants mean and how they are derived.
If you want to understand how to make the propellor generate video, I think this is a very good place to start.
Also included is an Excel spreadsheet that shows the calculations of the most important constants. If you're not sure how something is derived, look at the formulas here. On the other hand if you don't have Excel don't worry, the code is the main resource.
For those of you that already understand this stuff, please let me know if I've made a mistake anywhere. And likewise for those who haven't yet got to grips with the topic, if there's anything you don't understand in there, let me know. Either way I'll put out a new version.
EDIT:·The file that was here was not working.· So it's been deleted.· See message later·in the thread·for the latest version.
Post Edited (CardboardGuru) : 4/27/2007 2:51:04 PM GMT
I was having some trouble getting graphics to display properly (and sometimes to display at all) for my Donkey Kong remake. That's what comes of tinkering with things you don't understand. So I've taken the last couple of days out to properly understand how NTSC works, and how the video hardware on the Propellor/Hydra works.
In doing so I've created a program which is just about the simplest implementation of software to output NTSC. It's written to be read as a tutorial. I've tried to explain in detail whats happening where and what all the constants mean and how they are derived.
If you want to understand how to make the propellor generate video, I think this is a very good place to start.
Also included is an Excel spreadsheet that shows the calculations of the most important constants. If you're not sure how something is derived, look at the formulas here. On the other hand if you don't have Excel don't worry, the code is the main resource.
For those of you that already understand this stuff, please let me know if I've made a mistake anywhere. And likewise for those who haven't yet got to grips with the topic, if there's anything you don't understand in there, let me know. Either way I'll put out a new version.
EDIT:·The file that was here was not working.· So it's been deleted.· See message later·in the thread·for the latest version.
Post Edited (CardboardGuru) : 4/27/2007 2:51:04 PM GMT
400 x 275 - 13K
Comments
I hope it will become a standard document here for people who are interested in how the NTSC generator of the Propeller works.
because many people do not own Microsoft Excel (or any other program to open .XLS files) I took the liberty to covert the spreadsheet page to a .PDF.
Mahjongg
I tried it, but just get a blank screen [noparse]:([/noparse]
any ideas?
I've not got a hydra, but I ran it on a Protoboard, changing the pins to 12 instead of 24, still to no avail.
I've also tried it on a Prop on breadboard, and set it up to have pins 24-26 for tv out, yet still blank screen.
tried it with two tv's too [noparse]:([/noparse]
any suggestions.
PS, I also changed XINFREQ to 5_000_000 and CLKMODE for xtal1 + pll16x for protoboard, and the solderless breadboard, I also regrabbed the original, and put a 10Mhz clock on it, just to check source without modifying it.
Cheers in advance,
also, thanks for this, as once it's running, I hope to modify it to make my own driver + charmap and sprites, if you don't mind me using your app as a base platform.
Baggers.
Sorry for wasting your time.
The one attached here, version 002, does definately work on my set up.· Should work as is on any Hydra.· Provided you change the clock freq and pins to match as you suggested, I see no reason why it shouldn't work for your proto-boards.
I'll be interested to hear from anyone who gets it to work with a brief description of the set up.· In particular mine is a multimode TV, so I'd like to hear from anyone with a good old fashioned NTSC only set.· Also anyone who tries it with a LCD, plasma or·HD.
Baggers, sure you can use it for whatever you like.· Just as I made use of the Parallax TV driver and the COP·GFX driver source in creating it.
Bear in mind though that it was written as a learning aid, not as a real driver.· The·proper drivers have code in them to recalculate parameters on the fly.· Here all the parameters are explicit constants.· So someone won't be able to make it work on a PAL TV just by toggleing a bit in the parameter block for example.· Nevertheless, if you're wanting to write a new TV driver, you could do worse than build up from this.· Getting·a driver·to actually display anything for the first time is the hard part.·
Post Edited (CardboardGuru) : 4/27/2007 3:17:46 PM GMT
Keep up the good work...
Thanks...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Living on the planet Earth might be expensive but it includes a free trip around the sun every year...
Experience level:
[noparse][[/noparse] ] Let's connect the motor to pin 1, it's a 6V motor so it should be fine.
[noparse][[/noparse] ] OK, I got my resistors hooked up with the LEDs.
[noparse][[/noparse]X] I got the Motor hooked up with the H-bridge and the 555 is supplying the PWM.
[noparse][[/noparse] ] Now, if I can only program the BOE-BOT to interface with he Flux Capacitor.
[noparse][[/noparse] ] I dream in SX28 assembler...
/Bamse
I compared the new spreadsheet with my old .PDF to check for differences (there were none), and noticed that some comments were not converted.
So here is also a new .PDF of the spreadsheet page.
Mahjongg.
Re: .xls There is always Open Office!
Works on all my NTSC televisions, new and old.
Edit, here is one that runs at 80 pixels horizontally. It's the same image, roughly, just prep for a low resolution, high color depth bitmap exercise.
Post Edited (potatohead) : 4/28/2007 8:38:07 AM GMT
Andre'
if only work hadn't just stepped up a gear, always the way, they do like to spoil fun lol
Baggers.
Having some trouble parameter passing though. I've attached the ROM bitmap code. Works great. If you put in an absolute address in memory, it's happy to display it on screen. Some locations are too dark, which confuses the TV. (sync colors) That's hi-tv.spin. If you just run it, you can set tvpointer to some address, like $c100 and will see the ROM bitmap representation on screen.
The simple high_color_demo.spin should point the hi-tv code to a location in ram, then fill it with some simple values to see the bitmap works. It doesn't, meaning I'm missing some basic thing... Or a combination of things, because I can put an absolute address in the cognew, and it works the same way it does just doing the same in the driver.
Hints anyone?
Post Edited (potatohead) : 5/1/2007 2:51:34 AM GMT
Also, on your parameter passing. FIRST, make sure you understand HOW to do DEAD COLD. So just make something that blinks the led with a parameter, then try and make sure you can read local cog memory with a POINTER and self modifying code, then make sure you understand how to access global memory from the COG, then you will have all these memory things and parameter passing and you can deal with the graphics and timing stuff.
Everytime I code in ASM on the propeller, the instructions are confusing for accessing memory, the source and destination seems backwards, plus there is are no pointers, so you have to use self modifying code which can be very confusing.
So the best way to do this is know all the pieces cold, then merge them together for somethnig really simple.
Andre'
I find the prop assembly backward too. I keep a card handy to sort out source and destination. The self modifying bit isn't giving me too much trouble as I've done that plenty of times before on older 8 bit CPU's. I really like the assembly though. It's different, but it's also quite powerful. No longer term worries there.
Funny you mention the LED one. That's where I'm headed, when I get my next chunk of prop time.
As for the whole build from scratch bit, there is some fun in that and some understanding that comes along for the ride. I've some very specific graphics output ideas (software generated display stuff), that I have always wanted to explore. So this level is just fine for now.
I worked with this over the weekend and have timing questions. I now know why the Parallax TV driver interlaces the color --it's the partial scan line that differentiates even and odd frames. Lose that and the color will be stable line after line, allowing artifacting, etc...
That was a biggie for me. You started with the color clock and built upward and that's been helpful in a lot of ways.
As you develop your sprite driver, using this as a base, are you going to include the half scan to get interlaced color and the higher resolution possible with that? If you load and run your early DK demo, the interlaced color makes 256 pixels per line look good. This one will have that old computer look. (it's a look I'm after for other reasons) Visually it will not be as sharp.
One other thing I don't quite get. Your demo was at 256 pixels, yet the number of real color clocks (cycles of the NTSC colorburst) is more like 160 pixels for the area you defined as user graphics area? Doesn't that mean some pixels will render at different colors, or be different sizes, depending on their horizontal position?
If one color cycle is subdivided into 16 clocks, with one of those clocks being the basis for the driver timing, then building a display with 10 clocks per pixel seems too high. You get more pixels, but lose color precision, or.... and that's my question essentially for now.
What I'm after is a display where one pixel exactly equals one NTSC color cycle. This driver, programmed at 160 pixels appears to deliver that, but after comparing the results of it's output to yours, I'm still wondering why yours does not output color artifacts!
(the 80 pixel thing was a simulation of the old Atari GTIA mode. I had them both up on the screen for comparison, pixel size, etc... I'm probably going to go with the 160 or so for an overall balance between memory and color depth and build from there.)
Andre, the paramter passing is working. Was working as was the assembly language bit to display the bitmap. The trouble is with the array used to define the screen... For some elementary reason, it was not filling with values. I'll deal with that during my next session... Thanks for the review tip. Put me where I needed to be where troubleshooting goes.
So I don't have any intention of changing either for this project. And for SimpleNTSC, probably the most I'll do is add a comment about it if I do a future release.
I did wonder what the 80 pixel mode you came up with was for. Best I could imagine was that you were trying to recreate an illuminated disco dance floor.
I've had similar problems with parameter passing and addresses. All the bloody time in fact. That's another thing I haven't taken the time to understand properly. But I'm sure it'll all become second nature after a while.
Post Edited (CardboardGuru) : 4/30/2007 11:17:01 PM GMT
Turns out my trouble above all came down to a repeat command in the TV cog that prevented other statements from executing. Don't know how it got in there, nor how come it took so many )(&)(&$^#^! times to catch it, but it's caught. So the pointer stuff and assembly was good! Guess that's nice to know...
I'll be posting a 160 x 192 driver hi-color driver here soon. That's ~30K single buffered. Should be pixel perfect hi-color graphics... Looks like there is time for pixel packing, so maybe 64 color displays might make better sense. One could get 6 pixels per long, resulting in a bitmap that's somewhere around 22K for single buffered screen.
Edit, I've attached the 80x192 bitmap driver. It's useful for toying with color, etc... I am curious as to the timing. It looks great on my televisions, does it work on other monitors? If you've an LCD, run this please! Deleted the ones above...
Post Edited (potatohead) : 5/1/2007 2:53:26 AM GMT
i am a newbie and i would try to use this driver with pal tv. I have modified the following parameters in driver:
NTSC_color_frequency,NTSC_hsync_clocks,NTSC_control_sygnal_palette according to the TV.driver paramaters by parallax, for pal systems.
I have tried to compile and test but the generated sygnal is not good.
Any suggestions ?
Thanks.
And PAL stands for Phase Alternating Line, which means that it changes the phase of the colour signal on every other line. I didn't investigate this myself, but presumably that's what the "phaseflip" stuff does in the parallax TV driver. So you'd need to investigate that. And write some more code to implement it in SimpleNTSC.
Actually, I have a feeling that Baggers might already have made a PAL version of this driver, so he may be able to supply the mods needed.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Help to build the Propeller wiki - propeller.wikispaces.com
I haven't tried putting my driver in DodgyKong however, because most ( all the TV's I've had in the UK for the past 15 years ) have the ability to display the image from an NTSC signal. I just modified the parallax drivers for ease I guess, as it has the ability to change from PAL to NTSC at the change of a CON.
rt1k, what exactly is it your after?
However what i need is a driver to address any pixel within one of the 63 colors available, to create small images and display it on TV system or VGA.
Thanks.
Also what res are you thinking of using? since you have so little ram and each pixel takes one byte.
Baggers.
So, does that mean a small portion of a high resolution screen, or larger portions of a lower resolution screen?
Both can be done on the Prop. The latter involves just establishing a solid display signal for your target device, and choosing a resolution that is appropriate. 160x96 is half the RAM, BTW, when addressing each pixel individually.
Higher resolutions consume all the RAM quickly, so let's say a third of the RAM ends up being dedicated to the small images. What's gonna happen to the rest of the screen? Will it be text, tiled display, what?
In this scenario, you are likely to have to combine driver concepts to arrive at one that does the display you want, using a mix of the high-color mode, tiles and perhaps 2 or 4 color modes. There will be some timing considerations involved in this:
one set for the core signal (VGA, PAL, etc...)
another set for the scanlines, pixel sizes, tiled display, mix of color modes.
Will elements of the display be static? Are they repeatable? If text, will the ROM character set suffice?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
yes the idea is to mix (if this is possible) low color zone & hi-color zone for the graphics area.
The project requires zones of the display @ 1 color mode (buttons & text), other zones (icons and images) with more colors, tiles could be reused to reduce memory usage.
The output should use the VGA@320x240.
@Baggers: if the propeller ram is not enough i think to use the HX512 by Nurve.
@potatohead : tiles could be reused, rom characters will be used.
The propeller is used only as a display controller so i think to have a lot of free cogs, an 8 bit mcu (Microchip PIC) uses a serial interface to send commands to change icons and text to the propeller.
Data, images and texts are stored in external i2c EEprom, connected to the propeller.
Thanks.
rt1k
I think you should really start off with something a little simpler, not something so above your coding skills.
Either that or it's time to do some reading up on the net on vga signal timings, and look through the parallax VGA display examples, that's probably your best starting point,
Then work on getting their drivers to display a 320x240 tile mapped image.
Then start adding the HX512 for a large bitmap area. ( not forgetting that 320x240 is going to be over the 64K fast random access area when you come to modify the screen ram )
So there's lots of work ahead for you, with this project your doing, so just take your time, and start from the beginning, taking small steps as you go.
Good luck, and keep us all posted on how it goes.
Baggers
After reading this thread about 1000 times and reviewing the code 2000 times I finally managed to understand the NTSC drivers...
I first primed with Andr