Thinking about STMUzebox

[uze6666]

Pretty awesome indeed. My question is what happen with the main program trying to access the SRAM? Isn't there bus locking issues (i.e: cpu vs. dma controller) resulting in jitter?

[WAHa.06x36]

I haven't figured out what is supposed to happen in theory, but so far I have only seen jitter when the processor and DMA try to access the exact same row of the screen. With double buffering, that should never happen, and I see no jitter at all with that even though I am spending the entire frame drawing to the other buffer. I guess DMA gets priority over the CPU, or something.

[hpglow]

A slightly more useful video: http://www.youtube.com/watch?v=IRT4ShYi8Bw

I got 240, 200 and 175 row modes working. This one is 320x200, just like old DOS mode X. And just like that, there is now enough space for double buffering, if you use the entire 128k main SRAM bank for framebuffers. I moved the data and bss sections to the 64k CCM memory instead to make room for the framebuffers.

It renders about 450 of these star sprites at 70 Hz, full frame rate.

You could do some pretty impressive games on this, I am pretty sure.

Very nice video.

[vaclavpe]

A slightly more useful video: http://www.youtube.com/watch?v=IRT4ShYi8Bw

Really nice. Will you port the whole Uzebox code to the Discovery Kit ?

[WAHa.06x36]

All right, I finally put a dump of the source code up:

http://wakaba.c3.cx/repos/stm32f4-vga/

This is also a Mercurial repository, so it can be cloned with

hg clone http://wakaba.c3.cx/repos/stm32f4-vga/

There is a schematic for the particular DAC setup I use:

http://wakaba.c3.cx/repos/stm32f4-vga/D ... ematic.png

I probably won't be porting the Uzebox code, as I am not very familiar with it at all. However, if anyone else wants to do it, feel free to use whatever you want from the above code. Consider it public domain code, or zlib licensed if public domain does not seem valid where you live.

[HardlyUnique]

Nice work, WAHa! Thanks for sharing. You made it sound very simple in your description but that's not a trivial amount of code!

I think that since the stm32f4discovery board is so cheap, it will probably become the de-facto standard for a homebrew game system based on this chip.

I have one suggestion before we start settling on a standard design and kernel: Don't stick with 8-bit. I think 8-bit color would be crippling for a game system with such a powerful chip.

In fact, as a programmer, I've often wished the hardware would just use the same number of bits for each color channel. This makes blending and fading operations more straightforward (IMHO).

What do you guys think about 15-bit color? (Maybe 12-bit if the MEMS sensor can't give up PE1 & PE2?)

[WAHa.06x36]

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.

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.

[WAHa.06x36]

Funny thing: I was messing around with my sprite drawing code, and I worried I'd made it slower so tried it on the STM32F4 again, and it turns out it now draws 1050 sprites per frame instead of the previous 450. This is a pretty fearsome machine!

The updated code is in the repository, if anyone is playing around with it.

[uze6666]

and it turns out it now draws 1050 sprites per frame instead of the previous 450. This is a pretty fearsome machine!

That is pretty amazing! I just wish I has more time lately...thanks for posting the code, I will sooner or later check it out and experiment with the STM32F4.

-Uze

[WAHa.06x36]

Oh, I think I figured out what I did to get it so fast: I accidentally put my sprite data in RAM instead of ROM. It is apparently a bit faster.

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

With rendering that fast, you finally start to notice the pixel DMA jitter, though. It's not unusably bad on a rapidly changing picture, but it's noticeable. You probably want to draw a bit less than that to keep the image stable.