WinUAE 3.2.2 Early Startup display issues.

[Aegis]

Running an AGA config and changing the 'Chip Type' to original in the Early Startup screen doesn't seem to work in 3.2.2. (I use it to run Lucasarts stuff under 2.6.1) - seems to cause some intermittent gurus too - config attached:

[Toni Wilen]

What do you mean by "not working"? (never just say "not working"!)

Switch off JIT first and try again. If something did change, next keep JIT on but change JIT direct to JIT indirect.

Finally try older versions one by one until you find last working (whatever it is!) version.

Assuming you mean early boot menu display type is "forgotten" after clicking "boot" button in early boot menu, does PAL/NTSC change work? (It is easier to see and debug than chip type)

[Aegis]

By not working, assuming I can get that config to boot without guruing (after changing the chipset in 3.2.2) the display properties are still showing AGA enabled (256 colours available vs 16).

I'll try tinkering with JIT but in the meantime I tried a fresh config in AF2016 and it only seems to guru if 'synthetic (Full SCSI)' is enabled - not sure what that translates to exactly in the WinUAE settings.

*Edit* still gurus with JIT indirect or off altogether. 2.6.1 works fine but I'll try some more recent versions to see if I can find the last one that works.

[Toni Wilen]

Originally Posted by Aegis

By not working, assuming I can get that config to boot without guruing (after changing the chipset in 3.2.2) the display properties are still showing AGA enabled (256 colours available vs 16)

Ok, Does just entering and then exiting early boot menu do the same? Or do you have to change chipset type or PAL/NTSC to cause it? (With and without JIT)

EDIT: and does it guru when startup-sequence runs? Does it work if you boot without startup-sequence? (if it needs s-s, then it could be some odd patch in your system, or is it standard OS39 with up to BB2 updates?)

I'll try tinkering with JIT but in the meantime I tried a fresh config in AF2016 and it only seems to guru if 'synthetic (Full SCSI)' is enabled - not sure what that translates to exactly in the WinUAE settings.

I don't know exact AF configs either.

[Aegis]

Gurus if I enter and exit the Early Startup menu (with JIT on or off) - I don't have to change anything (!)

'Full SCSI' in AF seems related to 'uaescsi.device' - Workbench says 'cannot open uaescsi.device unit 0' if it's set to 'Synthetic (automatic)' or disabled.

*Edit* There seems to be 2 ways to access the early startup - if you hold down the mouse buttons immediately, accessing the early startup is instantaneous - changing the settings allows me to boot but AGA is still enabled.

If I wait a second and then hold down the buttons, it takes longer for the early startup to appear and then accessing it causes a guru.

3.1.0 shows the same behaviour - going to try 2.8.1 next.

[Aegis]

2.8.1 works (no gurus, boots into OCS).

*Edit* 3.0.0 gurus.

[Toni Wilen]

Originally Posted by Aegis

*Edit* There seems to be 2 ways to access the early startup - if you hold down the mouse buttons immediately, accessing the early startup is instantaneous - changing the settings allows me to boot but AGA is still enabled.

If I wait a second and then hold down the buttons, it takes longer for the early startup to appear and then accessing it causes a guru.

Confirmed. Guru appears if early boot menu was entered after OS39 ROM update was loaded.

Debugging...

[Toni Wilen]

I think this is same problem as blizkick issue after Z3 RAM was made to work like real Z2/Z3 board (matches real world behavior), it will temporarily disappear at reset and re-appear when autoconfigured again. Unfortunately early ROM patches (before autoconfig) are loaded to this RAM region too..

Adding some "CPU board" RAM should fix it.

Having Z3 RAM is very rare in real world because it is very slow compared to mainboard/accelerator board RAM. It probably happens with real hardware too if real Z3 RAM board is in use _without_ any mainboard RAM (which is extremely rare, practically non-existing configuration).

It looks like this really needs a special case where emulation works differently than in real world, Z3 RAM is very common setting in emulation.

[Aegis]

Yep, confirmed - adding some 'Processor Slot Fast' RAM makes the problem go away - boots into OCS without issue. Thanks Toni

*Edit* Adding Motherboard RAM works too - unfortunately AF2016 doesn't support either of those - it's 'Fast' RAM slider is mapped to Z2 RAM - I'll send a bug report to Cloanto.

[Aegis]

Originally Posted by Toni Wilen

It looks like this really needs a special case where emulation works differently than in real world, Z3 RAM is very common setting in emulation.

Or perhaps enforce a fix whereby if Z2/3 RAM is added then Motherboard/CPU RAM is automatically set to a minimum of 1MB? If this is the behaviour of a real Amiga then it seems a shame to make an emulation 'special case' when everything else is designed to replicate the hardware as closely as possible..?

It'd be nice to confirm this guru happens on the actual hardware though - sadly my A4000 bit the dust a long time ago - luckily it's been preserved in WinUAE

[Toni Wilen]

Originally Posted by Aegis

Or perhaps enforce a fix whereby if Z2/3 RAM is added then Motherboard/CPU RAM is automatically set to a minimum of 1MB? If this is the behaviour of a real Amiga then it seems a shame to make an emulation 'special case' when everything else is designed to replicate the hardware as closely as possible..?

Other RAM types are not necessarily supported by selected KS ROM. For example A1200 3.0 ROM don't automatically add "Mainboard RAM" regions.

Z2/Z3 RAM are the only RAM types that work with all ROMs. (Z2 = since KS 1.2, Z3 since 2.0+)

I think the only automatic method is to not unmap Z3 board at reset if it is the only Fast RAM board. (But technically it could cause address space conflict if autoconfig devices to do mapping differently. No existing ROM does it but some future patch/replacement may do it)

It'd be nice to confirm this guru happens on the actual hardware though - sadly my A4000 bit the dust a long time ago - luckily it's been preserved in WinUAE

I have A4000 but don't have any Z3 RAM boards. Autoconfig spec says all autoconfig devices should stop responding to all autoconfigured addresses and return to unconfigured mode and wait for reconfigure by expansion.library. (It is possible they actually don't do it but at least technically it is against the spec)

[Aegis]

Huh. Kinda tricky to know what the 'right' answer is - since this (popular emulation) configuration seems problematic on real hardware.

Maybe just add a tooltip to the Z2/3 sliders saying that Zorro-only RAM may cause incompatibilities? Cloanto could revise their default configs so it's not an issue I suppose.

[Toni Wilen]

I think the best and easiest option is to change Z3 mapping mode to only unmap Z3 at reset if it is set to "Real". "Automatic" and "UAE" (the original mapping mode in UAE) would never unmap it.

I generally don't like emulation special cases because it is too easy to write programs that only fail on real hardware. But in this case "UAE" mapping mode which does not match real world has been the default for ages until recently.

[Aegis]

That sounds like the best solution - for most users they'll never encounter/need it but for testing against 'real' hardware at least the option's there. Thanks for looking into this Toni