WinUAE 2.8.0 beta series (Was 2.7.1)

[thomas]

What do I expect.

When I enable the auto switch mode, many options on this page are disabled.

What I expect is that those options which are now disabled are automatically set to the best possible values and automatically change when the Amiga display changes.

By best possible in this context I mean most realistic compared to a real Amiga.

As a real Amiga I imagine an A4000 or A1200 connected to a M1438 monitor. This monitor is able to correctly display almost any screen mode the AGA chipset can create. And I expect WinUAE to be able to do the same. So if I open a lores display, the M1438 displays it filling almost the entire screen with a small border around it. If I change to hires, the display covers exactly the same area of the screen, but has twice as many pixels horizontally. If I switch to interlaced the same happens vertically. And if I switch to Super72, the display covers the entire screen and all pixels are displayed. Your "fix" makes Super72 unusable because you always have to manually switch beween hires/superhires when the screenmode changes. And it is not a fix because it is not like this on a real machine.

Actually there shouldn't be the need for an option for lores/hires/superhires in WinUAE. WinUAE should automatically choose the best mode depending on the screen mode choosen on the top of the display page so that the display looks most realistic.

[Toni Wilen]

Originally Posted by thomas

When I enable the auto switch mode, many options on this page are disabled.

What I expect is that those options which are now disabled are automatically set to the best possible values and automatically change when the Amiga display changes.

That kind of option can be added to autoresolution menu but current system is not designed for your use case, it is mainly for plain lores/hires/lace modes, not for programmed modes which are very different world. (You were only lucky it appeared to work in your use case)

Enable superhires first (before starting emulation) and you may get what you want, at least in interlaced modes.

By best possible in this context I mean most realistic compared to a real Amiga.

I don't think you really want most realistic results, see below.

As a real Amiga I imagine an A4000 or A1200 connected to a M1438 monitor.

It really isn't that simple. It is the monitor itself that does the scaling (and blurriness..), not the chipset.

This is also exact reason why LCD displays may have strange aspect ratio or huge borders and why Indivision AGA MKII is so complex to configure. (especially if you want integer pixel mapping)

I am also quite sure you had to adjust the monitor (width/height/position) first before display was good enough = it isn't that automatic. You also have to adjust settings again (unless you already did it and monitor has multiple mode memory slots which was quite common in multisync vga monitors) when switching to different programmed mode which most likely have different sync signal positions.

Actually there shouldn't be the need for an option for lores/hires/superhires in WinUAE. WinUAE should automatically choose the best mode depending on the screen mode choosen on the top of the display page so that the display looks most realistic.

Yes, it does. There is no best mode in all situations and switching is not glitch free. Also allowing superhires emulation takes much more resources (even if current mode is not superhires), this is the reason why autoswitch does not use superhires unless superhires was selected at startup. (Maybe 1% of users or less ever use superhires and probably only exception is Super Stardust AGA intro starfield!)

"Realistic" would be bad idea, realistic is not guaranteed 1:1 pixel mapping, no one wants blurry WB applications! (games are different thing and is personal preference)

(It feels like similar questions have been asked and replied 10+ times..)

EDIT: I'll think about some solution that does not need autoresolution (it really does not have anything to do with this option), some kind of option that allows "autoresolution" (hires<>superhires) in programmed modes only. TV-compatible modes should not change.

EDIT2: Just to make it clear, problem is as simple as many programmed modes being "half-width" superhires modes, which will fit in space of normal hires mode screen (normal superhires would not fit). This is special situation where superhires should always autoswitch to keep display correct but it really is special case which isn't that simple to handle without other side-effects. (for example state needs to be remembered so that switch back to "normal" mode would reset back to standard hires)

[Dunny]

Sorry to butt in, but would it be a good idea to actually simulate a monitor? Not the whole resolution switching thing, but what you said about adjustments...

If WinUAE could support the user being able to adjust position/width/height of the current screen and then those preferences be saved to the current config (or a separate monitor configuration file) then they could be recalled automatically when WinUAE next encounters those screen modes?

D.

[thomas]

@Toni: please tell me what is it good for to get an output like this:



or like this:

[Toni Wilen]

Originally Posted by thomas

@Toni: please tell me what is it good for to get an output like this:

You got what you asked (It is technically 100% correct output if mode would have been normal superhires), not what you wanted.

