Thinking about STMUzebox

[filipe]

Hi,

I got a Cortex-M3 based dev board some time ago and the first thing that came into my mind was to port Uzebox games to it. I didn't do anything yet, apart from this RGB resistors spreadsheet: https://docs.google.com/spreadsheet/ccc ... y=CKvQ-4MC
Actually I bought a scart lead today for it, but no idea when I really will start putting it all together.

My suggestion is...
Forget about flashing the games into the MCU's flash every time, just load them to RAM. The flash memory should be used for the kernel and game loader only, they are the common code shared by all games.

Note that, considering all IO is performed by kernel functions, different Cortex-M3 based microcontrollers could be used to run the same game (same binary). Kernel could provide a filesystem API for games to load more data at run-time and to save game states.

The tricky part is how to link the kernel. It requires some thought, but should be fine

Cheers,
-Filipe

[hpglow]

I was just going to use the ladder dac from the mbedgc project and see if it works?

May be add a couple rungs on the ladder for more color depth? For future iterations possibly.

But my first priority would be just to get API level compatibility so that simple re-compiles would make the games work with the STM32. There is so much flash on these chips I don't know if reserving the embeded flash for the kernel would be wise or not. It would definatly work more like a console if an SD card were put in and the games loaded from it. Loading all the game to ram would kind of defeat the purpose of going to a stronger chip. While all the current UzeBox games would fit in ram with plenty of working space remaining, moving forward to better games people would quickly run out of ram with that approach. It may be the aproach for migrating the current library over, but I for the newer games something else would have to happen.

I'm thinking of using a buffer, the STM 32 F4 is designed to transfer bytes, half-words, and words from flash. The thing is it takes the same amount of wait states to begin transfer of each one, so naturally in order to mitigate the 5 to 7 clock cycle wait states it would likely be best to make sure that the DMA only pulled 32-bit words at a time. Since the F4 has two DMAs that would mean 8 bytes per DMA for a total of 16 bytes could be read at one given time, I'm not sure if they are required to be in concurrent memory space or not. The other idea I had was to make a software inclusive buffer that kept the most common tiles. Keep like two rows worth of tiles in it, that way when a common tiles would already be in memory and the DMA would only have to read from flash when lesser used tiles are needed. Most of the time two rows of tiles would not be original but having about two rows of tiles on hand would reduce flash reads since flash on these chips is at 5 to 7 cycles and (on the F4 at least) reading from ram is 0 wait stats. So that would cover (assuming 8x8 tiles) 16 scanlines minumum of data at the same time avoiding filling the ram up with all the tiles in the tile set. Then the same could be done for the sprites. But for sprites it would probibly be best to have larger tiles like 16 x 16 and a larger buffer. These are just ideas I'm kicking around, none of them may be possible.

The more hands we have working on this idea, the better chance of sucess. My goals for the project would be:
* Lower cost than the current hardware.
* More avalible power than the current hardware.
* Easier to program.
* Have it ready within a year or two. Better to do it right then rush out the spec.

The STM32 may or may not be the right choice to migrate to, but right now it looks very promising.

[vaclavpe]

Hi all, I will try to answer everything in this one post.

How did you set up the vram?

I will try to post the code later. Now, I have mixed comments in english/czech so I need to clean it a little bit. So far I wrote render routine in C.

Code: Select all

// VideoMode1 - screen is 240x224 pixels, tile is 6x8 pixels -> 40x28 tiles
#define MANYMANY 6*8*30 /* 30 tiles for example */
unsigned int vram[40*28]; // we can have 65536 tiles
unsigned char tiles[MANYMANY]; //tiles are stored here

volatile int line_counter; // 0-447 (each line is shown twice); VSync is generated from this

void render_single_line( void)
{
   int icnt, jcnt;
   
   // ptrvram points to actual vram location
   int ptrvram = line_counter >> 4;
   int lineoffset = 6*((line_counter >> 1) & 0x07);
   unsigned char *ptrtiles = tiles + lineoffset;

   for (icnt = 0; icnt < 40; icnt++) { // number of tiles in line
      unsigned int ptrtile = vram[ptrvram];
      ptrtiles += 48*ptrtile;
     
     for(jcnt=0; jcnt < 8; jcnt++) {
        GPIOB->ODR = (*ptrtiles++) << 8;
     }
     
      ptrvram++;
   }
}

But compiled code is really not efficient at all... Disappointment for me...

