Thinking about STMUzebox

[hpglow]

Here in the US mouser has 1000's of bare f4 chips in stock for around $15. The F1 is a tad cheaper at $10. But I see your point, searching Farnell I see nothing other than the discovery boards. I think you will see stock of them soon. But I understand your desire to work with what you have on hand. I'm sure that if someone with a bigger brain than I could spend some time with your code they would have it converted to the F4 in no time. There are differences between the two but nothing that should be a show stopper. I will keep an eye on your SF project and keep trying to work with the code when I have time.

[uze6666]

I have several reasons to use STM32F103. F4 line exists now just as the Discovery kit. No MCU available at Farnell so far. No samples at ST.COM so far.

Also Digikey has plenty of STM32F405RG: http://search.digikey.com/scripts/DkSearch/dksus.dll?x=0&y=0&lang=en&site=us&KeyWords=STM32F405RG

-Uze

[hub.martin]

Another greetings from Czech Republic

I has been watching Uzebox project for few years.
I carefully read the whole thread because I'm interested and already developing on ARM Cortex M3/4 processors. I have practical experiences with LM3S processors and the latest STM32F4. I'm amazed how vaclavpe reached perfect pixel timing in software. I know AVRs, it's higly predictable what happens in every clock cycle but in ARM it's almost impossible

Here are some of my ideas and suggestions:

- STM32F4 (CortexM4) has in addtion to CortexM3 hardware floating point unit (faster 3D computations), Instruction and Data cache (so you're not always limited by flash speed) and some SIMD and saturation math instructions (Single instruction, multiple data).
- If you use STM32, you should decide to use FSMC (Flexible Static Memory Controller) to put image data to AD725. Not every line of STM32 has this controller but STM32F103 and STM32F4 do. The controller is flexible ( ) and data bus can be 8/16/32 bits wide and you can also create clock signals by hardware (there are /CE /WE /OE signals and lot of timing options), but this FSMC option needs further evaluation, I'm not aware of every aspect. I use the FSMC to connect LCD 320x240 with the 8080 interface. The LCD of course has to have its own controller with RAM, but the refresh and data transfer it's really fast! And the same throughput can be fed to AD724. If you use DMA with FSMC, the transfer is about few % slower but you get whole processor power.

So far my ideas. Later I consider to rip out one AD724 from old VGA card and play with it a little with my STM32F4 Discovery

As for IDE, I use Atollic but I hope that I find some free time to configure Eclipse. CooCox it's perfect IDE but the STM32F4 it's not supported yet and who knows if it ever will be because CooOS operating system was created primary for Cortex M3. I will probably use Eclipse with GCC utils from atollic because there's support for M4 and hardware FPU.

I played with a lot of processors and codes but Uzebox is a really big project and I don't expect that I have skills to port it to another platform. But I'll keep watching this thread.
Good luck to everyone and namely vaclavpe.

[vaclavpe]

Hello all (but personally UZE),

I found something interesting for me. Uzebox has TileMap and FontMap. My questions follow:
- How does it exactly work in the memory ? RAM_TILES_COUNT defines number of tiles and after them there are fonts (and it is used in Print() function). Is it in RAM or ROM?
- In Megatris Isawsomething like copying Tile from ROM to RAM (RestoreTile() function). How does it exactly work? It is bad that I don't understand AVR assembler code...
- My idea is to change VRAM from tile numbers to pointers to the start of tile. Then everything can be anywhere. Anywhere AND ALWAYS in ROM. Because of timing. It has an advantage that one can have different tile maps and use it at one time. But, is there any application which has to use Tiles/Fonts from RAM ? For example dynamically generated tiles? This would be problem and then all tiles and fonts have to be in RAM to be consistent.

[uze6666]

How does it exactly work in the memory ? RAM_TILES_COUNT defines number of tiles and after them there are fonts (and it is used in Print() function). Is it in RAM or ROM?

All VRAM indexes from 0 to RAM_TILES_COUNT-1 are assumed by the rendering engine to point to ram tiles. All remaining indexes from RAM_TILES_COUNT to 255 are for rom tiles. There's no FontMap in mode 3, instead you use SetFontTileIndex() to tell the engine which tile index in the current rom tileset contains the first font character (i.e: the space character). This has meaning only when using the Printxxx() functions. Naturally one can also display the same font tiles using the SetTile() function.

In Megatris Isawsomething like copying Tile from ROM to RAM (RestoreTile() function). How does it exactly work? It is bad that I don't understand AVR assembler code...

Well yeah that was a hack to save RAM or flash, but I can't quite remember. The whole game play screen is a big 30x28 map written to VRAM when the game begins. During the game, block and animations alters the background tiles in VRAM. The RestoreTile() function is used to revert back original background tiles from the main 30x28 map based on their X-Y position.

- My idea is to change VRAM from tile numbers to pointers to the start of tile. Then everything can be anywhere. Anywhere AND ALWAYS in ROM. Because of timing. It has an advantage that one can have different tile maps and use it at one time.

Mode1 uses a similar pointers-to-tiles in flash. Problem is that VRAM doubles in size for the same map resolution. For ARM that would be 4X (32-bit) but since we have a ton of RAM that's no big deal. That would work fine for "text-mode" games like megatris, but what about sprites? How would you handle them with ROM only tiles?

But, is there any application which has to use Tiles/Fonts from RAM ? For example dynamically generated tiles? This would be problem and then all tiles and fonts have to be in RAM to be consistent.

I'm afraid yes. All mode 3 games uses a mix of ROM tiles *and* dynamically generated tiles (ramtiles) to pre-blit the sprites during VSYNC. Some games like Bomberman and LodeRunner also uses them for other things like fake parallax effect.

Hope that makes sense!

-Uze

[uze6666]

Hi hub.martin,

Welcome to the Uzebox community and thanks for posting some interesting tidbits about the cortex M4. Your comments on the FSMC are quite interesting! Though I think it only avail on the 100+ pins devices. I was thinking that using simplest, lowest pin device would make it "easier" to solder for most.

As for the DMA I'm always concerned about how to make it deterministic to have a jitter free output. From what I understand that if the RAM bus is accessed by the CPU, the DMA controller has to wait. Unless there's some burst buffer that can cache a couple bytes in advance and guarantee a stable throughput.

-Uze

[hub.martin]

Though I think it only avail on the 100+ pins devices. I was thinking that using simplest, lowest pin device would make it "easier" to solder for most.

You're right, but the devices with 64 or 100 pins have the same package and size of pins. I guess that there's no big difference if you solder 64 pins or 100. The solder bridges could appear in both cases.

As for the DMA I'm always concerned about how to make it deterministic to have a jitter free output. From what I understand that if the RAM bus is accessed by the CPU, the DMA controller has to wait. Unless there's some burst buffer that can cache a couple bytes in advance and guarantee a stable throughput.

The DMA has higher priority than CPU itself. So there's no jitter. If there's a conflict in concurrent reading from BUS between CPU and DMA, then the CPU is halted for few bus cycles.

First I was not sure, but in the link below it's explained.
http://answers.yahoo.com/question/index ... 635AAcCLvU

[paul]

That yahoo question looks like it was asked during an examination bathroom break

[uze6666]

You're right, but the devices with 64 or 100 pins have the same package and size of pins. I guess that there's no big difference if you solder 64 pins or 100. The solder bridges could appear in both cases.

Ah right, good point, I didn't realize it was the same pin pitch for both packages.

-Uze

[hpglow]

I'm pretty sure that the F4 has an hardware IRQ system that allows you to prioritize all internal devices from 0 to 255 with 0 through 8 being reserved. So you can give any part of the MCU any priority you want. There are two DMAs in the F4. From the way I read it the FSMC can control external SD cards or external memory, I'm not sure it can read both but I don't understand well enough to comment. That means that using the FSMC to do any display work could render the SD card slot un-useable.