WinUAE 3.3.0 beta series

[Arnie]

Originally Posted by Toni Wilen

I understand but "works for me" = more information needed, how do you select it, using set configuration button or quickstart mode active, do you have default.uae or not and so on.

Quickstart mode wasn't active, (I usually have it set active so I didn't notice, sorry)

I still cant get a HDF to boot from the CDTV quickstart config.
It will only boot if you select CDTV WD33C93 SCSI from Adv Chipset.

I can't remember having to use that before, has something changed?

[SaphirJD]

Quickstart options seem not to work in the latest Beta.

No matter to which config i switch in Quickstart, nothing changes. Must also be the reason why Arnie has problems with booting when using the CDTV quickstart config.

Same problem with Beta 3.

Doing it the usual way, i go to the normal quickstart menu point on the left, pick the chosen config from the emulated hardware dropdown - normally now the settings should be auto loaded, but as Arnie said, only very basic settings are chosen - which are the same for whatever for a config i pick that way.

It worked normal In Beta 1.

[Arnie]

As Toni pointed out to me, make sure start in quick mode is ticked. It seems these betas don't have it ticked by default.

[SaphirJD]

I see, thanks

[Toni Wilen]

Originally Posted by Arnie

As Toni pointed out to me, make sure start in quick mode is ticked. It seems these betas don't have it ticked by default.

Now I understand what happened, no wonder I didn't notice anything different..

There was registry handling fix in previous beta (= by following proper test procedures this would not have been so confusing..) that caused some non-existing keys to return non-zero value and this affected Quickstart mode button (and some others) if you have never previously clicked the checkbox at least once.

When i open the floppy selection box winuae 64 bit crashes. The 32 bit version works instead.

[Toni Wilen]

Originally Posted by amigone

When i open the floppy selection box winuae 64 bit crashes. The 32 bit version works instead.

Crystall ball says:

http://eab.abime.net/showthread.php?t=80216

Also I think this also needs to be mentioned because crystal ball also says this is not unique to 3.3.

Main rule: Before reporting, make sure bug is NOT in previous offical version. It must be unique to this beta series! (If it is -> post in separate thread). No feature requests.

[mark_k]

Originally Posted by Toni Wilen

I know but I only wanted to add one option. Ok, option moved to Brightness/Contrast/etc select box and both options added

Heh, that's a bit overkill; why would anyone opt for $EE-is-white instead of $FC-is-white?

By the way, it looks like you do ST palette correction after gamma correction. Would it be better to do that before gamma correction?

An equivalent (at least for ST-colours) to
vi = (vi + (vi & 7)) * 2;
is
vi = (vi + (vi >> 4)) * 2;
I don't know which would be faster or produce better code.

Another equivalent would be
vi = (vi<<1) + (vi>>3);

Originally Posted by Toni Wilen

Crystall ball says:

http://eab.abime.net/showthread.php?t=80216

Also I think this also needs to be mentioned because crystal ball also says this is not unique to 3.3.

Sorry.

However if it serves to someone else, i tried to deactivate many shell extensions and finally Crystall ball say to me that i must deactivate avast extensions. It seems that avast are the problem as you posted also in other thread.

Hi.

[Toni Wilen]

Originally Posted by Arnie

I still cant get a HDF to boot from the CDTV quickstart config.
It will only boot if you select CDTV WD33C93 SCSI from Adv Chipset.

I can't remember having to use that before, has something changed?

Remembering something happening means nothing. Config that works with 3.2 but does not work anymore is required.

EDIT: I added HDF to CDTV config, nothing happened with previous version. CDTV CD/other external boot device priorities are strange.

Originally Posted by mark_k

Heh, that's a bit overkill; why would anyone opt for $EE-is-white instead of $FC-is-white?

As I already said, thats what you get if you want to make OCS/ECS compatible palette fix. It matches existing patches.

By the way, it looks like you do ST palette correction after gamma correction. Would it be better to do that before gamma correction?

I don't know and don't care

An equivalent (at least for ST-colours) to
vi = (vi + (vi & 7)) * 2;
is
vi = (vi + (vi >> 4)) * 2;
I don't know which would be faster or produce better code.

Another equivalent would be
vi = (vi<<1) + (vi>>3);

No one should care about speed of code that only runs once and/or when user changes brightness/etc values. Readability always wins unless it is performance critical. This is not performance critical.

[PortuguesePilot]

I'm here just to inform you that I'm having a strange issue with v3.3.0 Public Beta 4 - 2016.02.07.

When I load WinUAE my configurations are all as they always were but when I load a game, it automatically resets my controls (my USB Logitech Dual Action gets replaced with the Keyboad Layout A), rendering the use of the game pad impossible, even if i reassign and reconfigure it. I've tried to re-save the configurations but it still gets reset each time I load a new game.

Does anyone else experience this issue? The version I was using before (v3.3.0 Public Beta 2 - 2016.01.31, to which I have since reverted back) was working fine.

[Retro-Nerd]

The joy ports problem is already fixed.

http://eab.abime.net/showpost.php?p=...3&postcount=79

[mark_k]

Originally Posted by Toni Wilen

I don't know and don't care

Thinking about it some more, you should definitely do ST-correction before gamma correction. [Maybe the rest of this could/should be moved to a different thread...]

