Uzem on Raspberry Pi
Uzem on Raspberry Pi
I went ahead and compiled Uzem on the Raspberry Pi, not the actual hardware a Virtualbox VM. I have tested Megatris and Donkey Kong on it both seemed to work ok. The program reports a sound underrun error on the terminal, but I think that has to do with the VM because I get other sound errors while running the VM. Looks like running the emulator puts the 700 mhz ARM processor at 50% useage, of course I wouldn't know without actual hardware. All I had to do is 'Make clear' then 'make' it compiled fine. If anyone is interested the Pi VM is running an install of Debian.
Re: Uzem on Raspberry Pi
Sorry I jumped the gun on this post. The VM they supplied is not emulating ARM. It is just a speed/ram restricted VM running on virtual box. I should have known when it compiled real easy. I'm going to try qemu to see if I can get a more realistic setup for the ARM on the Raspberry Pi.
Re: Uzem on Raspberry Pi
wow, at 25$ , that's almost competition for the real deal
Re: Uzem on Raspberry Pi
There are a number of users that want to make a minimalist OS for retro gaming. We will see what happens after launch. I gave up trying to get Uzem going on VB. I will give it another go once I get my hands on the real hardware. I would like to make a full Uzebox development environment for it but we will see. Time is at a premium for me these days.
Re: Uzem on Raspberry Pi
The Raspberry Pi is a project I've been following for sometime and while I don't think its got the simplicity of the Uzebox it would be a cool development platform if we could get the AVR tools and Uzem working on it.
Re: Uzem on Raspberry Pi
You should be able to build Uzem without much problem for ARM. I would suggest you to use SDL on top of the framebuffer instead of using a X server in order to save some cycles.
Re: Uzem on Raspberry Pi
HPGLOW:
I have RPi please can you make UZEM+LINUX distro... Just booting to UZEM and I will choose ROMs from SD.
It will be great to have such distro (SD card image). I am huge FAN of UZEBOX since very beginnings... But still havent one.
I wanted to buy EUzebox kit. But cant wire it by myself. So RPi as UZEBOX will be supercool.
I have RPi please can you make UZEM+LINUX distro... Just booting to UZEM and I will choose ROMs from SD.
It will be great to have such distro (SD card image). I am huge FAN of UZEBOX since very beginnings... But still havent one.
I wanted to buy EUzebox kit. But cant wire it by myself. So RPi as UZEBOX will be supercool.
Re: Uzem on Raspberry Pi
Eh, yeah uzem on the rPi would be cool. If hpglow ever ports it, i'll buy one for sure!
Re: Uzem on Raspberry Pi
I have a Raspberry Pi at home that I got for christmas.
If I get some time this weekend, I'll see if it compiles. It should when you consider that all the dependencies are there. Doesn't mean it'll run at full speed, but I wouldn't expect any major problems.
Weeeee!
If I get some time this weekend, I'll see if it compiles. It should when you consider that all the dependencies are there. Doesn't mean it'll run at full speed, but I wouldn't expect any major problems.
Weeeee!
Re: Uzem on Raspberry Pi
I built it and ran it on a stock clocked Pi and it got ~3 MHz.
I've done some tweaking to get it up to 6MHz.
A bit more work and I'm confident we can hit 28MHz (possibly with ARM assembler, or statically decoding all the instructions in advance into byte fields to remove decoding overhead).
(The biggest perf killers were - big static array at the top of the class making all the other member references >64k away from base pointer, u8/s8/u16/s16's where native sized vars will do, and the main loop per cycle baggage - breakpoint checking (better done as a new instr), pixel rendering and timer ticking (both of which need hoisting / doing in a lazy fashion).
I've done some tweaking to get it up to 6MHz.
A bit more work and I'm confident we can hit 28MHz (possibly with ARM assembler, or statically decoding all the instructions in advance into byte fields to remove decoding overhead).
(The biggest perf killers were - big static array at the top of the class making all the other member references >64k away from base pointer, u8/s8/u16/s16's where native sized vars will do, and the main loop per cycle baggage - breakpoint checking (better done as a new instr), pixel rendering and timer ticking (both of which need hoisting / doing in a lazy fashion).