Thanks,
currently with this configuration no crash occurs but only with the 64bit version even adding a directory as an archive with amiga files
the same configuration with the 32bit version crashes very often even using only 128 of Z3 ram
strange thing is that if I add a directory at startup it only works the first time if I press F12 to restart for example it always crashes.
Currently the 64bit version works perfectly
Currently the 32bit version is very unstable at least for me.

separate note:
I also did all the tests recommended by you with the 32bit version by deactivating mediator pci etc.
it always crashes randomly and very often.

I suppose that having a crash dump without step to reproduce is useless right?

At the moment for the 32bit version I cannot give more precise details.

Instead this morning with the 64bit version I added the directory with the amiga files and it crashed again.

Do you mean it crashes after emulation has started and it works for a while and then it crashes? Or only if you press F12? Immediately when you press F12 or only after you return back to emulation?

Does it only happen if RTG is enabled? Or even in extremely limited config?

Dump makes it look like it crashes at startup.

All crash dumps so far have same problem, custom chipset emulation accesses invalid pointer which is impossible = something somewhere else overwrote it. (There probably is some old buffer overflow or new was introduced accidentally. But so far all changes have been PCem RTG and PCI so the main bit is that does it happen without RTG)

when it starts up and runs it never crashes
and everything works
when it crashes it does so on boot
or when I restart (F12)

when i try to disable voodoo (rtg) i noticed this
in reality the card is not disabled if "ROM DISABLED" is used the card remains in operation anyway and is marked with an asterisk as selected.

I have to select whitespace to turn it off
separate note:
now I try with a limited configuration

https://download.abime.net/winuae/fi...uae_4500b15.7z
https://download.abime.net/winuae/fi...e64_4500b15.7z

Beta 15:

- PCI Virge emulation. Not much point but Virge emulation already existed, so... Not all byteswapping modes emulated, only what Mediator driver needs to work correctly. G-REX + Virge also works but 24-bit modes have some byteswap problems.
- PCem PCI device config byte wide reads fixed (Voodoo/Virge + G-REX in CSPPC boot screen PCI list PCI device type is now shown correctly)
- Voodoo 3 now works with G-REX CGX4 drivers.
- G-REX didn't detect any PCI cards after FM801.
- PCI RTG board native/RTG mode autoswitching improved.
- Aranym JIT update missed move from FPU register to data register clamping (for example FPn -150.0 to Dn.B should become -128). Re-added.
- Fixed FPU instruction JIT blacklist support.
- Combitec HD 20 A/HD 40 A (not 100% sure it is exactly this model but very likely) emulation.
- Another blitter/copper timing bug fix. (b12)

Combitec HD 20 A/HD 40 A:
- OMTI compatible HD controller. Usual OMTI IO offset 0x641. Base address is at $800000 + autoboot ROM at $f00000.
- Autoboot ROM supports autoboot under KS 1.2 (seems to use same hack that other KS 1.2 autobootable HD controller use)
- Boot ROM version string: "autoboot.device (autoboot.device 6.18 (27.8.89) , Rom_1.2, FFS, Bildchen, Search, New Boot Partition Programmiert von Bernhard Möllemann & Hartmut Sprave (C) Combitec 1988,1989"
- Boot screen ("COMPUTER TOP EQUIPMENT COLOSSUS(R) HD-AutoBoot")

Toni sorry again,
I have tried all kinds of possible combinations the problem seems to occur only when I use a directory as an archive I also set winuae32-64bit to be used as administrator for security which I usually do because I usually use a real hard-disk.
But in this case I'm just using .hdf for testing.
with the new beta15 now the 64bit version of winuae has also crashed.
When I use both versions the crash never occurs
the crash occurs only when using a directory as an archive.
It will be fate that I cannot use voodoo3 with 4.1 :D

I can now duplicate the red autoconfig error screen. It also goes away if I untick "custom board order" in hardware info screen. Does this also "fix" your crash problem?

