[Exophase]

Since MZXCon is coming up real soon and I'm bringing my Pandora with me I thought it'd be fun to port MZX to it. Naturally it was an extremely simple port, taking a grand total of a few minutes.

Some of you should already know what Pandora is, and I know paulguy has one on preorder. For the rest of you, please read here: http://pandorawiki.org/Pandora

In short, it's a handheld that's far better suited for MegaZeux than PSP - which I imagine is itself far better suited than GP2X or DS. So really this is the handheld for MZX on the go. Compared to PSP it has:

- adequate resolution for full detail (800x480)
- full (enough) physical keyboard with pretty good keys, including all twelve function keys available via fn (you can tell this was made for emulating computers)
- touchscreen for mousing
- awesome controls save for the just-OK shoulder buttons and somewhat hit or miss analog nubs, neither of which are very important to MZX - great dpad on this one
- solid Linux (Angstrom) and X11 (xfce) environment
- tremendous battery capacity

So indeed, it's good for editing as well as playing.

Sadly, only some 500 are out in the wild right now, although that number will soon increase to 4000, and then eventually to 8000. I expect this product line to have some future ahead of it, so if you're interested in excellent portable MZX you should look out for this on the go.

Here's what the port is going to need - it's nothing much:

- For me to close loop with ajs because I probably dicked up the process somewhere (can't yell at me though, given there's no real porting guide ;P).. hopefully it's OK, I don't think I did anything too stupid.. anyway, most importantly, it needs to make it into mainline
- Support for the hardware scaler to let you run fullscreen 640x350 without black borders - personally I think many will prefer to keep it unscaled 640x350 since it isn't too much smaller, but the Pandora has a pretty good scaler so it won't look too bad... so many MZX games have such tiny viewports that I think this should be an option. Unfortunately, right now this requires an fbcon backend and Pandora's SDL doesn't work terribly reliably with this even with the right env vars, so we may need to access /dev/fb1 straight on this. I imagine that's not a huge deal to change.
- Right now I'm getting events 278, 279, 280, and 281 from the face buttons, and 303 and 305 from the shoulders. That's home, end, pageup, pagedown, rshift, and rctrl. I don't believe they're coming in as joypad events. It'd be good if these were remapped to something better - probably to be stuffed the same way joypad events can be. Is there some precedent for doing this? Maybe this is something that can be done on the Pandora instead of in MZX.
- Need to make a proper PND distribution, including documentation.

[ajs]

Awesome!

Can you post the diff? I'll merge it.

I think it's worth getting the hardware scaler working as you mention. If this is OMAP, I assume the scaler engine is implemented in terms of RGB overlays (TI love overlays)? If not, it would be worth getting the overlays working too. You might also want to look into getting OpenGL ES working on the device, since I'm using that for scaling on a Motorola Droid running Android, and the hardware specs for that aren't a million miles away, and it works well.

Event stuffing -- yes, I think the Wii and NDS ports do this. But they're not SDL ports, so there might be some more work to do. Should just be another case of adding a platform-specific hook. Alternatively hacking it in with CONFIG_SOMETHING for now is OK, it can be refactored later if necessary.

--ajs.

[Exophase]

All I did was created a pandora directory on arch. It seems like it'd be easiest just to submit that to trunk, but I think sourceforge dropped my account or something. You can tell me how to best proceed.

Scaler is overlay like you say, but the DSS2 drivers present it as an fbcon if you do the setup with some utilities. Can easily make a properly scaled 640x350 virtual framebuffer at /dev/fb1 that's as fast as writing to a real framebuffer. OpenGL ES works - is there code for it? I'd prefer not to use it for fullscreen if possible, because uploading textures on the device is slow, especially w/o the IMG texture stream extension utilized. Since MZX's refresh rate is usually very low it might not be a big problem but I'd prefer not to waste the pretty gratuitous amount of CPU on it unless really necessary.

I guess I have to revisit the joystick code.. I think we should have "stuff_key_press" and "stuff_key_release" code in event.c, make event_sdl gamepad use it, and I guess for now add a define for the SDLK's I mentioned to basically just pretend they're joypad events. It'll be artificially, but they'll map using some numeric mapping that existing conf files can use. This should just take a few minutes to do, if you can give me the okay on it.

[Dr Lancer-X]

