After writing this weekends commentary this little nugget of news slipped my clutches until discovered that a new beta version of WinUAE had been released over the weekend.
If you’re not already aware (and shame on you if you’re not!) WinUAE is currently the best Amiga emulation available outside of Cloanto’s Amiga Forever, and which I have to admit both get frequently used for various tasks. Link provided below to get you’re updated fix along with latest version changes:
Previous discussion: http://eab.abime.net/showthread.php?t=88777&page=8
Implemented lagless vsync mode (https://www.blurbusters.com/blur-bus…or-developers/)
Replaces old low latency vsync mode.
What does it do? It reduces input latency from usual 20ms-40ms+ to less than 5ms! (or even less)
– Does not support black frame insertion or frame doubling = use only standard 50Hz or 60Hz modes. (or up to 85Hz or so )
– Native mode only. Cycle-exact/approximate/fastest possible/JIT supported.
– Direct3D 9 and 11 only.
– Fullscreen only.
– Amiga display to monitor position mapping must be border to border vertically (or close enough) or you may see tearing lines.
– Does not gain anything from G-Sync.
– Input is read after each slice.
– Default is 4 slices (adjustable in GUI) which makes max input latency about 6ms. (Assuming quality “gaming grade” USB input devices that use <=1ms USB rate.)
– Because output is shader based, outputting each slice requires full render pass each time. It technically means same as rendering screen 4 times the frame rate. (for example 50Hz output requires rendering 200 frames) -> don’t enable any extra shaders unless you have powerful GPU. Most likely requires GPU with on-board RAM (discrete GPU) because this mode increases VRAM bandwidth requirements heavily. Or reduce resolution.
– END+F9 toggles debug colors when in low latency vsync mode (In normal modes END+F9 changes screens). When debug colors are disabled, useless screen clearing before each slice rendering is also disabled.
Multi virtual Amiga monitor support:
Enables multiple virtual Amiga monitors. Amiga monitor = single WinUAE window.
Default mode is unchanged, highest priority Amiga display output appear in single WinUAE window, switches automatically or manually (END+F9).
Optionally any video port display adapter or any RTG board can be disconnected from default monitor and connected to other monitor. (Monitor 1 to 4 select box in GUI, 1 = default). Only one signal source can be connected to non-default monitors. Only default monitor support on the fly switching/END+F9 manual switching.
Native (chipset) video output is always connected to first (default) monitor.
Each active monitor (WinUAE window) content is refreshed in real-time.
For example x86 VGA can be now visible at the same time with WB.
Limitations and other information:
– Windowed mode only (later full-window with single virtual monitor to physical monitor mapping)
– Fullscreen is not supported and won’t be supported.
– Direct 3D 9/11 mode only. DirectDraw won’t be supported.
– GUI options adjusts all monitors. If native/video port: native filter and all other native related settings are in use for all windows in native/video port mode, if RTG: GUI RTG settings are used for all monitors in RTG mode.
– Non-default monitors are always opened next to default monitor. Positions are not stored.
– It does not matter which window has focus/captured mouse. All windows listen for input normally.
– Non-default windows don’t have status bar or OSD and only have name of monitor in title bar.
– Video port device’s window opens immediately at startup, RTG board’s window open when board’s output is enabled with valid display configuration for the first time.
New debugger features:
Minimal Macrosystem Casablanca “emulation”
Supports Casablanca ROM images, none of Casablanca special IO address spaces supported. It is has very unknown custom hardware.
If you want to help with debugging/reverse-engineering Casablanca internals using emulation:
– Set correct ROM, either original 2x512k 1:1 ROM images (ROM scanner supported) or 1x1024M manually merged and byteswapped. (Don’t ask me, they contain KS modules, in scrambled format.) If rom starts with “00 00 00 00 00 00 00 18 44 52 42 52 00 01 00 06 ……..DRBR….” = correct merged and byteswapped image.
– CPU must be set to 68060 (MMU bus error handler assumes PC always points to faulting instruction, 68040 documentation says it isn’t guaranteed)
– MMU emulation must be enabled.
– Chipset extra must be set to Casablanca.
– Other chipset options don’t matter.
– RAM must be set manually: Select Z3 Fast #1, set size (32M/64M), tick “Manual configuration”, set Address range start = 40000000. (End address is set automatically). Casablanca RAM uses Z3 space but does not use autoconfig.
– Log window should be enabled.
It “works” if you see lots of casablanca io access log messages, including MMU enable message. (MMU: TC=109dc enabled=0 page8k=0 PC=00000106). Finally it gets in infinite loop with exec partially initialized.
Because ROM is descrambled and copied to RAM by boot code and MMU is used to remap it to usual $f80000 region, also “zero page” is remapped, you need to enable UAE debugger mmu mapping support (for example “mmu 1” = use current MMU tables to translate user space addresses, 5 = super space) or you most likely get random garbage when using debugger commands.
– Directory harddrives now use uaehf.device as a fake device driver (instead of non-existing uae.device), SysInfo does not anymore crash in Drives page when selecting directory harddrive. (SysInfo bug: it does not check for device driver open failure) HD_SCSICMD is also partially supported in this situation, mainly identification commands that don’t access the drive, like READ CAPACITY and INQUIRY. Unsupported commands return Incompatible Medium Installed ($05/$30 00) error.
– Partition hardfiles also support above HD_SCSICMD SCSI commands.
– Don’t show loaded config file “.uae” extension in GUI title.
– GUI title didn’t show loaded config file if it was loaded from command line or via doubleclicking config file.
– MSVC code analyzer warnings fixed (uninitialized variables, buffer size checks).
– ROM is slow -option only changed $e0-$e8 ROM space timing (wrong end address)
– Toccata recording used wrong interrupt bit.
– Fixed WD33C93 based SCSI controller and no SCSI devices: boot hang (3.6.1)
– If CD was changed and system was reset during change delay, drive become empty and new CD was never inserted.
– DKB RapidFire and SpitFire use same boot rom. Renamed to RapidFire/SpitFire. Only difference seems to be RAM expansion.
– Added Xetec FastTrak, CSA Magnum 40, GVP A1230 Series II, Hardital TQM and MacroSystem Falcon 040 (without SCSI).
– Real harddrive imager attempts to automatically temporarily dismount source drive first.
– Directory filesystem harddrive block size is dynamic adjustment now starts from smaller disk size to also fix WB free space calculation overflow.
– Disk swapper config file data is restored from statefile.
– If memwatch point is watching for blitter accesses, blitter registers at start of blit and current register are output when breakpoint is hit.
– 5380 based SCSI controller, byte wide fake DMA, uses MOVEP.L.
– “bootdisk.device” “bootdisk 1.42 (22 Mar 1990)” “Xetec FastTrak Autoboot”
CSA Magnum 40:
– A2000 68040 accelerator.
– 53C710 based SCSI, true DMA.
– ROM is loader only, SCSI driver is installed to RDB LSEG blocks by the installer.
GVP A1230 Series II:
– A1200 68030 accelerator.
– Usual GVP WD33C93 + 24-bit GVP DMA chip combination, with 2 extra external DMA bits to support up to 32M of RAM.
– ROM v5.0 gvpscsi.device.
– Clock not emulated. (DS1994 1-wire clock)
– A1200 68030 accelerator.
– ROM only adds RAM to system.
– Possibly clone of DKB 1230. Nearly identical ROM contents with “DKB1230” string in “hidden” nybble based data!
MacroSystem Falcon 040
– A1200 68040 accelerator.
– Only non-SCSI boot ROM currently available, adds only RAM to system. Uses MOVEP, not 68060 compatible. (SCSI boot ROM wanted!)