WinUAE 2.7.0 beta series

[Leandro Jardim]

Workbench does not boots here with CGX 4. I tried with DDraw and D3D. With D3D it locks-up on the CGX logo. With DDraw at least I could boot a PAL Workbench and change the resolution to a CGX one, but then Workbench locked.

[Toni Wilen]

Originally Posted by Leandro Jardim

Workbench does not boots here with CGX 4. I tried with DDraw and D3D. With D3D it locks-up on the CGX logo. With DDraw at least I could boot a PAL Workbench and change the resolution to a CGX one, but then Workbench locked.

I don't think this CGX or graphics board related problem and it probably happens in both modes randomly. Your config is quite "special", try first without extra hardware and using standard fastest possible 68020.

EDIT: Same when using other board types? Always try to narrow down the problem by changing most obvious options one by one.

[Leandro Jardim]

Originally Posted by Toni Wilen

I don't think this CGX or graphics board related problem and it probably happens in both modes randomly. Your config is quite "special", try first without extra hardware and using standard fastest possible 68020.

EDIT: Same when using other board types? Always try to narrow down the problem by changing most obvious options one by one.

Yes, it happens with all board types. I tried to use the fastest 68020 like you said, but it didnt worked yet, but in all ways its very slow.

When I first had problems with RTG, it seemed something like in http://eab.abime.net/902583-post13.html, because I had exactly the same side effects (before the new beta). But from some point to now, RTG got slow with or without VBlank/Triple buffering. It seemed like a conflict between configurations* because was needed justly one "toggle" (VSync thing) to things go wrong...

[* correct is "between VGA mode configuration of native chipset and RTG modes". This is what I meant, sorry...]

[FrodeSolheim]

Originally Posted by Toni Wilen

I have been comparing 68030 and 68020 instruction execution timing chapters and instruction cycle usage seem to be nearly identical. 68020 and 68030 execution engine probably is nearly identical, bus controller improvements (delayed writes are apparently not supported in 68020), increased frequencies and data cache makes the difference.

So next plan is to implement 68020 CE execution timing exactly as documented in 68030 documentation.

Why 68030? Because 68030 documentation "head"/"tail" overlap timing information is very useful and can be used to create very accurate emulation. (If it is accurate data..) 68020 documentation timing is useless for accurate emulation purposes.

Very exciting news I look forward to seeing the improvements for A1200/CD32 emulation, provided it works as hoped

[Toni Wilen]

Originally Posted by Leandro Jardim

Yes, it happens with all board types. I tried to use the fastest 68020 like you said, but it didnt worked yet, but in all ways its very slow.

What do you mean by slow? I don't see how you can mean RTG if it hangs immediately..

Try to be (much) more specific, please.

Originally Posted by FrodeSolheim

Very exciting news I look forward to seeing the improvements for A1200/CD32 emulation, provided it works as hoped

Perhaps it works, perhaps not..

68030 head/tail/cycle values are now stored in table68k, EA calculation formulas in gencpu and final cpuemu cores have calculated values in comments (separate values for EA calculation and instruction). Next step is to actually use those values for timing calculations, no good enough implementation ideas yet..

[Noth]

I've got a lovely crash report for you... I can crash WinUAE to the point that Win7 detects it when trying to do a tape install of AMIX (same results for 2.01, 2.03 & 2.1). This is using a tar archive as the tape "hardfile" that does contain an index.tape. Specifically, it crashes as soon as the install script tries to read the tape.

[Toni Wilen]

Originally Posted by Noth

I've got a lovely crash report for you... I can crash WinUAE to the point that Win7 detects it when trying to do a tape install of AMIX (same results for 2.01, 2.03 & 2.1). This is using a tar archive as the tape "hardfile" that does contain an index.tape. Specifically, it crashes as soon as the install script tries to read the tape.

This crash happened when GUI was open (Tape was changed?), not when something attempted to read the tape.

EDIT: Crash happens if new tape drive was added when emulation was already running. It is not supported, only tape change is supported. (Crash will be fixed in next beta)

[dazzleman]

