Beta Uae4All Additions

[notaz]

Of course there is a speed gain from Cyclone, dropping it is a step backwards for battery life and general optimisation.

That's not what my tests shown. The difference is insignificant.

And what do your tests show? Do you have anything in form of numbers?

On GP2X it used to be ~30%. If N900 port has bottleneck elsewhere the impact of CPU core is obviously lower, that's why it might look insignificant.

On the other hand uae4all is in hardly maintainable state and I would never want to look at it again myself, so if dropping Cyclone makes working with that code easier, go for it.

I really gave Cyclone a chance and tried to hunt the unsupported instruction bug. With no luck though.

I'm 99% sure all 68000 instructions are supported, it's more likely a timing issue.

 

[john4p]

Of course there is a speed gain from Cyclone, dropping it is a step backwards for battery life and general optimisation.

That's not what my tests shown. The difference is insignificant.

Besides choosing between 100% compatible cpu core, and 95% compatible core is simple.
Even more if it's a choice between playing my favorite shootem'up or not playing it.

I really gave Cyclone a chance and tried to hunt the unsupported instruction bug. With no luck though.

The uae4all executable's size is also insignificant, so no problem to let the users decide between the UAE core- and Cyclone-core version. I also found some games that only work with our Cyclone-version (see compatibility list: http://spreadsheets.google.com/ccc?key=0AuBR5X_s_5_idG92ZVQ5cEs4ZEhYTm5sSjFIcl83U2c&hl=en#gid=1).

But thanks for your hard work on the N900-port! In fact I've merged a lot of your sources into our version to get savestates with UAE core working.

Btw., could you provide an old version where savestates work with Cyclone? Savestates don't work in your Cyclone-branch...

 

[smoku]

And what do your tests show? Do you have anything in form of numbers?

There was no change in FPS no matter which core UAE4ALL was running on.
I wasn't testing battery life though, so it may be possible there is a difference.

On GP2X it used to be ~30%. If N900 port has bottleneck elsewhere the impact of CPU core is obviously lower, that's why it might look insignificant.

Games are running 100% speed on N900 on bot cores. Some games run even worse on cyclone (stuttering sometimes). But I guess this is related to all other N900 processes running in background. UAE core seems to better handle delays caused by preemption.

On the other hand uae4all is in hardly maintainable state and I would never want to look at it again myself, so if dropping Cyclone makes working with that code easier, go for it.

I don't find it that bad.

I'm 99% sure all 68000 instructions are supported, it's more likely a timing issue.

Yes. This is well implemented. The problem is with non documented features/bugs that some games (like Project X) use to do some tricks.
If the application is correct and behaves to the documented standard Cyclone works great. There are just some edge cases that breaks some games.

 

[smoku]

The uae4all executable's size is also insignificant, so no problem to let the users decide between the UAE core- and Cyclone-core version.

That's a valid point. I just wasn't feeling like modifying the code to support selectable cores.
But if you have done it already, I will merge it and give the option to N900 users too.

Btw., could you provide an old version where savestates work with Cyclone? Savestates don't work in your Cyclone-branch...

Are you sure these were ever working? I haven't tested savestates at all.
I based my Cyclone source on uae4all-wiz-0.8.0-src.zip http://dl.openhandhelds.org/cgi-bin/wiz.cgi?0,0,0,0,46,123

 

[john4p]

That's a valid point. I just wasn't feeling like modifying the code to support selectable cores.
But if you have done it already, I will merge it and give the option to N900 users too.

I haven't done this either. Some src-files are needed to be swapped to build the Cyclone-port.
In our PND-archive there are in fact 4 different UAE4All executables (UAE core doubled pixels, UAE core softstretched, Cyclone doubled pixels, Cyclone softstretched).
The different versions are just selectable by simple yes/no-dialogs at the start.

Are you sure these were ever working? I haven't tested savestates at all.
I based my Cyclone source on uae4all-wiz-0.8.0-src.zip http://dl.openhandhelds.org/cgi-bin/wiz.cgi?0,0,0,0,46,123

No, I just assumed you might have had them working. So savestate-support for Cyclone just wasn't implemented.


Do HAM- and EHB-modes work properly in your port now? I've read you were going to add the emulation of those (so no more garbled title screens in some games).

 

[smoku]

Do HAM- and EHB-modes work properly in your port now? I've read you were going to add the emulation of those (so no more garbled title screens in some games).

http://github.com/smokku/uae4all/issues/closed#issue/16

I've ported support for HAM and HB modes from E-UAE.

 

[smoku]

