Difference between revisions of "ZESERUse:known bugs"

Revision as of 23:21, 28 November 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).

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 - the fork is even more power hungry than vanilla ZEsarUX version
don't use "--enable-esxdos-handler" option together with running NextZXOS from full MMC card image - it will clash with the MMC functionality

Known bugs (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
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)
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

I'm building it in linux with this configuration (running the command in bash shell inside the src folder to launch configure script):

CFLAGS='-O2 -DTBBLUE_DELAYED_COPPER_WAITS' LDFLAGS=-O2 ./configure --disable-stdout --disable-simpletext --disable-curses --disable-aa --disable-caca --prefix ~/.local --disable-alsa --disable-dsp --disable-coreaudio --disable-cocoa --disable-cursesw

And I'm launching the emulator usually through helper scripts reconfiguring it to tbblue machine (not using config file), my helper scripts are available at ZXSpectrumNextTests/Tools, check "runzeseruse" and "mmczeseruse" (edit the file paths to use them at your own PC).

@@ Line 10: / Line 10: @@
 * 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) (should be fixed in latest commits, but I didn't re-test it thoroughly yet)
 * nextreg $8C "alt ROM" is probably not emulated 100% correctly
 * SRAM region shadowed by BRAM (bank5 + half-bank7) is not emulated