Excellent, now if only I had a Pandora to play it on... apparently some people on gp32x have found themselves moving further down the queue (e.g. from 250-350 to 325-425) so I'm probably on 1200 or so by now =P

[ajs]

Scaler approach sounds good.

Re OpenGL, I agree with your point about glTexImage2D(); it's not optimal. The best way would be to use the EGLImage extensions, then it's not vendor-locked to PowerVR, and no CPU copy is needed. I don't have a Pandora, but fortunately (working for IMG PowerVR) I just need a driver version to figure out what is supported. Can you do a "cat /proc/pvr/version" and paste it up here? In the mean time I'll work on adding support for EGLImage (probably a new renderer).

If you feel like it, you can see if you can get the existing renderers working. They're fairly entrenched in EGL, which might be a problem with SDL, but I have added full ES support to all three GL renderers (including the programmable one).

Event changes sound fine to me, go for it.

As for code submission, it'd be great if you could rebase your work on the latest Git HEAD of MZX, then I can merge it easily. You don't have to set up Git to do this, just grab a snapshot tarball and paste your stuff into it. Then extract another copy of the tree somewhere, and diff the two with diff -Nudr -U3 /path/to/treeA /path/to/treeB and I can apply the diff.

http://github.com/ajs1984/megazeux <-- Git tree
http://github.com/aj.../tarball/master <-- GNU tar of master
http://github.com/aj.../zipball/master <-- Zip of master

--ajs.

[Exophase]

PowerVR drivers string:

exophase-openpandora:~$ cat /proc/pvr/version
Version 1.4.14.2514 (release) /oe/omap3evm-oe/tmp/angstrom.5/work/omap3-pandora-angstrom-linux-gnueabi/omap3-sgx-modules-1.4.14.2514-r19a/OMAP35x_Graphics_SDK_3_01_00_02/GFX_Linux_KM
System Version String: SGX revision = 1.0.3

However, I think if there's any real amount of work involved at all it's not really worth it. The scaling is such a small ratio (1.25x in horizontal/vertical) that I think that bilinear filtering won't look very nice, compared to a 5-tap polyphase resampling. This isn't an option in windowed mode, but I reckon that when running it in a window you don't really want it to take up much more space than it does (nor would there be a reason for it to take up less), and allowing resizing allows for accidental resizes if you enable it.

Just the same, I'd like to know how this EGL based scaling works, the people on gp32x would probably be pleased to hear about something like that.

ES rendering is perhaps a better argument, but there should be lots of CPU for soft rendering, probably to the extent that texture uploads for char set modifications would counterbalance it.

I'll git clone and make the event changes a little later. Can I then give you a git diff off of that instead of a patch?

[ajs]

This driver supports the EGLImage extensions, but for us to use the pixmap method (most applicable here) it'd need some additional investigation to find out exactly what TI have done to the reference drivers. I had a quick look at their SDK and it does look as though they have a few mechanisms.. if we're lucky, we can pass an XPixmap through directly, but TI also have examples using something called CMEM. If none of these are workable, the texture streaming extension you mentioned is functionally just as good.

The reason I'm keen to flesh out the EGLImage approach is that it will definitely be useful on Android devices. Right now phones are shipping with 800x480 screens, but there's 854x480 (Moto Droid) and 864x480 (OMAP4) in the pipeline, and tablets will probably be 1024x768+. These devices really need to be using the GPU to do the scaling, and as you say, it's less effective if so much time is being spent on twiddling textures and other such useless things.

The EGL solution looks something like:

XPixmap p = XCreatePixmap(..);
EGLImage image = eglCreateImageKHR(dpy, EGL_NO_CONTEXT, EGL_NATIVE_PIXMAP_KHR, p, attribs);
glBindTexture(GL_TEXTURE_2D, name);
glEGLImageTargetTexture2DOES(GL_TEXTURE_2D, image);

/* set texture clamping on */
/* compute geometry and texture coordinates for tiles */
/* assume other binds for cursors, etc. */