Programmed modes work very differently compared to TV compatible modes and they are more or less in category: display works which is good enough for rarely used modes, will be improved slowly.

Getting what you want is not trivial, it is totally different world and very incompatible with TV modes and it is too easy to lose "normal" mode performance for 0.001% users that actually use programmed modes.

[Toni Wilen]

http://www.winuae.net/files/b/winuae.zip has quick hack that tries to adjust horizontal mode on the fly for best match for programmed modes.

Requirements: Display panel must be set Hires and Doubling enabled. Autoresolution should be disabled.

Originally Posted by Dunny

Sorry to butt in, but would it be a good idea to actually simulate a monitor? Not the whole resolution switching thing, but what you said about adjustments...

Not really, as I said, "programmed modes" are not that common (most use RTG) and no one switches between different programmed modes except for testing purposes.

[thomas]

Originally Posted by Toni Wilen

http://www.winuae.net/files/b/winuae.zip has quick hack that tries to adjust horizontal mode on the fly for best match for programmed modes.

Wow. This one works better than ever before. I would be perfectly happy if you could keep it like that.

[Toni Wilen]

http://www.winuae.net/files/b/winuae_2710b14.zip

Beta 14:

- FSINCOS second register supported in disassembler.
- FMOVEM and FMOVECR disassembler support. Disassembler should now support all FPU instructions.
- Added missing special case 68020+ instruction disassembler support: bit fields, MOVES.
- Disassembler output improved, most unsized instructions don't have .L size extension anymore.
- Action Replay 2/3 was incompatible with b8 cpu emulation changes.
- CPU mode (JIT/more compatible/cycle-exact) on the fly switching was unstable since b8.
- Mirror Expansion panel RTG scale options in Filter panel. (More options will be added in future)
- Removed some forced inlining that only increased size of executable and wasted CPU cache space.
- Added support for early 68040 revision that has slightly different FPU stack frames and version id. (Config file fpu_revision=0x40). Not much use in Amiga emulation but first 68040 based Next systems came with first revision 68040's and NextStep 2.0 unimplemented emulation code only supported first revision unimplemented stack frame type.
- FMOVEM predec/postinc mode bit emulation fixed again, now it really works correctly.
- Implemented (partial) 68040 FPU BUSY stack frame.
- Pre filters in RTG mode loaded incorrectly from config file.
- Implemented FPU exception state statefile support.
- b13 JIT FPU bug workaround replaced with fixed optimization (Peter Keunecke)
- Attempt to automatically select correct resolution (hires/shres) when programmed mode is active. Always active if resolution setting is hires or larger and doubling is enabled. No more programmed modes that are 2x wide or half width without manually changing resolution setting, note that currently "wrong" mode is visible at least 1 frame before mode changes.
- Arcadia game Aaargh supported.

[mark_k]

Originally Posted by Toni Wilen

- Attempt to automatically select correct resolution (hires/shres) when programmed mode is active. Always active if resolution setting is hires or larger and doubling is enabled. No more programmed modes that are 2x wide or half width without manually changing resolution setting, note that currently "wrong" mode is visible at least 1 frame before mode changes.

That seems to work quite well. Super72 Super-High Res (800×300) is now shown doubled which is nice. Would it be possible to tweak that feature to also work with HighGfx? Currently HighGfx super-high res (1024×384) is not shown doubled.

Also, I noticed that with the HD720 monitor driver (in the HighGfx archive), HD720 high res (640×360) is shown doubled in both width and height. Resolution mode in display settings is set to SuperHires. Manually changing the res mode to Hires doesn't change anything (it remains set to SuperHires). Having that mode doubled in width is probably a good thing though.

[vagrant]

Toni, switching modes on the fly is still not entirely stable compared to beta 9 and previous releases.

When I quit any whdload programs it will randomly crash. (CE off, JIT on).
Launching programs is fine. (CE on, JIT off).
Most of the time it will guru straight away, but system can also become generally unstable producing errors like "please insert volume 'DH0'.

It's hard to reproduce - happens randomly, maybe 1/10 attempts to switch from CE to JIT. In beta 14 it happened the first time I try to launch a game

Sorry for not posting this after your last update, I wanted to wait for beta 14 since the issue is so hard to reproduce!

[Toni Wilen]

Originally Posted by ED-209

Toni, switching modes on the fly is still not entirely stable compared to beta 9 and previous releases.

