QuadView 4-in1 artifact color driver
System
Posts: 42
in Propeller 2
This discussion was created from comments split from: P2 Arc8de Project.
Comments
Here we go, I present the QuadView video driver. Runs 4 composite video displays at 704x240 resolution in monochrome or artifact color. Can also do 8 monitors with 2 cogs. The example program I included will run up to 8 displays, but the second four are just repeats because I'm lazy. Just set the VIDEO_X constants to the pins you want, it will try to map them onto the available DAC channels.
I've also included a little script that will convert PNGs into raw artifact color buffers.
I'll write some more about this later, but too lazy right now.
That's cool @Wuerfel_21
Not sure if you can interleave the CPU with interrupts, if it's using xcode. I'm sure Chip could chime in, as he'd know best if it could be done.
There's some spare time in the video cogs during VBLANK, that could be used to some good. But really, the point is to be able to have the other cogs do the rendering and logic without being interrupted / prevented from using the FIFO/hubexec.
Also, I just noticed I bungled the pin%4==1 channel, here's that fixed.
Here's a slight modification that uses 4bpp instead of 8bpp. Slightly less-than ideal because only nibbles 5 throug F are actually useful values, but the quality is pretty OK still. This can of course fit 6 stills in RAM, so hey, this demo actually does 8 distinct displays! Obviously not very useful if one is rendering real-time graphics, but interesting still.
@Wuerfel_21
Hoping to try this out but what toolchain are you using to build your code? It failed when I first tried with flexspin (an older version) but then even the lastest flexspin doesn't seem to like it...was this only for PropTool?
I can get it to compile by hardcoding with 72 instead of qv.LEVEL_BLANKING on the offending lines.
Interesting flickering video effect I'm seeing on the 4th channel BTW. Not sure how much is by design or an artifact. It's very impressive out of a single COG.
I've only really tried it in PropTool, flexspin is currently just crashing for me. There shouldn't be any flickering, just some still images and some effects rendered by other cogs.
No there is some serious flickering when compiled with flexspin - seems like sync issues or something picky with my Dell monitor NTSC input although the first 3 channel outputs are stable. When I fire up my Windows machine next time I'll try it with PropTool.
Reverted to the latest flex release binaries and yeah, the alpha blending thing isn't properly synchronizing with the video cog. Odd, since that's just plain assembly.
That's really neat @Wuerfel_21, nice work!
Cool. Have you tried plugging into the other slots? And the 4bpp variant?
Also, that's some dank black crushing on those displays. Should probably adjust brightness/contrast a bit.
This is a rather fundamental misfeature (IMO) of Spin2 syntax: something like qv.LEVEL_BLANKING[N] may be parsed either as (qv.LEVEL_BLANKING)[N] or as qv.(LEVEL_BLANKING[N]). The former is the appropriate parse if LEVEL_BLANKING is a constant and we're compiling an assembly statement, but the latter is what is desired for arrays, labels, and variables, and hence it's what FlexSpin picks. For now the work-around is to insert explicit parentheses.
Ye, that's an old known issue. Though I don't think array syntax is ever valid in a DAT section, so I think that could be solved.
The broken synchronization between the video cog and the alpha blend cog is weird though.
@Wuerfel_21 can you start another thread for this please?
@"Moderator Monkey" Can you move the posts relating to Wuerfel_21's driver to another thread please?
Yeah, probably preferrable.
Call it "QuadView 4-in-1 artifact color driver" or something
What are the thread post numbers that you wish me to move?
Everything from #122 onwards, I guess
Yes, that's right. Thank you.
Done!
Great display!
What was done to stabilize artifact color?
Nothing in particular. The color burst has to be generated in software, so there's full-ish control over its phase.
Got it. The same ended up being true for P1.
That's a great way to do it though. Will be very stable.
Thanks for this Wuerfel_21! Will be fun and enlightening to look through.
Currently seeing if I can get it to do an indexed mode. Will probably need 350MHz unless I get a really good idea.
Yep, 8bpp paletted/indexed mode works, needs 343MHz.
Working on artifact color VJET.
Still need to rewrite text drawing to be in color and make it handle multiple independent screens (not a big issue, since basically no state is kept in cog RAM between lines)
I may have gotten just a bit sidetracked...
@Ahle2 well, now P2 really is the Amiga of microcontrollers, I guess :P
Here's the code for that - 8 screen simultaneous VJET vector graphics mayhem (though the other 7 aren't that interesting)
LOL, it really is. Not sure which of us said it first, but I believe it's true. (Amiga of Microcontrollers)
I think it was Ahle, that's why I pinged him.
Also, this ball really is made of filled quads (the actual Amiga demo just does bitplane tricks and color cycling), so if I wanted to, I could make it squish, add a second ball, rotate it differently, change the light source, etc.
Oh cool!
Well, I have my P2 setup and a nice PVM I have let sit idle for too long. Will give this a go.
TV Video is still my favorite. Looks like you have it sorted nicely! I saw the option to alternate phase. Very nice work.
Oddly enough, I haven't gotten satisfactory composite video from the actual video hardware yet, neither from @rogloh's code nor Chips. Satisfactory as-in "at least as good as P1 composite".
Part of that is an issue with the hardware design - it's really missing a low-pass filter for IQ and a notch filter for Y. Then again, P1 didn't have those either and it looks loads better. Maybe I should try re-figuring-out the CSC parameters from scratch or smth...
S-Video is fine, oddly enough...