for(;:confused:/>
{
  write_pixel_data(p);
  flush_affected_cpu_cache_lines(); // if cached surfaces
  glBindTexture(GL_TEXTURE_2D, name);
  /* bind buffer objects or arrays */
  glDrawArrays(..);
}

Basically this is a means, similar to texture streaming, of getting texture data into GL without any copies. All the setup is one-time. The tricky bit is that you either need uncached memory, some way of making the memory uncached, or a means of flushing the CPU cache. All of these things are harder on ARM, especially if you want to run on unmodified devices. This may explain what TI's CMEM thing is, but I haven't had a chance to look at it.

Re the git clone thing, if you can do that, it would be the best solution. If you use something like github, or can put the git repo somewhere, I can just "git pull" from it and push out the master repo.

Thanks again.

--ajs.

[Exophase]

Okay, control changes in..

How do I get git diff to list fresh directories/files? arch/pandora falls under that here.

[ajs]

"git status" to see all the things dirtying the tree.

"git add" the stuff you want (directories for example).

"git diff --cached" to get a diff against the last commit.

--ajs.

[Exophase]

Humm, git diff gives the diff for the changed files, git diff --cached for the added files. Hopefully you can sort out the two, or give me further direction.

http://exophase.devz...zx_pandora.diff
http://exophase.devz...ora_cached.diff

[ajs]

For future reference, just "git add" changed files too, and they'll appear in the cached diff. If they're not added, they're not staged, and --cached only shows you staged differences.

I've applied these changes and I'll get nightly builds set up ASAP. I tweaked the event hack a bit, just to reduce the #ifdefs. I assume this will be revisited at some point.

I've also added an empty README, updated the platform_matrix.html file -- some of which is made up, so feel free to correct it -- and updated the NDS and Wii ports with your helper function changes.

Here's the commit:
http://github.com/aj...5fc6c155e05daba

--ajs.

[Exophase]

Thanks ajs - yeah I'm a git newb -

Some apologies in advance for not just editing the damn file myself, I haven't gotten any sleep so I'm in some kind of mood or somethin a_A.. here's some platform_matrix stuff if you will:

- Pandora is Cortex-A8 (CPU type) or ARMv7-a (ISA).. Android should also usually be ARM11 or better (these days ARMv7a, but could be either Cortex-A8 or Scorpion); not sure if this is a reflection on your build flags more than the real hardware.
- PSP is little endian.
- PND package will be the distribution, yeah, it's an isofs container that's mounted with merged appdata directories and stuff
- MODULAR is just the ability, right? I'll probably distribute mine --disable-modular - do you think I should package the libs in the PND instead?

Give me a shout on here or AIM or wherever if you want to go over things, with the understanding that I have this pit in my stomach that makes me not want to touch MZX code and I might start begging you to do things instead ;D (but it's only fair that I at least take responsibility for a new port, especially on a platform only I have)

[ajs]

I'll probably want to finish off the packaging side, get this PND thing working. I'll also make the doc fixes you've suggested. I'll bounce a build off you once I've got it doing automatic builds.

Disabling MODULAR & mzxrun is a fine thing to do, and we do it on other platforms anyway, I just had no idea what you were building with.

The last immediate thing I need to set up auto-builds is the ./config.sh line you're using to build. I can then adjust the document and build script to exactly match your build, and put this info in the README.

--ajs.

[Exophase]

./config.sh --disable-gl --disable-modular --enable-tremor --enable-release --prefix /usr/local/pandora/arm-2009q3/usr --platform pandora

I don't have it in PND yet because I haven't yet actually worked out the procedure for doing that :B Since I needed to learn what that's about anyway now is as good a time as any.. hopefully will report back on that soon, maybe this part of the post will disappear. Fair warning, it'll probably require a hand created PXML, so look out for another patch.

[Dr Lancer-X]

PND yet?

[ajs]

I may get some time to look at this in a couple of weeks. Last time I looked at this I had toolchain issues, but it was very early days and these have probably been resolved.

If anybody feels like helping out, feel free to fork megazeux.git; the scripts used by the automatic build system are checked into scripts/ now, so almost everything required to get nightly PNDs working for Pandora could be tested by a third party.

--ajs.

[Exophase]

Lancer-X, on 24 January 2011 - 04:57 AM, said:

PND yet?

You have a Pandora now?

I don't think I had anything left that needed to be done outside of the actual PND packaging. But it'd probably be best if it targeted omapfb.

[Dr Lancer-X]

Quote

You have a Pandora now?

Yes.

Quote

I don't think I had anything left that needed to be done outside of the actual PND packaging. But it'd probably be best if it targeted omapfb.

Well, no binaries were posted and I'm still setting up my toolchain.

[Exophase]

Bother me on AIM or something, I'll dig it up. Won't be a PND though, you'll have to run it from a console.