I'll refer to brightness as ranging from 0 (black) to 1 (white) as that's simpler when talking about gamma correction (just raise to a power). Whatever the gamma correction factor y, 0^y = 0 and 1^y = 1. Black and white are always unchanged.

Suppose the user gamma-corrects with a value of 2. Unadjusted "ST white" is value 7/15. That becomes (7/15)^2 = 0.2178 approx after gamma correction. If we then double it (correcting ST to Amiga 4-bit) you get 0.4356 approx. So even ST white becomes less than 50% grey after ST-correction.

Alternatively, suppose the gamma correction factor is 0.5. Then ~half-brightness ST is 4/7, i.e. 4/15 Amiga = $44/255 8-bit = 0.2667 approx. Raise that to power 0.5 ==> 0.5164 approx. If we do ST-correction after that, end up with 1.0323 which clips to 1 (i.e. full white). So anything above ST value 3 gets clipped to white in that case.

[mark_k]

Another suggestion/option for ST-correction... There are probably some/many ST ports for the Amiga which have corrected (doubled) colours. (Can anyone research into likely examples? How about Speedball, Xenon, Gods?)

So an option to extend the doubled 4-bit colours to 8-bit could also be useful. In other words Amiga $EEE ⤇ $FCFCFC. (For each colour component %xyx0xyz0 ⤇ %xyzxyz00.)

The code could actually become clearer since you need to correct before gamma-correction. The current code in video_calc_gammatable() could become something like this:

switch (currprefs.gfx_threebitcolors) {
	case 0:	break;
	case 1:	con *= 2.0f;	// 0xEE/0x77
	case 2:	con = (con * 252.0f) / 119.0f;	// 0xFC/0x77
	case 3:	con = (con * 252.0f) / 238.0f;	// 0xFC/0xEE
}
v = video_gamma((float)(i - 256), gams[j], bri, con);

The three correction options are just preset values for the contrast adjustment.

By the way, similarly to needing to ST-correct before gamma correction, in video_gamma() it might be an idea to do value *= con; before value += bri;.

Edit: Moving that con-setting code to the start of video_calc_gammatable() (where con is initially set to con = ((float)(currprefs.gfx_contrast + 1000)) / 1000.0f ) might be cleaner still.

[Toni Wilen]

Originally Posted by mark_k

Another suggestion/option for ST-correction... There are probably some/many ST ports for the Amiga which have corrected (doubled) colours. (Can anyone research into likely examples? How about Speedball, Xenon, Gods?)

At least Speedball and Gods highest color value is EEE so it seems your third option makes sense.

[Toni Wilen]

http://www.winuae.net/files/b/winuae_3300b5.7z
http://www.winuae.net/files/b/winuae64_3300b5.7z

Beta 5:

- Game Ports mouse and joystick was always reset to defaults (b4)
- Dark palette fix adjustment is now calculated before other adjustments (brightness, contrast, gamma)
- Dark palette fix third option added, pre-converted Atari ST palette increased to full range, 12-bit EEE becomes nearly full white, FCFCFC in 24-bit RGB space. (Not FFFFFF because palette would not be linear anymore)

OS4 UAE expansion updates: (Discussion thread here: http://eab.abime.net/showthread.php?t=81146)

- Directory filesystem random errors fixed.
- Directory filesystem/CDFS CD on the fly insertion/removal supported! (It wasn't that difficult after all)
- uaescsi.device supported.

NOTE: Try not to change uaegfx resolution in OS4, it can cause mysterious crashes or side-effects. Fix coming later.

TODO: bsdsocket.library and fixing random hangs.

[mark_k]

I noticed that in video_calc_gammatable() you do
gamma[i][j] = (uae_u32)v;
where v is of type float.

Since the float-to-int conversion truncates, should you do this instead?
gamma[i][j] = (uae_u32)(v + 0.5f);

Edit to add: Similar issue in limit256() and limit256rb()? The limit256rb() case may be slightly different since there v can be negative.

[Snake79]

I'm sorry if i'm writing this in a wrong thread, but i have spotted that on winuae64_3300b5 (latest 64-bit beta and at least previous) Realtek 8029 PCI could not open. This is happening only on 64-bit versions. The same config is working properly on 32-bit versions. Debug attached.
PS. Official WinUAE3220 64-bit works ok (on emulated Picasso IV Zorro III).

[Toni Wilen]

Originally Posted by Snake79

I'm sorry if i'm writing this in a wrong thread, but i have spotted that on winuae64_3300b5 (latest 64-bit beta and at least previous) Realtek 8029 PCI could not open. This is happening only on 64-bit versions. The same config is working properly on 32-bit versions. Debug attached.
PS. Official WinUAE3220 64-bit works ok (on emulated Picasso IV Zorro III).

Your whole Z3 space is used by Z3 fast and RTG. No space for Prometheus anymore. True Z3 space is "only" 1G and due to Z3 spec alignment requirements, you lose 256M between Fast and RTG = 256M+256M+512M=1G. GREX probably is best option because it does not need Z3 space or Z2 mode Mediator. "UAE" mode Z3 space is much larger but it can't be used with non-m68k or non-AOS operating systems.

32-bit probably can't allocate full 512M.

[Snake79]

Thanks for diagnosis and explanation. I will try to re-config tonight.