Thinking about STMUzebox

[hpglow]

Very nice, I will look over the code this week. I'm glad you are making progress. I don't know how a octal bus tranceaver works, but its a real inexpensive IC. If SCART is close to VGA I may be able to get your project gong on my computer monitor.

[hpglow]

From what I can tell that code looks very good. I can't wait until I have some time to see how this runs, and to see if I can mod it to run some mode 1 uzebox games. I would like to put a some kind of bench mark in there to see how many cpu cycles/ memory/ ect are left. Hopefully it runs on my f4 eval board.

That code is supprisingly compact. The .hex is only 3k. If it were binary it would be even smaller.

[TonyD]

@vaclavpe
well done. I've been waiting for the STM32F4-DISCOVERY boards to become available in the UK. I think I'll definitely be buying one now.

It would be cool if we could get your circuit on a AVCore or stamp like board.

[vaclavpe]

I forgot one thing. Line renderer must be written in ASM to have exact timing and independence on compiler version. I found a way how to directly integrate ASM into C. And it looks that it can work properly:

Code: Select all

void render_single_line( void)
{
   asm volatile("\
      ldr   r2, [pc, #88]   @ here can be comment \n\
      push   {r4, r5, r6}\n\
...etc
      \n" :
     /* No output */ : // No output is returned from this routine.
     /* No input */ :  // Define the routine inputs (%0,%1,%2).
     "r3" );           // Specific which registers we destroy.
     // For more info on 'asm' read the GCC docs at gnu.org
}

One can start from the code created by GCC compiler.

[hpglow]

@vaclavpe
well done. I've been waiting for the STM32F4-DISCOVERY boards to become available in the UK. I think I'll definitely be buying one now.

It would be cool if we could get your circuit on a AVCore or stamp like board.

I was thinking the same thing.

I forgot one thing. Line renderer must be written in ASM to have exact timing and independence on compiler version. I found a way how to directly integrate ASM into C. And it looks that it can work properly:

Code: Select all

void render_single_line( void)
{
   asm volatile("\
      ldr   r2, [pc, #88]   @ here can be comment \n\
      push   {r4, r5, r6}\n\
...etc
      \n" :
     /* No output */ : // No output is returned from this routine.
     /* No input */ :  // Define the routine inputs (%0,%1,%2).
     "r3" );           // Specific which registers we destroy.
     // For more info on 'asm' read the GCC docs at gnu.org
}

One can start from the code created by GCC compiler.

Very nice.

What resistor values did you use in that wiring diagram posted a page back? I was going to try and make a prototype board, with snes connectors and all ( as uze was nice enough to send me two extra when I bought some from him.)

[uze6666]

Cool stuff! I just saw that Digikey has some in stock if you missed your chance on Mouser. Just ordered one too....

@vaclavpe: What's the purpose of the 74HCT245 in your schematic? The STM can't source enough current for the resistor DAC?

BTW, I saw a very cool VGA interface that uses a RBGI DAC I mentionned before, check that out. I reckon this should be used instead of the current design: http://lucidscience.com/pro-vga%20video%20generator-2.aspx

-Uze

[hpglow]

Cool stuff! I just saw that Digikey has some in stock if you missed your chance on Mouser. Just ordered one too....

@vaclavpe: What's the purpose of the 74HCT245 in your schematic? The STM can't source enough current for the resistor DAC?

BTW, I saw a very cool VGA interface that uses a RBGI DAC I mentionned before, check that out. I reckon this should be used instead of the current design: http://lucidscience.com/pro-vga%20video%20generator-2.aspx

-Uze

That is good stuff, those Lucidscience guys would be nice to have in the community here. It may also be a good idea to reserve a couple pins for more color depth possibly. Wouldn't it be possible to switch between like 8-bit and other modes depending on if you wanted more colors or you wanted to save program space? Even just adding 1-bit doubles colors. Just a thought. So if you guys decided to go RBGI then we could have 2:2:2:3 for 9 bits or 3:3:3:2 for 11 bit?

I liked that double buffering idea they used, but I'm not sure how practical it would be. I'm sure the STM32 has enough ram to double buffer at lower resolutions, but once higher video modes were developed it would be out of the question. A double tile pointer buffer may not be out of the question. So that the renderer would know which tiles were to be loaded the next frame. Then to do some tile trickery we could have a tile row buffer in ram that contained all the tile data for a given row and the next row then since all rendering would be done from an object in ram we could do tricks like color addition and subtration and other such things. Just some ideas none may be possible.

[vaclavpe]

Hi, I like foolproof solutions. That is why I used 74HCT245 (or in my test LS245) on output.

I use resistor values from Euzebox. They are computed for 5 Volts. Regarding RGBI DAC, I remember something similar was used for ZX Spectrum emulator. And there was roblem that only 8 colors instead of 16 (for 4bit DAC) could be shown. But I don't remember. It might be worth a try. Can somebody test it?

I have made next step. I can see "HELLO WORLD FROM UZEBOX!" ! The line render routine is running from FLASH but tiles[] have to be in RAM! Otherwise line renderer does not finish on time.

I tried to register stmuzebox project on sf.net. Then I will put everything there into SVN.

[uze6666]

I have made next step. I can see "HELLO WORLD FROM UZEBOX!" ! The line render routine is running from FLASH but tiles[] have to be in RAM! Otherwise line renderer does not finish on time.

From the original tutorial??? Awesome milestone, post some pics!!

-Uze

Hi, I like foolproof solutions. That is why I used 74HCT245 (or in my test LS245) on output.

Ahh, so do i! That said, it's surprising how "legacy" interfaces are forgiving. VGA, just like plain composite video (NTCS/PAL or what ever) will work just fine without any sort of buffers, lowering part count, cost and complexity.

[vaclavpe]

So, I imported some code into Sourceforge. It is here: http://stmuzebox.svn.sourceforge.net/viewvc/stmuzebox/

I will try to post some pictures here later on. But IMHO nothing interesting so far

tiles[] now can be in FLASH. But line renderer has to be in RAM. And timing is a little bit under 31.5kHz.

Have a nice reading