NES Emulator on archos605 (and SDL app porting guide)

[sideways]

FCE Ultra is an SDL based NES Emulator, version 0.98.13 compiles and runs on an archos 605, (sourcecode fceu-0.98.13-pre.src.tar.bz2).



UPDATE: see the new thread for a superior version.

Requires -frameskip 1 or 2 for most games, later gen archos units may run full-speed with no frameskip. Audio doesn't work (yet). (For the later gen units the screen initialisation method is probably different, and I'm not sure how you would do key input). I may try to speed it up if I get time.

(Probably needs screen rotated for easier keys, I might also look at that)


For those not interested in building SDL apps just download the install pack fceu.zip. Then assuming you have the GFT3 hack installed, unzip and copy the fceu directory to the top directory of the archos via usb or wifi file server (/mnt/data/fceu is created), and copy the new hack.sh (which is in the fceu directory) over old one in /mnt/data/hack.sh

UPDATE: see this post later in the thread for improved controls and a fix for the battery power off problem.

The code added to hack.sh is just after the part that renames jsplugins back to jspluginsx, you can run this from your own script if you're not using GFT3:

Code: Select all

...
# rename the jsplugins directory so hack can survive a reboot
if [ -d /mnt/data/jsplugins ]; then mv /mnt/data/jsplugins /mnt/data/jspluginsx; fi

# if NES emulator fce ultra is present, run that instead of restarting avos
if [ -d /mnt/data/fceu ]; then
  killall -SIGSTOP avos
  export LD_LIBRARY_PATH=/mnt/data/fceu
  export SDL_NOMOUSE=1
  export HOME=/mnt/data/fceu
  cp /mnt/data/fceu/transparency77 /dev/fb2
  /mnt/data/fceu/stopstart.sh &
  /mnt/data/fceu/fceu -sound 0 -fs 1 -bpp 16 -xres 800 -yres 480 -nofs 1 -frameskip 2 /mnt/data/fceu/game.nes >/dev/null 2>&1
  killall -SIGCONT avos
  exit 0
fi

...

Now run the emulator by activating GFT3 (rename jspluginsx to jsplugins and open 'dohack.html' (or content portal)). By default it runs super_mario_bros. To run any other game instead, put it in the fceu directory and rename it to 'game.nes' (rename the existing 'game.nes' file first), it can even be a zip file (but must be renamed to 'game.nes')

Keys are: up/down, left/right, X=quit, OK=enter (pause during gameplay), leftmenu=B, menu=A, leftvol=?, rightvol=tab (menu screen selection)

To run GFT3 as normal (so you can restart avos) just rename the directory to fceux.

To rerun the GFT3 hack afterwards you will need to change to another directory and back in the file browser to see the renamed jspluginsx (this is because avos is not restarted and the filebrowser is not refreshed)

NB: You really need to run this connected to usb power (or minidock power) since on battery power the unit shuts down after a few minutes (I think that's because avos is stopped, I'll have to look at it)

Get games using google search, eg http://www.nesfiles.com/, read about some cool ones at http://uk.ign.com/top-100-nes-games/3.html

============================================================================

