What's the best/latest EUAE build for OS4?

@LiveForIT
Quote:

By put code back i mean : put older code back. The code, which was before you change it in commits about keyboard changes. That old code back i mean. Because it was the working DAMN ! How many times need i repeat the same again and again ?

Are my english that bad , that i can't explain that now keyboard broken, right after you change the keyboard's code in uae. Before it was working FINE !

Should i explain it in some other language or what the problem with ?

@LiveForIt
Quote:

The keyboard keys which working before without-mapping way are: the "/" one , the < > , the + and | ones and some others, those i find just from the start.

@kas1e

"put older code back."

that will remove keyboard mapping, you will have dead keys!
There are things to fix, but that’s not the solution.

@LiveForIt
Quote:

Oh, at least you agree that they're an issue about keyboard, that good !:)

Now sure if anyone meet with those dead keys ? Previous way without mapping works fine before and i never meet with any needs with mapping of dead keys.

Is there any scenario when one need to worry about ?

@kas1e

You should run KeyShow in tools to see where ASC codes are mapped, note I did not design the keymap, I only look at scancode and try find closes place on the PC keyboard.

For exsample | keys right infront of the Backspace key, if you hold shift key.

< and > are on ; and : keys on Amiga keyboard.
the key on leftside close to left shift, is on some Amiga keyboards but not all.

@LiveForIt
Quote:

Don't we have something already working somewhere ? I mean, in os4 we do use standard keymaps by default, and all keys working as expected, can't we just clone it ?

For me , for example, the | key is not in front of the backspace key. In front of Backspace key i have + and =. The | i have in front of the Enter key. Just like on any casual keyboards.

And what problem with dead keys ? I mean, what exactly is bad with the old "non-mapped" way ?

@kas1e

becouse ? symbol is one of the dead keys, also ( and ) is on dead keys. So I can't do, this:

list #?(.mod|mod.)

@LiveForIT
Quote:

With both old non-mapped way, and new mapped-way we have now, i can't type "|" on the place where it placed, but yes, with new way i can hit the shift with + key to have "|" symbol, but then i can't type real + and = on that key.

IMHO, what we need to do, is to put "/" where it should be, and remap all the keyboard keys on their default way (probably we need to get values from default os4 keymaps maybe?)

@kas1e

I don’t see how can know what keymap / language setting OS3.2 is using and how that’s mapped, we only emulating hardware, so auto mapping OS3.2 or OS3.5 map to OS4.1 map when system using different language settings. Sorry that’s too complicated, design your own keymap if want it to be the same.

It also totally breaks, if you run a game, and game use scan codes, somehow emulation thinks there should be different scan codes there. No, we don’t want to be that clever.

If you wonder why messed up the / and ? key, its because on Norwegian keyboard layout the _ and - key is there.

we go by scancode layout, not keymap layout, as its different depending on language.

@LiveForIt
Quote:

If we need to choose any default, then it should be English layout of keyboards IMHO, because that what most of the users around the world uses. The Norwegian, Russians, or any other specific to languages things shouldn't be default of course.

Anyway, what we need to do, is to fix the keyboard now, so it will behave correctly again. I can't type a "/" at all, and many special keys swapped. So we probably need some kind of internal remaping. Because if keep it as it now, it will be much worse than previous issue with dead key and inability to type "|". The "/" thing is more important than "|", because without "/" you can't navigate for real in the shell.

@kas1e

Don't you have a menu key?

@LiveForIt
Tested latest changes: now, things start to be not just worse, but unusable : loading of the workbench in 32bit on 32bit screens takes more than 3 minutes now. I even can't wait till the moment when background image draws.

Quote:

No. I have a classic casual keyboard with the standard set of keys.

@kas1e

so if change line_skip = 0 its faster?
Anything happeing on console or rs232?

with line_skip you are only moving half the data, should be 2 x faster.

@LiveForIt
Quote:

With line_skip = 0, it at least load up workbench, and take not 3-4 minute for loading, but 40 seconds, which is even worse still than it was yesterday with 30 seconds, which also, worse, if we take a code before p96 and ami-win merge, which was pure 15 seconds.

