Yeah, I saw that two block speed up. Nicely done! Agreed on the 5*7, which would actually make things worse, because the waitvid loop would be faster, per pixel, limiting character density.
Well, I'll go dig up my notes. I more or less tore that all down building potatotext. Since your driver is mono, you've got a lot of options on the pixel loop. Generally those timings are based off of multiples of the color burst reference.
Seems to me, a mono driver could ignore those, meaning you can shrink, or enlarge the porches to "fit" a fixed timing pixel clock onto the display. That makes some sense. Let me dig up what I've got and I'll post it up here later.
Cluso99 said...
pullmoll: I have had to remove the inverse tests when displaying more characters on the line because there is no time in the pixel display. So I have to resort to swapping the actual character. I do this in the frame timing because it is not time restricted here and it displays for a few frames at a time.
Provided your code was to put the character into the screen where the cursor will be moved to before it is moved, the driver would replace the old cursor position correctly (as long as you had not changed it because the driver would overwrite it). If I implement this, it will require a little extra thought.
re using a different waitvid section, there is really no space for this. I am trying to implement as much as possible in this driver, but half the cog is taken with the 8x8 font. There is some space to be gained by using the init section for variables, but I have my eye on this anyway. Basically, the code is now almost all mine except the actual timing & drawing, although I started from Eric Ball's code. This is the only section I do not totally understand - the actual timings and how to calculate them. Once I understand this there may be other savings, but if I find more space I would like to do a better terminal emulation within the cog.
BTW, to improve performance, it is possible to include a hub buffer just like FDX.
Ok. I think I understand the problem with tight cog memory very well. If you want to have the font in the cog RAM, you can only have a limited set of terminal emulation in the same cog. A halfway clean VT100 emulation would certainly need two cogs, one for the display action and one for the emulation. The question is if you need this. If you wanted to run CP/M via TV, a VT100 (or VT52) emulation would be a nice thing to have. Together with a PC and UART you probably have a good terminal emulation already.
Hehe.. The actual drawing code is what totally escapes me also. I just don't understand how it works. I'd have to re-read the manual section covering this quite a few times more methings.
The performance is actually ok for debugging purposes. Otherwise I really would spend it another cog to deal with the frame buffer.
Juergen
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
David: I will have a think about how to substitute your string.
potatohead: Thanks Jonathan. Here is what I understand about NTSC (and I know the differences for this part in PAL)..
NTSC has·525 lines/frame and 30 frames/sec in non-interlaced mode. Hence the line frequency would be 525*30 = 15,750Hz. 486 lines are visible.
PAL has 625 lines/frame and 25 frames/sec in non-interlaced mode. Hence the line frequency would be 625*25 = 15,625Hz. 576 lines are visible.
Now, if I understand correctly, in each line, we start with the horizontal sync, followed by the back porch, then the visible pixels, and finally the front porch.
So, I have 25 character lines of 8 pixels high = 200 visible lines (so 400 in non-interlaced terms as it is repeated - is this correct?). I also have 40 characters of 8 pixels = 320 pixels visible. I manage to get more characters/line at higher clocking.
If I have the above correct, this is where I get lost. Of the 486 lines, divide by 2 for a half frame = 243 less 200 visible = 43 for top and bottom blank lines for retrace, plus a vertical sync pulse.
I understand the horizontal and vertical sync pulses are 0V and the front and back porches are slightly positive (as in reality, the hs & vs are supposed to be negative and the porches 0V). When a visible pixel is on, the output is 1V after the voltage divider. When it is off, the counter generates a PWM voltage equivalent to the porch voltage.
How big are the porches and what are the serration pulses and their timing (I am presuming they are to do with the color, which we don't really have)?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Yes, there are 200 visible lines on every frame, non-interlaced. Non-interlaced displays repeat the frame at 60Hz, or 50Hz, depending. A 200 line display under utilizes PAL, and slightly over uses NTSC.
An interlaced display has a half-scan line inserted between frame 0 and frame 1. That puts the scan lines between one another, doubling the vertical resolution. If you want to, you can change your character pixel address decode so that it does character even scans on one frame, and odd scans on the other frame, and pack in 400 lines, for a 50 line display, but then the character aspect becomes square which is kind of good, not tall which is bad because eye fatigue may set in for those viewers not using high persistence phosphor devices. I don't know if you can even get high persistence displays for TV signals any more, but I used to have one, and interlaced on it was great. It's not so great on your average TV, which is why I didn't do it on potatotext.
I think you were missing the half-scan line on that.
Thanks potatohead. Yes I have a NTSC/PAL TV here that I was using and I could get quite a number of more rows, but 25 is a good number and was what most real videos ended up with in the 80s. My TV displays 80 colums without problems (easy to see) provided I overclock the prop.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
I've got scan timing info coming. Mrs Potatohead has a to-do list in play today...
If I understand your intent correctly, for a given xtal, there will be optimal pixel loop HUB access times. If you determine those, you can take up slack in the porches, leaving the sync alone, meaning all you really need is the total scan time-minus the sync time, which is always the same, leaving you with whatever your optimal pixel loop consumes per desired number of characters and what is left over from that for porches, each probably equal.
Yes. If I can boost the number of columns by "syncing" to the hub window then I will. While looking at the code again last night, I discovered a few more longs that can be saved.
Can you tell me, the number of blank lines top and bottom are different. Is that necessary, and if so, is something else happening here that makes this necessary? I could save a bit if they were equal.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Spent some time looking at the 1 pin code Eric wrote.
nactive LONG 240 'number of scan lines even!
nblank2 LONG 1
nsync LONG 39 ' 4.7usec << 23
nhalf LONG 267 ' 31.777usec << 23
nbackp LONG 75 ' 4.5usec << 24
nfrontp LONG 25 ' 1.5usec << 24
The number of scan lines is even, so just put your display right in the middle. You will have to alter the calculations done in the tasks for this, but otherwise no problem. Your text display might run a bit low though.
oblank1 RES 1 ' number of blank lines
oactive RES 1 ' number of active lines
oblank2 RES 1 ' number of blank lines
Those are the calculated parameters. Oblank1 is your top border, oactive is number of scans for the text area, oblank2 is the bottom border. Look at the math in the tasks for this.
The porches are shown, those are npackp and nfrontp. I don't get why one porch is so much longer than the other one... I think it's because a mono signal has no color burst. Looks to me like you can just change the porch values in nbackp and nfrontp to impact the active area. Subtract from one or the other, or both to either move, or change display area size.
nbackp LONG 75 ' 4.5usec << 24 left border
nfrontp LONG 25 ' 1.5usec << 24 right border
obackp RES 1 ' VSCL back porch (sync to active)
ofrontp RES 1 ' VSCL front porch (active to sync)
That's all I've got for now. I have to go and run this. It's an excellent bit of driver code actually.
Aha, now I understand where the timing I will look at that.
It bugged me why they (porches, top/bottom)·were different although I know they are to fit the display equally within the screen.
Here is a pic of what timing I believe is happening (and a spin file).
As I understand it, there are 3 voltages generated. The HS & VS are 0V, pixel off and the porches are ~0.25V and are generated by the CTRA in PWM mode (black), and 1V is generated when a pixel is on (white).
Are the equalisation and serration pulses going between 0V & ~0.25V ?
The timing of the blank lines and the visible lines seem to be different. There may be some advantage to save code by making them the same.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
The blank line timing really can't be different, or the frame gets hosed up, because the horizontal sweep would be inconsistent. There must be an element you are missing, or I'm wrong about that, but I don't think I am. When I have failed to keep all scan line total timings the same, I've seen tearing in the display, or flat out failure to render the frame, depending on how ugly the error was.
The norm is to simply encode a blank line as sync, optionally color, then the entire line porches and active as one big waitvid, leading right into the next one. There is no need for any complexity.
Realistically, you can make each scanline the same code, with an active portion, but just don't use it, until the real active section is reached. Your vertical frame then becomes VSYNC, followed by all the scanlines, leading into VSYNC again. Eric's driver code appears to also support an interlaced display. That's the double scan line resolution bit. That's some complexity that could be removed as well. That would involve first removing the half-scan code, then the computation for it, the logic in the frame loop that makes use of it, finally nulling the mode switch that triggers it. For text, an interlaced display, particularly a color one, running two scan lines per vertical pixel, actually looks quite good. For a debug display, that is minimal and compact, this isn't needed.
One downside to that is figuring out what that blank line will display. Either it's literally the same code, and it's got a switch to not fetch from the HUB, and just use the color black for all pixels, or there is a buffer somewhere that it displays until the real active area is reached... This is usually why it makes sense to just code the blank lines as the simplest code case, and either call them, or in line them in the frame loop. That's been my general experience anyway.
Assuming you reach a satisfactory solution to that, all scan lines then are either part of the VSYNC, or are actually scanlines.
Here is v1.05 (not on obex yet as I am still working on it)
1. Fixes a bug in all 1-pin versions including Eric's original. MOVS VSCL,xxxx· should be MOV (2 places). No effect but sync pulse and back porch incorrect for displayable lines.
2. Slightly simplified code gaining a few longs. More to come.
potatohead: I already removed the interlaced code and the double height code. Thanks for the clarification on the blank scanlines.
I have found an article on the equalisation and serration pulses which show 6+6+6 which is what Eric has used. The PAL code uses 4+5+5 and I haven't found this info anywhere yet. I am wondering if you know whether 6+6+6 would be ok for PAL too?
I have not figured the maths to get 4.7uS sync to be stored as 4129 for 80MHz. Once I work this out I expect the others will fall into place.
I am trying to keep it simple to select·screen sizes of·40*25, 64*25 and 80*25, NTSC/PAL and different xtals without incurring code space.
Postedit: As I continue to understand the actual display section, I see that the equalisation/serration/equalisation pulses occur every frame, not as I thought at every line. This means that I have the terminal code running in the Vsych and not the blank line code where it will get much more time. I will move this asap. This should improve the terminal response significantly
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
I have found an article on the equalisation and serration pulses which show 6+6+6 which is what Eric has used. The PAL code uses 4+5+5 and I haven't found this info anywhere yet. I am wondering if you know whether 6+6+6 would be ok for PAL too?
@David Jensen, there is code to move the cursor round on a VGA display. You might see mention of "VT100" in this thread, which is a standard sort of terminal from many years ago. The "escape sequences" became a standard, and even though there are lots of them www.mit.edu/~vona/MSim/vona/terminal/VT100_Escape_Codes.html, two are the most useful, clear screen, and cursor move Move cursor to screen location v,h ESC[noparse][[/noparse]<v>;<h>H
The dracblade has VT100 code, which is actually copied from the PocketTerm, which in turn was borrowed from Oldbitcollector's code. It is in spin, and consequently slower than it needs to be and also takes more memory than necessary. A VT100 emulation in pasm of 'clear screen' and 'cursor move' could be very handy.
Smile, you had it running in the HSYNC? Well cool! That nice, long porch did some good. Yeah, if you've been operating under that constraint, the VBLANK will seem like a long time. Also, if you don't make all scan lines the same, you can get a whole lot done during the top and bottom vertical porches, or borders. That's one advantage of encoding a blank scan line as just one long waitvid, in that it frees the CPU up for a lot of activity.
As for the pulses, I think you are going to have to try it to see. Often a monochrome signal from either standard will display on a device from either standard, but there are probably a few out there that are picky. No way to really know.
potatohead said...
As for the pulses, I think you are going to have to try it to see. Often a monochrome signal from either standard will display on a device from either standard, but there are probably a few out there that are picky. No way to really know.
FWIW my trusty old FBAS PAL monitor of noname brand (Orion) has no problem displaying the NTSC video signal, except that I have to adjust the vertical synchronization to the 60Hz. The top and bottom blank lines were slightly deformed, but the picture itself was clean and stable.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Yeah, that's been my experience too. I think most devices will just display either one, potentially with minor league caveats. I would deffo try it. The goal of being in spec, is contradictory with just packing stuff in for a great debug, general text display driver. There are a lot of older video game type devices that deffo do not output a clean, in spec, signal, and that stuff tends to display just fine.
I did get caught pushing color boundaries on potatotext though. Some of the very low intensity text values get seen as sync. Was pushing the number of real Propeller colors. Every device in the house would display a signal with $09 in it, but as soon as I put the driver out there, somebody popped up with a futzed display. Didn't take long to isolate the trouble, but still it could happen.
If it sees a bunch of runs, and no worries, then it's probably good, with the occasional person just electing to either run another version with a different feature set, which I would publish, if it were me, or choosing a different display device.
PAL users are kind of lucky really. IMHO, a lot of PAL gear will display PAL 60, PAL 50, NTSC 50, NTSC 60, no probs. Over here, the devices are NTSC 60 only, with a fair chunk able to display NTSC 50 (longer blanking period for games is good), and if PAL displays at all, we are lucky.
The best overall choice for Propeller stuff is a capture card type device. I've a USB one that's excellent, and will render everything right to a PC window. Only downside is 250-500ms or so of latency. Good for programming, not good for interaction. I often use that just like I would a serial terminal window.
Nice effort Cluso! This will be a killer output driver. Small, with essential features all in the cog, and 1 pin is cool. Looking at Eric's notes, he ran the thing with no resistor at all and still got a display. That's bad, for load reasons, but good in that it's just not that tough to get the output in a pinch!
I was not understanding the values loaded into VSCL, but had not realised (remembered) it was in fact two values being loaded at once, the pixel and frame clocks. Now when I subtract the 4096 (1 pixel clk) it gives me the frame clocks. Some of these do not appear correct but I can now decipher them.
Now to delve into the VSCL a little more to see if it actually decrements as perhaps I could load just the lower 9 bits of the frame clocks by using movs vscl,#xxxx as so far all values are less than 512. I note the total blank line is 33+195+230=458 which still seems wrong
If I can use movs then I can use immediate values which saves quite a few longs for those larger values with 1 pixel clk set ($1_000)
The bug I reported in the post above using MOVS quite probably proves my point that VSCL is actually not decremented and that in fact it will work and keep pixel clk = 1
Looks like I can use the equalisation loop to do the equalisation and serration loops with a couple of movs instructions preceeding the call. Some more instructions shaved where time is not an issue.
I may end up getting enough space to fit a poormans VT100 into the cog yet!
pullmoll: That link is great thanks Jurgen. Much cleaner if I am recisely to spec and as you said, most sets with PAL have also been·NTSC compatible for years. Postedit: The link·for the timing clears a lot of things up - thanks again!
Postedit: I would not connect to a TV without a resistor as you could overdrive the TV. See my cable with the resistor mounted at the TV plug end (link on top thread). I have done the same for the keyboard, so a full debug terminal takes 2 pins and 2 cogs.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
I have updated the top post with a list of features.
Adds spin methods for home, clear, gotoxy and cr.
Question: I supported chr(0) for clear screen and added chr(24) also. However, all I have seen here use chr(0) although it was common years ago to use chr(24). I may need the space, so...
Should I remove chr(24) ??? or chr(0) ? or leave both ?????
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Based upon the work of Eric Ball and help from potatohead.
The following are the signals and timings used to generate the 1-Pin TV in non-interlaced mode. The frame really starts with the front porch, but it is easier to treat the front porch at the end of the line/frame.
We only use·3 output voltage levels...
0V······actually ~-0.3V and is a negative sync pulse and I will refer to it as (-)
~0.3V·actually OV for black and we generate this from CTRB by PWM and I will refer to it as (o)
~1V····actually ~0.7V for white pixel dot and I will refer to it as (+)
The frame begins...
Note: 1.5us (o) ofrontp··Front porch and we·generate this at the end of the frame
6 Equalising Pulses (total time = 3 lines @ 63.555us)
4.7us (-) xequal
27us· (o) xequalh
6 Serration Pulses (total time = 3 lines @ 63.555us)
27us ·(-) xsynch
4.7us (o) xsync
6 Equalising Pulses (total time = 3 lines @ 63.555us)
4.7us (-) xequal
27us· (o) xequalh
We are now at the end of line 9.
We have 200 active lines (25 lines * 8 pixels high) and there are a total of 262 lines (525/2).
So 262 - 200 - 9 = 53 lines
We will use 32 blank lines at the top and 21 blank lines at the bottom (unsure why this particular split)
In summary, 9 sync lines + 32 blank lines + 200 active lines + 21 blank lines = 262 lines per frame
32 Blank lines oblank1
4.7us (-) xsync
27us (-?) xsynch
31.7us (o) xhalf
200 pixel lines oactive
4.7us (-) xsync
4.5us (o) xbackp· Back Porch
52.7us (o/+) ovsclch· Display 40/64/80*8 pixels, 1 PLLA per pixel, 8 PLLA per char frame
1.5us (o) xfrontp· Front Porch
21 Blank lines oblank2
4.7us (-) xsync
27us (-?) xsynch
31.7us (o) xhalf
Frame complete, back to equalisation pulses
The other part to this is to calculate the ifrqa for counter A to drive the Video Register. I am currently having trouble understanding out how this is really calculated. It is based on the propeller clock frequency and the line frequency and varies due to the active pixels (40/64/80 characters per line).
If you have any corrections please let me know.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Toby Seckshund said...
I do not know much about VT100 but, I always thought that chr(12) was form feed i.e. clear screen.
I have gone out of my way to get rid of all but one 625 monitor, and that one only survived because it is NTSC/PAL.
You're right, it's 12. The 24 seemed odd to me (I like odd even numbers). So, I would suggest 12 for clear screen. It's an established control character.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
pullmoll: I used CAN because that is what we used in Singer & ICL terminals. The cursor movements I obtained from an ascii chart recently but just now I cannot find that one. Maybe FF would be better for home. Not sure why I chose vt. I have an idea the ICL teminals used chr(6) for home (ack).
Cluso99 said...
pullmoll: I used CAN because that is what we used in Singer & ICL terminals. The cursor movements I obtained from an ascii chart recently but just now I cannot find that one. Maybe FF would be better for home. Not sure why I chose vt. I have an idea the ICL teminals used chr(6) for home (ack).
With the latest release these are covered by method calls.
Hmm.. If I remember the times of CEPT (a terminal standard I once coded software for), then CAN was used there to clear to the end of the cursor line. I think it doesn't really matter what you use as long as it's documented. ACK is traditionally a line control and thus a non-displaying character, but who cares? Really, just go with what you think fits best. Most people will use the methods and not deal with control codes, except perhaps CR.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Comments
Well, I'll go dig up my notes. I more or less tore that all down building potatotext. Since your driver is mono, you've got a lot of options on the pixel loop. Generally those timings are based off of multiples of the color burst reference.
Seems to me, a mono driver could ignore those, meaning you can shrink, or enlarge the porches to "fit" a fixed timing pixel clock onto the display. That makes some sense. Let me dig up what I've got and I'll post it up here later.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
8x8 color 80 Column NTSC Text Object
Safety Tip: Life is as good as YOU think it is!
Ok. I think I understand the problem with tight cog memory very well. If you want to have the font in the cog RAM, you can only have a limited set of terminal emulation in the same cog. A halfway clean VT100 emulation would certainly need two cogs, one for the display action and one for the emulation. The question is if you need this. If you wanted to run CP/M via TV, a VT100 (or VT52) emulation would be a nice thing to have. Together with a PC and UART you probably have a good terminal emulation already.
Hehe.. The actual drawing code is what totally escapes me also. I just don't understand how it works. I'd have to re-read the manual section covering this quite a few times more methings.
The performance is actually ok for debugging purposes. Otherwise I really would spend it another cog to deal with the frame buffer.
Juergen
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
really just this:
text.str(string($A,26,$B,14))
which is prototyped in Chips documentation as:
'' $0A = set X position (X follows)
'' $0B = set Y position (Y follows)
Other than this, your 1-pin TV object works wonderfully well in substitution for the VGA_text object I started out with.
potatohead: Thanks Jonathan. Here is what I understand about NTSC (and I know the differences for this part in PAL)..
NTSC has·525 lines/frame and 30 frames/sec in non-interlaced mode. Hence the line frequency would be 525*30 = 15,750Hz. 486 lines are visible.
PAL has 625 lines/frame and 25 frames/sec in non-interlaced mode. Hence the line frequency would be 625*25 = 15,625Hz. 576 lines are visible.
Now, if I understand correctly, in each line, we start with the horizontal sync, followed by the back porch, then the visible pixels, and finally the front porch.
So, I have 25 character lines of 8 pixels high = 200 visible lines (so 400 in non-interlaced terms as it is repeated - is this correct?). I also have 40 characters of 8 pixels = 320 pixels visible. I manage to get more characters/line at higher clocking.
If I have the above correct, this is where I get lost. Of the 486 lines, divide by 2 for a half frame = 243 less 200 visible = 43 for top and bottom blank lines for retrace, plus a vertical sync pulse.
I understand the horizontal and vertical sync pulses are 0V and the front and back porches are slightly positive (as in reality, the hs & vs are supposed to be negative and the porches 0V). When a visible pixel is on, the output is 1V after the voltage divider. When it is off, the counter generates a PWM voltage equivalent to the porch voltage.
How big are the porches and what are the serration pulses and their timing (I am presuming they are to do with the color, which we don't really have)?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
An interlaced display has a half-scan line inserted between frame 0 and frame 1. That puts the scan lines between one another, doubling the vertical resolution. If you want to, you can change your character pixel address decode so that it does character even scans on one frame, and odd scans on the other frame, and pack in 400 lines, for a 50 line display, but then the character aspect becomes square which is kind of good, not tall which is bad because eye fatigue may set in for those viewers not using high persistence phosphor devices. I don't know if you can even get high persistence displays for TV signals any more, but I used to have one, and interlaced on it was great. It's not so great on your average TV, which is why I didn't do it on potatotext.
I think you were missing the half-scan line on that.
Working on the other questions.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
8x8 color 80 Column NTSC Text Object
Safety Tip: Life is as good as YOU think it is!
·
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Whit+
"We keep moving forward, opening new doors, and doing new things, because we're curious and curiosity keeps leading us down new paths." - Walt Disney
Hell, I wish we had these! Driving them would be no big deal. Trust me, that would get done at any cost.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
8x8 color 80 Column NTSC Text Object
Safety Tip: Life is as good as YOU think it is!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
If I understand your intent correctly, for a given xtal, there will be optimal pixel loop HUB access times. If you determine those, you can take up slack in the porches, leaving the sync alone, meaning all you really need is the total scan time-minus the sync time, which is always the same, leaving you with whatever your optimal pixel loop consumes per desired number of characters and what is left over from that for porches, each probably equal.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
8x8 color 80 Column NTSC Text Object
Safety Tip: Life is as good as YOU think it is!
Can you tell me, the number of blank lines top and bottom are different. Is that necessary, and if so, is something else happening here that makes this necessary? I could save a bit if they were equal.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
The number of scan lines is even, so just put your display right in the middle. You will have to alter the calculations done in the tasks for this, but otherwise no problem. Your text display might run a bit low though.
Those are the calculated parameters. Oblank1 is your top border, oactive is number of scans for the text area, oblank2 is the bottom border. Look at the math in the tasks for this.
The porches are shown, those are npackp and nfrontp. I don't get why one porch is so much longer than the other one... I think it's because a mono signal has no color burst. Looks to me like you can just change the porch values in nbackp and nfrontp to impact the active area. Subtract from one or the other, or both to either move, or change display area size.
That's all I've got for now. I have to go and run this. It's an excellent bit of driver code actually.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
8x8 color 80 Column NTSC Text Object
Safety Tip: Life is as good as YOU think it is!
Post Edited (potatohead) : 3/15/2010 6:08:10 AM GMT
Aha, now I understand where the timing I will look at that.
It bugged me why they (porches, top/bottom)·were different although I know they are to fit the display equally within the screen.
Here is a pic of what timing I believe is happening (and a spin file).
As I understand it, there are 3 voltages generated. The HS & VS are 0V, pixel off and the porches are ~0.25V and are generated by the CTRA in PWM mode (black), and 1V is generated when a pixel is on (white).
Are the equalisation and serration pulses going between 0V & ~0.25V ?
The timing of the blank lines and the visible lines seem to be different. There may be some advantage to save code by making them the same.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
The norm is to simply encode a blank line as sync, optionally color, then the entire line porches and active as one big waitvid, leading right into the next one. There is no need for any complexity.
Realistically, you can make each scanline the same code, with an active portion, but just don't use it, until the real active section is reached. Your vertical frame then becomes VSYNC, followed by all the scanlines, leading into VSYNC again. Eric's driver code appears to also support an interlaced display. That's the double scan line resolution bit. That's some complexity that could be removed as well. That would involve first removing the half-scan code, then the computation for it, the logic in the frame loop that makes use of it, finally nulling the mode switch that triggers it. For text, an interlaced display, particularly a color one, running two scan lines per vertical pixel, actually looks quite good. For a debug display, that is minimal and compact, this isn't needed.
One downside to that is figuring out what that blank line will display. Either it's literally the same code, and it's got a switch to not fetch from the HUB, and just use the color black for all pixels, or there is a buffer somewhere that it displays until the real active area is reached... This is usually why it makes sense to just code the blank lines as the simplest code case, and either call them, or in line them in the frame loop. That's been my general experience anyway.
Assuming you reach a satisfactory solution to that, all scan lines then are either part of the VSYNC, or are actually scanlines.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
8x8 color 80 Column NTSC Text Object
Safety Tip: Life is as good as YOU think it is!
Post Edited (potatohead) : 3/15/2010 7:42:09 AM GMT
1. Fixes a bug in all 1-pin versions including Eric's original. MOVS VSCL,xxxx· should be MOV (2 places). No effect but sync pulse and back porch incorrect for displayable lines.
2. Slightly simplified code gaining a few longs. More to come.
potatohead: I already removed the interlaced code and the double height code. Thanks for the clarification on the blank scanlines.
I have found an article on the equalisation and serration pulses which show 6+6+6 which is what Eric has used. The PAL code uses 4+5+5 and I haven't found this info anywhere yet. I am wondering if you know whether 6+6+6 would be ok for PAL too?
I have not figured the maths to get 4.7uS sync to be stored as 4129 for 80MHz. Once I work this out I expect the others will fall into place.
I am trying to keep it simple to select·screen sizes of·40*25, 64*25 and 80*25, NTSC/PAL and different xtals without incurring code space.
Postedit: As I continue to understand the actual display section, I see that the equalisation/serration/equalisation pulses occur every frame, not as I thought at every line. This means that I have the terminal code running in the Vsych and not the blank line code where it will get much more time. I will move this asap. This should improve the terminal response significantly
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
Post Edited (Cluso99) : 3/15/2010 11:17:32 AM GMT
I don't know if perhaps herein is the information you need? http://www.kolumbus.fi/pami1/video/pal_ntsc.html
Thanks for the improvement! I'll try that one.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
The dracblade has VT100 code, which is actually copied from the PocketTerm, which in turn was borrowed from Oldbitcollector's code. It is in spin, and consequently slower than it needs to be and also takes more memory than necessary. A VT100 emulation in pasm of 'clear screen' and 'cursor move' could be very handy.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
As for the pulses, I think you are going to have to try it to see. Often a monochrome signal from either standard will display on a device from either standard, but there are probably a few out there that are picky. No way to really know.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
8x8 color 80 Column NTSC Text Object
Safety Tip: Life is as good as YOU think it is!
FWIW my trusty old FBAS PAL monitor of noname brand (Orion) has no problem displaying the NTSC video signal, except that I have to adjust the vertical synchronization to the 60Hz. The top and bottom blank lines were slightly deformed, but the picture itself was clean and stable.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Post Edited (pullmoll) : 3/15/2010 3:27:15 PM GMT
I did get caught pushing color boundaries on potatotext though. Some of the very low intensity text values get seen as sync. Was pushing the number of real Propeller colors. Every device in the house would display a signal with $09 in it, but as soon as I put the driver out there, somebody popped up with a futzed display. Didn't take long to isolate the trouble, but still it could happen.
If it sees a bunch of runs, and no worries, then it's probably good, with the occasional person just electing to either run another version with a different feature set, which I would publish, if it were me, or choosing a different display device.
PAL users are kind of lucky really. IMHO, a lot of PAL gear will display PAL 60, PAL 50, NTSC 50, NTSC 60, no probs. Over here, the devices are NTSC 60 only, with a fair chunk able to display NTSC 50 (longer blanking period for games is good), and if PAL displays at all, we are lucky.
The best overall choice for Propeller stuff is a capture card type device. I've a USB one that's excellent, and will render everything right to a PC window. Only downside is 250-500ms or so of latency. Good for programming, not good for interaction. I often use that just like I would a serial terminal window.
Nice effort Cluso! This will be a killer output driver. Small, with essential features all in the cog, and 1 pin is cool. Looking at Eric's notes, he ran the thing with no resistor at all and still got a display. That's bad, for load reasons, but good in that it's just not that tough to get the output in a pinch!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
8x8 color 80 Column NTSC Text Object
Safety Tip: Life is as good as YOU think it is!
Post Edited (potatohead) : 3/15/2010 3:56:52 PM GMT
I was not understanding the values loaded into VSCL, but had not realised (remembered) it was in fact two values being loaded at once, the pixel and frame clocks. Now when I subtract the 4096 (1 pixel clk) it gives me the frame clocks. Some of these do not appear correct but I can now decipher them.
Now to delve into the VSCL a little more to see if it actually decrements as perhaps I could load just the lower 9 bits of the frame clocks by using movs vscl,#xxxx as so far all values are less than 512. I note the total blank line is 33+195+230=458 which still seems wrong
If I can use movs then I can use immediate values which saves quite a few longs for those larger values with 1 pixel clk set ($1_000)
The bug I reported in the post above using MOVS quite probably proves my point that VSCL is actually not decremented and that in fact it will work and keep pixel clk = 1
Looks like I can use the equalisation loop to do the equalisation and serration loops with a couple of movs instructions preceeding the call. Some more instructions shaved where time is not an issue.
I may end up getting enough space to fit a poormans VT100 into the cog yet!
pullmoll: That link is great thanks Jurgen. Much cleaner if I am recisely to spec and as you said, most sets with PAL have also been·NTSC compatible for years. Postedit: The link·for the timing clears a lot of things up - thanks again!
Postedit: I would not connect to a TV without a resistor as you could overdrive the TV. See my cable with the resistor mounted at the TV plug end (link on top thread). I have done the same for the keyboard, so a full debug terminal takes 2 pins and 2 cogs.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
Post Edited (Cluso99) : 3/15/2010 8:20:18 PM GMT
The screen buffer now overlays the hub cog driver code
No space is wasted for the screen buffer. The cog fills 496 longs and a further 4 longs are added to the end of the DAT to allow for a 80*25 screen.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
Post Edited (Cluso99) : 3/17/2010 5:26:13 PM GMT
Great idea to re-use the hub RAM. This makes it even better suited for debugging.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
It's in the OBEX
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
I have updated the top post with a list of features.
Adds spin methods for home, clear, gotoxy and cr.
Question: I supported chr(0) for clear screen and added chr(24) also. However, all I have seen here use chr(0) although it was common years ago to use chr(24). I may need the space, so...
Should I remove chr(24) ??? or chr(0) ? or leave both ?????
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
Description of NTSC composite video B&W
Based upon the work of Eric Ball and help from potatohead.
The following are the signals and timings used to generate the 1-Pin TV in non-interlaced mode. The frame really starts with the front porch, but it is easier to treat the front porch at the end of the line/frame.
The other part to this is to calculate the ifrqa for counter A to drive the Video Register. I am currently having trouble understanding out how this is really calculated. It is based on the propeller clock frequency and the line frequency and varies due to the active pixels (40/64/80 characters per line).
If you have any corrections please let me know.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
I think FF (form feed) is closer to a VT100 emulation for clear screen.
Just my .02€
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
I have gone out of my way to get rid of all but one 625 monitor, and that one only survived because it is NTSC/PAL.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
You're right, it's 12. The 24 seemed odd to me (I like odd even numbers). So, I would suggest 12 for clear screen. It's an established control character.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Just found PCTerm uses Ctrl^ (Ack=6) for home http://vt100.net/docs/vt510-rm/chapter11
With the latest release these are covered by method calls.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
Hmm.. If I remember the times of CEPT (a terminal standard I once coded software for), then CAN was used there to clear to the end of the cursor line. I think it doesn't really matter what you use as long as it's documented. ACK is traditionally a line control and thus a non-displaying character, but who cares? Really, just go with what you think fits best. Most people will use the methods and not deal with control codes, except perhaps CR.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.