Hi Toni, I've found that WinUAE crashes with a dosbox showing what appears to be CPU register values when I do the following:

Quickstart - A4000, 68040, Set Configuration.
CPU and FPU - Under CPU, turn off JIT, turn on More compatible.
Click Start.

I've tried all the 2.7 betas and this crash started with b4.

On a different note, running WinUAE in a virtual machine using VMWare Workstation. I change the RTG Graphics Card under Expansions and then save and load the configuration, but the rtg graphics card setting has returned to '-'.

[Leandro Jardim]

Originally Posted by Toni Wilen

What do you mean by slow? I don't see how you can mean RTG if it hangs immediately..

Try to be (much) more specific, please.

Hi Toni,

I means that the Intel CPU usage goes to 130% when I enable triple buffering on RTG together with triple buffering on native chipset. With double buffering on RTG I get 100% but in any case, Workbench does not boot, the CGX4 boot screen freezes. Its not the emulated CPU or Workbench that gets slow, its the host computer.

Happens with both A1200 and fastest possible speeds, on a window or fullscreen. The first versions of the beta was very responsive and worked even with A1200 speeds with a Intel CPU usage of 30% average.

[vagrant]

Hey Toni
I tried beta 6 today (I havn't tried any others).
Whenever JIT is enabled it will not boot and the CPU% box is yellow and reads "H 1".?
All is fine with JIT disabled.. something to do with the new RTG changes?

EDIT: JIT now works if I uncheck "more compatible"..

[Toni Wilen]

Originally Posted by dazzleman

Hi Toni, I've found that WinUAE crashes with a dosbox showing what appears to be CPU register values when I do the following:

Quickstart - A4000, 68040, Set Configuration.
CPU and FPU - Under CPU, turn off JIT, turn on More compatible.
Click Start.

I've tried all the 2.7 betas and this crash started with b4.

How I am going to duplicate it if it only happens when dosbox is running? Just setting above config does nothing interesting.

And do you really mean winuae crashes, not emulated program? Totally different thing

(and if it does, attach the dump file)

On a different note, running WinUAE in a virtual machine using VMWare Workstation. I change the RTG Graphics Card under Expansions and then save and load the configuration, but the rtg graphics card setting has returned to '-'.

No logs so crystall ball says: "Do not use Windows XP or add more RAM. Or add -maxmem 768 command line parameter. Or select Z2 board. Or you have 24-bit CPU addressing and Z3 board. Or possibly totally something else."

[Toni Wilen]

Originally Posted by Leandro Jardim

I means that the Intel CPU usage goes to 130% when I enable triple buffering on RTG together with triple buffering on native chipset. With double buffering on RTG I get 100% but in any case, Workbench does not boot, the CGX4 boot screen freezes. Its not the emulated CPU or Workbench that gets slow, its the host computer.

Does CPU% get lower if you have triple buffering and RTG refresh rate set to lower? (60Hz or 50Hz) in Expansion panel?

I assume this happens without vsync too?

Create minimal possible setup that has CGX4 freeze (Z2 memory and RTG only), create statefile and email or attach it here, thanks. (include also config file)

Happens with both A1200 and fastest possible speeds, on a window or fullscreen. The first versions of the beta was very responsive and worked even with A1200 speeds with a Intel CPU usage of 30% average.

Last "working" exact version please.

[dazzleman]

Originally Posted by Toni Wilen

How I am going to duplicate it if it only happens when dosbox is running? Just setting above config does nothing interesting.

And do you really mean winuae crashes, not emulated program? Totally different thing

(and if it does, attach the dump file)

Sorry, maybe I could have worded that a little better. I meant to say that a dos-like command prompt window opens (not the application DosBox). This happens as soon as the emulation starts. The WinUAE window stays black, the CPU is at 100 and the FPS changes to HALT1. I have attached a picture of this dos-like window plus the usual logs.

With regards to the VMWare issue, it looks like I underestimated the specs required to run WinUAE. It was fine in a more powerful virtual machine. I'll accept responsibility for that one

[vagrant]

Originally Posted by who

Hey Toni
I tried beta 6 today (I havn't tried any others).
Whenever JIT is enabled it will not boot and the CPU% box is yellow and reads "H 1".?
All is fine with JIT disabled.. something to do with the new RTG changes?

EDIT: JIT now works if I uncheck "more compatible"..

I'm still getting strange behavior.. When launching whdload games & changing cycle exact/cpu speed/jit on the fly sometimes winuae will crash, sometimes it will guru and sometimes it will crash with cpu meter yellow "H 1", (what does H 1 mean?)
Also JIT + CPU 'more compatible' always results in yellow 'H 1'.

[Leandro Jardim]

Hi, Toni. WinUAE only slow down when I set the RTG refresh rate to "Chipset" (or other than the VGA rate), and seems that the issue is not related to VSync. Here are the logs and the state save.

[Toni Wilen]

Originally Posted by Leandro Jardim

Hi, Toni. WinUAE only slow down when I set the RTG refresh rate to "Chipset" (or other than the VGA rate)

But does it slow down if you manually set 50? (Always quit winuae and set the value before starting emulation!)

Here are the logs and the state save.

I think I said to use as simple as possible config = preferably no Picasso IV.. (especially in Z2 mode with Z2 RAM active at the same time).

EDIT: Z2 RAM enabled + P4 in Z2 mode has memory mapping bug.

[Toni Wilen]

Originally Posted by dazzleman

With regards to the VMWare issue, it looks like I underestimated the specs required to run WinUAE. It was fine in a more powerful virtual machine. I'll accept responsibility for that one

No, it only happens because you have Windows XP. It is workaround for XP (or some XP drivers) being stupid. Use -maxmem 768 command line parameter.

(No idea about debugger console window, possible some forgotten debugging test I forgot to remove..)

Originally Posted by who

I'm still getting strange behavior.. When launching whdload games & changing cycle exact/cpu speed/jit on the fly sometimes winuae will crash, sometimes it will guru and sometimes it will crash with cpu meter yellow "H 1", (what does H 1 mean?)
Also JIT + CPU 'more compatible' always results in yellow 'H 1'.

H = CPU halted state (number is reason code) = emulation is practically paused. CPU is halted if double exception happens (real CPU halts also in this situation), or if CPU attempts to fetch instructions from non-RAM (IO, non-existing ram etc) region. Easier to debug when CPU stops immediately instead of executing lots of of random instructions and causing random exceptions until it finally overflows the stack and causes double-exception. (This is not enabled in 68000 cycle-exact because there is at least one protection that by design jumps to non-existing memory and expects exception...)

>68020 cycle-exact/more compatible is partially broken, do not use.

[Leandro Jardim]

Originally Posted by Toni Wilen

But does it slow down if you manually set 50? (Always quit winuae and set the value before starting emulation!)

Yes, it slow down too.

Originally Posted by Toni Wilen

I think I said to use as simple as possible config = preferably no Picasso IV.. (especially in Z2 mode with Z2 RAM active at the same time).

EDIT: Z2 RAM enabled + P4 in Z2 mode has memory mapping bug.

I know. I tried other configs and it seems to work now, but it continues slow.

[vagrant]

Originally Posted by Toni Wilen

H = CPU halted state (number is reason code) = emulation is practically paused. CPU is halted if double exception happens (real CPU halts also in this situation), or if CPU attempts to fetch instructions from non-RAM (IO, non-existing ram etc) region. Easier to debug when CPU stops immediately instead of executing lots of of random instructions and causing random exceptions until it finally overflows the stack and causes double-exception. (This is not enabled in 68000 cycle-exact because there is at least one protection that by design jumps to non-existing memory and expects exception...)

>68020 cycle-exact/more compatible is partially broken, do not use.

OK thanks for that

[Toni Wilen]

Originally Posted by Leandro Jardim

Yes, it slow down too.

I think I finally found the problem.

I know. I tried other configs and it seems to work now, but it continues slow.

It is also very important to include also situations when something works, not just including situations that don't work. It will narrow down the problem area greatly.

This is fixed, _if_ the problem only happened when Z2 RTG and Z2 RAM was enabled at the same time.

(Still no new betas until new 68020 ce mode is usable)