Uae4allgp2x 0.8.0 Beta By Noldor

[foleyjo]

:lol: I do apologise I think I dont know what I was thinking of. I think I got you mixed up with someone else and a different emulator.

 

[coevin]

Hey norlder ive just tried the new beta version out unfortunately the menu screen is an unreadable mess. Is there something im doing wrong, anyone else having this problem?

 

[noldor73]

Hey norlder ive just tried the new beta version out unfortunately the menu screen is an unreadable mess. Is there something im doing wrong, anyone else having this problem?

To use this beta you need to use all other files from the old one.

 

[coevin]

Hi ive just replaced the excutable file with the previous one, so all the old files are still present but i still get the same issue .

 

[coevin]

ok got it was being a full. cheers

 

[coevin]

Well i finally got it working but usb support doesnt seem to work yet. But great to see it being still worked on. Anyone else had any luck on usb support?

 

[coevin]

got usb pads working fine in game just a couple opf menus not working yet. However when playing through tv out it looks horrible and doesnt all fit on screen (probably my tv issue)

 

[trooper]

Hi coevin,

Sorry to sound like a grumpy old sod, But could you please edit your posts in future, As multiple consecutive posts are frowned upon and are against forum rules.

Thanks

Trooper

 

[noldor73]

got usb pads working fine in game just a couple opf menus not working yet. However when playing through tv out it looks horrible and doesnt all fit on screen (probably my tv issue)

"3) Preliminary Usb support (partially in the menù but near complete in-game support)... it is in test state"

 

[foleyjo]

:lol: I do apologise I think I dont know what I was thinking of. I think I got you mixed up with someone else and a different emulator.

I remember now. it was Critical saying he wasnt bothering with Ham and other graphic modes as he was working on other things that I was thinking of.

Will you be doing anything on these?

 

[HenrikE]

:lol: I do apologise I think I dont know what I was thinking of. I think I got you mixed up with someone else and a different emulator.

I remember now. it was Critical saying he wasnt bothering with Ham and other graphic modes as he was working on other things that I was thinking of.

Will you be doing anything on these?

HAM mode is rarely used. If I may make a humble suggestion, compatibility and speed of games (and please also demos!! but harder) is googolplex times more important (to me, and most users, I think).

One point that stops many games is the inability to change disk in drive 0 _without_ reset! Many multi-disk games had crappy loaders that didn't detect extra drives, so having 4 drives do not help if no cracked version exists that support > 1 drive.

I haven't updated in 2 months or so, has this maybe already been added?


noldor73: There was a bit of turmoil (regarding who I should ask) when I last asked if I could convert some specific tight loops or small functions called often, to assembler. I'd be happy to help out, if you could profile some parts of the code that are pretty finished but suspect could benefit from asm optimization. So, now that you have taken over it, I ask you: Can I help?

 

[noldor73]

HAM mode is rarely used. If I may make a humble suggestion, compatibility and speed of games (and please also demos!! but harder) is googolplex times more important (to me, and most users, I think).

Ham mode it is a very complex task (I taked a look into pspuae version) and probabily inuseful upgrade :°
I'm not a c programming guru and I not have the capacity to improve the compatibility and the games speed ^^
(In this and in my old beta I only have added "simple" but useful tasks that was needed to improve the user emulation experience)

One point that stops many games is the inability to change disk in drive 0 _without_ reset! Many multi-disk games had crappy loaders that didn't detect extra drives, so having 4 drives do not help if no cracked version exists that support > 1 drive.

You can change the disk in df0 (or in 1,2,3) whithout known problems ^^ at anytime (but there is a bug related to the emulator path and for now it is a good choice to install it in the sd root folder ). Having 4 drives helps in many games. Anyway the user can switch to 2 or 1 if needed by the game

noldor73: There was a bit of turmoil (regarding who I should ask) when I last asked if I could convert some specific tight loops or small functions called often, to assembler. I'd be happy to help out, if you could profile some parts of the code that are pretty finished but suspect could benefit from asm optimization. So, now that you have taken over it, I ask you: Can I help?

Maybe the drawing functions(drawing.cpp) and the sound (and maybe using the 2th processor? ). The sound seems to be the actual task that slow the emulation . And I think other optimizations can be gained using direct access to the gp2x hardware.

Sorry for my bad english

 

