Thinking about STMUzebox

Discuss anything not related to the current Uzebox design like successors and other open source gaming hardware
WAHa.06x36
Posts: 31
Joined: Sat Feb 04, 2012 6:11 pm

Re: Thinking about STMUzebox

Post by WAHa.06x36 » Sun May 06, 2012 9:27 pm

I'd suspect it would be something about the standard library and ARM/Thumb/Thumb2 code. Getting the multilib config correct is tricky, and I had lots of trouble with that too.

I recommend downloading the binaries for the devkitARM toolchain, and using that to build. If that works, you can either use that or try to figure out what your own build is doing differently.

(One thing to check is if arm-eabi-objdump -d file.elf is showing any code that looks like ARM code, with all opcodes being 32 bit words, rather than one or two 16-bit halfwords as on Thumb-2.)

Dirt.Diver
Posts: 6
Joined: Fri Apr 27, 2012 7:50 am

Re: Thinking about STMUzebox

Post by Dirt.Diver » Sat Jun 09, 2012 1:58 pm

I finally had some time to devote to this and I got it working, with the devkitArm. I wound up using st-link git://github.com/texane/stlink.git for flashing the stm32f4. I couldnt get openocd working in linux.

The demo looks really good. Instead of building out my own r2 ladder for the vga, I took the easy way out and purchased the Papilio Arcade Mega wing. Not to sound like a salesperson but for $20 you get a pcb board with

VGA Port - DB15 Female VGA connector capable of generating 4096 colors.
Stereo Audio Jack - 1/8" Stereo jack with low pass filter is ready for CD quality Delta-Sigma audio output.
Joystick Ports - Two DB9 Male joystick ports accept Atari, Commodore, and classic arcade joysticks.
PS/2 Ports - Two PS/2 ports accept a keyboard and mouse.
4 Way Buttons - 4 buttons in a plus configuration for user input.
4 LED's - 4 LED's for user feedback.
Reset Button - A single reset button.

http://www.gadgetfactory.net/papilio-megawings/

I started by just wiring up the vga outputs to check out the demo. My ultimate plan is to build out a stm32 homebrew arcade.

User avatar
makapuf
Posts: 13
Joined: Sun Jun 24, 2012 11:55 pm

Re: Thinking about STMUzebox

Post by makapuf » Mon Jun 25, 2012 12:45 am

hi there ; first of all congrats / kudos for the awesome demo ! :shock:

Having myself being interested in embedded electronics, the stm32f4discovery and homebrew consoles, this thread has really got me hooked !

Bravo for your work, I'm sure it will spark some enthusiasm.

I proceeded to buy a discovery and built a crappy R2R ladder dac (8bits) on a protoboard, and tried to run your sample VGA.

First step, the untold pain of having a build tool chain environment on a recent linux box (finally gotten to work through summon-arm-toolchain - but a patched version since original one cannot work with modern autotools. Gotten a blinkled code to compile, uploaded it with texane stlink (eternal praise for that tool to texane), undesrtanding / fighting with gdb etc etc : it worked !!! )

Then after fighting with the demos / STM4VGA multilib (the joy of using leds for debugging) : it worked ! After I found the culprit : the Terrible.specs (indeed!) LD flags. Once those lines removed : 8-) YAY ! (not without blasting my ears out using earphones with no volume setting ... :cry: )

So if others want to build their own toolchain on linux ubuntu 12.04 64bits :

- Stlink/texane for uploading to the STMf4 Discovery
- summon-arm-toolchain (patched for recent autolib : http://github.com/agschult/summon-arm-toolchain) - or use standard one and don't build openOCD, since we use stlinkv2 from texane
(rework makefiles to call arm-none-eabi-gcc / gdb was needed)
- profit !

OK, so my next steps : building a less crap 12 bits R2R DAC (not a real R/2R like I did since it would use too many resistors(with only R and 2R resitors - 16 resistors for a 8 bit dac, using 1% resistors, ...) ) , displaying a 640*480 / 12 bits still picture from flash (is it possible to generate the timings ?) and ... code new super mario bros :)

makapuf (who really needs a second monitor or a least a cheap kvm switch now ..)

