Thinking about STMUzebox

[vaclavpe]

Hello all,
as I work with STM32, I am slowly thinking about porting Uzebox to this architecture. As I am in Europe, my choice for video output is SCART connector, or AD722 (PAL output), or even some VGA mode for PC monitor.

I already did some experiments with generation of HSYNC/VSYNC with timer. For ouput of scan line I want to use DMA controller.

Several questions appeared.
- I saw that actual version of Uzebox support a plenty of video modes. Is there some list of games for each video mode ? In Wiki there is just complete list but no categories...
- I probably start with Video Mode 1. Is there some really short demo code?
- what should I take care about during porting ?

Thank you in advance

[uze6666]

Hi,

I lot of folks regularly talks to me about a Cortex-based Uzebox. Thinking more about it, I would use VGA as a primary output. The rationale is that LCD TVs are everywhere and composite looks like crap on those TVs.

To answer your questions:

- I saw that actual version of Uzebox support a plenty of video modes. Is there some list of games for each video mode ? In Wiki there is just complete list but no categories...

There's no list of games per video modes, but each game info page lists the video mode used. In any cases, the most popular video mode is mode 3, then mode 1.

- I probably start with Video Mode 1. Is there some really short demo code?

Indeed this is the easiest and the source is well documented. Use the "Tutorial" project, it's a simple Hello World application.

- what should I take care about during porting ?

I don't think there's a bootloader feature similar to the AVR that would allow the current menu we have. Also, I would consider a "legacy" mode kernel to run current games and a optimized kernel for new games to use the best of VGA.

-Uze

[vaclavpe]

Hi Uze

There's no list of games per video modes, but each game info page lists the video mode used. In any cases, the most popular video mode is mode 3, then mode 1.

OK, this might be an improvement for Wiki? I don't fully understand the kernel concept yet. I just assume that there is some default menu with games, user can choose one game from the list. At the beginning, video mode is initialized and game then starts.

- I probably start with Video Mode 1. Is there some really short demo code?

Indeed this is the easiest and the source is well documented. Use the "Tutorial" project, it's a simple Hello World application.

Are you sure? In Wiki I see that it uses Mode3. And there are some sprites etc...

I don't think there's a bootloader feature similar to the AVR that would allow the current menu we have. Also, I would consider a "legacy" mode kernel to run current games and a optimized kernel for new games to use the best of VGA.

STM32 has bootloader accessible through UART. What does it mean "Legacy mode kernel" for you? IMHO if I am API-compatible then there should be no difference between NTSC/PAL/VGA versions...

EDIT: is there some guide about Uzebox internals ?

[uze6666]

Hi,

OK, this might be an improvement for Wiki? I don't fully understand the kernel concept yet. I just assume that there is some default menu with games, user can choose one game from the list. At the beginning, video mode is initialized and game then starts.

The games menu is actually an AVR bootloader (check the mega644 specs for more details). It's a 4K section of the flash independent of the main program that can be configured to execute first upon reset. The bootloader I've made contains a minimal kernel with video and SD card reading functions. When the user chooses a game, the bootloader reflashes the remaining program memory with it. So if the STM only have UART bootloader, I'm wondering how such functionality will be possible.

Are you sure? In Wiki I see that it uses Mode3. And there are some sprites etc...

The one you are referring to is probably Space invaders. There's a simple demo project in SVN here: http://code.google.com/p/uzebox/source/browse/#svn%2Ftrunk%2Fdemos%2Ftutorial

What does it mean "Legacy mode kernel" for you? IMHO if I am API-compatible then there should be no difference between NTSC/PAL/VGA versions...

Sure the API should make the game agnostic to the underlying video technology, but the timing is not exactly the same (I think) for all of those. Now that I think of it, one statically or dynamically configurable kernel that supports NTSC/PAL/VGA would be much better.

-Uze

[paul]

I should probably rename that tutorial and replace the Tile Studio section with gconvert.

[vaclavpe]

Hi,

When the user chooses a game, the bootloader reflashes the remaining program memory with it. So if the STM only have UART bootloader, I'm wondering how such functionality will be possible.

If you mean that STM32 can write to its FLASH memory from the application, then yes, it is possible. FLASH is even used for emulation of data EEPROM (which is missing).

Sure the API should make the game agnostic to the underlying video technology, but the timing is not exactly the same (I think) for all of those. Now that I think of it, one statically or dynamically configurable kernel that supports NTSC/PAL/VGA would be much better.

Yes, timing will be different, that's true. Hopefully not too much to mangle games. PAL will be something else ( fv=50Hz) but for VGA, fv still can be 60Hz, 525 lines, fh=31500Hz, then for 240 pixels, the "full line" is 295 pixels, it means pixel clock is 9.2925MHz. Really ugly value. I want to try 9MHz (XTAL is 8MHz and PLL*9 to have full clock 72MHz), it is 286 pixels for full line.But I am not sure if HSYNC will be OK. Or to use higher pixel clock ( 72/7 MHz) and make the picture a little bit smaller.

I had a look in the kernel code, there is "void Initialize(void)" but I don't see where this function is called. I will probably have more such dummy questions. Should I create new topic in the "New to Uzebox" forum (something like "Kernel internals")? Or is it ok to stay here?

[uze6666]

If you mean that STM32 can write to its FLASH memory from the application, then yes, it is possible. FLASH is even used for emulation of data EEPROM (which is missing).

Now *that* is very interesting. Lack of Bootloader & EEPROM functionality were my biggest concerns. Btw, I have question regarding the cortex chips. I read somewhere that code can execute from flash *and* RAM, it this true?

I had a look in the kernel code, there is "void Initialize(void)" but I don't see where this function is called.

in uzeboxCore.c you will find this line:

Code: Select all

void Initialize(void) __attribute__((naked)) __attribute__((section(".init8")));

This instruct the C compiler to invoke this function upon startup. Check out avrlibc documentation for more details.

I will probably have more such dummy questions. Should I create new topic in the "New to Uzebox" forum (something like "Kernel internals")? Or is it ok to stay here?

Go head, I'll be glad to help. And this topic seems the best place for this stuff.

Cheers,

-Uze

[hpglow]

http://www.st.com/internet/evalboard/product/252419.jsp
Order yourself a free sample Uze. 1Mb Flash and 192Kb ram sounds awsome. The prototype boards arn't out yet but they are supposed to retail for around $25, pretty cheap.

[Harty123]

Hi,

Do you know this?

http://rossum.posterous.com/20131601

-Harty

[uze6666]

http://www.st.com/internet/evalboard/product/252419.jsp
Order yourself a free sample Uze. 1Mb Flash and 192Kb ram sounds awsome. The prototype boards arn't out yet but they are supposed to retail for around $25, pretty cheap.

As the Cortex approach goes, I think we have a winner here. 192Kb of RAM would be enough for a full screen, double-buffered frame buffer....awesome! And mouser will sell them for a mere 15$...I'm getting one the minute they ship. Thanks for the tip.

-Uze