WinUAE 1.5.0 beta series

[turrican3]

Toni, i have many configs can't you add a setting in the gui or a command which can tell put 0,0 to all configs or something like that because if i must change everytime my configs i will begin to be crazy.
I hope i don't ask to much ?

[Toni Wilen]

Originally Posted by turrican3

Toni, i have many configs can't you add a setting in the gui or a command which can tell put 0,0 to all configs or something like that because if i must change everytime my configs i will begin to be crazy.
I hope i don't ask to much ?

Just use some text search/replace utilities.

[Toni Wilen]

Originally Posted by AmigaSurfer

The new uaegfx.card 1.1 from 10.03.2008 still crash WinUAE 1.5.0beta7 at startup.

Can you try without JIT? Dump file is totally unusable because of JIT doing something.

Does attached uaegfx.card fix it? (if not, could you attach winuaelog.txt with old working uaegfx.card?)

[Ed Cruse]

I downloaded the new 1500b7 and updated uaegfx.card. Everything seems to work as far as what’s displayed, I tried full-screen/full-window/ windowed, filters off, 32 bit color, RTG color depth matching on, and 1024x768 windowed size. On the Amiga side I tried RTG 1024x768x8/16/32. The problem is the Amiga takes a very long time to come up and comes up running very slowly. I have to double click icons very slowly for it to catch it, and the time of day clock updates about every 8 seconds at which time it jumps forward to the correct time. The mouse pointer is very jerky moving across the screen. It’s like a real Amiga with everything, including the cpu clock, running at 1/8 the normal speed. It does this every time. This was a problem with earlier betas but is a 100% problem now.

[Toni Wilen]

Originally Posted by Ed Cruse

I downloaded the new 1500b7 and updated uaegfx.card. Everything seems to work as far as what’s displayed, I tried full-screen/full-window/ windowed, filters off, 32 bit color, RTG color depth matching on, and 1024x768 windowed size. On the Amiga side I tried RTG 1024x768x8/16/32. The problem is the Amiga takes a very long time to come up and comes up running very slowly. I have to double click icons very slowly for it to catch it, and the time of day clock updates about every 8 seconds at which time it jumps forward to the correct time. The mouse pointer is very jerky moving across the screen. It’s like a real Amiga with everything, including the cpu clock, running at 1/8 the normal speed. It does this every time. This was a problem with earlier betas but is a 100% problem now.

Does it do the same if you don't use RTG modes?

[Toni Wilen]

The problem is the Amiga takes a very long time to come up and comes up running very slowly

<snip>
CLOCKFREQ: QPF 2004.24MHz (7.83MHz, DIV=256)
Testing MM-timer resolution:
1.93ms 1.94ms 1.94ms 1.95ms 100.33ms
Testing Sleep() resolution:
12.93ms 15.62ms 113.99ms 548510.07ms 113.99ms
falling back to busy-loop waiting (timer resolution > 2.5ms)
</snip>

Something is wrong somewhere.. You sure you don't have some hardware failure (overheating?) or broken driver if it randomly happened previously? Broken power saving feature? You also 100% sure old versions don't have this problem?

Try -forcerdtsc -command line parameter.

EDIT: It looks like SMP (dual core) clock sync problem. (which was common few years ago) Does it stop happening if you set WinUAE's affinity to single CPU? (using task manager)'

