Propeller Backpack TV Overlay with User-defined Character Glyphs
Phil Pilgrim (PhiPi)
Posts: 23,514
Attached is an update to the original Prop Backpack TV overlay object, which allows users to define their own character glyphs (bitmaps). Unlike my initial attempt at this capacity, this version does not require mapping the entire font into RAM. Instead, 16-character blocks can be mapped, starting with $F0-$FF and working downwards. This is effected by placing the RAM blocks at the end of memory xxxx - $7FFF, so that they are contiguous with the ROM font, which begins at $8000. By changing the effective font address to the beginning of the RAM section and translating characters written into the overlay's window buffers by the amount of the offset, the font can bridge both RAM and ROM without exacting additional timing requirements on the realtime video overlay code.
-Phil
-Phil
Comments
I'm anxious to try this.· Now where did I put my Prop Backpack (aka HoBo)?
Duane
All,
I've submitted the package to the OBEX, but it seems either to be stuck in limbo waiting for approval, or was rejected due to missing license boilerplate (which is not missing, BTW). The messages I got back are a bit ambiguous as to the reason for the delay or rejection.
-Phil
This is great.· I'm got little guys waving at me across the top of the screen.
This has so much potential!
Thanks Phil!
The demo appears to use 2,654 longs.· I'm guessing this doesn't include the custom characters.· Are there any other resources using memory (besides normal stack stuff)?
I know some of the video drives look like they have plenty of free memory but if your program is too long then either your program doesn't work or you get weird stuff on the screen.
I'm hoping there is as much free memory (or nearly so) as F8 is telling me there is.
Again, Phil·thank you very for such a useful object.
Duane
Thank you for the programmable character version. I was able to get the little guy waving, but is there any way to get a window that is 1 character wide? When I select 1 or 2 I always get 2 characters wide. I want a window that is 1 character wide by 120 tall, then I add a 2-line mod to the SPIN code so that for a one-column display the characters are 2 lines high and voila, you have a 28800 baud data stream piggybacked on the video, while still allowing on-screen display.
Darryl
I think two characters wide is the minimum. Also, the custom characters have to have the same pixel dimensions as the ROM font, so a character two lines high will not be possible with the current firmware.
-Phil
Thank you for clearifying. I could live with two-characters wide, although I am curious if that is easily fixed, a hardware limit, or a significant software change? I noticed in the SPIN code, it handles the first character separately, and then begins a loop.
I was just discovering the 8-lines-per-character issue. My approach would then need 65535 custom characters which is not managable even if it were possible. If I "only" use 256 user characters, my data rate would be limited to 14,400 baud, which is too slow. I could use a second character position, but the data starts eating up significant parts of the viewing space. Besides, I suspect 256 characters at 32 bytes each is not going to fit.
Perhaps I should explain my goal. There are a lot of people doing UAVs and UGVs who want on-screen display and telemetery. Most people use a video transmitter and a separate data transmitter in a different band, with a different antenna. For FPV use the pilot needs live video to fly, so the telemetry takes a back seat. So if a Propeller Backpack could accept a serial data stream at 38400 (or more) and insert that data into the first column on the screen, at two pixels per line that would be 28800 baud, but raw data, no start or stop bits so the equivalent of 36000 baud 8N1 data. Some data could be extracted from the stream and put on-screen as well (thus you may want 57600 baud on the input). On the receiving side, another Propeller Backpack could extract the data to a serial port and optionally blank-out the left edge so the data stream was not distracting. I think there is an opportunity for Parallax to sell a lot of Backpacks. I want to use this on a ground vehicle, where I already have a 2 watt video transmitter, but I am new to the Propeller, and I can't afford to spend months on this small part of my project. I was hoping I could make some simple mods to existing applications.
Darryl
Does your video transmitter also transmit audio? I know some FPV use one of the audio channels to transmit data. I'd think using an audio channel would be a much easier way to add data to the transmission.
Typically, data in a video stream are transmitted in the vertical blanking lines (the ones that do not show up on the screen). That's the way closed captioning is transmitted. The advantage of CC, BTW, is that you can choose at the receiving monitor to display the data or not. Here's an object I wrote that superimposes closed captioning data onto a TV.spin-generated video output.
Perhaps you can modify it to sync from the overlay object instead. You won't get anywhere near 28800 baud with it, however.
-Phil
If you use the audio channel, then you need a modem to modulate an audio tone, and on the receive side, a demodulator to extract the data. The data rate for the most direct approach frequency-shift-keying will be limited to about one tenth the audio frequency. So for a 3KHz audio like a telephone you can only get 300 baud, unless you move to a DSP on each end which is what the 56k modems use.
Instead, I would encode the data as bits in the first character column. On the receiving side, you only have to find the first character position and then see if it is white or black in the first pixel. In fact it might be easier to always start with one pixel of white folowed by one data pixel. If you limit to two bits per line (example:white,data,black,white,data), 240 lines at 60-per-second, you get 28800 baud data throughput (actually equivalent to 36000 baud on a serial port because you send 8 bits not 10).
What I want to do is use 16 custom characters, each 2 lines tall, so there are 120 characters vertically and 240 lines. It appeared in the SPIN code that there was a limit to the number of rows less than 128 so I would use a 2-line-high character. The window would be 1 character wide by 120 characters tall, and would be filled with 120 different custom characters (say $81 to $F9). The transmit code would look at the first character to send , then assign one of the sixteen custom characters to $81,$82,$83,$84. Then it would move to the second character to send and apply that data to .$85-$88 etc. It would have to handle assigning 60 characters during the vertical blanking interval of about 2.5mS.
It would be possible to send more than 2 bits per line, but the clock synchronization of the receiver gets to be more challenging to identify the bit positions.The exact pattern sent could be adjusted to make the decoding easier, for example white-data-black-white-data so there is always a black-white transition before the data. It may be just as easy to send 3 bits per line, but then 3 does not map into an 8-bit character, so then do you throw away the 9th bit? You would get 38400 baud raw throughput, equivalent of 48000 baud on a serial port.
Darryl
You can get 1200 baud with the Bell 202 modem object:
-Phil
I need a lot higher data rate to monitor my UAV. On my bench I use 38400, I could probably live with 19200, but not much less. Just periodically updating the obstacle map takes 2 seconds and the sparse array data is already run-length encoded to reduce the size.
Darryl