WinUAE 4.4.0 beta series

[Toni Wilen]

Originally Posted by DamienD

One small issue I've noticed with the beta series is as follows:

If I play a game with say certain KS, then if I go into the GUI, change KS and reset, the old KS is still loaded and not the newly selected one.

This conflicts with "GUI Reset button now also copies current GUI config to active config. Normally only config entries that support on the fly changes are active after reset but because GUI Reset button does cold reset, all changed config entries can be safely enabled. (For example Harddrive panel automount options)" update. I'll try to find solution later..

Originally Posted by DamienD

Oh, so you might have found the culprit?

Possibly but I am not sure yet. If it still happens in next beta, I'll need to add more debug logging.

[Toni Wilen]

http://www.winuae.net/files/b/winuae_4400b4.7z
http://www.winuae.net/files/b/winuae64_4400b4.7z

Beta 4:

- 68010 address errors fixed. Most read and write bus errors tested and fixed.
- 68010 DIVU cycle count fix. It does not have fully static cycle count as I originally thought (due to not random enough test data). Best case 74 cycles, worst case 104 cycles. Most "normal" divisions (relatively small divisor) are 104 cycles. Algorithm seems to be exact same as used in 68000 but compare and subtract operation if comparison was true appears to be "free" in 68010. (MULs have similar operation, they do compare and add in a loop. 68010 hardware probably gained feature that first executes compare, then compare result is used to select between internal register or zero register, then following ALU operation is executed using selected value. 68000 had to do compare, check comparison result, branch if false, execute ALU operation if true which takes longer.)
- 68010 loop mode CLR.B and CLR.W need 2 extra cycles when loop ends. CLR.L was already correct.
- 68010 loop mode was 2 cycles too fast/loop round in prefetch (non-ce) mode.
- Verified real 68000 and 68010 in cputester cycle test mode again.
- 68030 MMU RTE software fixed pipeline stage handling bug fix. (WHDLoad QA tests 33003/33004/33005, 33012)
- 68030 MMU + prefetch: if instruction generated MMU access fault and it was Locked Read-Modify-Write (TAS, CAS, CAS2), MMU status register RM flag was not set. (94040)
- 68030 MMU + prefetch: "68030 MMU seems to do -(an)/(an)+ adjustment before bus error is detected and original register content is not restored when bus error exception starts" b1 update fix. Amix should boot again.
- Screen capture to clipboard created blank image if 256 color or less RTG mode and capture before filtering was set.
- When switching GUI panels, old sub panel window was not removed from element array. Possibly could cause crashes or some other issues when it was re-used.
- Added b1 debug logging format string flags and width specifier support (except floating point values). Alternate use mode implemented: write pointer to argument array to $BFFF08, then format string to $BFFF04. In this mode %d/%u/%x is assumed to be word wide, %ld/%lu/%lx long word wide (like exec/RawDoFmt). %c was missing.

[DamienD]

Hi Toni,

Thank you for the new beta

Tested Heretic & Hexen 10 times; only one crash which is pretty normal.

Originally Posted by Toni Wilen

Can you narrow it down? (=reduce number of panels that need to be opened to duplicate it)

Especially are panels that are config specific (like ROM) required?

Does it only happen if you first load some config?

EDIT: Already freed windows dialog entry handle is in list which probably is related problem. More debugging later..

Originally Posted by DamienD

Hi Toni,

I can't really narrow it down as it happens randomly.

I was checking configurations so I'd first load one, then click through each of the sections in the order listed etc. and then load of the next configuration file / repeat going through the sections.

Oh, so you might have found the culprit?

Originally Posted by Toni Wilen

- When switching GUI panels, old sub panel window was not removed from element array. Possibly could cause crashes or some other issues when it was re-used.

As per usual, I think you've nailed it

I tested loading 30 x configurations i.e. load one, flicking through the various sections, load the next configuration.

Not one crash

[Retroplay]

Did something regarding RDB HDFs change since 4.4.0b2 (last working for me) ?
I tried to run from command prompt using these parameters to figure out what's causing it to close immediately:
winuae64 -log -f classicwb.uae
In the log I see a bunch of these:
zfile: tried to free already closed filehandle!

Bootlog is the only file created, is there a way to force a full log ?

[Toni Wilen]

Originally Posted by Retroplay

Did something regarding RDB HDFs change since 4.4.0b2 (last working for me) ?
I tried to run from command prompt using these parameters to figure out what's causing it to close immediately:
winuae64 -log -f classicwb.uae
In the log I see a bunch of these:
zfile: tried to free already closed filehandle!

Bootlog is the only file created, is there a way to force a full log ?

It probably crashes before winuaelog.txt gets created. Check the log window if it has more log lines than the log file.

zfile: tried to free already closed filehandle!
KS ver = 45 (0x2d)

Possibly related to KS ROM loading than HDF. HDF gets opened when emulation starts, not when config gets loaded.

Attach your config file.

[Retroplay]

Check the log window if it has more log lines than the log file.

I'd be happy to but it opens and closes before I can see anything.

Btw, it's not just my ClassicWB with custom 3.1 rom (SCSI 43.45 & iconlib 46.4), it also happens with my A1200 3.1.4 setup.
Only thing they have in common is RDB mode, partitioned and PFS3-AIO formatted.

My Workbench 1.3 bog standard FastFileSystem HDF is working fine though.

Idk, maybe I need to create a new partitioned HDF in b4 and see if that changes anything.

[edit]
Attachment deleted as problem is solved.

[Toni Wilen]

Originally Posted by Retroplay

I'd be happy to but it opens and closes before I can see anything.

-log -logflush might help to not lose last few lines of the log.

What happens if you load the config using GUI?

