Kolejna beta WinUAE, emulatora całej rodziny komputerów AMIGA, i bezsprzecznie najbardziej profesjonalnego wśród udawaczy tego sprzętu. Oprócz zwyczajowej już wersji x86, tym razem pojawiła się także wersja dla systemów 64 bitowych.
WinUAE 2.8.0 beta 19 [30/04/14]
- Increased space for UAE boot ROM extension resident module structures, it was too small and overflowed (causing boot crash) if too many UAE resident module expansions were enabled simultaneously.
- Windows specific configuration defaults were not set if config was command line or double click loaded (missed in b17 fix)
- AROS ROM updated.
Winuae 64 bits differences (authors comment):
- No JIT, can support up to 2.5G of Z3 address space (any AOS supported combination of Z3 fast, Z3 chip and RTG total can be 2.5G), possibly slightly faster because x64 has more registers (big and fast L1 caches can hide it).
→ [AMIGA] Winuae 2.8.0 beta 18 RC1
WinUAE 2.8.0 beta 18 [25/04/14]
- 0xFFFF was not returned when reading write-only or non-existing custom register and previous cycle was idle cycle. Not exactly 100% correct but more compatible with programs that accidentally read wrong custom registers.
- Cirrus Logic emulation had some useless logging enabled.
- Added GUI option to enable/disable new automatic programmed mode resolution selection to Display panel, enabled by default. (For example if you want to use superhires all the time and use filter panel to scale the display back to correct aspect ratio)
- Unexpanded A1200 also reads last fetched opcode word when accessing non-existing memory, similar to unexpanded A500. (more compatible and cycle-exact only)
- Last possible displayable line was incorrectly drawn in border color in some situations when short field mode was active.
→ [AMIGA] Winuae 2.8.0 beta 17
WinUAE 2.8.0 beta 17 [24/04/14]
- Debugger breakpoints work again. (b14)
- Full CPUSHA/CPUSHL/CPUSHP disassembly implemented.
- Integer scale mode compatibility improved with programmed display modes.
- Integer scale mode changes Filter panel zoom slider range to -99 to 99 and is used to adjust integer scaling calculation. For example -10 means if next largest scaling factor is selected even if display height is 10% too big to fit normally. (This was implemented already but it didn't work properly)
- Fixed fill_line() top/bottom background line drawing buffer overflow in some programmed modes.
- Some programmed modes had single short background colored line in left horizontal blanking area.
- Command line (or icon doubleclick) loaded config didn't reset previously loaded config (default.uae, if it existed)
- Emulated more Fat Gary address regions that are unmapped (CIA is same as Gayle, upper 32k in clock space and Gary register space are unmapped, 0xdf0000-0xdf7fff is also unmapped)
- Emulate Fat Gary invalid address space access timeout if Gary timeout bit is set, first 50 timeouts are always logged. To prevent last moment stupid bugs or bug reports, delay is not yet enabled
→ [AMIGA] Winuae 2.8.0 beta 16
WinUAE 2.8.0 beta 16 [17/04/14]
- Borderblank blanked sprites incorrectly in some situations (b11, Roots AGA)
- SPRxDATx/SPRxPOS copper write/Denise internal sprite timing should now fully match real hardware.
- Ancient (and recently non-working) Superfrog flashing intro bee hack removed, properly emulated now.
- gfx_filter_keep_autoscale_aspect and gfx_filter_keep_aspect config entry change was not detected when using using uae-configuration.
- Last used AVI codec was not restored from registry if ICGetState() returned zero size data block.
→ [AMIGA] Winuae 2.8.0 beta 15
WinUAE 2.8.0 beta 15 [13/04/14]
- Finally bumped version to 2.8.0. This isn't small 2.7.0 update (Should have been done since b6 or so..)
- FPU register negative zero transformed to positive zero when it was written to or read from memory in extended FP format (FMOVE.X FPx,<ea> or FMOVE.X <ea>,FPx or FMOVEM). No one should care as usual.
- When loading FPU register from memory in extended format, normalize any "unnormal" zero. (non-zero exponent but zero mantissa part). Motorola FPUs do this automatically, x86 FPU does not seem to like them. (Another mostly Next specific update)
- Programmed mode autoresolution should now work with strange modes like highgfx.
- Only allow CPU mode changes between instructions, previously change sometimes happened mid-instruction (during instruction internal memory read/write) which wasn't safe.
- Small tweak to recent sprite update (Hybris)