Sorry, I didn't actually test it on a DE0 at the time.
Here's a fixed up version that has been tested on a DE0 successfully. I've just repeated every scan line twice (halves the hub ram buffer to 24kB) but used an offset of 1 pixel so the diagonal is still as sharp as you'd get with 256x192 buffer if you had the full ram, if that makes sense?
Oh, okay. I'd naturally thought it was something I had done wrong. I'll try this one too.
BTW: Maybe I'm OK with RP2 on P0..P3 after all... Did a quick test on this program by adding in two lines to toggle P0 and it seems to work, without affecting the video:
'
' Field loop
'
field mov x,#34 'top blanks
call #blank
or dira,#1 'RJA
xor pina,#1
BTW: Maybe I'm OK with RP2 on P0..P3 after all... Did a quick test on this program by adding in two lines to toggle P0 and it seems to work, without affecting the video:
'
' Field loop
'
field mov x,#34 'top blanks
call #blank
or dira,#1 'RJA
xor pina,#1
I was about to reply to your earlier message to say, I think you'd be fine, because I think the DACs are somewhat "internal" and probably can't be directed to pins anyway until we get silicon
Today's job is to try hooking up the DE2 to the real world, about 26 i/o, so I'll soon know for sure if there are issues. It's the same connector pinout so I should be able to try it on the DE0 too
I notice some issues when I used your driver to display a bitmap, there are some variances between tv lines.
To check this out I modified the bitmap generation section of your code to draw a white vertical line 16 pixels wide down the middle of the screen.
'****GC MODS****
setptra hubbuf 'move pointer to start of screen buffer in hub ram
mov y,#linestot 'get total number of lines to display, depends on available memory
bufwr reps #120, #1 'first 127 pixels / exactly one line
nop 'spare
wrbyte 255, ptra++ 'write one pixel and move ptra onto next one
reps #16, #1 'next 2 pixels / exactly one line
nop 'spare
wrbyte 0, ptra++ 'write one pixel and move ptra onto next one
reps #120, #1 'last 127 pixels / exactly one line
nop 'spare
wrbyte 255, ptra++ 'write one pixel and move ptra onto next one
djnz y,#bufwr 'loop to fill buffer
'****GC MODS****
This result in this effect....
Can you help?
Incidentally, your driver for the DE2 does not have the same effect, that is fine.
I did the DE2 version first and got that working. Then I did a DE0 version but didn't test it, and it had some errors.
The DE0 doesn't have enough ram so what I did is make the bitmap 256*96 (24kB) rather than 256*192 (48kB) on the DE2. Then when displaying I just repeat each line (so back to 256*192 at display time), but with a 1 pixel x offset, so it looks the same as the test pattern on the DE2.
It only works because of the diagonal test pattern I made, if you load your own test pattern you probably want to remove that line of code that adds 1 to the offset every second line.
Chip was going to look at whether the DE0 version could have bit more ram. It would be nice if it could make it to ~52kB (allowing a 48kB screen buffer)
I did the DE2 version first and got that working. Then I did a DE0 version but didn't test it, and it had some errors.
The DE0 doesn't have enough ram so what I did is make the bitmap 256*96 (24kB) rather than 256*192 (48kB) on the DE2. Then when displaying I just repeat each line (so back to 256*192 at display time), but with a 1 pixel x offset, so it looks the same as the test pattern on the DE2.
It only works because of the diagonal test pattern I made, if you load your own test pattern you probably want to remove that line of code that adds 1 to the offset every second line.
Chip was going to look at whether the DE0 version could have bit more ram. It would be nice if it could make it to ~52kB (allowing a 48kB screen buffer)
There is no bitmap generation routine in this drive it merely displays a buffer starting at $2000 resolution is fixed at 256x96
I'm using putty and the monitor to download my images to the DE0 from a text file prepared in the correct format.
The I download this program with PNut.
Comments
Oh, okay. I'd naturally thought it was something I had done wrong. I'll try this one too.
...
Tried it, works perfectly.
BTW: Maybe I'm OK with RP2 on P0..P3 after all... Did a quick test on this program by adding in two lines to toggle P0 and it seems to work, without affecting the video:
' ' Field loop ' field mov x,#34 'top blanks call #blank or dira,#1 'RJA xor pina,#1I was about to reply to your earlier message to say, I think you'd be fine, because I think the DACs are somewhat "internal" and probably can't be directed to pins anyway until we get silicon
Today's job is to try hooking up the DE2 to the real world, about 26 i/o, so I'll soon know for sure if there are issues. It's the same connector pinout so I should be able to try it on the DE0 too
I notice some issues when I used your driver to display a bitmap, there are some variances between tv lines.
To check this out I modified the bitmap generation section of your code to draw a white vertical line 16 pixels wide down the middle of the screen.
'****GC MODS**** setptra hubbuf 'move pointer to start of screen buffer in hub ram mov y,#linestot 'get total number of lines to display, depends on available memory bufwr reps #120, #1 'first 127 pixels / exactly one line nop 'spare wrbyte 255, ptra++ 'write one pixel and move ptra onto next one reps #16, #1 'next 2 pixels / exactly one line nop 'spare wrbyte 0, ptra++ 'write one pixel and move ptra onto next one reps #120, #1 'last 127 pixels / exactly one line nop 'spare wrbyte 255, ptra++ 'write one pixel and move ptra onto next one djnz y,#bufwr 'loop to fill buffer '****GC MODS****This result in this effect....
Can you help?
Incidentally, your driver for the DE2 does not have the same effect, that is fine.
Regards,
Coley
I did the DE2 version first and got that working. Then I did a DE0 version but didn't test it, and it had some errors.
The DE0 doesn't have enough ram so what I did is make the bitmap 256*96 (24kB) rather than 256*192 (48kB) on the DE2. Then when displaying I just repeat each line (so back to 256*192 at display time), but with a 1 pixel x offset, so it looks the same as the test pattern on the DE2.
It only works because of the diagonal test pattern I made, if you load your own test pattern you probably want to remove that line of code that adds 1 to the offset every second line.
Chip was going to look at whether the DE0 version could have bit more ram. It would be nice if it could make it to ~52kB (allowing a 48kB screen buffer)
cheers
tubular
I see why you did that now...
I changed the code as you suggested, from this.....
line call #hsync 'do horizontal sync waitvid v_bo,#0 'black left border test y,#1 wz 'even line? if_nz subptra #257 'repeat previous line if_z addptra #1 waitvid mode,#$80 '64*9 clocks per waitvid setspa #$80 call #render 'do waitvid and render 1st 64 pixelsto this....
line call #hsync 'do horizontal sync waitvid v_bo,#0 'black left border test y,#1 wz 'even line? if_nz subptra #256 'repeat previous line waitvid mode,#$80 '64*9 clocks per waitvid setspa #$80 call #render 'do waitvid and render 1st 64 pixelsand that resulted in this ;-)
Many thanks,
Coley
I'm as excited for P2 as the first time I saw P1, Baggers even more so lol
Exciting times lay ahead!!!
Coley
Thanks for that info
Give this a try, I'm not 100% happy with it but it's a good start.
P2_PAL_252x96_8bit_Greyscale_DE0.spin
There is no bitmap generation routine in this drive it merely displays a buffer starting at $2000 resolution is fixed at 256x96
I'm using putty and the monitor to download my images to the DE0 from a text file prepared in the correct format.
The I download this program with PNut.
An example image file is here... vader.txt
Regards,
Coley
line call #hsync 'do horizontal sync waitvid v_bo,#0 'black left border incmod ycnt,#2 wc '3rd line? if_nc subptra #256 'repeat previous line waitvid mode,#$80 '64*9 clocks per waitvid setspa #$80 call #render 'do waitvid and render 1st 64 pixelsWhen INCMOD executes, if ycnt=2 then it is set to 0 and C=1, else ycnt++ and C=0.