which Development Environment do you use for your STM32 projects?

I use just raw CodeSourcery GCC, or on Windows you can use Yagarto. GNU Make and makefiles. I plan to try Eclipse but it is not my priority. I am able to debug directly in GDB (I know it is quite hard). For flashing and debugging I use OpenOCD and FT2232 dongle (Amontec type), or JLink.

How are you handling the RGB to NTSC conversion?

No NTSC, just VGA. Here in Europe there is plenty of TV sets with VGA inputs. Or one can run game box on PC LCD.

What is taking all that time?

Rendering routine is quite ineffective. Furthermore, if I understand correctly, from FLASH it runs on 72/3=24MHz

Thinner client

There is just black/white signal generated through SPI data. Quite interesting but unusable for us.

Forget about flashing the games into the MCU's flash

Yes, truth. But STM32 has not so much RAM. Another advantage is no wait states as in FLASH. But it needs to be tested.

ladder dac

Be careful about output resistors (75Ohms). In LCDs they are already present. If you use them at output of the Uzebox, voltage swing will be 0.35 Volts. Another point - I wanted to use bus driver. 74LS245. But this chip just "copies" the voltage on inputs regardless of supply voltage. Can anybody try HCT245 at outputs from 3.3V chip? Will you see 5 Volts ?

* More avalible power than the current hardware.

Hehhh, now I am not so sure about that

My ToDo now:
- clean up the code
- test differences between running from RAM and FLASH (I already know that GCC adds some special routine to run some part from FLASH, don't know why)
- prepare at least something useful to show you

Does anybody work with Cortex assembler? Or anybody want to work on this port? I can set up the project at SourceForge. I am not sure if I am able to write the render routine in ASM.
Vasek

[DaveyPocket]

No NTSC, just VGA. Here in Europe there is plenty of TV sets with VGA inputs. Or one can run game box on PC LCD.

Concerning the Uzebox JAMMA, certain arcade monitors support VGA while other don't. Those that do support VGA monitors use JVS (JAMMA Video Standard). I guess I'll go in that direction for the upgraded Uzebox JAMMA if this is what we decide to do

While all the current UzeBox games would fit in ram with plenty of working space remaining, moving forward to better games people would quickly run out of ram with that approach.

I was hoping that games could be stored in RAM, I always feel weary re-flashing the ATmega when loading a different game and how the flash doesn't quite last "forever", but then again nothing really does

While you mentioned VGA and supporting old Uzebox games, I'm worried that there may be issues with the difference between VGA and CGA resolutions and timings. Basically, whether or not the new chip can properly display old Uzebox games on a VGA monitor.

I'm not sure if we should worry about backwards compatibility too much. If this idea is causing problems in the development for the new device or is very difficult to code, then backwards compatibility should be abandoned. It would be really nice to have backwards compatibility, but not having it might encourage writing new games for the device, or porting and improving existing ones.

EDIT: Just received development board sample in mail today, I'm willing to help with development of this project.

[hpglow]

No NTSC, just VGA. Here in Europe there is plenty of TV sets with VGA inputs. Or one can run game box on PC LCD.

I was hoping that games could be stored in RAM, I always feel weary re-flashing the ATmega when loading a different game and how the flash doesn't quite last "forever", but then again nothing really does

While you mentioned VGA and supporting old Uzebox games, I'm worried that there may be issues with the difference between VGA and CGA resolutions and timings. Basically, whether or not the new chip can properly display old Uzebox games on a VGA monitor.

I'm not sure if we should worry about backwards compatibility too much. If this idea is causing problems in the development for the new device or is very difficult to code, then backwards compatibility should be abandoned. It would be really nice to have backwards compatibility, but not having it might encourage writing new games for the device, or porting and improving existing ones.

EDIT: Just received development board sample in mail today, I'm willing to help with development of this project.

I'm sure that the embeded flash supports at least 10K write/erase cycles. At any rate, the goal should probibly be to load directly from the SD card. This would make it more painless for people who just want to play, and it would allow for game sizes that are limited by the maximum file size the STM32 can read. It will add a layer of complexity though, at least for larger games people would have to manage what data is in ram at a given time, smaller games would just be loaded to ram. Reading directly from SD would be too slow, I'm not sure but I'm guessing just by reading the spec sheets.

At this point none of that is important anyway. Right now the big thing will be to get the eval board to display some graphics at a decent resolution with some speed.

RGB out is going to have to happen, a good portion of the community is running of SCART, and then there is the JAMMA. Wouldn't be wise to alienate them. I would really like to loose the AD725 chip to lower costs of building it but I'm not willing to push out anyone to do it. Right now we don't even know if the STM32 is a good fit anyway. My eval board should be showing up in the mail any day now.

[uze6666]

A lot of good stuff going on here. Having the kernel in flash is a possibility but a lot of careful thinking and planning of the API should be done upfront since it won't be able to change easily. But then again, there's so much flash, that multiple versions of some calls would be possible. Running from RAM seems like a no brainer for kernel function were speed is primordial (like the rendering routines). In this case, some portion of the kernel in flash could be copied to RAM upon startup. Only issue is the space, there won't be that much space for games when you consider VRAM/sprites/mixer requirements. Perhaps at this point external RAM could be considered (does the chip supports an external bus and if so at what wait states) ? Finally for the video output, I think VGA should be seriously considered. NTSC sucks big time on LCD TVs and the AD725 may not be around for long (and it's expensive). And since almost all LCD TVs has a VGA input, it would make sense IHMO.

