English Amiga Board

English Amiga Board (https://eab.abime.net/index.php)
-   support.WinUAE (https://eab.abime.net/forumdisplay.php?f=5)
-   -   WinUAE 3.0.0 beta series (was 2.8.2/2.9.0) (https://eab.abime.net/showthread.php?t=74263)

Toni Wilen 09 December 2014 08:19

Quote:

Originally Posted by Ami_GFX (Post 990761)
This is interesting. I updated DirectX and it cured the problem of the small screen at boot but it had other effects. I have been testing in three different installations in Vista and Xp. In Vista, I had to tweak things a bit but it is an improvement and I can choose between Direct Draw and Direct 3D. For looking like a real Amiga, I prefer Direct Draw. The scaling in Direct 3D makes for jagged fonts that don't look quite like my real A4000 in an LCD display. In Xp, once I update DirectX, I am forced to use Direct 3D regardless of what the configuration file says. I had to restore the old version of Direct X to be able to use Direct Draw.

Enable bilinear filtering (in Filter panel). D3D has it optional, DD forces it (for some stupid reason). Or use some D3D shader filter.

D3D is the only one available when using RTG hardware emulation, you only got DD accidentally because you didn't have working D3D.

More advanced emulated hardware options: need to use more advanced other options too :)

Quote:

Updating DirectX has had no effect on the black screen in OS4 after launching Imagemaster.
This could be caused by VRAM limit. You probably used higher resolution&color depth vs your real hardware.

Quote:

Originally Posted by Ryrynz (Post 990803)
Not to criticize the dev process at all, but given that this started in July, wouldn't releasing a 2.8.2 version have been a good idea? Maybe 2.8.1 was stable enough?

Yes, that was the original plan but accelerator board, especially PPC support, appeared out of thin air during summer and leaving them half-finished would have not have worked.

2.8.1 didn't have any major bugs fortunately.

Toni Wilen 10 December 2014 14:48

Quote:

Originally Posted by ancalimon (Post 990805)
There might be a problem (read error, checksum error) when writing to high density floppy images (I tried with A4000T HD 3.1 floppies) but I'm not sure if it's related with the betas (I tried it first when ppc support was added) or not. I will test some more and create a new topic if I can reproduce the problem again with an old version.

This might be a bad bug report too :)

Works for me. You did enable HD floppy drive type?

rbm 11 December 2014 19:38

This doesn't have anything to do with the emulator functionality, but the link to the "UAE Home Page" under the About Settings send to a chinese website. If no longer exists should be deleted.

mark_k 12 December 2014 15:48

Quote:

Originally Posted by Toni Wilen (Post 988219)
Beta 25:
- Map Chip RAM mirror at 0x01000000 in A2620/A2630 config, to prevent A26x0 built-in monitor program detecting huge ram expansion at 0x01000000.

Could that be removed now you added 24-bit addressing support for 68030? The user might want to manually add non-AutoConfig memory from 0x01000000 to 0x07FFFFFF, representing a fully-populated DKB 2632 board. Of course if they do that the A2630 monitor will mis-detect a RAM expansion again, unless you feel like adding a special 27-bit addressing setting just for completeness.

Edit: I guess it's not possible to use addmem1/addmem2 to add a 112MB memory region, since the size has to be a power of 2?

Ratte 13 December 2014 21:33

Quote:

Originally Posted by BlackByte (Post 988643)
Hi Toni, the display resolution for OS4.1 WinUAE v2.9.0 b25 can be set higher than 1280x720?
If so, how?

1280x1024 .. using AGA with xtreme driver.
(Yes, HighGFX and other custom modes are working under OS4)

Ratte 13 December 2014 22:03

Quote:

Originally Posted by Toni Wilen (Post 982777)
Yes but uaegfx can be easily modified to also support alternative "hardware API", because it is mostly hardware emulation only, just poke parameters to some reserved memory, write command id to some address, just like real blitter-like hardware works.

I think it is not only a uaegfx.card problem!
This memory-area ($00F0.0000 - $00F7.FFFF) could be r/w-protected by os4 (Just like most other memareas).
Accessing any memory outside the os4-mempool is a problem.
I think someone from the os4-developers has to write a certified driver .. or better called config-structure .. that will enable access to the needed memory areas.
With such a granted access the old driver should work out of the box.
Code:

...
...
***********************************************************
SetPanning:
* set view origin for overscan displays
***********************************************************
* a0:    struct BoardInfo
* a1:    UBYTE *Memory
* d0:    UWORD Width
* d1:    WORD XOffset
* d2:    WORD YOffset
* d7:    RGBFTYPE RGBFormat
***********************************************************
    move.w    d1,(gbi_XOffset,a0)
    move.w    d2,(gbi_YOffset,a0)
    move.l    a1,d4
    sub.l    (gbi_MemoryBase,a0),d4
    ; UAECALL    #22
        movem.l    d2-d7/a2-a6,-(sp)
        movea.l    d3,a5
        moveq    #22,d3            ; #22
        movem.l    d3,-(sp)
        move.l    a5,d3
        movea.l    #$F0FF60,a5
        jsr    (a5)
        movem.l    (sp)+,d2
        movem.l    (sp)+,d2-d7/a2-a6
    rts
...
...


Toni Wilen 14 December 2014 08:38

Quote:

Originally Posted by Ratte (Post 991642)
I think it is not only a uaegfx.card problem!
This memory-area ($00F0.0000 - $00F7.FFFF) could be r/w-protected by os4 (Just like most other memareas).

I never said that it would have to use that region. It can be normal Z2 (or even Z3) autoconfig board.

Quote:

With such a granted access the old driver should work out of the box.
No, 100% impossible. This was already discussed (possibly in some other thread): It can only work if UAE m68k emulator runs this code. It does the internal "task switching" from uae side to native, it has special case for those weird traps and so on.

Other m68k emulator would only see normal trap instruction and emulate (or possibly decide that running program is broken) and jump to default OS trap handler. The end.

It needs complete rewrite.

Toni Wilen 14 December 2014 08:54

Quote:

Originally Posted by rbm (Post 991346)
This doesn't have anything to do with the emulator functionality, but the link to the "UAE Home Page" under the About Settings send to a chinese website. If no longer exists should be deleted.

Thanks. Removed, I forgot to remove it from About when it was removed from web site.

Quote:

Originally Posted by mark_k (Post 991454)
Could that be removed now you added 24-bit addressing support for 68030?

Done.

Quote:

Edit: I guess it's not possible to use addmem1/addmem2 to add a 112MB memory region, since the size has to be a power of 2?
Only JIT hates non-power of 2 memory regions. Only requirement is 64k alignment.

Toni Wilen 14 December 2014 17:39

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

Beta 28: (RC3. Next should be final because this has enough last minute changes!)

- qemu-uae.dll updated to final 2.2.0 QEMU release. (No PPC changes)
- Removed A26x0 chip ram mirror hack (b25), not needed anymore.
- Copper WAIT with BFD=0 (wait for blitter enabled) sequence was incorrect, copper first waits for blitter, then it goes to normal WAIT state. Previously WAIT state check was done first, then blitter wait. It is not same because copper requires idle cycle when WAIT ends and it should be after blitter has finished, not before. (Last minute change 1)
- Second last minute change: last line sprite DMA logic behavior difference between A1000 Agnus and Fat revisions. Sprite glitches are different in Skitro by Awesome/D-Tect/Vanish when run on A1000 vs OCS A500. Also fixes missing yellow glitches in same demo.
- b23 "Fixed missing graphics in Disposable Hero title screen in non-cycle exact modes." broke (again) demo Back in 90 / Samplers. Added quick workaround: only do "Disposable Hero" fix if CPU is 68020+ (=works in most whdload configurations without glitches).

thellier 15 December 2014 11:20

Hello

[ About 68k to native interface that use 68k traps so dont works in Petunia/PPC so no uaegfx driver in OS4 ]
>It needs complete rewrite.
Is it planned ? Will it be in "final" release ?
Certainly uaegfx is the "most wanted feature" now :-)

Alain Thellier

mark_k 15 December 2014 13:41

Quote:

Originally Posted by Toni Wilen (Post 991699)
Only JIT hates non-power of 2 memory regions. Only requirement is 64k alignment.

Ah, maybe I should have actually tried it before posting...

A test config with 112MB seems to work fine, the 2632 program detects and adds the memory.

Regarding JIT... I tried setting the addmem1 region size to 128MB, in the hope that after booting the OS (so 2630 boot ROM not in use) I could enable JIT. But that didn't work sadly.


All times are GMT +2. The time now is 03:45.

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.

Page generated in 0.10192 seconds with 10 queries