I am on mobile, but can you combine the move and shift on rowscan with one of the spiffy bit field manipulation instructions? Just move the bits to the right place, rather than shift, post move?
Could free a long everywhere that happens.
Nice work! I am happy to wait. But may pester... .
I love component because one pin gets a person monochrome from SD 240p on up. And simple level changes on the other channels gets tint and saturation. One thing I aim to try personally is clocking color slower than intensity. I am curious about what the TVs will do when doing advanced processing. (4K HDMI does that)
Anyway, looks like great work! A P2 will end up driving pretty much any display. Who knows? When one of us gets to doing old TTL, perhaps those can be abused a little to get more than intended.
The other thing I can do is HDMI sampling. I do a lot of travel right now. Can thrash many different displays. See more of what takes what.
One thing I aim to try personally is clocking color slower than intensity. I am curious about what the TVs will do when doing advanced processing.
As far as I understand, that is basically what a lot of less-integrated devices with component out do (basically anything where the graphics chip spits out BT.656 (or any of the kindof-similiar formats there are) to a video DAC). Makes sense for a DVD player, since the MPEG2 stream is only 4:2:0 anyways (One pair of CbCr values per 2x2 block!). I also know from programming it that the Wii has a 4:2:2 subsampled XFB (=framebuffer in main RAM) (which is horizontally scaled to 720(?) pixels before/while being scanned out, not sure if that happens at full 4:4:4 chroma resolution)
Not sure how one'd do it on P2 though, beyond manually feeding pixels to the DACs. (I guess one could expand an entire scanline to 4:4:4 at once, but that just seems obvious)
One thing I aim to try personally is clocking color slower than intensity. I am curious about what the TVs will do when doing advanced processing.
As far as I understand, that is basically what a lot of less-integrated devices with component out do (basically anything where the graphics chip spits out BT.656 (or any of the kindof-similiar formats there are)
Snip
Not sure how one'd do it on P2 though, beyond manually feeding pixels to the DACs.
Yeah, or more than one COG. There will be threads on display flogging in the future. Manually feeding values could simulate those cheezy color overlays seen early on in arcades.
test modedata #(1<<6) wcz
if_nz test scanline, #(1<<0) wcz
if_z incmod rowscan, rowheight wc
Checked the cases and unfortunately I don't think this quite works. Before the incmod step it will leave C set and Z clear in the case where modedata[6] (line doubling flag) is set, while scanline lsb[0] is 1. I need the C to be cleared in the cases where the incmod is never executed, so I don't increment the row further down in the code. It's tricky logic as there are interlaced font cases handled too after this where it tests bit10 of mode data (interlaced font enable bit). I think there is scope to optimize this somehow though eventually and rid ourselves of that excess "mov c, 0 wc" instruction.
I am on mobile, but can you combine the move and shift on rowscan with one of the spiffy bit field manipulation instructions? Just move the bits to the right place, rather than shift, post move?
In this case I don't think I can use setbyte to move rowscan into byte[1] of b because I need to clear b before the addition to the base font table address in hub memory. Be nice if I could have it clearing the rest of the long somehow.
Yeah it's tight by my standards but once people get the full code they can probably find even more compression.
Here are the only issues remaining that I know about:
When a side border is enabled and the mouse sprite is also enabled in a normal (non-transparent) text/graphics mode, I can run out of clock cycles on the scanline to render the mouse, this is due to the order of operations with the streamer and right side border. I need to find a creative way to move the early mouse calcs to before the right edge border streamer command gets issued without requiring more instructions that I don't have space for. This is so it doesn't resync to the end of the line between the border and hsync, where there is not really enough time to do the mouse before the hsync needs to be sent. Most hysnc front porches are small, though not 720p50 and below, they are massive.
I also want to add the interlaced SD component and progressive s-video/composite sync options to the initialization setup code. The former has high precedence, the latter may come afterwards as it is probably less used, but I still want it to go in at some point to be complete.
Composite/s-video sync are still seeing colour issues or timing glitches. Something is not quite right yet and I think custom PLL values that lock pixel rates and colour bursts to 455/2 line frequency for NTSC will be needed, and/or that xzero. But I'm not going there at the moment.
Also the two PAL colorburst values have not been calculated yet - I think we just need to solve a simultaneous equation with 3 variables to determine them, unless someone already knows what two particular RGB values should be used to get 135 and 225 degree U, V vectors at the right modulation intensity (40 IRE units p-p I think). In the meantime I'm just using the NTSC value Chip used for PAL and it sort of works on my displays, but this is certainly not correct PAL output yet.
I have also seen some text weirdness with regions ending on odd scanlines and interlaced font regions following them. For now when interlacing is enabled it might be best to keep region sizes a multiple of two scanlines until this is sorted (assuming it can be, might need another instruction!).
Now I'm finally a bit more awake I am looking at first two things today, and any ways to find more longs.
Update:
I've think I've found a way to fix the mouse+border combination, though it took my last long. :frown: Am still testing but it appears to solve the issue.
Update2: found another long to compensate for this change, maybe even two if I am lucky.
Can this driver do smooth vertical scrolling in text mode, i.e. first/last pixel row on screen not necessarily first/last pixel row of text characters?
test modedata #(1<<6) wcz
if_nz test scanline, #(1<<0) wcz
if_z incmod rowscan, rowheight wc
Checked the cases and unfortunately I don't think this quite works. Before the incmod step it will leave C set and Z clear in the case where modedata[6] (line doubling flag) is set, while scanline lsb[0] is 1. I need the C to be cleared in the cases where the incmod is never executed, so I don't increment the row further down in the code.
Ah, yes, I messed up the condition for the orz. It should be:
Hmmm, you're right, there's a problem if both modedata[6] and scanline[0] are set.
How about an alternative: C is set based on the parity of the bits being tested. I wonder if there's a way to always have even parity, e.g. if we set modedata[6] and modedata[7] to be the same then:
[code]
test modedata, #(1<<6)|(1<<7) wcz
will always clear C. That would require changes elsewhere in the code though.
I think there is scope to optimize this somehow though eventually and rid ourselves of that excess "mov c, 0 wc" instruction.
BTW I think you're missing a "#" in that mov in the code above, shouldn't it be "mov c, #0 wc"?
@rogloh Any idea when you might drop us some beta test code? I have this project...
Hopefully in the next few days if I get enough time on the weekend. I want to update the doc and do quick sanity test for regressions so I can at least identify the known issues. I could definitely release a beta prior to adding in final interlaced component SDTV etc if I don't get that far. I don't have a proper demo setup though and that bugs me. I'd also like to wrap it in a least some high level flexgui compatible SPIN in order to spawn it, but I'm still trying to set that up on the Mac and learning how do to that etc. Currently it is all just in a single PASM2 file which makes things a little bit unfriendly to use though it might be okay for people who know what they are doing.
Can this driver do smooth vertical scrolling in text mode, i.e. first/last pixel row on screen not necessarily first/last pixel row of text characters?
Yes, that's been in for a while now. Smooth as silk.
BTW I think you're missing a "#" in that mov in the code above, shouldn't it be "mov c, #0 wc"?
Doh! Yes you are correct, and this might explain some weirdness I am seeing for the first scanline.
Update: Damn, that isn't the cause. My first register 0 was just a pointer whose top bit will be zero anyway so it still clears C, but I've moved it to #0.
I'm seeing this weird thing where the first or second scan line on the screen appears to get duplicated when it shouldn't so I must have the region initialization logic wrong there and probably a regression related to the interlaced stuff I introduced recently. That's the problem with making feature changes now, the code is getting quite heavily optimised and it makes things more fragile. I have to revisit old code done weeks ago as well which isn't nice.
Was finally just able to get enough pieces together to build and run my video driver under flexgui + fastspin on the Mac. So now I can try to wrap something around it to spawn it.
BTW I think you're missing a "#" in that mov in the code above, shouldn't it be "mov c, #0 wc"?
Doh! Yes you are correct, and this might explain some weirdness I am seeing for the first scanline.
Update: Damn, that isn't the cause. My first register 0 was just a pointer whose top bit will be zero anyway so it still clears C, but I've moved it to #0.
MODC/Z is a safer way to modify the flags, but I agree that using a whole long just to clear C is defeatist. Re source code release, would it be a lot of trouble to put wc/wz/etc. at the same tab stop? It makes code much easier to understand.
Re source code release, would it be a lot of trouble to put wc/wz/etc. at the same tab stop? It makes code much easier to understand.
Yeah I know what you mean and it annoys me as well. Really the only reason for it is I've been trying to keep this source code to only 80 columns wide (old school) with comments still visible, but I think I'll have to bite the bullet and expand wider to add a few more tabs stops for labels and conditionals. If people ever have to print it out they'll have to change their fonts to fit it on the page (or go landscape) if their printers are still limited to 80 columns. Probably not many would be these days...lol.
Separate to that, I was thinking about what @"Peter Jakacki" was saying about transparent overlays and TAQOZ overnight. I think this might possibly be doable with an external mixer COG synced up to the output of my driver COG. You could read in the scanline data it creates and mix it before it finally streams out to the display. You just need to start at the right time on the scanline and keep up. It would be very CPU intensive but I think even one COG running flat out might be able to just do it. For example the the slowest 7 clock blendpix transparent mixing operations on 32bpp data could be used with 3 setq read/write transfer bursts (2 read, 1 write) in DVI mode with its high 10 sysclks/pixel ratio. You would run unrolled pixel blend loops from LUTRAM working on pixel data in COGRAM and you'd limit the read/write burst sizes to reduce latency and get data out before it is read by the FIFO and displayed by the streamer in my driver. It would be worth experimenting with at some point in the future. This is an interesting possibility for video & other text/sprite overlays etc.
Another idea for this is having two driver COGs (one potentially with its outputs somehow disabled), and a mixer COG. Then you could possibly have one doing text and the other doing graphics (or both doing graphics) and the mixer blending them before one, or both, driver COG(s) displays the result. You could have different blend parameters for different screen regions too.
I need a way to sync up driver COGs so a new one with the same timing parameters could sync to an existing running one when it is spawned - that can be a future feature.
Had a pretty successful day today working on this...after not so much time on the weekend as I'd hoped.
-Updated quite a lot of the documentation to match the driver code etc (now it's almost 100% true )
-Completed the final sync code integration of progressive SDTV S-Video/CVBS and interlaced SDTV component, so now we finally have all these built in and supported: VGA/DVI/HDTV/SDTV(PAL/NTSC) over component, S-video, CVBS, with interlaced/progressive output.
-Optimized the code further by jumping around to reuse more code and saved 5 longs in the processs which is some nice space for any future bug fixes required. I'm not going to add new features until we know any bugs are fixed.
-Optimized the cursor code to save space and eliminate that "mov c, #0 wc" operation and gained more capabilities in the process (variable cursor height)
-Chased down an annoying bug in the display of the first top two lines
-Got a FASTSPIN video driver API now mostly written and working at least for a simple example
-Putting together a fun demo.
So I'd expect it should be ready in the next day or so now. PAL/NTSC composite output colour bursts are still messed up a bit at this point and really flicker a lot, but perhaps people like @potatohead and others can help me figure out the right timing settings or other techniques to resolve it. I did attempt some xzero operations per field but it didn't help, I think the XFRQ and CFRQ relationship must need to be setup very accurately and stay in sync for it to have any chance of working correctly but don't have time to chase it down right now.
@Ahle2 I think it would need to be another day before I can release it. Transforming it from pure PASM2 into fastspin has taken me longer than I wanted it to and today I had to adjust how I initialize it's clocking to try to fit in somewhat better in that environment rather than just take over everything. But I've done most of that work today.
It's funny as I am sort of eating my own dog food now and running into real world operating problems that others can and will as soon as they use this thing.
One problem is that if you exceed it's capabilities by under clocking for a certain resolution while running text regions it simply won't produce a signal monitors will recognize, so you sort of need to be aware of that. It's hit me many times today and I keep thinking it is a regression due to a change I made but when I track it down, it's just that I overloaded it's ability. You need at least a 4-5x multiplier for rendering text and I kept forgetting that when I was testing higher HD resolutions. It would be much nicer if it could know upfront what it could do and render blank text regions if there are not going to be enough cycles, but at least keep the signal operating. I might be able to calculate and patch it at setup time to do that based on the clock, but that's for later.
I would have liked a bit more time to put together some more interesting and fancier demos and tidy the API and other things up a bit more in this code but I think it is more useful to get this out and those things can evolve over time. As a result it is likely you will encounter things in there that don't make sense. Looking back at it I already see a couple of test things I didn't take out, and the API for printing text was a total last minute addition and is pretty ugly right now. My focus has been on the PASM side not SPIN, but I should have loaded FASTSPIN sooner as it would have helped more during development instead of testing only with PASM. I only installed that a few days ago!
When I woke up I just realized I didn't get the chance to retest pixel doubling in graphics modes before releasing this overnight at 5.30AM local, which is something I'd wanted to do as there had been some changes there recently so perhaps that is broken? Certainly some regressions are going to be possible, but they should be easy enough for us to fix when identified. It is still only the first beta after all. Some of the HD modes are not using proper 74.25MHz clocks, so they might only work with VGA monitors, not HDTVs, although my plasma TV was okay with them over component.
Update: Had a chance to test pixel doubling in gfx mode, looks okay.
By the way if you leave the complexdemo running for a while, you'll see it starts running out of data as the scrolling relentlessly continues, and at some point shows its own scan line in hub RAM being constructed on the fly and other dynamic data and gives an interesting shearing effect. I first thought it was a bug but don't think it is now.
By the way if you want to run the complexdemo using RGB output at 800x600 and 1024x768 you can, you just need these changes to lower the usage...
Disable the side border and mouse setup by commenting them out. Perhaps one change can work without the other, but I didn't try all the different combinations. You could try putting the mouse in the graphics region, that might help too as there are more cycles on those scan lines to do it. SVGA may be okay with its 6x divider, XGA is a lot tougher on the 5x cycle budget when doing text+side border+mouse together.
timing := vid.getTiming(VID#RES_800x600) 'P2 will clock at 240MHz
vid.setSkew(@second, 1280-1600) ' sets up skew for a 640 wide 16bpp image to work with 800 pixels
For XGA, you would make these changes:
timing := vid.getTiming(VID#RES_1024x768) ' P2 will overclock at 325MHz BE WARNED!
vid.setSkew(@second, 1280-2048) ' sets up skew for a 640 wide 16bpp image to work with 1024 pixels
The demo code has some hard coded numbers (I was too lazy last night) for initial text data fill pattern which means it was setup for 80 columns, but that can be changed too.
Bear in mind this complex demo code is close to the 512kB size limit because of the large bird image. If you make changes and go over 512kB in size bad things will happen. It happened to me last night quite a lot and I thought my code was broken! Trim the bird image down to make room.
I was thinking about this overnight and right now if you want to define display regions enabling the inbuilt text capabilities, my video driver needs a pixel clock divider of 5x or higher, sometimes for pixel doubled text it only needs 4x depending on scan line timing, while for non-doubled graphics regions it now only needs 2x (or even 1x for transparent mode).
For VGA output, a 5x divider means the P2 already needs to run upwards of 125MHz+, but for higher resolutions of 800x600 up it means overclocking over 200MHz. I think there may be applications where text is still desired but you may not want to clock the P2 that high. If another COG can be spared I think we can use the capabilities of my driver to add text with reduced P2 clocks, if the second COG does the text rendering and the driver COG does the display.
For example I found a way to compress the text loop down to less than one clock per pixel for monochrome text in an external COG. This means we could have text/graphics at just 25MHz for VGA and 13.5 for NTSC. The basic loop including the inner loop become this...and looks like it would fit in the 800 clock cycles budget for standard VGA with 80 column text. In theory it also means we could do full HD mono text with 240 columns at only 74.25MHz P2 which would be great too.
'wait here for scanline buffer to be ready
'TODO: additional per buffer overhead, calculate font addr etc
setq #64-1
rdlong font, fontaddr
setq2 #20-1 'read 20 LONGs = 80 chars
rdlong 0, screenaddr
rep @endloop, #20 ' 20 loops * 4 chars/loop = 80 chars
rdlut d, ptra++ ' read 4 chars
getbyte c, d, #3
altgb c, #font
rolbyte a, 0-0, #0
getbyte c, d, #2
altgb c, #font
rolbyte a, 0-0, #0
getbyte c, d, #1
altgb c, #font
rolbyte a, 0-0, #0
getbyte c, d, #0
altgb c, #font
rolbyte a, 0-0, #0
wrlut a, ptrb++ ' write 32 pixels
endloop
'14.5 instructions (29 clocks) per 32 pixels
setq2 #20-1 'write back 20 LONGs = 640 pixels
wrlong 0, bufaddr
A coloured text version with blinking is more involved and would take 3 additional COGs at a 1x pixel clock divider each COG doing every 3rd scanline, or 1 additional text COG with a 3x divider (easier to code). There should also be a way to get it down to 2 additional text COGs with a 2x clock divider but I haven't investigated that one. The 3x divider would allow coloured XGA test at 195MHz P2 and only two COGs (1 driver + 1 text), which is barely an overclock. If you had 3 total video COGs you could do it at 130MHz, or with 4 COGs down at 65MHz.
The unrolled loop below takes 49 clocks per character pair multiplied by 40 for VGA = 1960 clocks out of the 2400 cycle budget with 3x text COGs or a 3x clock divider and one COG. This leaves plenty of time to load the 64 font longs plus read/write the 80 longs of input/output data, with per scanline housekeeping overhead. Higher resolutions work similarly.
rep @endloop, #40 'repeat 40 times (49 clocks per 16 pixels)
rdlut d, pb 'read pair of characters/colours
getword c, d, #1 'save top word the long
altgb b, #font 'determine font lookup address
getbyte pixels, 0-0, #0 'get font for character's scanline
testflash1 bitl d, #15 wcz 'test (and clear) flashing bit
flash1 if_c and pixels, #$ff 'make it all background if flashing
movbyts d, #%01010101 'colours becomes BF_BF_BF_BF
mov b, d 'grab a copy for muxing step next
rol b, #4 'b becomes FB_FB_FB_FB
setq ##$F0FF000F 'mux mask adjusts fg and bg colours
muxq d, b 'c becomes FF_FB_BF_BB
movbyts d, pixels 'select pixel colours for char
wrlut d, ptrb++ 'write coloured pixel data into LUT
altgb b, #font 'determine font lookup address
getbyte pixels, 0-0, #0 'get font for character's scanline
testflash2 bitl c, #15 wcz 'test (and clear) flashing bit
flash2 if_c and pixels, #$ff 'make it all background if flashing
movbyts c, #%01010101 'colours becomes BF_BF_BF_BF
mov b, c 'grab a copy for muxing step next
rol b, #4 'b becomes FB_FB_FB_FB
setq ##$F0FF000F 'mux mask adjusts fg and bg colours
muxq c, b 'c becomes FF_FB_BF_BB
movbyts c, pixels 'select pixel colours for char
wrlut c, ptrb++ 'write coloured pixel data into LUT
endloop
Actually it would be really neat if when patched to a special "partial text mode" my driver could do half the text of the scan line and an additional COG could do the other half at a 2x pixel clock divider rate, but that would get a lot harder to integrate and requires the space in my driver COG to be patched with the special half scan line version if it works a lot differently to what I already have it doing.
I might still think about this though. It's not a perfectly even balance unfortunately because the main driver COG has other per scan line overheads too that this text only COG doesn't have. It might be more like an 800:640 split for example, though 2x COGs at 2x rate may allow closer to a 50:50 split because it is gives you 33% more processing time than you need.
I think the only way to reasonably split the work this way with these 2 COGs is to do the first half of the line in one COG and the second half in the other COG. If you want a mouse it would need to be overlayed as late as possible too so finishing sufficiently early is important too. The driver COG already has to finish within the active portion of the previous scanline. Ideally the text COG would need to finish around then too so the mouse can still work at those low speeds.
Update: Looking at the numbers I think a 50:50 split should be doable with 2x divider and 2 total COGs.
@potatohead, regarding SDTV video quality with composite and s-video, I found one difference in my driver vs Chip's NTSC code. He's not doing any xzeros anywhere now. So in SDTV mode I've swapped out my xzero there for an xcont and with his same XFRQ/CFRQ settings and 400 pixels I see about the same quality as the spiral demo. On the scope I see the two colourburst phases and it is only slipping it's phase very slowly now (maybe 1 burst cycle in ~15 seconds). There is still some glitchiness left but that is also possibly also there too in the spiral demo I think too - it's just more noticable with text showing than the spiral pattern.
I've put in a fix into the code (add this new line at interlacedcommon). I created a timing structure with Chip's progressive NTSC timing and added it below if you wanted to try it too. You'd need to create the display with the VID#PROGRESSIVE flag and hack in this timing instead. There is a little bit of mucking around to hook it in for testing.
interlacedcommon
if_nz setr hsync, #$198 'remove xzero if CVBS or S-Video
getword a, m_vi, #0 'get visible + front porch pixels
getword b, m_bv, #0 'get back porch pixels
I replaced @prog240_timing with Chip's progressive timing in the PUB initDisplay() code in p2videodrv.spin2
and added a 250MHz clock and the computed XFRQ/CFRQ values, which is what Chip uses, plus the timing structure for it.
CON
CLK250MHz = %1_000011_0000110001_1111_10_00 '(20MHz/4) * 50/1 = 250 MHz
f_color = 3_579_545.0 'colorburst frequency
f_scanline = f_color / 227.5 'scanline frequency
f_pixel = f_scanline * 400.0 'pixel frequency for 400 pixels per scanline
f_clock = 250_000_000.0 'clock frequency
f_xfr = f_pixel / f_clock * float($7FFF_FFFF)
f_csc = f_color / f_clock * float($7FFF_FFFF) * 2.0
DAT
chiptiming
long CLK250MHz
long 250000000
'_HSyncPolarity___FrontPorch__SyncWidth___BackPorch__Columns
' 1 bit 7 bits 8 bits 8 bits 8 bits
long (SYNC_NEG<<31) | ( 50<<24) | ( 29<<16) | ( 65<<8 ) | (256/8)
'_VSyncPolarity___FrontPorch__SyncWidth___BackPorch__Visible
' 1 bit 8 bits 3 bits 9 bits 11 bits
long (SYNC_NEG<<31) | ( 27<<23) | ( 0<<20) | ( 35<<11) | 192
long round(f_xfr) ' XFRQ parameter
long (7<<24) + (18<<16)
long round(f_csc) ' CFRQ parameter
I've also made it so you could modify the vertical front porch for composite/s-video if you need to, which is what Chip does to get only 192 active scanlines instead of the normal 240. Previously I didn't allow for this but now I do. The sync width is still overridden for video however. That remains fixed for NTSC or PAL (non-component variants).
Just change this line:
mov patchvfp, writestat 'no front porch (just equalization)
into this
alti patchvfp, #%100_000
test a wz
if_z mov patchvfp, writestat 'no front porch (just equalization)
Comments
Could free a long everywhere that happens.
Nice work! I am happy to wait. But may pester... .
I love component because one pin gets a person monochrome from SD 240p on up. And simple level changes on the other channels gets tint and saturation. One thing I aim to try personally is clocking color slower than intensity. I am curious about what the TVs will do when doing advanced processing. (4K HDMI does that)
Anyway, looks like great work! A P2 will end up driving pretty much any display. Who knows? When one of us gets to doing old TTL, perhaps those can be abused a little to get more than intended.
The other thing I can do is HDMI sampling. I do a lot of travel right now. Can thrash many different displays. See more of what takes what.
Not sure how one'd do it on P2 though, beyond manually feeding pixels to the DACs. (I guess one could expand an entire scanline to 4:4:4 at once, but that just seems obvious)
Yeah, or more than one COG. There will be threads on display flogging in the future. Manually feeding values could simulate those cheezy color overlays seen early on in arcades.
Checked the cases and unfortunately I don't think this quite works. Before the incmod step it will leave C set and Z clear in the case where modedata[6] (line doubling flag) is set, while scanline lsb[0] is 1. I need the C to be cleared in the cases where the incmod is never executed, so I don't increment the row further down in the code. It's tricky logic as there are interlaced font cases handled too after this where it tests bit10 of mode data (interlaced font enable bit). I think there is scope to optimize this somehow though eventually and rid ourselves of that excess "mov c, 0 wc" instruction.
In this case I don't think I can use setbyte to move rowscan into byte[1] of b because I need to clear b before the addition to the base font table address in hub memory. Be nice if I could have it clearing the rest of the long somehow.
Here are the only issues remaining that I know about:
When a side border is enabled and the mouse sprite is also enabled in a normal (non-transparent) text/graphics mode, I can run out of clock cycles on the scanline to render the mouse, this is due to the order of operations with the streamer and right side border. I need to find a creative way to move the early mouse calcs to before the right edge border streamer command gets issued without requiring more instructions that I don't have space for. This is so it doesn't resync to the end of the line between the border and hsync, where there is not really enough time to do the mouse before the hsync needs to be sent. Most hysnc front porches are small, though not 720p50 and below, they are massive.
I also want to add the interlaced SD component and progressive s-video/composite sync options to the initialization setup code. The former has high precedence, the latter may come afterwards as it is probably less used, but I still want it to go in at some point to be complete.
Composite/s-video sync are still seeing colour issues or timing glitches. Something is not quite right yet and I think custom PLL values that lock pixel rates and colour bursts to 455/2 line frequency for NTSC will be needed, and/or that xzero. But I'm not going there at the moment.
Also the two PAL colorburst values have not been calculated yet - I think we just need to solve a simultaneous equation with 3 variables to determine them, unless someone already knows what two particular RGB values should be used to get 135 and 225 degree U, V vectors at the right modulation intensity (40 IRE units p-p I think). In the meantime I'm just using the NTSC value Chip used for PAL and it sort of works on my displays, but this is certainly not correct PAL output yet.
I have also seen some text weirdness with regions ending on odd scanlines and interlaced font regions following them. For now when interlacing is enabled it might be best to keep region sizes a multiple of two scanlines until this is sorted (assuming it can be, might need another instruction!).
Now I'm finally a bit more awake I am looking at first two things today, and any ways to find more longs.
Update:
I've think I've found a way to fix the mouse+border combination, though it took my last long. :frown: Am still testing but it appears to solve the issue.
Update2: found another long to compensate for this change, maybe even two if I am lucky.
Ah, yes, I messed up the condition for the orz. It should be: will always clear C. That would require changes elsewhere in the code though.
BTW I think you're missing a "#" in that mov in the code above, shouldn't it be "mov c, #0 wc"?
Hopefully in the next few days if I get enough time on the weekend. I want to update the doc and do quick sanity test for regressions so I can at least identify the known issues. I could definitely release a beta prior to adding in final interlaced component SDTV etc if I don't get that far. I don't have a proper demo setup though and that bugs me. I'd also like to wrap it in a least some high level flexgui compatible SPIN in order to spawn it, but I'm still trying to set that up on the Mac and learning how do to that etc. Currently it is all just in a single PASM2 file which makes things a little bit unfriendly to use though it might be okay for people who know what they are doing.
Yes, that's been in for a while now. Smooth as silk.
Doh! Yes you are correct, and this might explain some weirdness I am seeing for the first scanline.
Update: Damn, that isn't the cause. My first register 0 was just a pointer whose top bit will be zero anyway so it still clears C, but I've moved it to #0.
I'm seeing this weird thing where the first or second scan line on the screen appears to get duplicated when it shouldn't so I must have the region initialization logic wrong there and probably a regression related to the interlaced stuff I introduced recently. That's the problem with making feature changes now, the code is getting quite heavily optimised and it makes things more fragile. I have to revisit old code done weeks ago as well which isn't nice.
MODC/Z is a safer way to modify the flags, but I agree that using a whole long just to clear C is defeatist. Re source code release, would it be a lot of trouble to put wc/wz/etc. at the same tab stop? It makes code much easier to understand.
Yeah I know what you mean and it annoys me as well. Really the only reason for it is I've been trying to keep this source code to only 80 columns wide (old school) with comments still visible, but I think I'll have to bite the bullet and expand wider to add a few more tabs stops for labels and conditionals. If people ever have to print it out they'll have to change their fonts to fit it on the page (or go landscape) if their printers are still limited to 80 columns. Probably not many would be these days...lol.
Separate to that, I was thinking about what @"Peter Jakacki" was saying about transparent overlays and TAQOZ overnight. I think this might possibly be doable with an external mixer COG synced up to the output of my driver COG. You could read in the scanline data it creates and mix it before it finally streams out to the display. You just need to start at the right time on the scanline and keep up. It would be very CPU intensive but I think even one COG running flat out might be able to just do it. For example the the slowest 7 clock blendpix transparent mixing operations on 32bpp data could be used with 3 setq read/write transfer bursts (2 read, 1 write) in DVI mode with its high 10 sysclks/pixel ratio. You would run unrolled pixel blend loops from LUTRAM working on pixel data in COGRAM and you'd limit the read/write burst sizes to reduce latency and get data out before it is read by the FIFO and displayed by the streamer in my driver. It would be worth experimenting with at some point in the future. This is an interesting possibility for video & other text/sprite overlays etc.
Another idea for this is having two driver COGs (one potentially with its outputs somehow disabled), and a mixer COG. Then you could possibly have one doing text and the other doing graphics (or both doing graphics) and the mixer blending them before one, or both, driver COG(s) displays the result. You could have different blend parameters for different screen regions too.
I need a way to sync up driver COGs so a new one with the same timing parameters could sync to an existing running one when it is spawned - that can be a future feature.
-Updated quite a lot of the documentation to match the driver code etc (now it's almost 100% true
-Completed the final sync code integration of progressive SDTV S-Video/CVBS and interlaced SDTV component, so now we finally have all these built in and supported: VGA/DVI/HDTV/SDTV(PAL/NTSC) over component, S-video, CVBS, with interlaced/progressive output.
-Optimized the code further by jumping around to reuse more code and saved 5 longs in the processs which is some nice space for any future bug fixes required. I'm not going to add new features until we know any bugs are fixed.
-Optimized the cursor code to save space and eliminate that "mov c, #0 wc" operation and gained more capabilities in the process (variable cursor height)
-Chased down an annoying bug in the display of the first top two lines
-Got a FASTSPIN video driver API now mostly written and working at least for a simple example
-Putting together a fun demo.
So I'd expect it should be ready in the next day or so now. PAL/NTSC composite output colour bursts are still messed up a bit at this point and really flicker a lot, but perhaps people like @potatohead and others can help me figure out the right timing settings or other techniques to resolve it. I did attempt some xzero operations per field but it didn't help, I think the XFRQ and CFRQ relationship must need to be setup very accurately and stay in sync for it to have any chance of working correctly but don't have time to chase it down right now.
Will do as time and opportunity pernit.
It's funny as I am sort of eating my own dog food now and running into real world operating problems that others can and will as soon as they use this thing.
One problem is that if you exceed it's capabilities by under clocking for a certain resolution while running text regions it simply won't produce a signal monitors will recognize, so you sort of need to be aware of that. It's hit me many times today and I keep thinking it is a regression due to a change I made but when I track it down, it's just that I overloaded it's ability. You need at least a 4-5x multiplier for rendering text and I kept forgetting that when I was testing higher HD resolutions. It would be much nicer if it could know upfront what it could do and render blank text regions if there are not going to be enough cycles, but at least keep the signal operating. I might be able to calculate and patch it at setup time to do that based on the clock, but that's for later.
https://forums.parallax.com/discussion/170676/p2-dvi-vga-driver#latest
AWESOME! Get your rest. Thank you.
My productivity at work took a hit today. Just peering at this work of art.
Play time!
Thanks again. I think this will see a lot of use.
I would have liked a bit more time to put together some more interesting and fancier demos and tidy the API and other things up a bit more in this code but I think it is more useful to get this out and those things can evolve over time. As a result it is likely you will encounter things in there that don't make sense. Looking back at it I already see a couple of test things I didn't take out, and the API for printing text was a total last minute addition and is pretty ugly right now. My focus has been on the PASM side not SPIN, but I should have loaded FASTSPIN sooner as it would have helped more during development instead of testing only with PASM. I only installed that a few days ago!
When I woke up I just realized I didn't get the chance to retest pixel doubling in graphics modes before releasing this overnight at 5.30AM local, which is something I'd wanted to do as there had been some changes there recently so perhaps that is broken? Certainly some regressions are going to be possible, but they should be easy enough for us to fix when identified. It is still only the first beta after all. Some of the HD modes are not using proper 74.25MHz clocks, so they might only work with VGA monitors, not HDTVs, although my plasma TV was okay with them over component.
Update: Had a chance to test pixel doubling in gfx mode, looks okay.
By the way if you leave the complexdemo running for a while, you'll see it starts running out of data as the scrolling relentlessly continues, and at some point shows its own scan line in hub RAM being constructed on the fly and other dynamic data and gives an interesting shearing effect. I first thought it was a bug but don't think it is now.
By the way if you want to run the complexdemo using RGB output at 800x600 and 1024x768 you can, you just need these changes to lower the usage...
Disable the side border and mouse setup by commenting them out. Perhaps one change can work without the other, but I didn't try all the different combinations. You could try putting the mouse in the graphics region, that might help too as there are more cycles on those scan lines to do it. SVGA may be okay with its 6x divider, XGA is a lot tougher on the 5x cycle budget when doing text+side border+mouse together.
' vid.showMouse(@first, 1)
' vid.setDisplayBorderSizes(@display1, 15, 15, 16)
For SVGA, you would make these changes:
timing := vid.getTiming(VID#RES_800x600) 'P2 will clock at 240MHz
vid.setSkew(@second, 1280-1600) ' sets up skew for a 640 wide 16bpp image to work with 800 pixels
For XGA, you would make these changes:
timing := vid.getTiming(VID#RES_1024x768) ' P2 will overclock at 325MHz BE WARNED!
vid.setSkew(@second, 1280-2048) ' sets up skew for a 640 wide 16bpp image to work with 1024 pixels
The demo code has some hard coded numbers (I was too lazy last night) for initial text data fill pattern which means it was setup for 80 columns, but that can be changed too.
Bear in mind this complex demo code is close to the 512kB size limit because of the large bird image. If you make changes and go over 512kB in size bad things will happen. It happened to me last night quite a lot and I thought my code was broken! Trim the bird image down to make room.
For VGA output, a 5x divider means the P2 already needs to run upwards of 125MHz+, but for higher resolutions of 800x600 up it means overclocking over 200MHz. I think there may be applications where text is still desired but you may not want to clock the P2 that high. If another COG can be spared I think we can use the capabilities of my driver to add text with reduced P2 clocks, if the second COG does the text rendering and the driver COG does the display.
For example I found a way to compress the text loop down to less than one clock per pixel for monochrome text in an external COG. This means we could have text/graphics at just 25MHz for VGA and 13.5 for NTSC. The basic loop including the inner loop become this...and looks like it would fit in the 800 clock cycles budget for standard VGA with 80 column text. In theory it also means we could do full HD mono text with 240 columns at only 74.25MHz P2 which would be great too.
'wait here for scanline buffer to be ready 'TODO: additional per buffer overhead, calculate font addr etc setq #64-1 rdlong font, fontaddr setq2 #20-1 'read 20 LONGs = 80 chars rdlong 0, screenaddr rep @endloop, #20 ' 20 loops * 4 chars/loop = 80 chars rdlut d, ptra++ ' read 4 chars getbyte c, d, #3 altgb c, #font rolbyte a, 0-0, #0 getbyte c, d, #2 altgb c, #font rolbyte a, 0-0, #0 getbyte c, d, #1 altgb c, #font rolbyte a, 0-0, #0 getbyte c, d, #0 altgb c, #font rolbyte a, 0-0, #0 wrlut a, ptrb++ ' write 32 pixels endloop '14.5 instructions (29 clocks) per 32 pixels setq2 #20-1 'write back 20 LONGs = 640 pixels wrlong 0, bufaddrA coloured text version with blinking is more involved and would take 3 additional COGs at a 1x pixel clock divider each COG doing every 3rd scanline, or 1 additional text COG with a 3x divider (easier to code). There should also be a way to get it down to 2 additional text COGs with a 2x clock divider but I haven't investigated that one. The 3x divider would allow coloured XGA test at 195MHz P2 and only two COGs (1 driver + 1 text), which is barely an overclock. If you had 3 total video COGs you could do it at 130MHz, or with 4 COGs down at 65MHz.
The unrolled loop below takes 49 clocks per character pair multiplied by 40 for VGA = 1960 clocks out of the 2400 cycle budget with 3x text COGs or a 3x clock divider and one COG. This leaves plenty of time to load the 64 font longs plus read/write the 80 longs of input/output data, with per scanline housekeeping overhead. Higher resolutions work similarly.
rep @endloop, #40 'repeat 40 times (49 clocks per 16 pixels) rdlut d, pb 'read pair of characters/colours getword c, d, #1 'save top word the long altgb b, #font 'determine font lookup address getbyte pixels, 0-0, #0 'get font for character's scanline testflash1 bitl d, #15 wcz 'test (and clear) flashing bit flash1 if_c and pixels, #$ff 'make it all background if flashing movbyts d, #%01010101 'colours becomes BF_BF_BF_BF mov b, d 'grab a copy for muxing step next rol b, #4 'b becomes FB_FB_FB_FB setq ##$F0FF000F 'mux mask adjusts fg and bg colours muxq d, b 'c becomes FF_FB_BF_BB movbyts d, pixels 'select pixel colours for char wrlut d, ptrb++ 'write coloured pixel data into LUT altgb b, #font 'determine font lookup address getbyte pixels, 0-0, #0 'get font for character's scanline testflash2 bitl c, #15 wcz 'test (and clear) flashing bit flash2 if_c and pixels, #$ff 'make it all background if flashing movbyts c, #%01010101 'colours becomes BF_BF_BF_BF mov b, c 'grab a copy for muxing step next rol b, #4 'b becomes FB_FB_FB_FB setq ##$F0FF000F 'mux mask adjusts fg and bg colours muxq c, b 'c becomes FF_FB_BF_BB movbyts c, pixels 'select pixel colours for char wrlut c, ptrb++ 'write coloured pixel data into LUT endloopI might still think about this though. It's not a perfectly even balance unfortunately because the main driver COG has other per scan line overheads too that this text only COG doesn't have. It might be more like an 800:640 split for example, though 2x COGs at 2x rate may allow closer to a 50:50 split because it is gives you 33% more processing time than you need.
I think the only way to reasonably split the work this way with these 2 COGs is to do the first half of the line in one COG and the second half in the other COG. If you want a mouse it would need to be overlayed as late as possible too so finishing sufficiently early is important too. The driver COG already has to finish within the active portion of the previous scanline. Ideally the text COG would need to finish around then too so the mouse can still work at those low speeds.
Update: Looking at the numbers I think a 50:50 split should be doable with 2x divider and 2 total COGs.
I've put in a fix into the code (add this new line at interlacedcommon). I created a timing structure with Chip's progressive NTSC timing and added it below if you wanted to try it too. You'd need to create the display with the VID#PROGRESSIVE flag and hack in this timing instead. There is a little bit of mucking around to hook it in for testing.
interlacedcommon if_nz setr hsync, #$198 'remove xzero if CVBS or S-Video getword a, m_vi, #0 'get visible + front porch pixels getword b, m_bv, #0 'get back porch pixelsI replaced @prog240_timing with Chip's progressive timing in the PUB initDisplay() code in p2videodrv.spin2
else ' CVBS/S-video if flags & PAL <> 0 syncFlags |= %0_0_001000 timing := @prog288_timing else timing := @chiptiming ' @prog240_timingand added a 250MHz clock and the computed XFRQ/CFRQ values, which is what Chip uses, plus the timing structure for it.
CON CLK250MHz = %1_000011_0000110001_1111_10_00 '(20MHz/4) * 50/1 = 250 MHz f_color = 3_579_545.0 'colorburst frequency f_scanline = f_color / 227.5 'scanline frequency f_pixel = f_scanline * 400.0 'pixel frequency for 400 pixels per scanline f_clock = 250_000_000.0 'clock frequency f_xfr = f_pixel / f_clock * float($7FFF_FFFF) f_csc = f_color / f_clock * float($7FFF_FFFF) * 2.0 DAT chiptiming long CLK250MHz long 250000000 '_HSyncPolarity___FrontPorch__SyncWidth___BackPorch__Columns ' 1 bit 7 bits 8 bits 8 bits 8 bits long (SYNC_NEG<<31) | ( 50<<24) | ( 29<<16) | ( 65<<8 ) | (256/8) '_VSyncPolarity___FrontPorch__SyncWidth___BackPorch__Visible ' 1 bit 8 bits 3 bits 9 bits 11 bits long (SYNC_NEG<<31) | ( 27<<23) | ( 0<<20) | ( 35<<11) | 192 long round(f_xfr) ' XFRQ parameter long (7<<24) + (18<<16) long round(f_csc) ' CFRQ parameterI've also made it so you could modify the vertical front porch for composite/s-video if you need to, which is what Chip does to get only 192 active scanlines instead of the normal 240. Previously I didn't allow for this but now I do. The sync width is still overridden for video however. That remains fixed for NTSC or PAL (non-component variants).
Just change this line: into this
alti patchvfp, #%100_000 test a wz if_z mov patchvfp, writestat 'no front porch (just equalization)