More exciting for hobbyists and hackers is exploring SDL app porting (I originally planned to look at this ~2 years ago see here ). I provided a basic development environment (including SDL) on the GFT3 hack thread (read the relevant section in post #1 there for more info)
http://www.jbg.f2s.com/archos605/armx.ext3.gz http://www.jbg.f2s.com/archos605/setpaths.sh

UPDATE: see this post for details on how to do all this using the archos supplied cross-compiler toolchain

The fceu ultra sources compile with just two small tweaks to the configure script:

Assuming you have unzipped and copied /mnt/data/armx.ext3 and /mnt/data/setpaths.sh then from a linux box do 'ssh ip.of.archos -l root' (blank password)

then in archos ssh session type:

Code: Select all

. /mnt/data/setpaths.sh   (there is a space after the dot!)
cd /mnt/system/
wget http://fceu.googlecode.com/files/fceu-0.98.13-pre.src.tar.bz2
tar xvf fceu-0.98.13-pre.src.tar.bz2
cd fceu

Now you make 2 edits to the configure script, best to use vi:

Code: Select all

vi configure

on line 3720 (in vi, type '3720' and then shift+G) remove 'ac_preproc_ok' from the test and replce with ':' so it becomes:

Code: Select all

if :; then

(hit 'i' to enter insert mode, make the change then hit ESC)

on line 5592 add '!' to the test so it becomes:

Code: Select all

if test ! -z "${C80x86_TRUE}" && ...

now press esc, then type ':wq' to save and exit.

Then run configure:

Code: Select all

./configure

Now you could just run 'make', but we need to add some code to src/drivers/pc/input.c to handle the archos keys. I used a select() call as a quick hack to do non-blocking reads of /dev/tty0, you can download the modified input.c and copy over the old one:

Code: Select all

wget http://www.jbg.f2s.com/archos605/input.c
cp input.c src/drivers/pc/

Then run make:

Code: Select all

make

and ~25mins later src/fceu will be built (cf ~1min on a 2GHz Core2 Duo!), best to strip symbols to reduce size from ~1.2M to ~500K, (check with 'file src/fceu')

Code: Select all

strip src/fceu

============================================================================

To run from the ssh session you need to initialise the screen first, make sure the backlight is on and stop the main avos process (you don't want screen inteference from avos)

Code: Select all

kill -SIGSTOP `pidof -s avos`

(and restart avos afterwards with: kill -SIGCONT `pidof -s avos`)

if you completely kill avos rather than stopping it you won't get any key events in /dev/tty0. Note that the wifi connection will be permanent while avos is stopped - so nice alternative to keeping the file server or browser open for example.

then initialise the screen using transparency77:

Code: Select all

cp /mnt/data/fceu/transparency77 /dev/fb2

( alternative: dd if=/dev/zero bs=200k count=1 | tr '\0' '\x77' >/dev/fb2 )

now run the emulator with something like:

Code: Select all

src/fceu -sound 0 -fs 1 -bpp 16 -xres 800 -yres 480 -frameskip 2 /mnt/data/fceu/zelda.nes

then hit CTRL-Z to stop the process and then type 'fg' (Not sure why this is necessary, but it works from ssh, you can also use SIGSTOP and SIGCONT signals if launching fceu from a script, like I used above with stopstart.sh called from hack.sh)

to end a game hit CTRL-C (or 'X' button on the archos)

============================================================================

There are several SDL examples in the development pack directory /mnt/system/armx/SDLtest, you run them the same way:

Code: Select all

cd /mnt/system/armx/SDLtest/
./testwin

(then hit CTRL-Z and enter 'fg')

all these should work: testoverlay, testoverlay2, testalpha, testpalette, testbitmap, testsprite and for info try testvidinfo, testblitspeed and testplatform. (note that testsprite moves ~100 sprites at over 100fps, so with proper coding decent apps would definitely be possible)

If you kill avos then you can access the audio device via /dev/dsp, I created a python script to set volume (it's in the setpaths.sh file)

Code: Select all

kill `pidof avos_helper.sh`
volume 60
./loopwave sample.wav

or

Code: Select all

playwave /mnt/system/armx/SDltest/sample.wav

edit: there's a bug in the environment I set up for playwave which means you'll need to do: ln -s /mnt/system/armx /mnt/system/X)

I included the SDL_mixer library in the development pack, you can build others if required (eg SDL_Image (use ./configure --prefix=/mnt/system/armx/usr, make, make install)

There are many SDL examples on the web, as long as they don't use opengl or advanced SDL features they should compile and run on the archos eg a nice parallax scrolling demo http://olofson.net/download/parallax-2.tar.gz
(NB must have environment variable SDL_NOMOUSE=1 set, this is done for you if you run the setpaths.sh script from the development pack)

I noticed that ldd doesn't properly trace the libraries on these SDL apps, instead you can use the alternative 'LD_TRACE_LOADED_OBJECTS=1 sdlappname' to list the dynamic link libraries.

I probably should put all this in a wiki, but I'm not sure if there is a maintained and active one for the 605 devices, last time I looked it was spammed to oblivion.

There is an older version of the fce emulator v0.75, which is supposed to be faster, but I couldn't get it to run without segfaulting, http://hultinedutainment.se/~noname/fil ... rce.tar.gz . However, it's clear that this device could run some very nice SDL based apps with a little more tweaking, if there were more of a developer community I'm sure some cool stuff would have emerged, as it is, this is probably 2 years late now


TODO:

1. Screen rotate 90 degrees DONE
2. Speed up DONE
3. Audio ? (can only get crackles atm, may not be feasible)
4. usb gamepad (PSX1 type) via libusb see this old thread DONE
5. Fix issue with power off on battery power. DONE

[generic_username]

!!!!!!!!! nice!!!!!!!!!!!!!

once i get over the shock im gunna try this!(i assume it works basicly the same way with MC as with gft3 cept i gotta SSH the commands or use the wifi server dialog or some such?)

this and the text edit were all i really wanted from archos!

[divx118]

You did a lot of work sideways . Sorry I am too busy at my work, I barely have time for my family . As soon as I have a free moment I will try this. It looks great.

Thanks for your time and effort you put into this.

Maurice

[sideways]

@generic_username: Cheers, but don't get too excited, the key control is a little frustrating at the moment (until I work out how to rotate the screen). The usb joystick (via minidock usb port) won't be too tricky, but it's probably only worthwhile if playing on a tv, and while you can do that via the minidock, the screen is not orientated very well, so until I fix that (if ever) and get audio, the full console experience is lacking

@divx118: I've had some spare time recently babysitting days on end, so decided to explore the ideas that came up a couple of years back, and take them to some conclusions.

An arm based device like this with a fantastic screen is great to experiment with.

It's just a shame Archos didn't open the devices for development early in 2008, back then a fairly positive hacking philosophy existed (we weren't aiming at unlocking plugins for instance), a lot of momentum could have been created and the developer community would be much more vibrant, which would have passed on to the new gen devices.

I really ought to get a new gen device and get involved with the official open development.

I also like the look of the Archos 9 tablet, apart from battery life, it's far more desirable imho than the apple ipad (for the stupid and overly fashion conscious only)

[grond]

First of all: good job!

the key control is a little frustrating at the moment

At least the 605 does have some keys...

The usb joystick (via minidock usb port) won't be too tricky

Does it require a kernel module? There is still that nasty kernel module signature stuff in your way...

I really ought to get a new gen device and get involved with the official open development.

That would be cool! Right now most people involved in the development seem to have an a5 but now that the a5it is open, too, the a5it seems to be much more attractive (twice the amount of RAM and 256M of flash to put the operating system on while you get the problem of the harddisk spinning up and down all the time on the a5).

I also like the look of the Archos 9 tablet, apart from battery life, it's far more desirable imho than the apple ipad

I'm sure not going to defend an Apple product but I'm not sure whether the Archos 9 is desirable at all. Just look at this:

http://www.reghardware.co.uk/2010/02/15 ... page3.html

Okay, with a better operating system it might not crawl that badly but even my EEEBox 202 with a much faster Atom breed and running linux / gnome is quite slow...

[sideways]

The usb joystick (via minidock usb port) won't be too tricky

Does it require a kernel module? There is still that nasty kernel module signature stuff in your way...

No you can read usb devices pretty simply via libusb (the library is in the default firmware), I did that 2 years ago

I'm sure not going to defend an Apple product but I'm not sure whether the Archos 9 is desirable at all. Just look at this:

http://www.reghardware.co.uk/2010/02/15 ... page3.html

Okay, with a better operating system it might not crawl that badly but even my EEEBox 202 with a much faster Atom breed and running linux / gnome is quite slow...

The comparisons in that review with netbooks is a bit silly, it's not a netbook. And at least it runs flash (if not optimally), the iPad doesn't. I'm sure someone who knows what they are doing with linux and doesn't run shite windows 7 starter edition could make this baby perform perfectly well, I've had very few problems on the slighty faster atom based netbooks with linux, and the cpu is rarely maxed out, so I wouldn't expect huge issues with the Archos 9 (admittedly I haven't tested), I bet you'll even get H264 open source solutions for it (assuming it doesn't die)

edit, I notice they say

We tested a selection of H.264 and AVI video files up to and including 1080p and didn't encounter any playback issues.

I don't think any netbook (maybe the latest nvidia ion based ones) or the iPad does that.

And comparing 6cell netbook battery life with smaller batteries is pointless.

And the reviewer is ignorant of flash performance on other poulsbo graphics based netbooks, that'll will be fixed in falsh 10.1 I believe.

[sideways]

the key control is a little frustrating at the moment

At least the 605 does have some keys...

Thinking about that, it would be pretty easy to put touchscreen controls on the display (ts events can just be read from /dev/input/tsraw0) since there's space on the rhs if you run the emulator at 640x480 mode (or at the bottom if I rotate the screen), but it would not be an ideal controller to use (can't fire/jump and move at the same time)

I'll probably experiment with this and the usb joystick method.

It shouldn't be difficult for someone with a newer gen model to test if the fceu emulator runs, the arm development environment may even work on these models if you want to try compiling it yourself (or better, use a cross-compiler if you have one setup, you need to compile SDL first), the instructions for building fceu above should work.

[CheBuzz]

What would be really awesome is if somebody could get this code to work on the A5IT. That has built-in bluetooth, so you could connect to a wiimote. That's about as native of a controller as you can get...

Anybody up for some driver work/code porting? Maybe it's time to set up a donation pool so kevin_ can get an A5IT.

[sideways]

There are lots of other possible emulators to try http://www.usinglinux.org/emulators/

I think the newer gen devices would run many of these well, the a605 is a little underpowered, eg I did get also get this gameboy emulator running http://m.peponas.free.fr/gngb/ , but at <20fps full screen it's not really playable on the a605. fce ultra seems to be very well optimised.

In the end I feel a better option would be to get one of these great open-source portable game consoles:

http://www.pocketgamer.co.uk/r/GP2X+Wiz ... sp?c=14461 (update of the classic GP2X )

http://www.cbargains.co.uk/index.php?ro ... duct_id=91 (£70 for the Dingoo A320 !!)

http://www.open-pandora.org/ (looks awesome, but not fully released yet)

[Styler]

Thanks! It's good work, but I have reboot after 5 playing min. ( I use GTF2 )
There is possible to emulate sega?

[sideways]

Thanks! It's good work, but I have reboot after 5 playing min. ( I use GTF2 )
There is possible to emulate sega?

Is the reboot on battery power? I pointed out that issue, it occurs because I have to stop avos while the emulator is running, I'm trying to work out a fix, it doesn't happen on mains power.

btw, I realised I could use the blank lhs of the touch screen as the A and B buttons (top=A, bottom=B), which makes the control much easier (keys for direction movement and lhs of touchscreen for fire/jump etc, so you can use two hands)

So I don't need to rotate the screen, I'll post an update soon when I figure out a couple of other issues.

There are some good sega emulators around, but they often use opengl and/or custom intel assembler (for speed), I'm not confident that the existing code will run fast enough on the a605. But people have done ports to things like the GP2X I mentioned above, which has a similar spec arm chip (but smaller screen), it would take quite some time to port to the a605, and might not be worth the effort.

[divx118]

Home early today from work and just tried the emulator. It works great . Speed is good, but just like you said the controls are a bit tricky to use.
When on main power I had no problems with a sudden shutdown.
I am now going to take a look at the source and try to build it myself.

Maurice

[CheBuzz]

The reboot happens because the power co-processor is not poked. This is referred to often as "petting the watchdog". It should be pretty simple to add code that will go out and do this for you.

[sideways]

@chebuzz, ok cheers, any idea if there's a /sys entry I can echo to, or do I need to write to a memory address? (I couldn't find anything obvious to use on the archos.g3nius.org site )

(frustratingly, this would be solvable by running the emulator from /opt/usr/bin/pdf a la qtopia, but that runs as user 'nobody' and I then have the problem with using a setuid which ignores LD_LIBRARY_PATH for the SDL lib, and not sufficient permission to read /dev/tty. But I can probably resolve both these if the poking method fails)

As well as fixing that, I want to tweak the speed more, but that may take some time, so I'll just post this update which maps the touchscreen to the A and B buttons (A = lower half, B = Upper half). This makes the control much easier since you can use the directions buttons with your right hand and press the blank lhs of the touchscreen with your left thumb)

In fact, I might add on screen direction buttons to the blank rhs part of the screen too. This would be a solution for the newer gen units without physical buttons, although the real buttons are easier to use for direction control.

This is just a quick update to add the touchscreen controls, so it doesn't draw on-screen buttons A & B (just press the top/bottom half of the screen), it makes vertical shoot-em-ups like galga much easier.

http://www.jbg.f2s.com/archos605/fceu.gz

(unzip and copy fceu over the existing executable in the fceu directory)

[divx118]

On the 605 I would prefer an option to rotate the screen and play the games with the buttons.
Does avos control the charging? I don't see my green led start blinking when I have stopped avos and the battery is full. However the battery isn't getting hot so it is not overcharging.
BTW I also tried the atari800 emulator SDL based. It compiles ok, but when running I get a segmentation fault.
I am looking also for some other usefull SDL applications that can be compiled and run on the 605.

Maurice

EDIT: I have the atari emulator running, I took an older version and it worked. I will see if I can make it to some use and then make a new thread about it. BTW sideways thanks for the SDL compiling guide.

[map002]

I still don't see where you plug the Star Raiders cartridge in...

Oh player-missile graphics and typing in pages of code from the back of Antic magazine, how I do miss it so...

Michael

[sideways]

@map002 yeah, as I mentioned the full console experience isn't possible

@divx118: cool, which version of the atari800 emulator works? (maybe post in new thread if you prefer)

Probably need a usb keyboard, which isn't too difficult to write with libusb code, but I don't own one to test with (I have successfully tested a usb joystick and mouse, see here)

In the meantime you could map the existing keys and some touchscreen events to the various function keys used, here's the code I added to the fce ultra src/drivers/pc/input.c code to read the keys and touchscreen

Code: Select all

...
// next two includes required for archos event code
#include <fcntl.h>
#include <unistd.h>
...
...
struct ts_event {
  unsigned short pressure;
  unsigned short x;
  unsigned short y;
  unsigned short millisecs;
};

static void KeyboardCommands(void)
{
  int is_shift, is_alt;

  keys=GetKeyboard();

  // custom code to read archos touchscreen & key events
  // ***************************************************
  static int tsfd=0, ttyfd=0;

  struct ts_event tsev;
  uint8 archoskey;

  // variables used by the select() command to poll keyboard 
  fd_set rfds;
  struct timeval tv;
  int retval;

  // Open the touchscreen for reading
  if (!tsfd) tsfd = open("/dev/input/tsraw0", O_RDONLY) ;
  if (!tsfd) {
     printf("Error: cannot open touchscreen raw device.\n");
     exit(1);
  }

  // Open /dev/tty0 for reading key presses
  if (!ttyfd) ttyfd = open("/dev/tty0", O_RDONLY);
  if (!ttyfd) {
     printf("Error: cannot open /dev/tty0.\n");
     exit(1);
  }

  /* Watch keys and touchscreen for input */
  FD_ZERO(&rfds);
  FD_SET(tsfd, &rfds);
  FD_SET(ttyfd, &rfds);

  /* Set wait period to 1  millisecs */
  tv.tv_sec = 0;
  tv.tv_usec = 1;

  retval = select(ttyfd+1,&rfds, NULL, NULL, &tv);

  if (retval)
  {
    if (FD_ISSET(ttyfd, &rfds))  // was a key pressed?
    {
      // decode the key press event
      read(ttyfd, &archoskey, 1);
      switch (archoskey) {
        case 0x3c: KEY(ESCAPE)=1; break;// X
        case 0x1c: KEY(ENTER)=1; break;// OK
        case 0x9c: KEY(ENTER)=0; break;
        case 0x67: KEY(W)=1; break;// Up
        case 0xe7: KEY(W)=0; break;
        case 0x6c: KEY(Z)=1; break;// Down
        case 0xec: KEY(Z)=0; break;
        case 0x69: KEY(A)=1; break;// Left
        case 0xe9: KEY(A)=0; break;
        case 0x6a: KEY(S)=1; break;// Right
        case 0xea: KEY(S)=0; break;
        case 0x73: KEY(TAB)=1; break;// Vol Up
        case 0xf3: KEY(TAB)=0; break;
        //case 0x72: KEY(?)=1; break;// Vol Down
        //case 0xf2: KEY(?)=0; break;
        case 0x3e: KEY(KP2)=1; break;// Menu left
        case 0xbe: KEY(KP2)=0; break;
        case 0x3b: KEY(KP3)=1; break;// Menu right
        case 0xbb: KEY(KP3)=0; break;
      }
    }

    if (FD_ISSET(tsfd, &rfds)) // was there a touchscreen event?
    {
      read(tsfd, &tsev, 8);
      //printf("pressure=%u x=%u  y=%u  msec=%u\n", tsev.pressure, tsev.x, tsev.y, tsev.millisecs);

      if (tsev.y > 2000) KEY(KP3)=1;
      else  KEY(KP2)=1;
      if (tsev.pressure == 0) { KEY(KP3)=0; KEY(KP2)=0; }
    }
  }

  //**************************************
  // end of custom archos code
...
...

The touchscreen code is very basic, just to check whether the top or bottom of the screen was pressed for buttons A (KP3) and B (KP2), and when you remove your finger from the screen you get a zero event.

For the keys, you get a single bytecode when pressed, and bytecode+0x80 when released.

[divx118]

@ sideways thanks for the inside on the input methods. For the USB keyboard, it could also be done with the remote from the DVR dock. There is all kind of input support already integrated in the atari emulator, but I still need some time to look all trough that.
Like with your nes emulator, I also didn't have any audio yet.
I tried the 1.3.3 version which works and the newest version 2.1.0 which gave me the segmentation fault. I still have to try the versions in between.
When compiling I didn't have to change anything in the configure file, it just compiled out of the box. If I have any update I will make a new thread.

Some other issue with the NES emulator is when I use the TV output the display will be scrambled on the TV. My guess is that TV out is a different resolution so the width and height parameters need to be changed. I have however not tried that yet. Also the remote doesn't work, but that is also not a surprise.

I also could compile the AKFavatar with some minor changes in the configure file. Only when I run it the display is a bit scrambled. My guess again the wrong resolution. This has to be however changed in the source, there are no command line parameters available to do it.

Maurice

[sideways]

For tvout I think -xres 640 -yres 480 works if you change that in the fceu command, but it still displays a little off screen on my tv, and touchscreen doesn't work in tv mode, but if it's attached to the tv via a dock you'll be able to plug in a usb gamepad, which I'm gonna add to the code soon;)

edit: oh, actually the touchscreen does work in tv mode, I never thought to test!

(The NES 8 sprite limit per scanline is more noticeable on the tv, but you can add '-no8lim 1' to the fceu options to disable that, and you won't get the flickery graphics on games like gradius (and other horizontal scrollers))

[serag]

is it the same procedure to make it work on 605's that have the moldy cheese patched firmware instead of the GTF3?