[foleyjo]

HAM mode is rarely used. If I may make a humble suggestion, compatibility and speed of games (and please also demos!! but harder) is googolplex times more important (to me, and most users, I think).

It wasnt just Ham that was missing. I think EHB mode was unsupported in the last version as well

Im sure they were supported in an earlier version or maybe in the other UAE on Gp2x

 

[HenrikE]

HAM mode is rarely used. If I may make a humble suggestion, compatibility and speed of games (and please also demos!! but harder) is googolplex times more important (to me, and most users, I think).

Ham mode it is a very complex task (I taked a look into pspuae version) and probabily inuseful upgrade :°
I'm not a c programming guru and I not have the capacity to improve the compatibility and the games speed ^^
(In this and in my old beta I only have added "simple" but useful tasks that was needed to improve the user emulation experience)

One point that stops many games is the inability to change disk in drive 0 _without_ reset! Many multi-disk games had crappy loaders that didn't detect extra drives, so having 4 drives do not help if no cracked version exists that support > 1 drive.

You can change the disk in df0 (or in 1,2,3) whithout known problems ^^ at anytime (but there is a bug related to the emulator path and for now it is a good choice to install it in the sd root folder ). Having 4 drives helps in many games. Anyway the user can switch to 2 or 1 if needed by the game

noldor73: There was a bit of turmoil (regarding who I should ask) when I last asked if I could convert some specific tight loops or small functions called often, to assembler. I'd be happy to help out, if you could profile some parts of the code that are pretty finished but suspect could benefit from asm optimization. So, now that you have taken over it, I ask you: Can I help?

Maybe the drawing functions(drawing.cpp) and the sound (and maybe using the 2th processor? ). The sound seems to be the actual task that slow the emulation . And I think other optimizations can be gained using direct access to the gp2x hardware.

Sorry for my bad english

Hey, that was a quick reply h34r:

Yeah, the latest thing I've looked at is the 940T. Using it for the right stuff could potentially give a 50% gain right away, even with C (simplified, you could say 940T=920T but running at half speed, about 88 MIPS for 940T and 176 for 920T @ 200MHz. That's a lot of power!)

The first thing that springs to mind from reading threads on it is graphics post-processing/finalization -> video, the other, "pure" internal operations, like "executing" a heavily compressed bit of code or data (i.e. no big chunk of result data to store in memory). This is to avoid fighting over the memory bus with the 920T, and it seems tricky to make sure 920T doesn't read data that 940T hasn't finished storing yet.

Does this give you any ideas? The important thing is to find "the right job" for the 940T and not just put "random small routines" that take only a few % of the cpu time, but to give it a reasonably big chunk of the total time to work on (50% speed = max 1/3 of total).

From what I've learned so far, 940T should be perfect for overlays, layer mixing, antialiasing, pixelfilters... which makes me think of the copper But even though the copper is a simple statemachine, it's only simple when it's timed to the video clock of a physical machine, so it probably isn't implemented as a "finalization routine"?

If I would translate bitmap screen + copperlist -> RGB, I would "execute" the copperlist while stepping through the pixels the way Paula would output it to monitor, keeping track of a timer counter. Any copper instructions that modify the palette would modify the RGB of the pixel, if the instruction had been executed before the "time point" of that pixel.

But it all depends on how it's coded - I'm only here for the asm, since I'm inexperienced with C.


A good starting point could be looking at what functions are executed at the "end of each frame", I think. Ideas?

 

[Macguyver]

Hey Gang, any word on a new release for UAE4ALL?

We were on a roll there for a while.

I was wondering about:
Savestates
full USB pad support
EHB support
touchscreen
faster optimization by using the 940T for some routines
and proper emulation of Populous, for goodness sakes!


Any posts indicating an upcoming release are welcome!

Many thanks for all the many contributors so far.

Mac

 

[yaKC]

Hiya

It's been a while since I had the Amiga emulator on my F200, so thought it was time I updated... downloaded
this latest version, loads in the games OK (well apart from those needing virtual keyboard to start game, where'd that go?), but once in game the direction pad won't move the character on any of my games

fire works OK, tried all three of the control options, and it just changes which button is fire button... anyone have any ideas why this could be, I'd go back to previous version but that didn't let you pick between Kickstarts so less games work.

F200 Firmware 4.0 btw