WAHa.06x36 wrote:There are two main problems with 15-bit colour. The first is that I don't think there are 15 free pins on any of the ports on the STM32F4DISCOVERY. If you built your own hardware, this isn't a problem, but if you want to use the ready-made board, even finding eight pins in a row was hard.
Yeah, that's a pretty big problem
. I was aware that 3 pins from port E go to the MEMS accelerometer but I was considering cutting the traces with an x-acto knife. I decided not to do this, since it disables the sensor and I assume most people wouldn't want to do the procedure.
So, forget 15-bit color. Now, I'm proposing 12-bit color. That's still more color depth than the Sega Genesis and it still allows for even color channel lengths. Plus, you could pack two direct colors into three bytes with minimal effort.
WAHa.06x36 wrote:Second, 15-bit colour requires two bytes per pixel, and that means that if you want a framebuffer you get very tight on memory. You can fit a single 320x200 15-bit framebuffer in memory, but then you won't have doublebuffering, which makes it fairly useless.
Assuming you can get past the first problem, one thing you could do is arrange the bits in the pixel somewhat unusually. For instance, something like R3:G3:B5:R2:G2:x1. You could then either send 8-bit pixels to the upper half of the port, or 15-bit pixels to the entire port, letting you use 15-bit colour for those situations where you can figure out how, and 8-bit pixels otherwise.
That's a very creative solution but it benefits the old at the expense of the new.
I think you can make a framebuffer with 8-bit data but still have a higher bit depth at the hardware level. You can have a 256-entry pallet so that you can map the 8-bit colors to their actual hardware bit values. Doing this, you could come up with a "standard palette" to emulate 8-bit color for backwards compatibility (or, programming simplicity). However, this also opens up the possibility for cool effects like color rotation.
If you think about it, you can still boot a modern computer into DOS and request 8-bit video modes from the video BIOS. More than likely, that BIOS does this same mapping of 8-bit color values to their hardware-native counterparts.
Color mapping was also how things were (typically) done on the SNES. According to Wikipedia, the SNES would use 256 colors from a palette of 15-bit colors. From Wikipedia:
...256 × 15 bits of color generator RAM (CGRAM) for storing palette data...
Colors are chosen from the 15-bit RGB color space, for a total of 32,768 possible colors... Most graphics use palettes stored in CGRAM, with color 0 of any palette representing transparency.
The Genesis (I was surprised to learn) typically has a palette of just 64-colors per-line, but has 9-bit color output. Note that both systems had more than eight bits, both had even bit counts per color channel and each had a CPU that was probably at least 50 times slower than the STM32F4(!).
What you lose in going with a higher color depth is the ability to output directly from your frame buffer via DMA. However, I believe with a little extra processing and a little extra work the stm32f4 can be made to output from the same frame buffer, even to a higher bit depth. And this chip certainly has extra processing!
What you gain with more colors is obvious - everything in the future can use more vibrant colors and you don't have a very powerful chip crippled by 8-bit color (that consoles 50 times slower had already moved past). As a bonus, having even color-channel length is something that should make game programmers happy
One last thought on the issue of a framebuffer: On the Uzebox, we usually are given nothing for a framebuffer, and like it!
Okay, Okay. I know I tend to ramble on. Sorry. Anyways, I know that the best way to get a feature supported in the open-source community is to make it yourself! To that end, I have designed a 12-bit circuit based on WAHa's that I'm hoping will become popular.
Here's a schematic of what I built:http://sites.google.com/site/trevorsuzeboxfiles/files/vga%20sch1.png
This schematic is designed to re-use some resistors from WAHa's design. What worries me about both is that they don't use 75 ohm termination. If someone can explain how that might be a problem, I'd love to hear it!
Anyways, I've read that VGA is supposed
to be terminated with 75 ohm's at each end. So, if perhaps for superstitious reasons more than engineering ones, I've made this schematic, which is the one I recommend anyone else follow:http://sites.google.com/site/trevorsuzeboxfiles/files/vga%20sch%2075%20ohm.png
Here's some pics of the board I built the other day. This was such an easy build that I could actually build an 8-bit and 12-bit version into the same board. However, I wished halfway through that I just built two separate boards. I left just enough room for an avcore header in the middle.
12-bit mode (of course, no software really supports 12-bit color yet, but the wiring is almost identical to WAHa's design, so the rotozoomer actually looks pretty close to the 8-bit version, and shows the hardware isn't broken):http://sites.google.com/site/trevorsuzeboxfiles/files/P1010009.JPGhttp://sites.google.com/site/trevorsuzeboxfiles/files/P1010011.JPG
Again, this is a REALLY easy build, so I encourage some more people to get in on the ground floor of whatever it is we're making here.
BTW, WAHa's code is very easy to follow and well-commented from what I've seen so far. Thanks again for sharing your work, WAHa.06x36!!