Your port support scrolling the fully rendered Amiga modes on the screen.
So I guess you managed to revert the changes rendering to 320x240 bitmap only? I was working on porting the graphics rendering code from E-UAE, but ended up with garbled screen.
I have a working screen scaling code using GLES in PSX4ALL, so if rendered correctly I could just scale the Amiga screen directly to N900 screen no matter what the original resolution was. (I'm doing this for all the strange PSX modes.)

 

[john4p]

http://github.com/smokku/uae4all/issues/closed#issue/16

I've ported support for HAM and HB modes from E-UAE.

Thanks, I'll have a look at these sources.

 

[john4p]

Your port support scrolling the fully rendered Amiga modes on the screen.
So I guess you managed to revert the changes rendering to 320x240 bitmap only? I was working on porting the graphics rendering code from E-UAE, but ended up with garbled screen.
I have a working screen scaling code using GLES in PSX4ALL, so if rendered correctly I could just scale the Amiga screen directly to N900 screen no matter what the original resolution was. (I'm doing this for all the strange PSX modes.)

I didn't have to change anything about rendering. Here's the simple code to move the displayed area:

extern void moveHorizontal(int value);
extern void moveVertical(int value);

^ declaration in drawing.h

int moveX = 0, moveY = 0;

[...]

static __inline__ void pfield_draw_line (int lineno, int gfx_ypos, int follow_ypos)
{
[...]
xlinebuffer -= LINETOSCR_X_ADJUST_BYTES + moveX;
[...]
}

[...]

static _INLINE_ void init_drawing_frame (void)
{
[...]
thisframe_y_adjust_real = thisframe_y_adjust + moveY;
[...]
}

[...]

void moveHorizontal(int value)
{
	moveX += value;
}

void moveVertical(int value)
{
	moveY += value;
}

Just add this to your drawing.cpp and call moveVertical()/moveHorizontal() from gui.cpp when certain button-combinations occur.

 

[smoku]

Oh. Clever.

 

[john4p]

But there's also a 320x256 softstretched (to 608x480 pixels) mode available which really draws 256 lines.

Just setting GFXHEIGHTINFO (don't know the exact name) to 256 worked for that.

 

[silver]

That's not what my tests shown. The difference is insignificant.

Besides choosing between 100% compatible cpu core, and 95% compatible core is simple.
Even more if it's a choice between playing my favorite shootem'up or not playing it.

I really gave Cyclone a chance and tried to hunt the unsupported instruction bug. With no luck though.

The point is probably moot, as it looks like both N900 and Pandora ports of Uae4all are running fullspeed without Cyclone (and little OC).

But if you are getting no speedup at all with Cyclone, it suggests you are being significantly limited in the non-cpu parts of the emu. Assume you tested with no frame limit, and found no difference UAE vs Cyclone? (Only other option is that the C compiler has improved in leaps and bounds - unlikely).

68000 instructions are fairly well documented, including all the unofficial undocumented stuff, so unless Amiga emulation requires something Cyclone specifically does not support (prefetch emulation), its probably not any missing opcodes.

 

[jonlad1]

I got to the party late on this - no tearing! WOOHOO!!

John, you da man! Keep it coming!!

 

[Pleng]

Hey guys.....suffering with a major hangover here so forgive me for being stupid. I've downloaded the pnd to my Pandora/menu and desktop folders with all my other pnd's but doesn't show up on the Pandora. It's happened before and I formatted my card and it worked. Don't really wanna do that again, besides, all the other emulators are showing anyway so it can't be that. Any idea's? Really want to try this version too.....

Sounds like a corrupted download. Try deleting the PND and downloading again.

Incidentally, if you want PNDs to appear in both the menu and on the desktop then you can make a folder inside pandora called apps. No need to duplicate PNDs in menu & desktop.

 

[jonlad1]

Hey,

Is anyone having an issue with savestates with the latest release?

I can load savestates but cant create new ones. L + S doesnt save (cant see the access light on the LED so I know nothing was saved) and same goes for the menu option to save.

 

[john4p]

Is anyone having an issue with savestates with the latest release?

I can load savestates but cant create new ones. L + S doesnt save (cant see the access light on the LED so I know nothing was saved) and same goes for the menu option to save.

Is it different if you use the ZIP-release (instead of the PND)?

 

[EvilDragon]

If you're using the PND: Did it work with the PND before?
If you used an old PND version (where it didn't work), you need to delete the old files from the appdata dir (everything except roms and kick.rom).

Then it should work.

 

[jonlad1]

Using the PND, this version and old version.

I always delete the appdata folder whenever a new version of an emu comes out (apart from the roms and kick.rom ;

Can you guys make new savestates with the latest PND? If you guys can I must be doing something wrong....

 

[cosam]

I have this great idea for a menu system for this emu that will make it very intuitive plus a joy to use (now the UI is kind of "rough"). It will solve many issues (hint: one is an elegant solution for multi-disk games). I would do the design, layout and any artwork for the menu. All is needed is someone to code it (ok, that is the hard part but I can't do it) If someone here was interested in coding it let me know.

Care to enlighten us as to what your great idea may entail? No coder in their right mind is going to sign up for a project which has essentially no description. In my experience, professional programmers get enough of those kinds of projects at work already ;-) I'm not so hot for the existing menu either, but you'll have much more chance of a bite if you tell us something about your design and "wow" us with its brilliance.

 

[DaveC]

I have this great idea for a menu system for this emu that will make it very intuitive plus a joy to use (now the UI is kind of "rough"). It will solve many issues (hint: one is an elegant solution for multi-disk games). I would do the design, layout and any artwork for the menu. All is needed is someone to code it (ok, that is the hard part but I can't do it) If someone here was interested in coding it let me know.

Care to enlighten us as to what your great idea may entail? No coder in their right mind is going to sign up for a project which has essentially no description. In my experience, professional programmers get enough of those kinds of projects at work already ;-) I'm not so hot for the existing menu either, but you'll have much more chance of a bite if you tell us something about your design and "wow" us with its brilliance.

Ohh ouch! The stinging sarcasm is thick here. that is ok I can take a shot

Anyway I just wanted to float it to see if someone was even mildly interested. John said he wasn't so I posted here just in case someone was thinking about it. As far as "brilliance" it is not really brilliant as there is only so much that a menu can do but it would just be well thought out and intuitive. It would make using the emu much quicker and easier.

Rather than type a wall of text to explain everything (and that would be difficult to get the feel anyway) I would basically mock one up in Photoshop to show what I was thinking. Of course doing that would take allot of time. If no one cared I didn't want to waste hours on something that would never be used. I took a chance when I did that with Minimenu and luckily Skeezix picked it up. I figured I wouldn't push my luck That said someday I might just do it, even if no one does pick it up. Maybe it would spark an idea at the least.