EDIT: What if kickstart_rom_file in config file points to plain rom image? (not archive) EDIT2: Edit it manually using text editor to guarantee that nothing else changes!

EDIT3: It is related to "When ejecting directory filesystem that points to plain file or archive, not all host file handles were closed properly.". Fix later..

[Retroplay]

Here's new log with above parameters. (winuae64 -log -logflush -f classicwb.uae)

If I load config via GUI WinUAE just exits.

[edit]
Hmmmm, that's odd.

It seems that my zipped custom rom (not detected by WinUAE via rom scanner) causes the issue, unzipped it's fine.
However all my other configs with detected zipped kickroms works though, no wonder I was scratching my head on this one.

[edit 2]
Yep, undetected kickroms in scanner must not be zipped.

[edit 3]
Removed attachment as problem is solved.

[Toni Wilen]

Does today's winuae.7z fix it?

[Retroplay]

Yes it does.

[ransom1122]

It seems with a quickstart cd32 on version 4.4.0 (Public Beta 3 , 2020.05.17) Zool 2 CD32 (Zool 2 (1994)(Gremlin)[!].zip) from tosec set has corrupt gfx right from the start?

I'm not sure if the game is corrupt or emulation problems with latest winuae release?

Can anyone else verify this issue form their end?

[jotd]

Earok said there are blitter errors in the CD32 release. Didn't witness that. Can you check if you have "immediate blitter" in chipset?

[ransom1122]

Originally Posted by jotd

Earok said there are blitter errors in the CD32 release. Didn't witness that. Can you check if you have "immediate blitter" in chipset?

It's deactivated by default after you select Quickstart CD32...

Wait for Blitter is Enabled, I tried to disable it but it did not change the gfx issue.

[Zarnal]

It's very curious. Same issue with quickstart mode but with my personnal settings for CD32, gfx are corrects in full CE mode.

I just added a CDROM ( because generally, i don't use Quickstart modes ) on IDE0. All others settings are identicals.

You can also solve your problem by switching CPU to fastest mode.

[ransom1122]

Originally Posted by Zarnal

You can also solve your problem by switching CPU to fastest mode.

Switching CPU to fastest mode does indeed fix the problem.... but

Does this mean there is an issue with winuae emulation using CD32 quickstart default settings?

@Toni ?

[Toni Wilen]

There is a problem with this thread. Betas should not mentioned in other threads and especially not without confirming it is beta related.

[lilalurl]

The 6 above posts (Zool CD32) moved from their own thread to the dedicated beta thread.

[Toni Wilen]

Thanks. Still need required information: does it happen in previous official? What was first non-working beta?

[Zarnal]

It's not a beta issue.

Old versions of WinUae have this problem with CD32 Quickstart Mode.

At least since WinUae 3.1.

[Toni Wilen]

http://www.winuae.net/files/b/winuae_4400b5.7z
http://www.winuae.net/files/b/winuae64_4400b5.7z

Only bug fixes after this beta. As usually, this needs to be out before end of June. (Or it won't be out until winter 2020). CPU updates have taken much longer than expected. And almost no one notices any difference anyway

Some previously reported bugs to fix.

Beta 5:

Some more or less edge-case cpu tester detected fixes:

- 68020 and 68030 unexpected difference found: RTE causing format error with trace set (T0, T1 or both). 68020: format error stacked SR has trace bits unmodified (expected behavior). 68030: stacked SR has trace bits cleared! (Stacked SR equals current SR at the beginning of format exception handler) Very useless difference. 68040/68060 works like 68020.
- 68040 and 68060: instruction that can generate exception internally (CHK, CHK2, DIV, TRAPx) and if trace is active: trace is not generated after execution continues from address pointed by exception vector. All previous CPU models generate trace exception in this situation.
- 68040 T0 trace + MOVEC: only MOVEC to control register triggers T0 trace. (Documentation only lists "MOVEC")
- 68040/68060 + cpRESTORE/cpSAVE (=FSAVE/FRESTORE with co-pro ID!=1) will always generate F-line exception. Probably because external co-pro interface was removed in 68040. 68020-68030 will generate privilege violation if not in supervisor mode.
- 68040 RTR and RTE with odd return address in stack: address error stacked SR contains contents before RTR/RTE SR modifications. SR register contents when address error exception starts has correct contents.
- 68060 RTR odd return address: CCR is loaded first, then address exception is generated. Previous models: CCR is not modified.
- 68060 RTE odd return address: SR is not updated, CCR part is cleared. Z is set if new SR would have been zero, N is set if new SR would have had bit 15 set.
- 68040/68060 seems to halt if trace (probably any exception) is being processed but exception vector is odd. 68000-68030 will generate address error without halting.

- UAE: 68020+ MOVE to CCR triggered T0 trace but it only should be done if MOVE to SR (which does pipeline refill which triggeres T0 trace)
- UAE: 68020+ and trace exception with odd trace exception vector (which will generate address error): SR trace bits were not cleared when address error started.
- UAE: 68040+ BSR/JSR address error stacked address field was incorrect.
- UAE: 68020+ MOVE to SR, EOR SR, OR SR enabled trace: following trace exception stack frame PC field in stack was wrong.

- b3 "When ejecting directory filesystem that points to plain file or archive, not all host file handles were closed properly." caused problems when opening archive files.
- ROM scanner now prefer roms that have matching size (overdumps and a1000 ks disks have lower priority) and are not in archive (was already done previously).
- Debugger assembler didn't support instructions that modify address register but mnemonic does not end to 'A'. (for example EXG x,An)
- Debugger fa and s commands skipped chip ram.
- FPU default is back to 64-bit. Very few programs requires 80-bit, it isn't worth the speed loss.
- Optional (config file only) halt if BKPT instruction is executed. Some accelerator boards hang when it is executed because they don't generate required acknowledge cycle.