EDIT2: do you have latest bios update? bios update was usually require to fix above problem. (it didn't happen in earlier winuae versions because winuae forced single cpu for main thread but that was removed some time ago)

[AmigaSurfer]

Originally Posted by Toni Wilen

Can you try without JIT? Dump file is totally unusable because of JIT doing something.

Does attached uaegfx.card fix it? (if not, could you attach winuaelog.txt with old working uaegfx.card?)

The new uaegfx.card 1.1 from 11.03.2008 still crash WinUAE 1.5.0beta7 if JIT is enabled.
If I disable JIT, then WinUAE does not crash. But it seems to stay at the black bootscreen with the LEDs at the bottom. The floppydrive still change the track and I hear the click from the speakers. But I don't see any further progress. After a while I've done a keyboard reset. But after a while the HD LED goes off and then again nothing happens, except the click of the floppydrive.

There is no different in this behaviour, if I start WinUAE in windowed mode.

Attached the logs from with the new uaegfx.card 1.1 from 11.03.2008 and with the old 1.1beta.

[AmigaSurfer]

Originally Posted by AmigaSurfer

WinUAE 1.5.0beta7
If I press both mouse buttons at startup, the mouse pointer at the startup menue leaves ugly flickering artefakts on the screen. If I boot without startup-sequence, the pointer, cursor and text output shows strainge and flickering effect.

Attached a snapshot with the artefacts of the mouse pointer at the startup menue.

With beta6 I don't have this artefacts. And beta6 does not show this strange and flickering effects if I boot without startup-sequence.

[Toni Wilen]

Originally Posted by AmigaSurfer

The new uaegfx.card 1.1 from 11.03.2008 still crash WinUAE 1.5.0beta7 if JIT is enabled.

Problem is this:

Illegal instruction: 0008 at 00000005 -> 00F80B36

Most likely caused by jump to address 0.. but I still can't duplicate this and I can't see anything wrong with uaegfx.card.

Do you have something special (unofficial patches?) in your startup-sequence?

Could you try http://www.winuae.net/files/b/winuae.zip and attach winuaelog.txt again. (lots of P96 related logging enabled) It should help me to find the P96 routine that causes the crash.

Current changelog: (NOTE: do not report any other bugs except P96 crash. Real beta will be released when P96 crash is fixed.)

- uaegfx.card fallback graphics routines fixed (rarely used drawing modes that native C-code "blitter" does not support)
- print uaegfx.card version to log file
- simple RTG scaling support, do not change resolution but scale to fullscreen if display size configured in display panel is larger than requested Picasso96 resolution. Quality is bad, real filter support later. Perhaps.. Mainly useful with games/demos that use very low resolutions. (configuration option not yet added)
- "super skid marks fix" updated, previous "fix" broke all attached AGA-mode sprites
- GUI does not get overdrawn in fullscreen when adjusting filters
- timer calibration removed, uses now performance counters only, also checks periodically if counter frequency changes and adjusts to new rate automatically (power saving features)
- fullscreen non-filter mode graphics problems fixed
- vsync working but it isn't 100% smooth yet (at least on my PC)

[Ed Cruse]

Originally Posted by Toni Wilen

Something is wrong somewhere.. You sure you don't have some hardware failure (overheating?) or broken driver if it randomly happened previously? Broken power saving feature? You also 100% sure old versions don't have this problem?

Try -forcerdtsc -command line parameter.

EDIT: It looks like SMP (dual core) clock sync problem. (which was common few years ago) Does it stop happening if you set WinUAE's affinity to single CPU? (using task manager)'

EDIT2: do you have latest bios update? bios update was usually require to fix above problem. (it didn't happen in earlier winuae versions because winuae forced single cpu for main thread but that was removed some time ago)

OK, here goes, I’ll try and answer your questions but it’s kind of messy.

I’ve always had trouble with the betas of all the versions that I have been beta testing, but I’ve had very little problems with the final released versions. Even though the Task Manager shows cpu0&1, the released versions always come up looking like they are locked to cpu0, going by the core usage graphs in the Task Manager. This is for sure with 1460 and I believe 1450 and 1440, not sure before that. If I use the Task Manager to set to cpu0 there’s no change, set it back to cpu0&1 and now it looks like both cores are being used. 1500b7 does come up looking like both cores are being used, if I had to guess I would say all the betas have been using both cores and the final releases have been using only one.

Below are two charts of the length of times it took WinUAE to come up using –paffinity to lock to cpu0 or cpu0&1. Using cpu0&1, most of the time WinUAE came up with the times below and ran real slow once it came up. Sometimes it would come up in the single core times and run normal speed.

Fullscreen, 32 bit color, RTG 1024x768x8, Scale2x filter.
1460, filters off cpu0=14 sec cpu0&1=14 sec
1460, filters on cpu0=17 sec cpu0&1=69 sec
1500b7, filters off cpu0=15 sec cpu0&1=69 sec
1500b7, filters on cpu0=55 sec cpu0&1=100 sec

Fullscreen, 1280x1024x32, NTSC interlaced, Scale2x filter.
1500b7, filters off cpu0=16 sec cpu0&1=68 sec
1500b7, filters on cpu0=55 sec cpu0&1=102 sec

Looking at the tables above I’d have to say it doesn’t matter whether it comes up in RTG or native mode. With NTSC interlace and the filters off, the icons flashed continuously and the mouse pointer left a trail. There was no problems with the filters on.

I tried –forcerdtsc, it appeared to lock WinUAE to cpu1 which gave me the same times as being locked to cpu0.

While it was in slow mode I set the Task Manager to cpu0 and no change in Amiga speed, switched back to cpu0&1 and still slow. I also noticed the total cpu usage was almost zero, spiking up to 4%. Normally total cpu usage is around 34%.

If my computer was at fault wouldn’t Windows not be very stable?
Windows uses multi threaded processes, both cores, and is very stable. Windows very rarely ever goes down even when an application does.

[AmigaSurfer]

Originally Posted by Toni Wilen

Do you have something special (unofficial patches?) in your startup-sequence?

In order of there appearance:

 
C:CMQ060                                    1.4 (03.04.1999)
Anwendungen:Diagnose/Enforcer/SegTracker    37.72 (11.04.1998)
SetPatch NOROMUPDATE WAITFORVALIDATE QUIET  44.38 (08.03.2002)
run >NIL: SYS:Picasso96/p96_uae_tweak       filesize 11676
run >NIL: SYS:WinUAE/timehack               filesize 6956
C:nopaz topaz_iso-8859-15                   1.0 (08.06.1992)
C:nopaz topaz_iso-8859-15 9                 1.0 (08.06.1992)

Could you try http://www.winuae.net/files/b/winuae.zip and attach winuaelog.txt again. (lots of P96 related logging enabled) It should help me to find the P96 routine that causes the crash.

Attached the logs with this beta8.
- with JIT (log and dumpfile)
- without JIT
- without JIT, without screenmode.prefs then change to uae800x600x32
- without JIT, with the following diagnose tools enabled in startup-sequence after segtracker

run > nil: SYS:WinUAE/vbrcontrol ON
run > nil: SYS:WinUAE/sashimi
run > nil: SYS:WinUAE/wipeout
run > nil: SYS:WinUAE/winuaeenforcer

[Toni Wilen]

Originally Posted by AmigaSurfer

Attached the logs with this beta8.

33-524 [5170 226x312]: 27: 00000005 00000001 0000005e 0000000b 000000ff 0000000b 00000001 00000009, 1022b61c 1022ae1c 1025b000 1022ae00 102da50c 00f0ff60 1022d646 1025af8c
33-524 [5170 226x312]: BlitTemplate() xy(5,1), wh(94,11) draw 0x1 fg 0x0 bg 0xffffff00 
33-524 [5170 226x312]: =00000001
33-524 [5170 226x312]: 28: 00000001 00000001 0000005e 0000000b 000000ff 0000000b 00000001 00000009, 1022b61c 1022ae1c 1025b000 1022ae00 102da50c 1025af88 1022d646 1025af3c
33-524 [5170 226x312]: BlitRectNoMaskComplete() op 0x01, 21000000:(   1,   1) --> 10226bf6:(  94,  11), wh( 255,  11)
33-524 [5170 226x312]: (1x1)=(94x11)=(255x11)=1
33-524 [5170 226x312]: =00000001
33-524 [5170 226x312]: Illegal instruction: 0008 at 00000005 -> 00F80B36

Bolded part "can't" happen. uaegfx.card internally calls "UAE ROM" via register A5 (bolder register) and it is always set to 0xf0ff60 inside uaegfx.card (except in some special cases) which means you have some program that calls this function directly and expect old-style stack frames.

 
run >NIL: SYS:Picasso96/p96_uae_tweak       filesize 11676

Tried without this? Also make sure you don't have another copy of uaegfx.card somewhere.

ADDED: I got p96_uae_tweak sources. It assumes some invalid things, it can't be made compatible with any updated uaegfx.card, p96_uae_tweak has to be updated first. Unfortunately this can't be detected.

Enforcer hits are caused by debugging code I forgot to remove but they are harmless.

[AmigaSurfer]

Originally Posted by Toni Wilen

 
run >NIL: SYS:Picasso96/p96_uae_tweak       filesize 11676

Tried without this? Also make sure you don't have another copy of uaegfx.card somewhere.

ADDED: I got p96_uae_tweak sources. It assumes some invalid things, it can't be made compatible with any updated uaegfx.card, p96_uae_tweak has to be updated first. Unfortunately this can't be detected.

Thanks Toni! That's it!
I dissabled p96_uea_tweak. Now uaegfx.card 1.1 (11.03.2008) works without crashing WinUAE.

Bugs fixed:
- starting with hardware sprite, disable hardware sprite and doing an keyboard reset the hardware sprite is no longer visible.

Bugs not fixed:
- The hardware sprite have still wrong colors in HiRes mode.
- The mouse blanker from MultiCX still doesn't blank the hardware sprite.
- Writing text still clears parts of the pointer which are in the same screenlines than the cursor.

The speed is in high resolutions still in most cases slower than with WinUAE 1.4.6.

 
P96Speed 1.2 - ©`97-99 by Jens Langner
.-----------------------------------------.
| Computer......: UAE/AGA                 |
| CPU...........: 68040/7MHz              |
| OS / WB.......: V45.57/V45.3            |
| SetPatch......: V44.38                  |
| Chip/Fast.....: ~8.0MB/256.0MB          |
| Graphics card.: KEINE GRAFIKKARTE       |
| GFX system....: Picasso96               |
| Resolution....: 1920 x 1200 x 24        |
| Depth/Colors..: 16777215 colors         |
| Testlength....: 13                      |
+-----------------------------------------+
Description...: WinUAE 1.5.0beta8 (12.03.2008)
uaxgfx.card 1.1 (11.03.2008)
Hardware Sprite enabled
No p96_uae_tweak
No p96refresh 60
'-----------------------------------------'
.============= SPEEDRESULTS ==============.
| RectFill()................   2347 op/s  |
| RectFill() Pattern........   1845 op/s  |
| WritePixel().............. 1604018 op/s  |
| WriteChunkyPixels().......   1036 op/s  |
| WritePixelArray8()........   1038 op/s  |
| WritePixelLine8().........  41685 op/s  |
| DrawEllipse().............  29818 op/s  |
| DrawCircle()..............  32363 op/s  |
| Draw()....................    233 op/s  |
| Draw() Hor/Ver............   5929 op/s  |
| ScrollRaster() X..........  47149 op/s  |
| ScrollRaster() Y.......... 226661 op/s  |
| PutText().................  17944 op/s  |
| BlitBitMap()..............   2552 op/s  |
| BlitBitMapRastPort()......   2727 op/s  |
| BitMapScale().............   2015 op/s  |
|--------------- Intuition ---------------|
| OpenWindow()..............    378 op/s  |
| MoveWindow()..............   1083 op/s  |
| SizeWindow()..............    840 op/s  |
| CON-Output................    497 op/s  |
| ScreenToFront()...........     50 op/s  |
`========================================='

[Toni Wilen]

Originally Posted by AmigaSurfer

Thanks Toni! That's it!
I dissabled p96_uea_tweak. Now uaegfx.card 1.1 (11.03.2008) works without crashing WinUAE.

Updated p96_uae_tweak may be included in future uaegfx.card (+ configuration option somewhere), not sure yet.

Bugs not fixed:
- The hardware sprite have still wrong colors in HiRes mode.
- The mouse blanker from MultiCX still doesn't blank the hardware sprite.

These are not emulation problems but Amiga-side software problem (some random patch or rtg.library or something similar)

- Writing text still clears parts of the pointer which are in the same screenlines than the cursor.

Will test..

The speed is in high resolutions still in most cases slower than with WinUAE 1.4.6.

I am trying to find PCs that show this problem but so far I haven't seen similar huge slowdown.

[ziosante]

Benchmark made on laptop computer:
Intel core duo 1.67 Ghz
1 GB RAM DDR2
Intel 945GM graphics chipset

the speed increase with WinUAE 1.5.0b8 is visible but there are some function that are a little faster on WinUAE 1.4.6.
Attached WinUAE config.

[Toni Wilen]

Originally Posted by ziosante

the speed increase with WinUAE 1.5.0b8 is visible but there are some function that are a little faster on WinUAE 1.4.6.

It is very possible "real world" programs run (much) faster even if P96Speed shows lower scores. Bottleneck in emulation is copy from emulated VRAM to real display and P96Speed updates whole screen continuously (emulation needs to copy whole screen every frame). Normally only small part of display gets updated (except games but there is not much point in running Amiga games at 1920x1200..)

Any ideas for "real world" benchmarks?

btw, biggest change from 1.4.6 to 1.5.0 is emulated VRAM access mode. 1.4.6 always used indirect JIT (slow), 1.5.0 enables direct JIT which can increase emulated VRAM access speed by 10x+

Next beta will increase offscreen bitmap write access speed, previously whole VRAM was "watched" for modifications, next beta will only "watch" visible part of VRAM. (P96Speed does not show any difference because it does modify offscreen bitmaps continuously)

[StevenJGore]

Any ideas for "real world" benchmarks?

Run Quake in a uaegfx screenmode, and then run one of the built-in benchmarks?

[Toni Wilen]

Originally Posted by StevenJGore

Run Quake in a uaegfx screenmode, and then run one of the built-in benchmarks?

Quake (and most ported games) only use display as a dumb framebuffer. Not same as real world Amiga applications.

[turrican3]

Any ideas for "real world" benchmarks?
you could try amigod or amigod2 from aminet ?

[Toni Wilen]

http://www.winuae.net/files/b/winuae_1500b8.zip

Beta 8:

NOTE: OGL/D3D filters still using old scaling

- uaegfx.card fallback graphics routines fixed (rarely used drawing modes that native C-code "blitter" does not support)
- print uaegfx.card version to log file
- simple RTG scaling support, do not change resolution but scale to fullscreen if display size configured in display panel is larger than requested Picasso96 resolution. Quality is not good, real filter support later. Perhaps.. Mainly useful with games/demos that use very low resolutions. (configuration enable option not yet added)
- "super skid marks fix" updated, previous "fix" broke all attached AGA-mode sprites
- GUI does not get overdrawn in fullscreen when adjusting filters
- timer calibration removed, uses now performance counters only, also checks periodically if counter frequency changes and adjusts to new rate automatically (possible fix for random power saving slowdown problems)
- fullscreen non-filter mode graphics problems fixed
- vsync is working but it isn't 100% smooth yet (at least on my PC)
- real CD32 rom (391640-03) checksums added to rom scanner
- fixed left and top border RTG hardware cursor graphics problems
- added warning if p96_uae_tweak is detected, it is incompatible with new uaegfx.card (update will be released later)
- filter temporary directdraw surface size restricted to max hardware supported 3D texture size (at least some cards apparently switch to very slow software blitter if size is bigger than max texture size) note that this can restrict scaling range, image simply disappears if scaling multiplier is out of supported range
- "watch" only visible RTG display RAM, should improve performance if program uses multiple temporary offscreen bitmaps
- RTG hardware cursor didn't always get erased properly when cursor shape was changed
- ROM chip part numbers added to rom scanner data, also added to GUI because not all ROMs have confirmed part number yet. "Non-ROMs" not included, like separate CD32 ROMs (real CD32 has single 1M ROM)
- PCMCIA SRAM on the fly insert/removal fix (again)