I got a little ways into the counter documentation and realized that the DACs and video circuits needed explaining, too, because there is a lot of overlap among them.
The counter section is not done, but the DACs and video sections are, though the video section will get more example code to round it out. All the critical stuff is in there, anyway.
Here is a picture of the sample program at the end of the doc file making some luma-graduated color bars on 1280x1024 VGA. The program that does this is very short:
''*******************
''* VGA 1280x1024 *
''*******************
' P0 = HSYNC
' P1 = BLUE
' P2 = GREEN
' P3 = RED
' P4 = VSYNC
CON
_clkmode = xinput
_xinfreq = 60_000_000
DAT org
reps #64,#2 'start 8-bit incrementing sequence at $BB
setspa #$BB
pusha luma
add luma,lumad
setctra #%00111 'set ctra for PLL*8
setfrqa frqa_ 'set frqa
setvid #%0100 'set vid for vga output
setvidy vidy_ 'set yiq coefficients
setvidi vidi_
setvidq vidq_
cfgdacs #%11_11_11_11 'set dacs to video mode
cfgpins pinmask,pindacs 'set pins for dac outputs
'
'
' Field loop
'
field mov x,#38 'top blanks
call #blank
mov y,lines_vis 'set visible lines
line call #sync 'do horizontal sync
waitvid mode,#0 '1280 clocks per waitvid
djnz y,#line 'another line?
mov x,#1 'bottom blanks
call #blank
setp #4 'do vertical sync
mov x,#3
call #blank
clrp #4
jmp #field 'field loop
blank call #sync 'blank lines
waitvid v1280,sync_color0
djnz x,#blank
blank_ret ret
sync 'horizontal sync
sync_ret retd
waitvid v48,sync_color0
waitvid v112,sync_color1
waitvid v248,sync_color0
'
'
' Initialized data
'
luma long $03020100
lumad long $04040404
frqa_ long $3800_0000
vidy_ long $00_2C_00_00 'red gain
vidi_ long $00_00_2C_00 'green gain
vidq_ long $00_00_00_2C 'blue gain
pinmask long %1111 'pin mask for P0..P3
pindacs long %1111_101100000 'pin configuration for video DAC
' color base mode clocks/pixel clocks/waitvid
mode long $BB << 24 + $A << 20 + 5 << 13 + 1280
lines_vis long 1024
sync_color0 long $0_000000
sync_color1 long $1_000000
v48 long 48
v112 long 112
v248 long 248
v1280 long 1280
x long 0
y long 0
setctra #%00111 'set ctra for PLL*8
setfrqa frqa_ 'set frqa
frqa_ long $3800_0000
Based on the intervals, this is running the screen refresh rate at 60Hz. But between the _xinfreq and the CTRA output, I can't seem to get numbers (e.g pixel frequency of 108MHz) that match what I'm expecting for 1280x1024@60Hz. Can someone spell it out for me?
' color base mode clocks/pixel clocks/waitvid
mode long $BB << 24 + $A << 20 + 5 << 13 + 1280
Can you clarify the clocks/pixel field in the mode value? I thought the dot clock was the same as the pixel clock, so this is confusing me. Something to do with the DAC, maybe?
Can you clarify the clocks/pixel field in the mode value? I thought the dot clock was the same as the pixel clock, so this is confusing me. Something to do with the DAC, maybe?
Oh, wait. I think I just figured this out. The stack contains only 256 pixel values (64 registers * 4 8-bit pixel values), but outputting 1280 pixels. So the clocks/pixel means "repeat each pixel for X clocks".
Oh, wait. I think I just figured this out. The stack contains only 256 pixel values (64 registers * 4 8-bit pixel values), but outputting 1280 pixels. So the clocks/pixel means "repeat each pixel for X clocks".
That's right. Each pixel is repeated for 5 clocks, making 256 pixels over 1280 clocks.
About FRQA being $3800_0000... At 60MHz, $8000_0000 would result in a 30MHz PHSA rollover. So, $3800_0000/$8000_0000 would result in 13.125MHz rollover. With the PLL multiplying it 8 times, you'd get 105MHz for the VID dot clock. It's not 108MHz, but close enough. $3800_0000 is a good value, since there are only three contiguous set bits, which the PLL can digest pretty well without noticeable "birdies" appearing in the output, causing pixel positions to shift slightly to and fro on the monitor.
Do we have an estimate on when the DAC adapter boards will be available?
I just got the latest rev's yesterday. The DE0-Nano board was used in the video example above. I need to do some quick checks and give the go-ahead to build both boards up so we can send them out to you guys.
I just finished testing both of the latest DE0-Nano and DE2-115 add-on boards and they look perfect now, so we will build them and send them out next week.
I just finished testing both of the latest DE0-Nano and DE2-115 add-on boards and they look perfect now, so we will build them and send them out next week.
That's great! I know everyone else wants to do video but I'm looking forward to being able to boot from SPI flash and start work on XMM mode.
I just finished testing both of the latest DE0-Nano and DE2-115 add-on boards and they look perfect now, so we will build them and send them out next week.
XMM mode is a big deal David! That's not an area where I think my skills match up well, but I'm pretty excited about the prospect of running large programs faster on P2.
Totally agree with that Ym2413a. The video methods look fantastic, and the new streaming model will certainly allow a major performance boost for higher resolutions and free more COGs. Great design work!
One related question I have for Chip is whether we really have a RGBI nibble format or IRGB in STR4_RGBI4? From the latest documentation:
%1000 = STR4_RGBI4 - 4-bit pixels are streamed from stack RAM starting at %AAAAAAAA
plus S[7:0], with S[31..29] selecting the starting nibble. The
pixels are colored as:
%0000 = black
%0001 = dark grey
%0010 = dark blue
%0011 = bright blue
%0100 = dark green
%0101 = bright green
%0110 = dark cyan
%0111 = bright cyan
%1000 = dark red
%1001 = bright red
%1010 = dark magenta
%1011 = bright magenta
%1100 = olive
%1101 = yellow
%1110 = light grey
%1111 = white
This documentation shows the RGBI nibble format, but I was wondering why it was encoded like this if standards such as CGA used the latter. Was the difference arbitrary/intentional? Was only wondering if this will mean some extra translation may be required for 16 color bitmaps exported from the PC etc...? I suspect it just doesn't matter much in the end as CGA is so ancient these days and we have bit shift instructions if we need them and 16 bit color will probably be more useful for text modes than bitmaps. It just stood out when I looked a the order of the colors in this list and saw them in this particular sequence which is different to how I remembered the PC's colors back in the day which had the msb of the nibble as the intensity bit IIRC.
Totally agree with that Ym2413a. The video methods look fantastic, and the new streaming model will certainly allow a major performance boost for higher resolutions and free more COGs. Great design work!
One related question I have for Chip is whether we really have a RGBI nibble format or IRGB in STR4_RGBI4? From the latest documentation:
%1000 = STR4_RGBI4 - 4-bit pixels are streamed from stack RAM starting at %AAAAAAAA
plus S[7:0], with S[31..29] selecting the starting nibble. The
pixels are colored as:
%0000 = black
%0001 = dark grey
%0010 = dark blue
%0011 = bright blue
%0100 = dark green
%0101 = bright green
%0110 = dark cyan
%0111 = bright cyan
%1000 = dark red
%1001 = bright red
%1010 = dark magenta
%1011 = bright magenta
%1100 = olive
%1101 = yellow
%1110 = light grey
%1111 = white
This documentation shows the RGBI nibble format, but I was wondering why it was encoded like this if standards such as CGA used the latter. Was the difference arbitrary/intentional? Was only wondering if this will mean some extra translation may be required for 16 color bitmaps exported from the PC etc...? I suspect it just doesn't matter much in the end as CGA is so ancient these days and we have bit shift instructions if we need them and 16 bit color will probably be more useful for text modes than bitmaps. It just stood out when I looked a the order of the colors in this list and saw them in this particular sequence which is different to how I remembered the PC's colors back in the day which had the msb of the nibble as the intensity bit IIRC.
Cheers,
Roger.
My mistake, sort of. I meant to replicate the old VGA color palette, but I put the intensity bit in the LSB, not the MSB. I think I might have done that because in other similar modes on the Prop2, the intensity bits were always in the LSB's, so that they could be masked in more simply in software. Oh, well...
Thanks for the explanation Chip. Don't think it is going to be too much of a dealbreaker. Can't wait for the final device to come out to try out with some higher resolutions/color depths and external SRAM.
Has anyone else had performance issues with Google Docs? It had become very slow for me and is nearly impossible to open the files on anything other than a desktop/laptop. I would still like to work on a centralized reference, but not in GDocs. Thoughts?
A while ago, I downloaded the current state of the doc, and began converting it to LyX. Once I finish, I intend to update the original to the latest again, apply the changes, then post it here. So far, the output is pretty nice.
Comments
So, here is some new documentation:
Prop2_Docs.txt
The counter section is not done, but the DACs and video sections are, though the video section will get more example code to round it out. All the critical stuff is in there, anyway.
Here is a picture of the sample program at the end of the doc file making some luma-graduated color bars on 1280x1024 VGA. The program that does this is very short:
''******************* ''* VGA 1280x1024 * ''******************* ' P0 = HSYNC ' P1 = BLUE ' P2 = GREEN ' P3 = RED ' P4 = VSYNC CON _clkmode = xinput _xinfreq = 60_000_000 DAT org reps #64,#2 'start 8-bit incrementing sequence at $BB setspa #$BB pusha luma add luma,lumad setctra #%00111 'set ctra for PLL*8 setfrqa frqa_ 'set frqa setvid #%0100 'set vid for vga output setvidy vidy_ 'set yiq coefficients setvidi vidi_ setvidq vidq_ cfgdacs #%11_11_11_11 'set dacs to video mode cfgpins pinmask,pindacs 'set pins for dac outputs ' ' ' Field loop ' field mov x,#38 'top blanks call #blank mov y,lines_vis 'set visible lines line call #sync 'do horizontal sync waitvid mode,#0 '1280 clocks per waitvid djnz y,#line 'another line? mov x,#1 'bottom blanks call #blank setp #4 'do vertical sync mov x,#3 call #blank clrp #4 jmp #field 'field loop blank call #sync 'blank lines waitvid v1280,sync_color0 djnz x,#blank blank_ret ret sync 'horizontal sync sync_ret retd waitvid v48,sync_color0 waitvid v112,sync_color1 waitvid v248,sync_color0 ' ' ' Initialized data ' luma long $03020100 lumad long $04040404 frqa_ long $3800_0000 vidy_ long $00_2C_00_00 'red gain vidi_ long $00_00_2C_00 'green gain vidq_ long $00_00_00_2C 'blue gain pinmask long %1111 'pin mask for P0..P3 pindacs long %1111_101100000 'pin configuration for video DAC ' color base mode clocks/pixel clocks/waitvid mode long $BB << 24 + $A << 20 + 5 << 13 + 1280 lines_vis long 1024 sync_color0 long $0_000000 sync_color1 long $1_000000 v48 long 48 v112 long 112 v248 long 248 v1280 long 1280 x long 0 y long 0Based on the intervals, this is running the screen refresh rate at 60Hz. But between the _xinfreq and the CTRA output, I can't seem to get numbers (e.g pixel frequency of 108MHz) that match what I'm expecting for 1280x1024@60Hz. Can someone spell it out for me?
Can you clarify the clocks/pixel field in the mode value? I thought the dot clock was the same as the pixel clock, so this is confusing me. Something to do with the DAC, maybe?
Oh, wait. I think I just figured this out. The stack contains only 256 pixel values (64 registers * 4 8-bit pixel values), but outputting 1280 pixels. So the clocks/pixel means "repeat each pixel for X clocks".
That's right. Each pixel is repeated for 5 clocks, making 256 pixels over 1280 clocks.
About FRQA being $3800_0000... At 60MHz, $8000_0000 would result in a 30MHz PHSA rollover. So, $3800_0000/$8000_0000 would result in 13.125MHz rollover. With the PLL multiplying it 8 times, you'd get 105MHz for the VID dot clock. It's not 108MHz, but close enough. $3800_0000 is a good value, since there are only three contiguous set bits, which the PLL can digest pretty well without noticeable "birdies" appearing in the output, causing pixel positions to shift slightly to and fro on the monitor.
I just got the latest rev's yesterday. The DE0-Nano board was used in the video example above. I need to do some quick checks and give the go-ahead to build both boards up so we can send them out to you guys.
XMM mode is a big deal David! That's not an area where I think my skills match up well, but I'm pretty excited about the prospect of running large programs faster on P2.
I scanned over the document twice to make sure I wrapped my brain around it.
I'm excited for the 8-bit mode with the 2+8+8+8 CLUT.
One related question I have for Chip is whether we really have a RGBI nibble format or IRGB in STR4_RGBI4? From the latest documentation:
%1000 = STR4_RGBI4 - 4-bit pixels are streamed from stack RAM starting at %AAAAAAAA plus S[7:0], with S[31..29] selecting the starting nibble. The pixels are colored as: %0000 = black %0001 = dark grey %0010 = dark blue %0011 = bright blue %0100 = dark green %0101 = bright green %0110 = dark cyan %0111 = bright cyan %1000 = dark red %1001 = bright red %1010 = dark magenta %1011 = bright magenta %1100 = olive %1101 = yellow %1110 = light grey %1111 = whiteThis documentation shows the RGBI nibble format, but I was wondering why it was encoded like this if standards such as CGA used the latter. Was the difference arbitrary/intentional? Was only wondering if this will mean some extra translation may be required for 16 color bitmaps exported from the PC etc...? I suspect it just doesn't matter much in the end as CGA is so ancient these days and we have bit shift instructions if we need them and 16 bit color will probably be more useful for text modes than bitmaps. It just stood out when I looked a the order of the colors in this list and saw them in this particular sequence which is different to how I remembered the PC's colors back in the day which had the msb of the nibble as the intensity bit IIRC.Cheers,
Roger.
My mistake, sort of. I meant to replicate the old VGA color palette, but I put the intensity bit in the LSB, not the MSB. I think I might have done that because in other similar modes on the Prop2, the intensity bits were always in the LSB's, so that they could be masked in more simply in software. Oh, well...
I prefer the consistency between all modes.
(deleted)
Looks good and is a lot easier to read.
Edit: File deleted.
--- file deleted ---
Propeller.wiki spaces.com
We'd lose the simultaneous edit ability, but gain more flexible organization. I'm fine with that. Is Chip/Parallax ok with us using the wiki?