Difference between revisions of "ZEsarUX:known bugs"

Revision as of 05:02, 22 September 2020

You may want also to check the official ZEsarUX FAQ to see if you have a known issue which has solution (ZX Next is "TBBlue" type of machine).

Github "master" branch at 2020-05-13 21:27CEST:

sprites rendering is at "4B type" level (no anchor/relative sprites or scaling) (5B init is correctly accepted but doesn't render the extra features)
4bpp sprites are not supported
sprites rendering is not one-scanline-buffer delayed and all changes in sprites affect current scanline
Layer 2 displays shadow variant (NextReg $13) when the "shadow" mapping is enabled
Layer 2 extra memory mapping controlled by Layer 2 Access Port ($123B / 4667) works only in core2.x way.
Layer 2 does not support "priority" bit in L2 colors
palette read (NextReg $41 + $44 produces wrong results)
clip windows control $1C has old layout of bits, thus producing incorrect readings
NextRegs $09 reads wrong values (the more "esoteric" ones like expansion bus related are not part of this test/list)
NextReg $09 function bit "Reset divmmc mapram bit (port 0xe3 bit 6)" is not implemented
missing Nextreg $64 "video line offset" (core 3.1.5)
tilemode gfx/map address read (NextReg $6E + $6F) does return original value without top bits set to zero
DMA: too many differences to list, but most crucial: CONTINUE is not supported, slow "burst" functionality is not complete, legacy Z80 mode is not implemented
blending modes are not implemented
ULA scroll is not at new NextReg $26, $27 (but still shared with LoRes offset registers)
ULA+tilemode does not support stencil mode
audio has "clicks" and noise on many platforms, although YMMV
tilemode doesn't wrap in memory the same way as HW (when gfx/map address is toward end of Bank 5)
direct loading of NEX file doesn't init the machine in the same way as NEXLOAD from NextZXOS (it's close, but few things are different)
screen saver of NextZXOS will "crash" the emulated machine (not emulator itself)
modifications to NextRegs done in copper propagate to rendering usually only once per scanline, usually retroactively for full scanline when triggered in h-blank area (palette changes, X/Y offsets, etc)
when running without the full NextZXOS card image, the esxdos services are provided by the emulator itself, which does not implement all of them, and they don't always return the state described by the NextZXOS documentation
missing Nextreg $8F (core 3.1.6)

Official 8.1 release has also these:

registers from core 3.1.1+ onward are not implemented at all
altROM next register does not work correctly and core 3.1.3 does further change it
Layer 2 modes 320x256x8bpp and 640x256x4bpp are not implemented
screen saver of NextZXOS will "crash" the emulated machine (not emulator itself)
monochrome tilemode has wrong colours (and overall attribute usage)

Other Issues (not a bug):

28MHz mode requires quite powerful PC to emulate it smoothly, "lagging" emulator menu/etc is likely to happen in 28MHz mode and unfit for many development purposes.
don't use "--enable-esxdos-handler" option together with running NextZXOS from full MMC card image - it will clash with the MMC functionality

@@ Line 36: / Line 36: @@
 * 28MHz mode requires quite powerful PC to emulate it smoothly, "lagging" emulator menu/etc is likely to happen in 28MHz mode and unfit for many development purposes.
 * don't use "--enable-esxdos-handler" option together with running NextZXOS from full MMC card image - it will clash with the MMC functionality
-----------------
-Personal [https://github.com/ped7g/zesarux/ "ZESERUse" fork (branch "tbblue_small_fixes2")] of Ped7g (ordered by importance "to understand" from Next SW developer point of view and most likely to affect your SW output):
-* modifications to NextRegs done in copper propagate to rendering usually only once per scanline, usually retroactively for full scanline when triggered in h-blank area (palette changes, X/Y offsets, etc) - when compiled with extra flag "-DTBBLUE_DELAYED_COPPER_WAITS" it will delay copper instructions waiting for h-blank till next line (does produce better visual output in some cases, but makes the emulation less accurate in terms of timing)
-* blending modes - only L2+ULA blending (core 3.0 mode), +tiles and new core3.1.3 modes are not implemented
-* ULA+tilemode does not support stencil mode
-* sprites rendering is not one-scanline-buffer delayed and all changes in sprites affect current scanline, calculation of pixel-bandwidth exhaustion is vastly incorrect
-* relative sprites with huge relative offsets in "unified" mode don't wrap-around correctly in large scale situations (like x8 scale with +120 offset, the HW will wrap it somehow all the way around making the child visible somewhere on screen, but in ZESERUse they seem to get completely rejected as offscreen pixels)
-* nextreg $8C "alt ROM" is probably not emulated 100% correctly
-* SRAM region shadowed by BRAM (bank5 + half-bank7) is not emulated
-* CP/M "no files" stub screen can't reach NextZXOS after space (it's doing `nextreg 2,1` in loop, soft-reset implementation seems is incomplete)
-* missing all core 3.1.6 features (the emulator is targetting core3.1.5 state at this moment)
-* tilemode doesn't wrap in memory the same way as HW (when gfx/map address is toward end of Bank 5)
-* audio has "clicks" and noise on many platforms, although YMMV ("--ao pulse" made it better for me)
-* 28MHz mode requires quite powerful PC to emulate it smoothly, "lagging" emulator menu/etc is likely to happen in 28MHz mode - the fork is even more power hungry than official version
-* when running without the full NextZXOS card image, the esxdos services are provided by the emulator itself, which does not implement all of them, and they don't always return the state described by the NextZXOS documentation