NTSC/PAL 4bpp Driver Inside Spin2 Cog
cgracey
Posts: 14,151
I finally made a 4bpp driver that lives in the Spin2 interpreter cog's empty registers and runs on streamer-empty interrupts.
https://drive.google.com/file/d/1w8elHtgySjdTT5YTEejwBy_Om9DYY_WF/view?usp=sharing
In the demo, both progressive and interlaced 16:9 sample images are included.
We could make some drawing routines and have a nice 16-color graphical display that doesn't use any other cogs.
For 16:9 monitors, to have square pixels, we have these maximum resolutions possible in NTSC:
416 x 240 progressive (49 KB bitmap)
832 x 480 interlaced (195 KB bitmap)
PAL could go a little larger, but the color modulation is messy-looking.
839 x 588 - 44K
Comments
We could add an interrupt for a sound player (INT2) and the 5-buttons-on-1-pin (INT3) code to make this work with the ARC8ADE system, with the ability to program games in Spin2 and then instantiate them as single-cog objects.
Just ran it, wow, that's cool. How much of the COG's time do you expect is used by this if interrupting every 8 pixels? Any good way to benchmark that?
The bottleneck is when the Spin2 interpreter does a CORDIC operation (like *) and blocks interrupts long enough to get the CORDIC result. That's maybe 58 clocks. In interlaced mode, you need to run at least 254 MHz to get through that bottleneck. It's less for non-interlaced mode. For 320 x 240 (4:3 aspect ratio), you probably would only need 100 MHz.
By going to 2bpp, we would deliver pixels at half the current rate, because we'd be handing off 16 at a time, instead of 8. That would relax things quite a bit. Also, fewer bits-per-pixel and pixels-per-line reduce how many longs need to be buffered, freeing up lots of registers for valuable interrupt code.
These 1-wire composite monitors are very inexpensive and can be great monochrome (no chroma) text displays. I'm tempted to make a text driver, but with some graphics routines, we'd have something to rival 1980's color video games.
Yeah the CORDIC will block but that is part of the application code so doesn't count. Looking at your video code I'm guessing @300MHz it's in the region of ~10% COG overhead or so if you burn (say) 16 P2 clocks every 8 pixels in the active portion with 832 pixel being sent, but I'm not sure of the actual total overhead per interrupt. Plus there is the sync stuff where you use the COG more, but the blanking part gives back too. My gut feeling says it could be around 10% or thereabouts....let's say within 5-20%.
Yeah the one wire monochrome composite still has its use. I have an old monochrome amber video monitor from the 80's which looks retro AF, and would benefit from being driven by the P2, especially for debug in SPIN code etc. You could map SEND to this and have a nice way to debug your code live with no extra COG used. Maybe even hooked up to some type of debugger. That's where it could be useful.
Here is the Parallax font being output by this driver. This would only need a 1bpp driver.
Yes, about 10% on average, I think.
Yes a 1bpp driver would be even less, with only 1/4 of the interrupt rate. If the overhead to debug SPIN internally is only around 2-4% that would be fabulous. One issue might be the impact on the amount of inline assembly that would be possible with this video code loaded?
Right now, we buffer a line of up to 832 pixels. That''s 104 longs. That would become 26 longs if we were doing 1bpp. That would free up lots of space.
That's a helpful saving. Do you think you would be able to do text as a graphics scan line filled by the COG in interrupt context on the fly from a text buffer (to save HUB RAM). You'd need to read the character value and font table etc. Hopefully achievable in the sync/blanking portion, but this obviously won't be as fast as setq transfer burst and will consume more COG cycles. Other option is more hub RAM being used and have the COG application context populate the 1bpp frame buffer from font table in a SEND routine for example. Easier if the driver could do text generation but will consume more COG cycles all the time then, vs not much if the buffer is unchanging. Typical space-time tradeoff.
Super cool!
16 colors is just great. Often 2bpp drivers end up with palettes and or tiles. This all did not see anywhere near the use many of us thought it might.
A full on 16 color bitmap will deliver a lot more for a modest cost, IMHO. Great choice!
Re: one wire composite
Yeah, I still use it and have both el cheapo displays and a super nice pro grade one that will display any composite.
My other favorite one wire is component, just the Y input gets one all the way to 1080i/p depending. Huge bang for the pin! And, at 1bpp, dithers make a lot of sense.
(One of these days, I want to run the color diff signals on a lower clock to get max bang for the RAM.)
@potatohead
What are you up to these days? You did some cool things on the P1. I remember your Apple 2 style color NTSC driver and Nyan cat!
Lol, a few things:
Had to take over raising my granddaughter. Son got sucked into meth. There is hope, but a long road yet. Upside is she likes stuff we like. So, fun times ahead.
She is five, likes music, dance, games, science. She is just getting into the classics!
Startup. Been a grind. We had a Propeller 1 product out to market and it is successful. I am about to send Ken photos he asked for right when we sold our last one and had to remanufacture. I inherited that mess, cost reduced it and am building the first two this week.
Why?
Company producing it got bought and quit making it for us, so right at this moment I am just about through bringing it in house!
I miss banging around on P2 very much. I did just set my eval board and misc displays up this weekend though. I want to at least run some of the latest. I did get to fire up your work and begin to explore a little right as this all went down. (Nice, very nice) Maybe finish up on a little brick out game using the gortzel for control I had started. (Think a little english, or physics on the ball by waving a hand or finger around.
Those things plus this pandemic just maxxed me out!
Ouch.... Life is not always easy! Glad you still have time to come back here from time to time.
It will, is, passing! Once I have the product remanufacture project done, I free up a lot more. Got My P2 eval board setup, scope, pro multi format CRT.
I gotta run these latest driver efforts. Having proper, old school stuff on this chip is exciting!
This weekend I also setup a Retropie. She is old enough apparently. A little while ago, she wanted to check my Apple //e out and we learned she can play pretty well at 5.
She insisted on "Mad Max" on NES on the Retropie, after I showed her Ms Pac Man, to which she said, "Those baddies just won't leave me alone papa", and later found her some considerable way into the Mad Max game! Call me impressed.
Motivation: "I like finding new places." Ok little one, open world inclination noted. We are absolutely playing FF7 together at some point.
Her current fave so far is Drol on Apple 2. That is a beautiful game, so why not?
That's awesome Chip
So much you can do with those handy interrupts! and getting spin and the tv driver in one cog is pretty cool.