User avatar
makapuf
Posts: 13
Joined: Sun Jun 24, 2012 11:55 pm

Re: Thinking about STMUzebox

Post by makapuf » Sat Jun 30, 2012 10:06 am

WAha, a few questions about your code : what license is it released in ?

Do you have a documentaiton about the "BitBin" tracker / is there a song editor (other than vi ;) ) ? is it related to http://bit.s3m.us/ ? I tend to recognize a song ... if so, how do you get the data locally / do you have a code gen tool ?

Same, is the Graphics / Pixels subpart documented (or commented) somewhere ? Is it a reuse from a library ?

thanks !

Markus Gritsch
Posts: 5
Joined: Tue Aug 14, 2012 2:23 pm

Re: Thinking about STMUzebox

Post by Markus Gritsch » Mon Aug 20, 2012 2:58 pm

WAHa.06x36 wrote:All right, I finally put a dump of the source code up:

http://wakaba.c3.cx/repos/stm32f4-vga/

This is also a Mercurial repository, so it can be cloned with

hg clone http://wakaba.c3.cx/repos/stm32f4-vga/

There is a schematic for the particular DAC setup I use:

http://wakaba.c3.cx/repos/stm32f4-vga/D ... ematic.png

I probably won't be porting the Uzebox code, as I am not very familiar with it at all. However, if anyone else wants to do it, feel free to use whatever you want from the above code. Consider it public domain code, or zlib licensed if public domain does not seem valid where you live.
When I try to compile Sprite.c, I get lots of errors. It seems that RLECode(), RLECodeCount(), RLEEndCode(), RGB(), etc. are nowhere defined. Is there some file missing from the source code?

Thanks, Markus

Markus Gritsch
Posts: 5
Joined: Tue Aug 14, 2012 2:23 pm

Re: Thinking about STMUzebox

Post by Markus Gritsch » Mon Aug 20, 2012 3:54 pm

ok, the peridiummmm-source has an updated version of RLEBitmap which contains these defines. However, due to other changes in these files, they are not a drop-in replacement. It would be nice, if the stm32f4-vga sources would be updated to a consistent state again :)

Markus Gritsch
Posts: 5
Joined: Tue Aug 14, 2012 2:23 pm

Re: Thinking about STMUzebox

Post by Markus Gritsch » Tue Aug 21, 2012 7:32 am

The program runs fine without the Sprite-part. The generated image using the DMA-transfer is not perfectly stable. The individual lines jitter around a little bit. As already said, not really noticeable on sequences with lots of movement, but not really good looking for still images.

WAHa.06x36
Posts: 31
Joined: Sat Feb 04, 2012 6:11 pm

Re: Thinking about STMUzebox

Post by WAHa.06x36 » Fri Mar 22, 2013 5:33 pm

Well, Easter is coming up again and that means a new Revision party, so we've been working on the STM32 source again.

There is now an updated version of the VGA code at http://wakaba.c3.cx/repos/stm32f4-vga/.

The jitter is almost completely fixed, by using the hardware timers to drive the hsync pin and DMA timer directly. It looks a whole lot better now.

There's going to be another demo for Revision too, but that's still in development

Markus Gritsch
Posts: 5
Joined: Tue Aug 14, 2012 2:23 pm

Re: Thinking about STMUzebox

Post by Markus Gritsch » Sat Mar 23, 2013 7:40 pm

Thanks for the update. Looking forward to your demo :)

Still a bit jittering, but I think this cannot be avoided when using DMA to do the transfer.

One note: Please remove the line #include <strings.h> in DrawingRLEBitmaps.c. It is not part of the standard library and thus not included in my toolchain. And its not used my the code anyways.

Cheers,
Markus

Dirt.Diver
Posts: 6
Joined: Fri Apr 27, 2012 7:50 am

Re: Thinking about STMUzebox

Post by Dirt.Diver » Sun Mar 24, 2013 1:16 am

For the stm32f4 what tool chains are people using? I have seen a few setup guides for linux. I would love to see other peoples code/info to learn from. Thanks

Post Reply

Who is online

Users browsing this forum: No registered users and 2 guests