This configuration is similar to the previous one with the difference that there is already a directory preset in this so winuae32bit never crashes.
If I uncheck "custom board order" it crashes immediately
Even if I delete the preset directory it crashes immediately
In summary it seems that if I leave the configuration file already with the preset directory configuration everything works.
If instead I delete the directory from "CD & Hard Driver" and I boot it gives me the Red screen.
Currently if I uncheck "custom board order" it immediately crashes with the current configuration.
Here the new dumps with "custom board order" deselected always with 32bit winuae

It seems a benign update for me. The games I use for testing seem to work fine now (as pre b12) and it mostly removed the occasional hiccups with scrolling and copperlist they had...

Can we test the OCS demos again with beta 15 or do you have any other changes to make before ?

Does 64-bit version work? It still sounds like available RAM (not physical RAM but per process virtual RAM) problem because Voodoo emulation can increase it noticeably. (You don't have any weird Windows hacks configured, like disabling page file etc?)

Red autoconfig error screen after hard reset is a bug but only indirectly related, shouldn't have anything to do with the crashes. Oddly enough it says problem is with UAE autoconfig board when it is actually Z3 RAM that failed to work..

Not yet. There is still some minor glitches in my usual test statefiles. (EDIT: biggest problem is that copper emulation is basically wrong [wrong assumption about copper blitter waits. Chip schematics have proven it to be wrong] but it worked with old blitter emulation when copper writes to blitter registers. Now it needs some extra tweaks. It needs rewrite but not until next official version or even later)

Quite strange because it would only caused random graphics glitches on some demos that use copper to setup blitter. (only if blit finishing would have woken up copper during scanline's last possible slot)

With previous beta I had some hiccups for example in Fantastatic Dizzy AGA background parallax using copperlist for day-night cycle that are now not reproducible anymore (I think introduced after b12)... So it seems to me some timings you corrected were possibly involved (?)

Toni,
No at the moment windows is installed by default I have not yet disabled any service and the paging file is set by default on drive "C:" and all drives automatically.
I also tried to disable kaspersky internet security 2021 because in the 2020 version it happened every now and then that winuae was blocked as a false positive when it tried to access a directory.
But in the 2021 version this has never happened again.

The 64bit version of winuae does not seem to have this problem apparently but yesterday for example just launched the last beta 15 to try it crashed immediately as reported in the dump.

Now I try to make a new configuration from scratch to see if it works directly with the beta15 without overwriting the existing one.

I redid a new configuration from scratch without the "directory" but it crashes immediately. (winuae32-bit beta15)
I left "custom board order" unchanged so automatically.

now the 64bit beta15 version seems to work without problems with or without directory but I have to do a lot of boot to be able to say for sure

The 64bit version seems to be very stable I can increase and decrease the ram in Z3
On reboot I added and removed directories
Before it completely booted I did a warm reset etc. seems to be very stable.

Instead the 32bit version crashes or even if the boot succeeds it simply stops working suddenly.

Isn't that to much of Z3 memory for 32 bit WinUAE?

Remember that with Quickstart A4000 with Cyberstorm PPC you already have 128 MB of Cyberstorm card memory + 8 MB A4000 Motherboard Fast RAM (32-bit). Plus your 512 MB ...

@Toni Could you add all memory info to Hardware info?

@Tomislav
thanks for the advice, at the moment the crashes seem random at least to me they happen with 128mb 256 and 512 I never go further with the 32bit version

Yes and no. 32-bit Windows + 32-bit WinUAE can only allocate about 384M to 512M mem. 64-bit Windows + 32-bit WinUAE has almost 2G of address space.

But I think it also depends on used Windows version, perhaps there is some differences between even Windows 10 versions. And there are programs that inject in every process, like virus scanners etc.

There is not much that can be done because for example entering GUI when emulation is running might cause lots of new dlls to be loaded and if there is not enough space in winuae process' address space -> instantly dead.

Only solution is 64-bit everything. 64-bit process address space is practically unlimited (currently seems to be 128T) so you run out of physical RAM first :)


Hardware info can only show devices that are dynamically configured ("new style" expension devices). Static regions like chip/slow/mainboard RAM are not compatible. They probably should be converted to more dynamic method but it is very big task.

Good :)

Does 32-bit version work better if you run it with -maxmem 1024 or -maxmem 512 command line parameters? (This limits max reserved memory space for JIT compatible RAM. Which is not needed when emulating OS4)