Difference between revisions of "ZEsarUX:known bugs"
From SpecNext official Wiki
(fixing FAQ url to go to the main Cesar repository (was some abandoned copy of it)) |
(refreshing info by doing quick test today with current github master) |
||
| Line 1: | Line 1: | ||
You may want also to check the official [https://raw.githubusercontent.com/chernandezba/zesarux/master/src/FAQ ZEsarUX FAQ] to see if you have a known issue which has solution (ZX Next is "TBBlue" type of machine). | You may want also to check the official [https://raw.githubusercontent.com/chernandezba/zesarux/master/src/FAQ 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- | + | Github "master" branch at 2020-10-07 16:00CEST (commit ef4b6d7, version 9.1-SN): |
| − | * | + | * both 4B/5B sprite types are now implemented, but only partially with lot of bugs and incorrect on-screen results |
| − | * 4bpp sprites are | + | * 4bpp sprites are only partially supported (20%) |
* sprites rendering is not one-scanline-buffer delayed and all changes in sprites affect current scanline | * 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 displays shadow variant (NextReg $13) when the "shadow" mapping is enabled | ||
* Layer 2 extra memory mapping controlled by {{PortNo|$123B}} works only in core2.x way. | * Layer 2 extra memory mapping controlled by {{PortNo|$123B}} works only in core2.x way. | ||
* Layer 2 does not support "priority" bit in L2 colors | * Layer 2 does not support "priority" bit in L2 colors | ||
| − | |||
| − | |||
* NextRegs $09 reads wrong values (the more "esoteric" ones like expansion bus related are not part of this test/list) | * 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 | * 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) | * 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 | * 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 | + | * 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, all transfers are "instant" |
* blending modes are not implemented | * blending modes are not implemented | ||
* ULA scroll is not at new NextReg $26, $27 (but still shared with LoRes offset registers) | * ULA scroll is not at new NextReg $26, $27 (but still shared with LoRes offset registers) | ||
| Line 32: | Line 30: | ||
* screen saver of NextZXOS will "crash" the emulated machine (not emulator itself) | * screen saver of NextZXOS will "crash" the emulated machine (not emulator itself) | ||
* monochrome tilemode has wrong colours (and overall attribute usage) | * monochrome tilemode has wrong colours (and overall attribute usage) | ||
| + | * palette read (NextReg $41 + $44 produces wrong results) | ||
| + | * clip windows control $1C has old layout of bits, thus producing incorrect readings | ||
| + | |||
| + | (sorry, no test for official 9.0 release) | ||
Other Issues (not a bug): | 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. | * 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 | * don't use "--enable-esxdos-handler" option together with running NextZXOS from full MMC card image - it will clash with the MMC functionality | ||
Revision as of 16:43, 7 October 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-10-07 16:00CEST (commit ef4b6d7, version 9.1-SN):
- both 4B/5B sprite types are now implemented, but only partially with lot of bugs and incorrect on-screen results
- 4bpp sprites are only partially supported (20%)
- 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
- 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, all transfers are "instant"
- 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)
- palette read (NextReg $41 + $44 produces wrong results)
- clip windows control $1C has old layout of bits, thus producing incorrect readings
(sorry, no test for official 9.0 release)
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