Nothing to do with the render engine, but I had to have a little go at something yesterday, as I was wondering if it could be done.
As it happens, doing it this way is only fast enough to do 73 pixels per scanline, but it is on one cog, whilst doing the TV driver also, and not using PIX.
edit: so I scaled the screen to 64pixels wide, although on real Prop2 I will take it to 256.
@all, I have had a brain wave, at how awesome this chip is, and come up with a nice surprise for DE0 owners.
A threaded composite TV driver, which heavily frees up the task, as the tv COG is running at 1/16th of the TASKS most of the time, freeing up oodles or prop goodness for you guys to play with.
It's a 128x96 8bit (RGB:332) bitmap thus also leaving lots of RAM left, even on the DE0s
So with only $3000 for the bitmap, and pretty much three threads available, with 15 out of 16 thread slots to play with, you have the option to code many things whilst also having a display to use.
I have done this too, and I have made the same "mistake" as you ;-)
You really need to use POLVID before every WAITVID to give other tasks a chance to do their things. With a testcode like yours you don't notice that, but if do real code in other tasks (like a serial receive) you get strange results. The other tasks stall for the whole waitvid time. So instead of just a waitvid you need this:
polvid wc
if_nc jmp #$-1
waitvid d,s
The code looks not nice anymore with this, but it helps a lot. You can also call a subroutine which does the POLVID before every WAITVID that saves some instructions, and looks nicer, but is not as efficient.
Added JB_Sprites_DE0, which is a composite TV driver using one cog, for 128x96 8bit RGB:332 bitmap including 8 x 8x16 sprites ( note if you have too many on a line, it will wobble a little ) but you can do great things with the sprites as you will see in the demo.
the sprites are 8bytes of image data and 8 bytes of mask data 16 times for each y line of the sprite ( you will see in the BMP file for the sprites. because it's done this way, you can do some nice things, like ghosting type sprites, again you will see in the demo.
if you alter the BMP image, the sprite will be re-grabbed from the BMP when you use SEND.BAT
also the source file is too big for PNut, so you will have to make your changes, then use SEND.BAT
Thanks Sapieha I'm quite happy with how it turned out, especially for one cog and the fact it's mainly just on one thread too! and you can still do a lot with the other threads, although you can't use the INDA or INDB instructions, at least you have PTRB to play with though.
It should help the DE0 users have some fun with graphics now also, and have cpu power left over to do something with it too.
Here are a couple of nice captures, and a photo of the actual video signal seen on a CRT TV.
Edit: The monochrome one is a luma only capture to show detail. Notice the color artifacts on the capture card version that aren't there in the CRT photograph? The P2 signal quality is now excellent compare to the very best we could get with P1 and the coarse DAC used for video. The smoother video signal really makes the most of the old TV standards. On P1, it was the opposite. Capture card performed better with the sharper signals and ordinary TV's worse. This suggests to me that standard definition LCD TV's might not display this to full potential, the result looking a lot like the capture device.
Can anyone take a photo on a standard definition LCD? I don't have one.
Comments
As it happens, doing it this way is only fast enough to do 73 pixels per scanline, but it is on one cog, whilst doing the TV driver also, and not using PIX.
edit: so I scaled the screen to 64pixels wide, although on real Prop2 I will take it to 256.
On real Prop this will have a fighting chance
It also fits in DE0.
test.zip
Worked fine on my DE0.
@pedward
It's composite out on Dac0 of a rotating zooming map.
Regards,
Coley
@all, I have had a brain wave, at how awesome this chip is, and come up with a nice surprise for DE0 owners.
A threaded composite TV driver, which heavily frees up the task, as the tv COG is running at 1/16th of the TASKS most of the time, freeing up oodles or prop goodness for you guys to play with.
It's a 128x96 8bit (RGB:332) bitmap thus also leaving lots of RAM left, even on the DE0s
So with only $3000 for the bitmap, and pretty much three threads available, with 15 out of 16 thread slots to play with, you have the option to code many things whilst also having a display to use.
Edit: Updated and moved to first post.
Let me know if you think it's useful?
You really need to use POLVID before every WAITVID to give other tasks a chance to do their things. With a testcode like yours you don't notice that, but if do real code in other tasks (like a serial receive) you get strange results. The other tasks stall for the whole waitvid time. So instead of just a waitvid you need this:
polvid wc if_nc jmp #$-1 waitvid d,sThe code looks not nice anymore with this, but it helps a lot. You can also call a subroutine which does the POLVID before every WAITVID that saves some instructions, and looks nicer, but is not as efficient.Andy
@cluso99, yeah, don't try yet, get debugger and spin sorted first :P
Edit: updated and put in first post! Thanks again to Andy
the sprites are 8bytes of image data and 8 bytes of mask data 16 times for each y line of the sprite ( you will see in the BMP file for the sprites. because it's done this way, you can do some nice things, like ghosting type sprites, again you will see in the demo.
if you alter the BMP image, the sprite will be re-grabbed from the BMP when you use SEND.BAT
also the source file is too big for PNut, so you will have to make your changes, then use SEND.BAT
Nice Work!!!
It should help the DE0 users have some fun with graphics now also, and have cpu power left over to do something with it too.
Will tidy up how to get image to SDRAM, so it's simple, then upload source tomorrow
Thanks Chip!
Looking forward to it. I'm working on another project, so I won't have much time for SDRAM for a week or so.
Functions nice on my DE2 and LCD TV
> Only some picture flicking but very little
Not that.
It is some brighter horizontal lines (In background) that go from TOP to bottom of LCD picture --- Picture are sharp
I made simple mov --- but on it I don't see this.
I think once P2 finally ships and we have real silicon it (DE2) will be useful on that other project we are doing ;-)
Regards,
Coley
Edit: The monochrome one is a luma only capture to show detail. Notice the color artifacts on the capture card version that aren't there in the CRT photograph? The P2 signal quality is now excellent compare to the very best we could get with P1 and the coarse DAC used for video. The smoother video signal really makes the most of the old TV standards. On P1, it was the opposite. Capture card performed better with the sharper signals and ordinary TV's worse. This suggests to me that standard definition LCD TV's might not display this to full potential, the result looking a lot like the capture device.
Can anyone take a photo on a standard definition LCD? I don't have one.
VGA 1024x768 SDRAM driver
Surely you mean 16 bit Colour !!!!
Looks great Jim, as always sterling work.
Regards,
Coley
Coley, thanks for posting a pic too!