Uzem on Raspberry Pi

The Uzebox now have a fully functional emulator! Download and discuss it here.
Post Reply
hpglow
Posts: 269
Joined: Wed Apr 14, 2010 6:06 am

Uzem on Raspberry Pi

Post by hpglow »

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.
UzemRPi.jpg
UzemRPi.jpg (60.17 KiB) Viewed 12297 times
hpglow
Posts: 269
Joined: Wed Apr 14, 2010 6:06 am

Re: Uzem on Raspberry Pi

Post by hpglow »

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.
User avatar
codecrank
Posts: 66
Joined: Sun Nov 16, 2008 10:13 pm
Location: Denver, Co

Re: Uzem on Raspberry Pi

Post by codecrank »

wow, at 25$ , that's almost competition for the real deal ;)
hpglow
Posts: 269
Joined: Wed Apr 14, 2010 6:06 am

Re: Uzem on Raspberry Pi

Post by hpglow »

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.
User avatar
TonyD
Posts: 134
Joined: Mon Oct 27, 2008 2:23 pm
Location: Newcastle, UK
Contact:

Re: Uzem on Raspberry Pi

Post by TonyD »

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.
User avatar
filipe
Posts: 42
Joined: Thu Dec 17, 2009 10:37 pm
Location: Cambridge, UK

Re: Uzem on Raspberry Pi

Post by filipe »

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.
Tinctu
Posts: 65
Joined: Sun Aug 31, 2008 2:22 pm

Re: Uzem on Raspberry Pi

Post by Tinctu »

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.
User avatar
uze6666
Site Admin
Posts: 4801
Joined: Tue Aug 12, 2008 9:13 pm
Location: Montreal, Canada
Contact:

Re: Uzem on Raspberry Pi

Post by uze6666 »

Eh, yeah uzem on the rPi would be cool. :-) If hpglow ever ports it, i'll buy one for sure!
User avatar
Flecko
Posts: 158
Joined: Mon Jan 05, 2009 11:50 pm

Re: Uzem on Raspberry Pi

Post by Flecko »

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!
jiminy
Posts: 16
Joined: Fri Jan 06, 2012 2:00 pm

Re: Uzem on Raspberry Pi

Post by jiminy »

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).
Post Reply