It is currently Mon Jun 18, 2018 4:05 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 15 posts ] 
Author Message
PostPosted: Tue Aug 19, 2014 4:51 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 20158
Location: NE Indiana, USA (NTSC)
I do most of my NESdev on a Dell Inspiron mini 1012 laptop with a 10.1" inch screen. But Dell doesn't make those anymore, and I worry about what I'll use once it no longer boots or once replacement batteries stop being manufactured. With the decline of 10" laptops that run desktop operating systems in favor of convertible tablets that run Android and Chromebooks that run Chrome OS, it has become harder to find good hardware to do NESdev on the go. Someone recently managed to get ASM6 running on Android. But it'd be nice to have a decent emulator that runs on Android. I see three issues with the emulators out there.

First, we need an emulator that we know emulate the NES accurately enough that game logic, common mappers, and well-behaved raster effects run correctly. I imagine that at first, most people won't be working on projects using oddball mappers or trying to debug raster effects that require cycle accuracy while away from home. But a lot of the NES emulators on Android are paid applications, which makes it harder to evaluate their accuracy without buying them all. Or do paid NES emulators for Android include the developer's promise of best effort to get their behavior on particular ROMs to match the observed behavior of an NES running the same ROM?

Second, I tried a Mario style platformer for Android called Pixeline and the Jungle Treasure on my Nexus 7 tablet. It handled fine with a Bluetooth keyboard, but I kept missing jumps with the on-screen gamepad. So we need an emulator with a useful translation from touch to NES input so that game logic can be tested efficiently. This might involve mapping swipes (not presses of visible buttons) to keypresses, or treating the screen as a trackpad and emulating the Super NES Mouse, or exposing additional registers to reflect touch and accelerometer coordinates for Android debug builds, or some other method I haven't thought of.

Third, a developer's emulator should include saved states and a step debugger, possibly accepting FCEUX .nl files or symbol files from the popular assemblers.

What would be the best way to go about this? Or should one just accept the misfortune of having to carry a larger laptop?


Top
 Profile  
 
PostPosted: Tue Aug 19, 2014 4:57 pm 
Offline
User avatar

Joined: Mon Feb 07, 2011 12:46 pm
Posts: 985
I think using a laptop computer would be a better way, although for Android, you could instead of using the Google store, search elsewhere such as Google Code or Sourceforge or whatever for open source software and see if there is any suitable. If not, you can either use the Google store or modify a program that is almost suitable so that it can be used.

_________________
.


Top
 Profile  
 
PostPosted: Tue Aug 19, 2014 5:30 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 7211
Location: Seattle
You can get x86 chromebooks and install ordinary linux (or even windows sometimes) on them... but touch screens are so awful I don't think it's really worth trying to make it not suck for programming.

libwine could probably be used with the FCEUX source to get a native ARM build with the debugger, or maybe cpow's MFC→QT compatibility layer would hurt less.


Top
 Profile  
 
PostPosted: Tue Aug 19, 2014 5:52 pm 
Offline
Formerly 43110
User avatar

Joined: Wed Feb 05, 2014 7:01 am
Posts: 325
Location: us-east
I have the same feeling about the transition to tablets as well, and how it's discouraging how much of the massive backlog of software (with or without source) is completely incompatible. Even at the point of how software can be installed.
I'm interested in the general progress of framework porting to android, but I get the felling it's going to be years until I'm happy with android as much as any flavor of GNU/Linux.

Not to imply i'm doing this now, but I have a plan to implement a complete IDE in local browser javascript, using things like loading and saving a zip folder for directory trees, and maybe a bit of hand written asm.js.


Top
 Profile  
 
PostPosted: Tue Aug 19, 2014 6:30 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 20158
Location: NE Indiana, USA (NTSC)
lidnariq wrote:
You can get x86 chromebooks and install ordinary linux (or even windows sometimes) on them

As I recently wrote in this Slashdot comment: Does putting a Chromebook in developer mode void the warranty on the hardware? I don't want to have to buy a new Chromebook if it develops a broken hinge or an unusably loose charging port a week after I put it in developer mode.

Quote:
... but touch screens are so awful I don't think it's really worth trying to make it not suck for programming.

It can't be worse than early 8-bit computers by Atari, Sega, and Sinclair with membrane keyboards. In fact, a specialized editor on a tablet would allow predictive completion of instructions and symbol names and background syntax checking.


Top
 Profile  
 
PostPosted: Wed Aug 20, 2014 12:23 am 
Offline
User avatar