-Uze

[uze6666]

Oh, another thing, the DAC. The current design, although simple, leads to poor usage of the RGB color space. I recall discussing with Clay Cowgill (creator of the AVCore) about an improved DAC. One that would use something like R2:G2:B2:I2 (I being intensity) to yield much better linear gradients. It would not be directly backward compatible, but a graphics conversion tool could take care of that.

-Uze

[hpglow]

A lot of good stuff going on here. Having the kernel in flash is a possibility but a lot of careful thinking and planning of the API should be done upfront since it won't be able to change easily. But then again, there's so much flash, that multiple versions of some calls would be possible. Running from RAM seems like a no brainer for kernel function were speed is primordial (like the rendering routines). In this case, some portion of the kernel in flash could be copied to RAM upon startup. Only issue is the space, there won't be that much space for games when you consider VRAM/sprites/mixer requirements. Perhaps at this point external RAM could be considered (does the chip supports an external bus and if so at what wait states) ? Finally for the video output, I think VGA should be seriously considered. NTSC sucks big time on LCD TVs and the AD725 may not be around for long (and it's expensive). And since almost all LCD TVs has a VGA input, it would make sense IHMO.

-Uze

The chip does support external sdram, there are pre-written libraries for it. I don't know what the wait states are, but it does consume something like 45 pins to implement. It also supports running from the external ram. There are are F4 chips with 144 pins though, but the discovery only has 60 pins. One thing I found interesting was that the support for sd cards seems to be very good. The F4 can read SD cards at either 25 or 50 Mhz and can transfer 512-byte blocks or if concurrent it can transfer a stream of 512-byte blocks. The document says nothing of the wait states on reading SD cards but at 512-bytes it definatly has more data thouroughput than the embeded 1MB flash.

I was going through the libraries, and I found LCD drivers. I'm not sure if these are worth trying to adapt for use with a computer monitor or not. It kind of looks like the lcd they support has it's own ram and the chip just sends an image to that ram and it does the rendering. I'm not sure but that is how it looks at this point. So not too useful, but possibly I'm reading it wrong. I'm hoping that the dual 12-bit DACs can be used to send the image to the display device, but for some reason I feel like a third dac would be needed to generate video data. I haven't tested the theroy yet but that is just my guess.

The other libraries I found interesting were for the the DSP. They show how to use it for 3d rendering.

[hpglow]

I plugged it in and gave it a whirl. Haven't done anything yet just tried it out with the built in accelorometer sofware.

http://youtu.be/ym1atfR1FSw

[vaclavpe]

So, in the meantime, I cleaned the code a little bit and attached to this message. I can get boxes on the LCD screen as in the second attachment. Third attachment is my proposal to STMuzebox schematic (which does not exactly correspond to the attached source code). There are some unused pins. I don't know, how to use them.

There was not necessary to use RAM function for line rendering. There is another possibility how to spare power. I want to use output compare feature of TIM2 to generate VSync signal. Then render_line() will be run from IRQ handler of TIM2_OC.

Unfortunately, I don't have any SNES controller. I might use something similar or I can breadboard some "SNES emulator".

Anyway, I think it is on the good way to implement at least something.

I must then have a look how sound is generated. Plan is to add simple LM386 on the board.

Vasek

First screenshot

IMG_20111019_223838.jpg (59.75 KiB) Viewed 6000 times