Thinking about STMUzebox
Thinking about STMUzebox
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
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
Re: Thinking about STMUzebox
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:
-Uze
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:
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 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...
Indeed this is the easiest and the source is well documented. Use the "Tutorial" project, it's a simple Hello World application.- I probably start with Video Mode 1. Is there some really short demo code?
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.- what should I take care about during porting ?
-Uze
Re: Thinking about STMUzebox
Hi Uze
EDIT: is there some guide about Uzebox internals ?
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.uze6666 wrote: 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.
Are you sure? In Wiki I see that it uses Mode3. And there are some sprites etc...uze6666 wrote:Indeed this is the easiest and the source is well documented. Use the "Tutorial" project, it's a simple Hello World application.- I probably start with Video Mode 1. Is there some really short demo code?
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...uze6666 wrote: 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.
EDIT: is there some guide about Uzebox internals ?
Re: Thinking about STMUzebox
Hi,
-Uze
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.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 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/ ... 2FtutorialAre you sure? In Wiki I see that it uses Mode3. And there are some sprites etc...
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.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...
-Uze
Re: Thinking about STMUzebox
I should probably rename that tutorial and replace the Tile Studio section with gconvert.
Re: Thinking about STMUzebox
Hi,
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?
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).uze6666 wrote: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.
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.uze6666 wrote: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.
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?
Re: Thinking about STMUzebox
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?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).
in uzeboxCore.c you will find this line:I had a look in the kernel code, there is "void Initialize(void)" but I don't see where this function is called.
Code: Select all
void Initialize(void) __attribute__((naked)) __attribute__((section(".init8")));
Go head, I'll be glad to help. And this topic seems the best place for this stuff.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?
Cheers,
-Uze
Re: Thinking about STMUzebox
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.
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.
Re: Thinking about STMUzebox
Life's too short to remove usb safely
Web: www.hwhardsoft.de
http://www.facebook.com/hwhardsoft
YouTube: http://www.youtube.com/user/hwhardsoft
Web: www.hwhardsoft.de
http://www.facebook.com/hwhardsoft
YouTube: http://www.youtube.com/user/hwhardsoft
Re: Thinking about STMUzebox
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.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.
-Uze