I.e., line skip code make it slower even with 0.

IMHO, better need to understand first why after merge we have 2 times slower speed. As it makes no sense to improve other areas, on top of this "2 times slower" issue.

Quote:

Nope, all silent.

To summarize, issues about rendering is :

-- merging of p96 with ami-win drop speed to 100%, and make it be 30 seconds instead of 15 for load up a 32bit WB on 32bit screens.

-- change about “line-skip” on top of first bug, make things be much-much worse, it takes about 3-4 minute to load up. The change of line skip to 0, make it load up in 40 seconds, which of course not 3-4 minute, but not 15 as it should be (and as it was before merge) and even not 30.

Definitely something very wrong somewhere, because every improve lately cause things to be slower and slower, even if by theory it should be faster.

@kas1e

Do you have vsync enabled? or disenabled? in monitor tool type.

@LiveForIt
Quote:

My monitor tooltype is the standard-default one (and on the same monitor tool type all working ok previously of course).

But just in case, that what i have in:



That all

@LiveForIt
Tried the latest code where you add "picasso_handle_vsync() is not vsynced, drop FPS" together with some previous commit.

Now, new issue : visually, when move the mouse cursor, it looks like rendering of the cursor is with skip line, but that probably expected because of skip_line=2 by default. But ! What is strange is that the whole process still pretty slow, and with line skip enabled even worse when line_skip=0 ! While by idea, the line_skip=2 should be faster, but it is not, and slower instead.

I benchmark the boot times of workbench now, and this is 24 seconds now instead of previous 30-40, etc. But still, it's not 15 as it was before p96-amiwin merge. Of course, it better than 40 or 30, but still, if we about improvements we need to get back those loosed 10 fps.

I tried to rebuild it with line_skip = 0; and then, loading times improves and start to be 20 seconds instead of "good" 15. Also issue with mouse cursor gone, but then, it feels a bit sluggish in the entire rendering. The mouse cursor moves slower than in pre-merge version, the opening of the directories also more sluggish in compassion with pre-merge version.


All of this mean, that there are something still wrong: With line_skip=0, we have 20 seconds for boot, and slower cursor movement and directories opening speed also have regression. And entire rendering slower much visually.

But with line_skip=2, while there are visually not everything renders (that is expected probably with line_skip 2), it's instead of giving speed boost in rendering, give the speed loss (!) in the rendering and entire emulation speed where gfx data involved.


Maybe that issue about which Joerg told ? WPA accelerated good when do copy big data, but when it comes to the small chunks (by which probably euae operate), CPU copy routines will be faster instead ? At least that looks like it. Because when you merge, you replace all with WPA, and issues with speed and slow rendering starts.

@kas1e

Yes, but scores better in P96Speed.

@kas1e
Quote:A HW emulator like UEA can't emulate keys but has to emulate scan codes instead, but there are several problems with that as well:
- Amiga and PC keybaords have different keyboards layouts (for example PC has 2 instead of the single CRTL key on Amiga keyboards, 2 instead of 3 keys between 0-9 and the backspace key, swapped Logo(Amiga) and Alt keys, etc.), 100% compatible scan codes aren't possible because of that.
- AmigaOS 4.x includes a setting in prefs/input to either use PC or Amiga layouted keyboards, but the emulated AmigaOS 3.x didn't have any support for that yet.
- The standard keymaps included in AmigaOS 3.x (language/country specific) don't support PC layouted keyboards, you have to create a new key mapping with one of the, since AmigaOS 1.x/Kickstart 1.x already available, keymap editors to use a PC layouted keyboard instead.

@kas1e

I think we found interesting things out.

1# Blitting lines is bad.
2# line skips are stupid.
3# is_vsync() is mostly for AGA.
4# We can get better drawing speed, at cost of frame rate.
5# Smart stuff will give better CPU emulation speed when gfx card is ideal, not a lot is happening.
6# Multiverse demo is preforming 2 x faster without the smart stuff.