When I quit any whdload programs it will randomly crash. (CE off, JIT on).
Launching programs is fine. (CE on, JIT off).
Most of the time it will guru straight away, but system can also become generally unstable producing errors like "please insert volume 'DH0'.

It's hard to reproduce - happens randomly, maybe 1/10 attempts to switch from CE to JIT. In beta 14 it happened the first time I try to launch a game

Sorry for not posting this after your last update, I wanted to wait for beta 14 since the issue is so hard to reproduce!

Can you duplicate it easily if you run uae-configuration manually (using as simple parameters as possible) in CLI to switch modes. It should be much quicker than using whdload.

[vagrant]

I tried switching on the fly via CLI & no-startup 50+ times and could not reproduce.

Then I restarted winuae with winlog enabled, loaded WB and proceeded to load/quit whdload games to try and force guru.. still nothing after 50 attempts. Then I had the idea to have Dopus 4 running in the background (since this is true to my usual environment.) Strangely the first attempt of quitting a whdload game resulted in guru.. I'll attach the log for the whole session. (Had to archive it because over 100k)

Problem is:
A) Afterwards, I still couldn't reproduce the problem with Dopus 4 running in BG.

B) When it guru'ed the first time I ran beta 14 I was not even launching from workbench - the game was launched via wbrun with no-startup..

[dlfrsilver]

the JIT system doesn't exist on a real amiga, it was just made to get the maximum speed on winuae for PC. Today the computers are very powerful, and i personaly don't see the point of it anymore.

[Toni Wilen]

Originally Posted by dlfrsilver

the JIT system doesn't exist on a real amiga, it was just made to get the maximum speed on winuae for PC. Today the computers are very powerful, and i personaly don't see the point of it anymore.

I don't see the point of post above. "Something has a small bug, that something must be removed". JIT also runs faster on fast PCs, not the other way round! EDIT: and relatively "slow" PCs are still very common.

JIT being useful or not is off topic in this thread, do not continue discussion of this topic in this thread, thanks.

EDIT: Games/demos: generally JIT is mostly useless (of course there are exceptions). Applications: can be really useful.

[Toni Wilen]

Originally Posted by ED-209

I tried switching on the fly via CLI & no-startup 50+ times and could not reproduce.

Then I restarted winuae with winlog enabled, loaded WB and proceeded to load/quit whdload games to try and force guru.. still nothing after 50 attempts. Then I had the idea to have Dopus 4 running in the background (since this is true to my usual environment.) Strangely the first attempt of quitting a whdload game resulted in guru.. I'll attach the log for the whole session. (Had to archive it because over 100k)

Problem is:
A) Afterwards, I still couldn't reproduce the problem with Dopus 4 running in BG.

B) When it guru'ed the first time I ran beta 14 I was not even launching from workbench - the game was launched via wbrun with no-startup..

Logs and screenshots are useless. I need to duplicate it myself, easily..

What if you run some CPU heavy program in background while switching modes? (like file compression, benchmark program etc..)

[vagrant]

Yeh I mainly keep it running for those games & demos that my E8400 can't handle at full framerate.. plus some applications really fly with JIT enabled

[vagrant]

Toni I tried changing modes whilst compressing a massive archive but could not reproduce..

Just now I managed to quickly reproduce the problem a few times in succession by loading dopus 4 on WB then changing modes via CLI... but now yet again I can't reproduce

All I can confirm is that this does not happen in beta 9 or earlier

[Toni Wilen]

Originally Posted by ED-209

Toni I tried changing modes whilst compressing a massive archive but could not reproduce..

Just now I managed to quickly reproduce the problem a few times in succession by loading dopus 4 on WB then changing modes via CLI... but now yet again I can't reproduce

All I can confirm is that this does not happen in beta 9 or earlier

I know what probably is the cause, I removed some JIT-only variables from very regularly called functions that are not called by JIT code. It should work..

I assume JIT <> more compatible on/off switching is now stable? It is only JIT <> CE switch that randomly breaks?

[vagrant]

Yep 'more compatible' switching has been stable since the change, only JIT<>CE is causing problems. Specifically, switching back to JIT from CE mode.

[dlfrsilver]

EDIT: Games/demos: generally JIT is mostly useless (of course there are exceptions). Applications: can be really useful.

This is exactly what i meant