Nice idea on the old code. I'll take that spin file and make it part of the forward process.
You showed me a lot of useful things. Appreciated.
Edit: You have a good TV for testing. Mine are either very old (and won't render 80 no matter what), or very new / high end, or capture device. Not exactly good for display quality / sync testing.
I put the status on the top post and will keep it updated there. Won't be very long and the color text release archive will be done. This memory mapping scheme will work, meaning things can be written to this WIP and still work fine in the final.
Before moving on, I'm doing some code infrastructure changes that will permit run time parameters. Changing color palette, color mode, interlace mode, etc... will be possible to do without restarting the driver.
The TV cog isn't going to do 80 characters in multi-color mode at 80 Mhz, but it will do it in two color mode at 80 Mhz. So, that option is going in! Monochrome, or two color per screen text, 80 characters per line @ 80Mhz. I've also made Eric's suggestion an option. Color burst can be on or off, and interlace can be on or off. See the two screen captures for an idea of what this means at high character densities.
I'll upload an archive and update the top post with functionality notes soon.
OBC: The 80x25 character display at 96MHz was nice but a bit of shimmering on my 9-10yr old TV (Panasonic High Definition - expensive at the time). Certainly the quality is not bad for a CPM output (hobbyist).
We are certainly getting some nice code becoming available. Thanks again Doug (potatohead)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
I saw the shimmering too. There are trade offs with composite video. After viewing various combinations, I decided to include the various signal options so that people can get a display they can live with. Based on what I've learned, from the code help and some testing, here's the revised spec I'm working from:
Color options will be:
The two color one is a simple matter of clock speed and low memory foot print. All that is needed is the text display buffer and a few longs to handle the details of display graphics generation. Small, and fast. A single long holds the color value and can be updated from outside the driver. If the mouse pointer ends up in there, this long will also hold those colors. (done), CORE
Color cell mode uses 1 additional byte per character, and references a 16 color palette that can also be updated outside the driver. One nibble is background, the other is foreground. (in process), CORE
The signal options will be:
S-video toggle. For those who have wired up that circuit, this one will render the color text at high character densities in the most pleasing way. I can't wait to try it. (not coded yet)
Interlace Toggle. That's scan doubling or not. Depending on your display device you may or may not like that one. Lower contrast colors can reduce the shimmer, as can rolling the sharpness off on the TV. (done), CORE
Color Burst Toggle. Eric had a great suggestion and I'm glad I checked it out. This one simply does not send the color reference signal, leaving everything else unchanged. The TV will behave as if it's a black and white signal. Some TV's will open up their bandwidth for this, rendering sharper text. This one, with monochrome colors looks monitor perfect on most of my devices. (done), CORE
There is one more toggle and I don't know whether or not I will be able to do that one. In non-interlaced mode the driver right now does not interlace the color. Color cycles are fixed in relation to the pixels, and staggered, which actually looks good. The simpler way seen in other drivers also fixes the color clocks in relation to the pixels, but didn't stagger them. Effective resolution is 160 - 256 pixels, depending on your tolerance for artifacts. Staggered color cycles looks higher than that, even though it really isn't. That's the mode that OBC was liking.
(on a monochrome display device, the difference between these two is vertical bars -vs- a checkerboard pattern seen where colors would be seen. The interlace would be a moving checkerboard.)
So the last signal toggle is to not interlace the display vertically, but continue to interlace it horizontally. What this will do is increase the frequency of the shimmer from the 15 Hz it's at now (the result of both interlaces happening is 60 / 4 = 15) to 30Hz. This is what the C64 does, for reference. I'm gonna try it, but really am hoping I can snag a bit of Eric's time to understand better how to do it. (if doing this doesn't break a lot of other things, it's gonna get done)
The final display mode options will be:
Multiple character per line settings, up to 80. Not sure if faster props could do more, but then again, I don't think it matters. 640 pixels is at the upper limit for TV graphics anyway. 16, 32, 40, 64, 80 are the target settings as those divide evenly into the clocks per scan line value I'm using. (done), CORE
Two color mouse pointer, driven from X, Y, pointer index. (not coded yet, but not looking all that tough)
Clock will be 80Mhz+ Lower clocks might work at 40 characters, or maybe something lower, like 32, but I'm not really going to test below 80Mhz.
Memory options:
1 byte per character screen memory, necessary
1 byte per character color memory, optional
16 longs color palette, optional
80 long pixel buffer
160 long color buffer, optional
8 bytes per character font table, up to 256 characters.
If implemented, 16 bytes per mouse pointer table, multiple pointers, optional.
Cluso showed me some tricks and made me think a bit differently about timing. IMHO, the core stuff will fit into two cogs. Damn cool, considering my initial expectations. [noparse]:)[/noparse] All in all, that's pretty close to what I started out doing.
Right at this moment, I'm double buffering the color and breaking things. That's needed to get color building over several scans. The next working build will get posted here.
Cluso99, the same resistors and circuit work for S-video. All you do is not connect the start_pin+3 resistor to the others. Run it as a seperate signal to the chroma pin of an S-video receiver and send the rest in the Luma pin. This will probably be the best color display option. Only three pins are needed in either case. Since you were short on pins anyway, thought you might appreciate that.
Really nice. Lots of options to try for a good display.
I like the S-Video option - I wil chech that out also as I have an S-Video input.
Currently I am interstate (on our boat), so presuming I get the time I will check this out on our LCD here. It is VGA 1024x748 with video in, S-video in, and inbuilt analogue tuner.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
That video capture device also has S-video input, so I'm also looking forward to that option.
(I didn't realize that it was that easy to do the interface.)
Do I understand correctly that these video options will be changeable on the fly?
Folks would be able to pick which video mode works best for them with things like PropDOS. Awesome.
Yes. I want it to work just like a graphics chip does in an 8 bit computer. You twiddle a memory location and stuff happens. I've spent the last coupla days getting the code for that working. Mostly tweaking the driver code to respond to the option changes. The options are there now and working nicely, just need to update them from the HUB during VBLANK and that's done. Once the display is running, the code that ran it can be erased, leaving just the buffers and parameter longs. I would have posted it, but for a day or two spent tinkering with getting "C64 signal mode" to work the way I want. That will get set aside for a bit as it can be done later on. I'm close, but just don't understand the relationship between the color burst and pixels well enough. I should by now, but just don't yet. (grrr...)
This weekend I'm going to code out the CORE stuff, get color cells running and hopefully post a Rev 1.0. From there, feature function changes will only add to that, meaning that archive can be used to build stuff with few worries about additions. Rev 1.0 stuff won't change. That revision is just text, and colors. I'm sure the mouse will fit, but am leaving it alone until the color cells are done. I've no plans for a third COG at the moment.
It then will be possible for a SPIN program to call out 40 characters with color cells, redefine some of the font characters, or change fonts, do some stuff, call out 80 characters, interlaced monochrome, do some stuff, then switch to 64 characters, putting the font back, in two color mode, do stuff, etc... without re-launching the video driver. Future functions, like the mouse pointer, or new signal options, will build on that and just be an additional long or two for controls. Most everything on the fly will happen with just a change to a long. Changing characters per line takes a little math. I'll probably keep that in SPIN and just make a short and sweet procedure that can be called to do that. Copy paste into your code and call it good. At that point, it will be time to start porting over TV_Text and the other goodies that operate with AiGeneric, and we should be off to the races with better text! Not far now.
S-Video: I was surprised it was easy too. All that really happens is color gets moved from start_pin+1 to start_pin+3. The same resistor is used on both pins on the Parallax reference designs, and pin 4 goes unused most of the time. Could cut a trace and solder a cable.... [noparse]:)[/noparse] I think I'll just breadboard a circuit though and run a test. Eric brought up the S-video mode won't have the super saturated colors seen in the composite, but it won't have artifacting either. Nice trade-off, IMHO. Eric mentioned the spec being 400 lines. If so, that's a considerable improvement over composite and it's 200 lines or so. (that's where the 15 Hz or 30Hz shimmering comes from)
It's taking me a while to sort out the color. Color indirection is just costly.
To get font pixels on screen, it's fetch, shift, add, fetch, write.
To get the color with the byte scheme, it's fetch, move, mask, add, fetch, mask, add, fetch, combine, write. Ugh...
To get color with a word scheme, where color values are used directly is faster. fetch, add, mask, write. Color longs maybe fetched with the TV cog, at the cost of 7K+ RAM. Not gonna go there.
So which is worse? RAM or a COG? With the third COG, the byte scheme will fit. Without it, I think there is going to have to be a RAM cost, maybe double the color cell memory. Words -vs- bytes.
Good news is the mouse pointer isn't HUB access heavy when drawing. That's going to fit into the text cog fairly easily no matter what, leaving just the color cells to consider. So that is the question! Is color worth a third COG to save RAM, if there isn't a way to distribute it over 8 scans that makes sense?
I'll think on it a bit, and do some more speed / time tests to see exactly what I have to work with.
Ok, I've slept on this and have decided to go with color words for the moment. Most of the choices I came up with were either convoluted, or time consuming, or made too many display trade-offs to be useful.
That is the most likely option that will get the driver 1.0 done. Other choices can happen from there. Maybe do a color cog at that time as an option, depending on the needs of whatever wants to display some text.
potatohead said...
So the last signal toggle is to not interlace the display vertically, but continue to interlace it horizontally. What this will do is increase the frequency of the shimmer from the 15 Hz it's at now (the result of both interlaces happening is 60 / 4 = 15) to 30Hz. This is what the C64 does, for reference. I'm gonna try it, but really am hoping I can snag a bit of Eric's time to understand better how to do it. (if doing this doesn't break a lot of other things, it's gonna get done)
I think a lot of what you are looking for has it's origins in the relationship between colorburst and line timing.
Now, NTSC colorburst (unlike PAL) is pretty easy. It's a free-running 3.5795MHz clock signal which is inserted between the end of horizontal sync and the start of active video. The TV uses this to sync a PLL which is then used to demodulate the color portion of the signal. This also explains why a pixel clock of close to 7.159MHz will cause color artifacts - light/dark/light is equivalent to 3.57MHz.
The free running clock is easy on the Propeller - it just PLLA, with a frequency of 57.2727MHz. The color selection circuit divides that by 16 for phase selection.
Okay, that's the frequency domain, but the time domain is where things get interesting. The nominal NTSC line period is 63.555us, which works out to 227.5 cycles of colorburst. So, in this case, the phase the colorburst shifts by 180 degrees with respect to the previous line. So a colored pixel which was high, low, high (in the time domain) on one line would become low, high, low on the next line. Frame-to-frame phase therefore depends on the number of lines. Interlacing (because of the half line) introduces a 90 degree phase shift.
Again, on the Propeller, this is handled by making sure there are 3640 PLLA cycles per line.
PAL is weird because the phase of colorburst (and the colors) is inverted every line. So for one line colorburst is 135 degrees and the color phase is a positive shift from burst, then the next line colorburst 225 degrees and color is a negative shift from burst. PAL is also much pickier on the number of lines and how interlacing is done.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Composite NTSC sprite driver: Forum
NTSC & PAL driver templates: ObExForum
OnePinTVText driver: ObExForum
Given that, I thought I could just have an odd number of scan lines per frame, non vertically interlaced. Didn't work. The phase relationship appears to be keyed to the scan line being either even or odd. I'm not sure where that fixed relationship is coming from. It's almost as if something other than the timing of the scan line is not quite as it should be. Not to pick on your excellent and very much appreciated work, but ???
If I can get this, I've got all I need to generate any signal characteristics I want to. [noparse]:)[/noparse]
There is one upside to how it works now and it was unexpected. With the color phase relationship stable on a frame, but offset every other scan line, implied resolution is still higher than it is with Atari style video, where that relationship is the same on every scan line. From my testing, the Atari style stuff breaks down into heavy artifacts somewhere around 256 pixels. (and that's debatable actually) With it running how it is now, that same breakdown happens around 320+ Nice, and something I didn't consider, but that I like a lot.
The down side is artifcating makes little sense, but if that's the goal, then it's kind of easy to do. I want to keep that signal option on the table, and add the full horizontal color interlace as well. That way people can make the most of whatever display device they happen to have. Nice perk that comes from software control of the video signal.
So then, there are 4 basic ways to do this for a non-vertically interlaced screen.
Fixed color phase relationship every scan, Atari Style. (I think I can do this with your template code --I've not tried it as it does not apply to this project, but I know the timing for this from my earlier work in this area.)
Fixed, but staggered phase relationship, as it currently runs now. (I've not seen any video system do this actually.)
Alternating every other frame. (C 64 style)
No color burst.
Add to that an offset from the reference, and you get a nice tint control. I'll probably add this, with some limits on change per frame. I toyed with this last night and the result of that was favorable also. Possible to get a nice red, for example, at the expense of some other colors, just like turning the tint knob. I don't see a downside to this, as all my display devices rendered non standard color burst just fine.
I'm close... if you have the time, a hint on the C64 style timing would be appreciated [noparse]:)[/noparse] I've a scope now. (thanks to you know who you are) Tonight I'm gonna go look at the various signal bits to see if that doesn't help me sort this out. At the least, I've been itching to use it. Now's the time! Maybe I'll just see it.
BTW: I absolutely loved expressing everything in terms of PLLA / pixel / scan. This cured a whole lot of timing problems I had before. Thanks for that. I'm having a good time, but for nailing down this pesky bit. I normally would let it pass, but it actually matters a lot where text displays are concerned. There are enough different displays out there that I think it's worth it to just have all the signal options in place for best use case. At the very least, I'll have the framework done for some very nice graphics oriented scan-line drivers.
---> Not sure if others here got the 2600 PLLA in the template default color bar configuration, but I did. [noparse]:)[/noparse]
Here's an archive with color cog disabled. You need to have two_colors set in the main program, because the color cog isn't running.
I've put in a little demo loop, showing the nice live signal options. Characters per line, the two screen colors in use, interlace, color burst are all now active at all times.
Parameters are refreshed during VBLANK, so that the next frame is stable and drawn cleanly.
Color work is in progress.....
DANG!! I can't seem to attach anything. So, it's been mailed to OBC. I can be contacted at opengeek@gmail.com. OBC asked for an update, so he got one. When I can attach later, I'll do so.
What are the kinds of things needed? And can they just be some callable spin procedures located where the Demo procedure is now? I've forgotten how font.redefine was done, can you link me to the code you are thinking of?
OBC, I think what I am going to do is clean up the code released here, so that all the variable names and locations make good sense.
From there, the top SPIN file will start the driver and contain a little library of functions. That should be really easy. The Demo procedure will go away, and be another SPIN demo program that calls the driver, like PROPDOS would.
I'm thinking of some stuff like: scroll_up, scroll_down, printstr(x,y, string, colornum, colornum), cleartext(num), clearcolors(num,num), setcolor(x,y), chars_per_line(16,32,40,64,80), set_mode( something ), etc...
I'll get the cleanup done, and build out a few library functions. From there, adding new ones should be pretty easy.
The character redefine one you asked for isn't tough, and I thought of another way to do that.
Then just call block_define(character_num, @smiley), to define one character with the happy face. Later, if you want the other one, you just call it again, with @unhappy. All the routine needs to do is multiply character_num * 8, add to the address of the font, then block memory copy in the 8 bytes, and the character is done!
IMHO, for text, the library of functions can all be SPIN. They will be plenty fast enough.
Also, if there is a VBLANK latch, they will only draw when the screen is blanked, so there won't be tearing or flicker, meaning a single buffered screen would work out for most common things.
Well, there is no reason why that one can't be done. Where I was going with the block_define is spin programs that want custom characters. Very easily done, low overhead, etc...
Comments
Postedit: 80 characters & 96MHz running
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade, RetroBlade,·TwinBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index) ZiCog (Z80) , MoCog (6809)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
Post Edited (Cluso99) : 9/22/2009 7:48:42 AM GMT
Nice idea on the old code. I'll take that spin file and make it part of the forward process.
You showed me a lot of useful things. Appreciated.
Edit: You have a good TV for testing. Mine are either very old (and won't render 80 no matter what), or very new / high end, or capture device. Not exactly good for display quality / sync testing.
I put the status on the top post and will keep it updated there. Won't be very long and the color text release archive will be done. This memory mapping scheme will work, meaning things can be written to this WIP and still work fine in the final.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net
Safety Tip: Life is as good as YOU think it is!
Post Edited (potatohead) : 9/22/2009 4:04:46 PM GMT
The TV cog isn't going to do 80 characters in multi-color mode at 80 Mhz, but it will do it in two color mode at 80 Mhz. So, that option is going in! Monochrome, or two color per screen text, 80 characters per line @ 80Mhz. I've also made Eric's suggestion an option. Color burst can be on or off, and interlace can be on or off. See the two screen captures for an idea of what this means at high character densities.
I'll upload an archive and update the top post with functionality notes soon.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net
Safety Tip: Life is as good as YOU think it is!
Post Edited (potatohead) : 9/24/2009 4:35:34 AM GMT
This driver just keeps getting better and better! [noparse]:)[/noparse]
What are the chances that you might be able to add a plot(x,y) and related
pixel graphics commands?
OBC
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
New to the Propeller?
Visit the: The Propeller Pages @ Warranty Void.
Text, single color character cells, and mouse pointer first though. [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net
Safety Tip: Life is as good as YOU think it is!
Post Edited (potatohead) : 9/25/2009 12:09:57 AM GMT
We are certainly getting some nice code becoming available. Thanks again Doug (potatohead)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade, RetroBlade,·TwinBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index) ZiCog (Z80) , MoCog (6809)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
Color options will be:
The two color one is a simple matter of clock speed and low memory foot print. All that is needed is the text display buffer and a few longs to handle the details of display graphics generation. Small, and fast. A single long holds the color value and can be updated from outside the driver. If the mouse pointer ends up in there, this long will also hold those colors. (done), CORE
Color cell mode uses 1 additional byte per character, and references a 16 color palette that can also be updated outside the driver. One nibble is background, the other is foreground. (in process), CORE
The signal options will be:
S-video toggle. For those who have wired up that circuit, this one will render the color text at high character densities in the most pleasing way. I can't wait to try it. (not coded yet)
Interlace Toggle. That's scan doubling or not. Depending on your display device you may or may not like that one. Lower contrast colors can reduce the shimmer, as can rolling the sharpness off on the TV. (done), CORE
Color Burst Toggle. Eric had a great suggestion and I'm glad I checked it out. This one simply does not send the color reference signal, leaving everything else unchanged. The TV will behave as if it's a black and white signal. Some TV's will open up their bandwidth for this, rendering sharper text. This one, with monochrome colors looks monitor perfect on most of my devices. (done), CORE
There is one more toggle and I don't know whether or not I will be able to do that one. In non-interlaced mode the driver right now does not interlace the color. Color cycles are fixed in relation to the pixels, and staggered, which actually looks good. The simpler way seen in other drivers also fixes the color clocks in relation to the pixels, but didn't stagger them. Effective resolution is 160 - 256 pixels, depending on your tolerance for artifacts. Staggered color cycles looks higher than that, even though it really isn't. That's the mode that OBC was liking.
(on a monochrome display device, the difference between these two is vertical bars -vs- a checkerboard pattern seen where colors would be seen. The interlace would be a moving checkerboard.)
So the last signal toggle is to not interlace the display vertically, but continue to interlace it horizontally. What this will do is increase the frequency of the shimmer from the 15 Hz it's at now (the result of both interlaces happening is 60 / 4 = 15) to 30Hz. This is what the C64 does, for reference. I'm gonna try it, but really am hoping I can snag a bit of Eric's time to understand better how to do it. (if doing this doesn't break a lot of other things, it's gonna get done)
The final display mode options will be:
Multiple character per line settings, up to 80. Not sure if faster props could do more, but then again, I don't think it matters. 640 pixels is at the upper limit for TV graphics anyway. 16, 32, 40, 64, 80 are the target settings as those divide evenly into the clocks per scan line value I'm using. (done), CORE
Two color mouse pointer, driven from X, Y, pointer index. (not coded yet, but not looking all that tough)
Clock will be 80Mhz+ Lower clocks might work at 40 characters, or maybe something lower, like 32, but I'm not really going to test below 80Mhz.
Memory options:
1 byte per character screen memory, necessary
1 byte per character color memory, optional
16 longs color palette, optional
80 long pixel buffer
160 long color buffer, optional
8 bytes per character font table, up to 256 characters.
If implemented, 16 bytes per mouse pointer table, multiple pointers, optional.
Cluso showed me some tricks and made me think a bit differently about timing. IMHO, the core stuff will fit into two cogs. Damn cool, considering my initial expectations. [noparse]:)[/noparse] All in all, that's pretty close to what I started out doing.
Right at this moment, I'm double buffering the color and breaking things. That's needed to get color building over several scans. The next working build will get posted here.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net
Safety Tip: Life is as good as YOU think it is!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net
Safety Tip: Life is as good as YOU think it is!
Really nice. Lots of options to try for a good display.
I like the S-Video option - I wil chech that out also as I have an S-Video input.
Currently I am interstate (on our boat), so presuming I get the time I will check this out on our LCD here. It is VGA 1024x748 with video in, S-video in, and inbuilt analogue tuner.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade, RetroBlade,·TwinBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index) ZiCog (Z80) , MoCog (6809)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
That video capture device also has S-video input, so I'm also looking forward to that option.
(I didn't realize that it was that easy to do the interface.)
Do I understand correctly that these video options will be changeable on the fly?
Folks would be able to pick which video mode works best for them with things like PropDOS. Awesome.
OBC
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
New to the Propeller?
Visit the: The Propeller Pages @ Warranty Void.
This weekend I'm going to code out the CORE stuff, get color cells running and hopefully post a Rev 1.0. From there, feature function changes will only add to that, meaning that archive can be used to build stuff with few worries about additions. Rev 1.0 stuff won't change. That revision is just text, and colors. I'm sure the mouse will fit, but am leaving it alone until the color cells are done. I've no plans for a third COG at the moment.
It then will be possible for a SPIN program to call out 40 characters with color cells, redefine some of the font characters, or change fonts, do some stuff, call out 80 characters, interlaced monochrome, do some stuff, then switch to 64 characters, putting the font back, in two color mode, do stuff, etc... without re-launching the video driver. Future functions, like the mouse pointer, or new signal options, will build on that and just be an additional long or two for controls. Most everything on the fly will happen with just a change to a long. Changing characters per line takes a little math. I'll probably keep that in SPIN and just make a short and sweet procedure that can be called to do that. Copy paste into your code and call it good. At that point, it will be time to start porting over TV_Text and the other goodies that operate with AiGeneric, and we should be off to the races with better text! Not far now.
S-Video: I was surprised it was easy too. All that really happens is color gets moved from start_pin+1 to start_pin+3. The same resistor is used on both pins on the Parallax reference designs, and pin 4 goes unused most of the time. Could cut a trace and solder a cable.... [noparse]:)[/noparse] I think I'll just breadboard a circuit though and run a test. Eric brought up the S-video mode won't have the super saturated colors seen in the composite, but it won't have artifacting either. Nice trade-off, IMHO. Eric mentioned the spec being 400 lines. If so, that's a considerable improvement over composite and it's 200 lines or so. (that's where the 15 Hz or 30Hz shimmering comes from)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net
Safety Tip: Life is as good as YOU think it is!
Post Edited (potatohead) : 9/25/2009 3:49:16 PM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade, RetroBlade,·TwinBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index) ZiCog (Z80) , MoCog (6809)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
To get font pixels on screen, it's fetch, shift, add, fetch, write.
To get the color with the byte scheme, it's fetch, move, mask, add, fetch, mask, add, fetch, combine, write. Ugh...
To get color with a word scheme, where color values are used directly is faster. fetch, add, mask, write. Color longs maybe fetched with the TV cog, at the cost of 7K+ RAM. Not gonna go there.
So which is worse? RAM or a COG? With the third COG, the byte scheme will fit. Without it, I think there is going to have to be a RAM cost, maybe double the color cell memory. Words -vs- bytes.
Good news is the mouse pointer isn't HUB access heavy when drawing. That's going to fit into the text cog fairly easily no matter what, leaving just the color cells to consider. So that is the question! Is color worth a third COG to save RAM, if there isn't a way to distribute it over 8 scans that makes sense?
I'll think on it a bit, and do some more speed / time tests to see exactly what I have to work with.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net
Safety Tip: Life is as good as YOU think it is!
That is the most likely option that will get the driver 1.0 done. Other choices can happen from there. Maybe do a color cog at that time as an option, depending on the needs of whatever wants to display some text.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net
Safety Tip: Life is as good as YOU think it is!
I think a lot of what you are looking for has it's origins in the relationship between colorburst and line timing.
Now, NTSC colorburst (unlike PAL) is pretty easy. It's a free-running 3.5795MHz clock signal which is inserted between the end of horizontal sync and the start of active video. The TV uses this to sync a PLL which is then used to demodulate the color portion of the signal. This also explains why a pixel clock of close to 7.159MHz will cause color artifacts - light/dark/light is equivalent to 3.57MHz.
The free running clock is easy on the Propeller - it just PLLA, with a frequency of 57.2727MHz. The color selection circuit divides that by 16 for phase selection.
Okay, that's the frequency domain, but the time domain is where things get interesting. The nominal NTSC line period is 63.555us, which works out to 227.5 cycles of colorburst. So, in this case, the phase the colorburst shifts by 180 degrees with respect to the previous line. So a colored pixel which was high, low, high (in the time domain) on one line would become low, high, low on the next line. Frame-to-frame phase therefore depends on the number of lines. Interlacing (because of the half line) introduces a 90 degree phase shift.
Again, on the Propeller, this is handled by making sure there are 3640 PLLA cycles per line.
PAL is weird because the phase of colorburst (and the colors) is inverted every line. So for one line colorburst is 135 degrees and the color phase is a positive shift from burst, then the next line colorburst 225 degrees and color is a negative shift from burst. PAL is also much pickier on the number of lines and how interlacing is done.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Composite NTSC sprite driver: Forum
NTSC & PAL driver templates: ObEx Forum
OnePinTVText driver: ObEx Forum
If I can get this, I've got all I need to generate any signal characteristics I want to. [noparse]:)[/noparse]
There is one upside to how it works now and it was unexpected. With the color phase relationship stable on a frame, but offset every other scan line, implied resolution is still higher than it is with Atari style video, where that relationship is the same on every scan line. From my testing, the Atari style stuff breaks down into heavy artifacts somewhere around 256 pixels. (and that's debatable actually) With it running how it is now, that same breakdown happens around 320+ Nice, and something I didn't consider, but that I like a lot.
The down side is artifcating makes little sense, but if that's the goal, then it's kind of easy to do. I want to keep that signal option on the table, and add the full horizontal color interlace as well. That way people can make the most of whatever display device they happen to have. Nice perk that comes from software control of the video signal.
So then, there are 4 basic ways to do this for a non-vertically interlaced screen.
Fixed color phase relationship every scan, Atari Style. (I think I can do this with your template code --I've not tried it as it does not apply to this project, but I know the timing for this from my earlier work in this area.)
Fixed, but staggered phase relationship, as it currently runs now. (I've not seen any video system do this actually.)
Alternating every other frame. (C 64 style)
No color burst.
Add to that an offset from the reference, and you get a nice tint control. I'll probably add this, with some limits on change per frame. I toyed with this last night and the result of that was favorable also. Possible to get a nice red, for example, at the expense of some other colors, just like turning the tint knob. I don't see a downside to this, as all my display devices rendered non standard color burst just fine.
I'm close... if you have the time, a hint on the C64 style timing would be appreciated [noparse]:)[/noparse] I've a scope now. (thanks to you know who you are) Tonight I'm gonna go look at the various signal bits to see if that doesn't help me sort this out. At the least, I've been itching to use it. Now's the time! Maybe I'll just see it.
BTW: I absolutely loved expressing everything in terms of PLLA / pixel / scan. This cured a whole lot of timing problems I had before. Thanks for that. I'm having a good time, but for nailing down this pesky bit. I normally would let it pass, but it actually matters a lot where text displays are concerned. There are enough different displays out there that I think it's worth it to just have all the signal options in place for best use case. At the very least, I'll have the framework done for some very nice graphics oriented scan-line drivers.
---> Not sure if others here got the 2600 PLLA in the template default color bar configuration, but I did. [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net
Safety Tip: Life is as good as YOU think it is!
I've put in a little demo loop, showing the nice live signal options. Characters per line, the two screen colors in use, interlace, color burst are all now active at all times.
Parameters are refreshed during VBLANK, so that the next frame is stable and drawn cleanly.
Color work is in progress.....
DANG!! I can't seem to attach anything. So, it's been mailed to OBC. I can be contacted at opengeek@gmail.com. OBC asked for an update, so he got one. When I can attach later, I'll do so.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net
Safety Tip: Life is as good as YOU think it is!
Post Edited (potatohead) : 9/27/2009 7:26:52 PM GMT
Anyone wire up S-video yet? [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net
Safety Tip: Life is as good as YOU think it is!
Awesome release!!! Looking forward to some more demos for this!
Could you demo font.color and font.redefine?
Looks like it's time to drop this into PropDOS. [noparse]:)[/noparse]
OBC
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
New to the Propeller?
Visit the: The Propeller Pages @ Warranty Void.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net
Safety Tip: Life is as good as YOU think it is!
Love this routine, works like the Commodore sprite routine.
Passed to the next object..
In the font file..
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
New to the Propeller?
Visit the: The Propeller Pages @ Warranty Void.
From there, the top SPIN file will start the driver and contain a little library of functions. That should be really easy. The Demo procedure will go away, and be another SPIN demo program that calls the driver, like PROPDOS would.
I'm thinking of some stuff like: scroll_up, scroll_down, printstr(x,y, string, colornum, colornum), cleartext(num), clearcolors(num,num), setcolor(x,y), chars_per_line(16,32,40,64,80), set_mode( something ), etc...
I'll get the cleanup done, and build out a few library functions. From there, adding new ones should be pretty easy.
The character redefine one you asked for isn't tough, and I thought of another way to do that.
block_define(char_num, data_address)
So, in a DAT somewhere you have this:
smiley %00000000 %01101100 %01101100 %00000000 %00010000 %10000010 %01111100 %00000000 unhappy %00000000 %01101100 %01101100 %00000000 %00010000 %00000000 %11111110 %10000010Then just call block_define(character_num, @smiley), to define one character with the happy face. Later, if you want the other one, you just call it again, with @unhappy. All the routine needs to do is multiply character_num * 8, add to the address of the font, then block memory copy in the 8 bytes, and the character is done!
IMHO, for text, the library of functions can all be SPIN. They will be plenty fast enough.
Also, if there is a VBLANK latch, they will only draw when the screen is blanked, so there won't be tearing or flicker, meaning a single buffered screen would work out for most common things.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net
Safety Tip: Life is as good as YOU think it is!
Post Edited (potatohead) : 9/28/2009 8:11:30 PM GMT
What makes the other routine for redefine interesting is that it can be called from
programs like FemtoBASIC. No DAT required.
OBC
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
New to the Propeller?
Visit the: The Propeller Pages @ Warranty Void.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net
Safety Tip: Life is as good as YOU think it is!
I'm looking forward to that polished release!
OBC
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
New to the Propeller?
Visit the: The Propeller Pages @ Warranty Void.
Does it call SPIN procedures? Can you send me a femtobasic code snippet, showing the redefine command in context?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net
Safety Tip: Life is as good as YOU think it is!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite
·
Glad you got some Prop time. It comes and goes, doesn't it?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net
Safety Tip: Life is as good as YOU think it is!
'' REDEFINE CHARACTER COMMAND: (Example: REDEFINE 224,255,195,195,195,195,195,195,255) '' '' How .redefine works: '' 224 = Character to change. (character must be in use by font) '' 11111111 = 255 (Row 1) '' 11000011 = 195 (Row 2) Design the new font row by row in binary. '' 11000011 = 195 (Row 3) Convert each row to decimal and use in '' 11000011 = 195 (Row 4) .define(CHAR,ROW1,ROW2,ROW3,ROW3......) '' 11000011 = 195 (Row 5) '' 11000011 = 195 (Row 6) Thie should look somewhat familiar to '' 11000011 = 195 (Row 7) Commodore 64 users. :) '' 11111111 = 255 (Row 8) Thank you Baggers!! 192: 'REDEFINE <char>,<b1>, rdchar:=expr skipspaces rdc1:=expr skipspaces rdc2:=expr skipspaces rdc3:=expr skipspaces rdc4:=expr skipspaces rdc5:=expr skipspaces rdc6:=expr skipspaces rdc7:=expr skipspaces rdc8:=expr dsp.redefine(rdchar,rdc1,rdc2,rdc3,rdc4,rdc5,rdc6,rdc7,rdc8)▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
New to the Propeller?
Visit the: The Propeller Pages @ Warranty Void.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite
·