Joined: Mon Feb 07, 2011 12:46 pm
Posts: 985
lidnariq wrote:
... but touch screens are so awful I don't think it's really worth trying to make it not suck for programming.
I agree; I hate touch screens too. However, Android does have support for physical keyboard, at least.

_________________
.


Top
 Profile  
 
PostPosted: Wed Aug 20, 2014 4:52 am 
Offline
NESICIDE developer
User avatar

Joined: Mon Oct 13, 2008 7:55 pm
Posts: 1060
Location: Minneapolis, MN
lidnariq wrote:
You can get x86 chromebooks and install ordinary linux (or even windows sometimes) on them... but touch screens are so awful I don't think it's really worth trying to make it not suck for programming.

libwine could probably be used with the FCEUX source to get a native ARM build with the debugger, or maybe cpow's MFC→QT compatibility layer would hurt less.

Interested.


Top
 Profile  
 
PostPosted: Wed Aug 20, 2014 5:13 am 
Offline

Joined: Tue Feb 11, 2014 7:12 am
Posts: 44
There is an NES (several cores are available within it) that also supplies it's source code: RetroArch (Multiple platforms are Emulated with it)
It has got 3 NES cores to emulate the system, it is available on Google Play, and the source code with a tutorial on how to compile it for Android OS is also available.
You might want to check it out:
http://www.libretro.com/index.php/wiki/ ... m-windows/
This link is a tutorial on how to compile the Emulator for Android.


Top
 Profile  
 
PostPosted: Wed Aug 20, 2014 5:24 am 
Offline
User avatar

Joined: Mon Jan 03, 2005 10:36 am
Posts: 3076
Location: Tampere, Finland
lidnariq wrote:
or maybe cpow's MFC→QT compatibility layer would hurt less.

Pretty sure FCEUX's GUI is plain Win32 API though, no MFC.

_________________
Download STREEMERZ for NES from fauxgame.com! — Some other stuff I've done: fo.aspekt.fi


Top
 Profile  
 
PostPosted: Wed Aug 20, 2014 6:22 am 
Offline
NESICIDE developer
User avatar

Joined: Mon Oct 13, 2008 7:55 pm
Posts: 1060
Location: Minneapolis, MN
thefox wrote:
lidnariq wrote:
or maybe cpow's MFC→QT compatibility layer would hurt less.

Pretty sure FCEUX's GUI is plain Win32 API though, no MFC.

Yep. As usual, this is somewhere around the third or fourth time I've forgotten that. This time I didn't stumble to the source to figure it out. :beer:


Top
 Profile  
 
PostPosted: Wed Aug 20, 2014 9:13 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 20158
Location: NE Indiana, USA (NTSC)
I wonder if the mainline FCEUX devs would be interested in porting it away from raw Win32.


Top
 Profile  
 
PostPosted: Wed Aug 20, 2014 10:37 am 
Offline
User avatar

Joined: Sun Sep 19, 2004 9:28 pm
Posts: 3387
Location: Mountain View, CA
tepples wrote:
I wonder if the mainline FCEUX devs would be interested in porting it away from raw Win32.

No, and the pushback you'd get would be major. Nobody goes from Win32 to MFC; they go the other way and for a lot of damn good reasons. MFC is awful.

Everyone step back a moment and think about the real "problem" (if it is even a problem to begin with): FCEUX was designed and intended for Windows, not other platforms (yes I'm aware of the SDL port). So what's needed is for parts of the source to be split up / separated out so that FCEUX could be built for other UI frameworks or platforms (e.g. QT, GTK).


Top
 Profile  
 
PostPosted: Wed Aug 20, 2014 10:59 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 20158
Location: NE Indiana, USA (NTSC)
I wasn't thinking Win32 to MFC. I was thinking Win32 to something more modern, like Qt.


Top
 Profile  
 
PostPosted: Wed Aug 20, 2014 12:36 pm 
Offline
User avatar

Joined: Sun Sep 19, 2004 9:28 pm
Posts: 3387
Location: Mountain View, CA
tepples wrote:
I wasn't thinking Win32 to MFC. I was thinking Win32 to something more modern, like Qt.

Choose wisely.


Top
 Profile  
 
PostPosted: Wed Aug 20, 2014 2:10 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 20158
Location: NE Indiana, USA (NTSC)
Buck feta. But anyway:

According to the article, Qt is GPLv2/LGPLv3, and FCEUX is GPLv2+. I see no incompatibility.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 15 posts ] 

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 2 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group