Difference between revisions of "ZEsarUX:known bugs"
From SpecNext official Wiki
(known bugs of ZEsarUX emulator (initial list, probably missing few)) |
|||
| Line 15: | Line 15: | ||
* 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) | * 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) | * screen saver of NextZXOS will "crash" the emulated machine (not emulator itself) | ||
| + | * 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 | ||
---------------- | ---------------- | ||
| Line 26: | Line 27: | ||
* sprites rendering is not one-scanline-buffer delayed and all changes in sprites affect current scanline, calculation of pixel-bandwidth exhaustion is vastly incorrect | * sprites rendering is not one-scanline-buffer delayed and all changes in sprites affect current scanline, calculation of pixel-bandwidth exhaustion is vastly incorrect | ||
* screen saver of NextZXOS will "crash" the emulated machine (not emulator itself) | * screen saver of NextZXOS will "crash" the emulated machine (not emulator itself) | ||
| + | * 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 | ||
Revision as of 07:11, 7 March 2020
Official ZEsarUX 8.1:
- 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
- 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)
- palette read (NextReg $41 + $44 produces wrong results)
- 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)
- audio has "clicks" and noise on many platforms, although YMMV
- 28MHz mode requires quite powerful PC to emulate it smoothly, "lagging" emulator menu/etc is likely to happen in 28MHz mode.
- monochrome tilemode has not fully correct colours handling
- 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)
- 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
Personal "ZESERUse" fork of Ped7g:
- 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)
- altROM/global memory map not updated to core 3.1.0 changes
- audio has "clicks" and noise on many platforms, although YMMV
- 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
- blending modes are temporarily not working (implemented in older versions, but broken in latest)
- sprites rendering is not one-scanline-buffer delayed and all changes in sprites affect current scanline, calculation of pixel-bandwidth exhaustion is vastly incorrect
- screen saver of NextZXOS will "crash" the emulated machine (not emulator itself)
- 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