WinUAE 4.1.0 beta series

[mark_k]

Originally Posted by Toni Wilen

Anyway, I'll add workaround because this kind of config that can't exist in real world is mostly useless in this case: if no MMU emulation enabled and data cache emulation is enabled, chip ram is always forced not data cacheable.

Don't most real accelerator boards disable data cache in hardware for chip RAM accesses? I think my GVP 68030 board does.

[Toni Wilen]

Originally Posted by mark_k

Don't most real accelerator boards disable data cache in hardware for chip RAM accesses? I think my GVP 68030 board does.

External cache inhibit pin only inhibits memory reads (only if address is not already cached) from being cached. CPU writes always goes to cache if enabled. MMU based cache inhibit method inhibits both.

It does not cause problems with 68030 because it does not have copyback mode.

[Toni Wilen]

http://www.winuae.net/files/b/winuae_4100b7.7z
http://www.winuae.net/files/b/winuae64_4100b7.7z

Beta 7:

- If disk image's track size is less than 66% of nominal 2us track, assume it is using 4us (GCR) bit rate.
- Added option that catches JIT crashes that happen when already translated code jumps to non-existing memory causing interpretetive emulation to access non-existing RAM (for example JSR (An) was already translated but due to program bug, later call contains garbage in An) Logs a message and then generates fake exception 2 (if PC was even) or 3 (if PC was odd). This is not fully safe option because it is practically impossible (without slowing down JIT which would be against the point of JIT) to detect if crash is due to bad CPU PC or address registers or due to real bug causing access fault that now gets catched and not causing crash..
- Recording from hardware emulated RTG board always recorded internal resolution.
- Emulated undocumented AGA 64 pixel wide sprite feature: if sprite FMODE is lowered when sprite's first 32 pixels are being drawn, matching part in last 32 pixels will get zeroed.
- AGA sprite's width is decided and stored when SPRxDATx is written to, if sprite FMODE is changed after SPRxDATx write, sprite width won't change on screen except in above 64 pixel wide special case. (Previously used current FMODE value)
- Added vertical offset option to D3D scanlines.
- 68030 MMU rejected PTEST/PMOVE with EA mode 6 and generated F-line exception.
- 68030 MMU PTEST levels 1-7 does not check TTRs.
- If 68030/040/060 config has data cache emulation enabled but MMU emulation is not enabled: force chip ram as non-data cacheable.
- Magic mouse uncapture (uncapture when moving against window edges) now only uncaptures if no buttons are pressed.

[Saghalie]

[QUOTE=Toni Wilen;1274550]http://www.winuae.net/files/b/winuae_4100b7.7z
http://www.winuae.net/files/b/winuae64_4100b7.7z

Trojan:Script/Foretype.A!ml

Windows Defender found that threat in your above downloads.
Is this a result of compilation features? There is something that
causes this threat when a certain feature is used via the
compiler, I can't remember exactly what that feature is though.

[Toni Wilen]

I stopped bothering with those false positives because there is always at least one during each beta series..

[AMIGASYSTEM]

Originally Posted by Saghalie

Trojan:Script/Foretype.A!ml.

Never found an infection, you've checked if your system has any small infections? try to do a short scan with ADWCleaner

[Rotareneg]

VirusTotal results (all clean of course) for both archives:

https://www.virustotal.com/#/file/b7...1bc5/detection

https://www.virustotal.com/#/file/07...5892/detection

And yes, Windows Defender with the 1.277.717.0 threat definition file (current as of this post) does give a false positive for Trojan:Script/Foretype.A!ml for both files as previously mentioned.

*update* And now the false positive is gone with 1.277.719.0.

[ross]

Hi Toni, subpixel emulation doesn't open right border.

Total senseless and messy exe attached.
Quickstart A1200 (but everything 020+/AGA is good).
Left/right mouse button change BPLCON1.

[Toni Wilen]

Originally Posted by ross

Hi Toni, subpixel emulation doesn't open right border.

Total senseless and messy exe attached.
Quickstart A1200 (but everything 020+/AGA is good).
Left/right mouse button change BPLCON1.

Fixed. End of line final buffer flush was not large enough in all situations.

[ross]

Originally Posted by Toni Wilen

Fixed. End of line final buffer flush was not large enough in all situations.

[ross]

Sorry Toni, another strangeness, only in very last winuae.7z.

This time from an extreme overscan, but valid PAL hi-res WB config. (in fact I use this and noticed there).
I replicated the same DDF and DIW (border closed) in my stoopid test exe.
Quickstart A1200, left/right mouse change BPLCON1.

Last column in the far right is 'weird' with subpixel emul. active.

[Toni Wilen]

It probably was already fixed when you posted it (EDIT: Possibly only 10 minutes before you posted it..)

[ross]

ahah great, just tested it

EDIT: Toni's crystal ball improves day to day

[Toni Wilen]

http://www.winuae.net/files/b/winuae_4100b8.7z
http://www.winuae.net/files/b/winuae64_4100b8.7z

Beta 8:

- Another undocumented AGA 32 (only if FMODE bit 3 is set) and 64 pixel wide sprite feature emulated: when writing to SPRxDATx, first 16 pixels of sprite equals previous data in chip bus. Remaining 16 pixel "parts" contain written data duplicated. Unless SPRxDATx write is immediately after bitplane DMA fetch, then first 32 pixels of sprite gets replaced with previously fetched bitplane data, last 32 pixels are duplicated SPRxDATx written value. If normal 32 pixel wide mode (FMODE bit 2 set): both first and last 16 pixels contain written data.
- Subpixel mode didn't always flush all buffered pixels at the end of scanline.
- When DIWSTRT or DIWSTOP is accessed neither old or new value can match comparisons during the access cycle. (Fixes Bograts and Penguins small graphics glitch in top left corner)
- Very large directory filesystem harddrives (>3T or so) returned halved disk used and free values.
- 68030 MMU data fault handling update: SSW register FC mode bits must be used for data access retry cycle. Exception handler may have modified it. (So far only one program does it, Memwatch debugging tool for Atari ST and later models..)
- In some situations 68030 MMU access fault size stored to stack frame was byte even when actual fault size was word or long size.
- 68030 MMU mode FPU FRESTORE didn't handle possible access fault retries when reading stack frame.
- Above MMU updates break Amix boot, this gets fixed in next beta because I couldn't find the problem quickly enough and there must be better test cases than Amix..

[TEOL]

Keep up the good work Toni & Frode. I understand why you deleted my post but it was an itch we needed to scratch in 64-Bit emulation kinda thing. Did not mean a thing in that post guys.

[Toni Wilen]

http://www.winuae.net/files/b/winuae_4100b9.7z
http://www.winuae.net/files/b/winuae64_4100b9.7z

Beta 9:

- UNPK and PACK instructions (very rarely used) had code like "v = read_from_address(x) + read_from_address(y)" which has undefined function call execution order in C.
- 68030 MMU MOVEM to memory access fault retry special case fixed (b8). Amix boots normally again.
- 68030 MMU unaligned data access retries always used aligned access. (b8)
- AGA 32/64-pixel FMODE BPLxDAT writes are also now emulated accurately. Behavior is same as sprites, FMODE=3: first 16 pixels are last bus data, remaining 48 pixels are duplicate of written data. FMODE=2: first 16 pixels bus data, last 16 pixels written data. FMODE=1: written data duplicated. (Last bus data is first word of copper MOVE to BPLxDAT if copper was used to write to BPLxDAT). Writing to BPLxDAT when FMODE=3 and then lowering FMODE disables last 32 pixels (like sprites do) but this is not yet emulated.
- Yet another undocumented AGA bitplane special case. When FMODE=1/2 and modulo is added, bit 1 carry is ignored, for example 0x102 + 0x12 = 0x110. FMODE=3: same except bit 2 carry is ignored. This can only happen if bitplane pointer and/or modulo is "unaligned", not integer divisible by fetch size. Quite useless feature because unaligned bitplane pointers will always result in corrupted display. But at least (corrupted) display is now 100% accurate.
- Debugger memwatch points detected also debugger read or write accesses.
- Multi Evolution v2.2 ROM added. Does not seem to be RDB compatible, probably only v3.0+ are RDB compatible.

68030 MMU is still reported as having problems in some Next OS versions (Previous emulator) but I can't duplicate any problems with my usual test images (not even Amix). Please test any existing Linux/NetBSD etc.. in 68030 mode and report any differences between this beta and last official version.

[DamienD]

Originally Posted by TEOL

Keep up the good work Toni & Frode. I understand why you deleted my post but it was an itch we needed to scratch in 64-Bit emulation kinda thing. Did not mean a thing in that post guys.

I'm not surprised Toni deleted your post

I can still read it though... so yeah; not everyone gives a toss about "Vampire" stuff; plus it makes absolutely no sense what-so-ever to be implemented in emulation...

Read this thread if you're still unsure as to why: Vampire emulation in WinUAE

[malko]

As a side note (other thread is closed), I like meynaf's idea

Originally Posted by meynaf

[...] We could grumble all day but -- why not doing it better ourselves ?
Criticism is easy but actually doing it is something else.
We could form a task force and design what we want.
Then it would be implemented in Winuae and perhaps in other Uae as well.
There are more Uaes out there than there are nightstalkers so it could become a new standard, like 68020+. And a well designed one.
That would put some pressure on that undead designer to follow.
Why not ?

end of side note

[Windfisch]

First of all, great work! The bridgeboard emulation now seems to run much better with PCem as its core, albeit the graphics output is much slower, but I reckon this was the case with the real bridgeboards, too.

However, I am having some issues with djmount.

When I configure the A2286 with standard AT IDE and use ADISK to create an Amiga partition on the virtual hard drive, djmount correctly detects it and I can use it.

When I configure an A2088XT at C000 with XT-IDE at EC00, XT-IDE and the Janus integration work, however when DOS is booted and I am using djmount, I get a division by zero error on the PC side and djmount hangs.

Also, CGA display is still corrupted. To reproduce, configure an A2088XT with Color video output, and open QBASIC on MS-DOS 5.0+, and execute the following program:

SCREEN 1
CIRCLE (159, 99), 50, 1

I expect a circle to appear, but all I get is a distorted display.

Is this already known?

[Toni Wilen]

Originally Posted by Windfisch

First of all, great work! The bridgeboard emulation now seems to run much better with PCem as its core, albeit the graphics output is much slower, but I reckon this was the case with the real bridgeboards, too.

However, I am having some issues with djmount.

When I configure the A2286 with standard AT IDE and use ADISK to create an Amiga partition on the virtual hard drive, djmount correctly detects it and I can use it.

When I configure an A2088XT at C000 with XT-IDE at EC00, XT-IDE and the Janus integration work, however when DOS is booted and I am using djmount, I get a division by zero error on the PC side and djmount hangs.

Also, CGA display is still corrupted. To reproduce, configure an A2088XT with Color video output, and open QBASIC on MS-DOS 5.0+, and execute the following program:

SCREEN 1
CIRCLE (159, 99), 50, 1

I expect a circle to appear, but all I get is a distorted display.

As usual, this needs real hardware confirmation. Nothing can be assumed when using bridgeboards.. Also XT-IDE + Janus harddrive is known to work strangely, at least with older bridgeboard versions.