Thinking about STMUzebox

[vaclavpe]

(Edit: No, actually, it is still in ROM. I guess the code is just that much faster all of a sudden.)

Hi WAHa.06x36, I am interested if there is some situation to need sprites in RAM. For example animations. Did you try to move everything to RAM ?

If I understand correctly, You can not have some sprites in RAM and some fo them in ROM because of different timing. Or it is not the situation ?

[WAHa.06x36]

The only reason to keep sprites in RAM is if you generate them on the fly somehow. For animation, you can just keep all different frames in ROM. Possibly it might also be a bit faster to read them from RAM than ROM.

As all sprite rendering in my code happens entirely in software into a framebuffer, it doesn't matter where you keep them. Rendering is not synchronized with anything other than the v-blank. It works just like rendering in old DOS games.

[uze6666]

I made a XM player back then for the GBA, it was mainly assembler for the Armv7tdmi. I guess that it would not work since the cortex does not support the full ARM instruction set. What about Thumb-2 and Thumb...do you know what's the main difference?

-Uze

[WAHa.06x36]

As I understand it, Thumb-2 is compatible with ARM assembly code (but not machine code). The assembler will actually compile ARM-style instructions down into multiple 16-bit opcodes. The tradeoffs for what is fast and what is slow will probably be different, of course.

I haven't actually tried this myself beyond writing a four-instruction inner loop for one of the effects in my demo app, so I don't know how it works out in practice.

[WAHa.06x36]

Actually, it seems it sort of compatible. You can write code in the ARM style with some modifications and it will work on both ARM and Thumb-2, as I understand it.

[hpglow]

From what I understand the difference between ARM, Thumb, and Thumb-2 is...ARM is native assembly code, Thumb is compressed assebly and is limited to 16 bit but due to the compression takes a performance hit. Thumb-2 has performance enhancements to Thumb-1 and allows the use of some 32-bit code.

[WAHa.06x36]

Thumb is just as 32-bit as ARM. However, Thumb opcodes are 16 bits long rather than the 32 bit opcodes ARM uses. This means they are less expressive. They use two-operand opcodes rather than three-operand ones like ARM, and they can't easily access all registers, and lack some other flexibility of ARM opcodes. As a result, sometimes what can be done in a single instruction on ARM requires multiple instructions on Thumb. Thumb-2 introduces variable-length opcodes, meaning opcodes can optionally include a second 16-bit code to express longer opcodes, making it closer to ARM in expressivity and performance.

[uze6666]

Thumb is just as 32-bit as ARM. However, Thumb opcodes are 16 bits long rather than the 32 bit opcodes ARM uses

Yeah, that's what I recall from my GBA stuff. IIRC, one more great thing 32-bit ops have vs thumb is conditional execution for most instructions.

-Uze

[WAHa.06x36]

I just fixed a really annoying problem, and I figure I should post and warn others experimenting with the STM32F4 about it:

The devkitARM toolchain, at least, does not have a proper multilib entry for the Cortex-M4. For some reason, this causes it to link ARM versions for some internal functions, such as 64-bit divides, which of course causes a crash. I put in a .specs file to kludge this in my project, but I am not sure if that will instead break other compilers or not.

If you are using some other toolchain, hopefully it doesn't have this problem.

[HardlyUnique]

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.

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.
Board pics:
http://sites.google.com/site/trevorsuzeboxfiles/files/P1010014.JPG
http://sites.google.com/site/trevorsuzeboxfiles/files/P1010018.JPG
8-bit mode:
http://sites.google.com/site/trevorsuzeboxfiles/files/P1010005.JPG
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.JPG
http://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!!