Difference between revisions of "CSpect:known bugs"
From SpecNext official Wiki
(adding Layer2 and streaming API bugs discovered by playflx, rewording some older bugs) |
(V2.15.02 refresh) |
||
Line 1: | Line 1: | ||
− | CSpect V2.15. | + | CSpect V2.15.02 |
* sprites: the collision bit is not implemented (intentional for performance reasons) | * sprites: the collision bit is not implemented (intentional for performance reasons) | ||
* sprites rendering is not one-scanline-buffer delayed and all changes in sprites affect current scanline (intentional for performance reasons) | * sprites rendering is not one-scanline-buffer delayed and all changes in sprites affect current scanline (intentional for performance reasons) | ||
− | * ( | + | * (changed a bit in 2.15.02) modifications to NextRegs done in copper propagate to rendering usually only once per scanline, the state for rendering is sampled around <del>end of right border area before h-blank area</del> after h-blank area or in left-border, affecting previous line instead of next (palette changes, X/Y offsets, etc) (intentional for performance reasons) |
* modifications to NextRegs done by CPU propagate to rendering usually only once per scanline, usually retroactively for whole current scanline (mostly intentional for performance reasons) | * modifications to NextRegs done by CPU propagate to rendering usually only once per scanline, usually retroactively for whole current scanline (mostly intentional for performance reasons) | ||
− | + | * blending modes: quite wrong (worse than 2.14.08), but the test is not comprehensive (HW core 3.1.5 now blends Layer2+ULA in different way ([https://github.com/MrKWatkins/ZXSpectrumNextTests/issues/8 details])) | |
− | * blending modes: | ||
* sprites: 4bit relative patterns are incorrect in complex cases | * sprites: 4bit relative patterns are incorrect in complex cases | ||
* DMA: reading-registers are a bit off (for example status bit5+0 not reset correctly after LOAD, probably few more (but core 3.1.5 also reads bit0 wrongly, so always test own code with all target platforms)) | * DMA: reading-registers are a bit off (for example status bit5+0 not reset correctly after LOAD, probably few more (but core 3.1.5 also reads bit0 wrongly, so always test own code with all target platforms)) | ||
* DMA: Zilog mode is not implemented (port 0x0B) | * DMA: Zilog mode is not implemented (port 0x0B) | ||
* NextZXOS streaming API doesn't work (the initialization of stream fails - rst 8 service 0x86 ; DISK_STRMSTART) | * NextZXOS streaming API doesn't work (the initialization of stream fails - rst 8 service 0x86 ; DISK_STRMSTART) | ||
− | * NextReg $02 | + | * there's still something not completely right about Enhanced ULA colours, maybe just default values are wrong, or even something is emulated wrongly? (test TFalBUla.sna) |
+ | * di : halt doesn't put CPU in infinite loop waiting for NMI, but proceeds further | ||
+ | * NextReg $02 implementation of soft/hard-reset does something, but not the same thing like HW yet (stuck in ROM03 infinite loop) | ||
* sprites: the wrap-around the 512x512 coordinate space is only partially implemented in extreme cases (relative sprite so far from anchor that x8 scale wraps it back onto screen) | * sprites: the wrap-around the 512x512 coordinate space is only partially implemented in extreme cases (relative sprite so far from anchor that x8 scale wraps it back onto screen) | ||
− | |||
* default value: $6E and $6F are supposed to be fixed since V2.12.30, but the SNA test still reads zeroes | * default value: $6E and $6F are supposed to be fixed since V2.12.30, but the SNA test still reads zeroes | ||
* some NextRegs read as zero until they are written into first (quick-boot mode with SNA file without full NextZXOS image) (for example regs $03, $12, $13, $14, $42, $4A, $4B, $4C) | * some NextRegs read as zero until they are written into first (quick-boot mode with SNA file without full NextZXOS image) (for example regs $03, $12, $13, $14, $42, $4A, $4B, $4C) | ||
− | * NextRegs $09, $34, $41, $8E read incorrectly (reads after certain writes produce wrong value) | + | * NextRegs $09, $34, $41, $8E read incorrectly (reads after certain writes produce wrong value) (but also the test is checking 3.1.5 behaviour, needs update to 3.1.10) |
+ | * Copper disassembler plugin does not open under ctrl+alt+c | ||
+ | * the initial file-import sequence of CP/M BIOS fails. (get cpm-a.p3d file from somebody with a working clean CP/M installation and copy that into c:/NextZXOS, or use other emulator to create the file) | ||
+ | * Z80: block of prefixes/instructions 0xDD/0xFD/EI does not inhibit masked interrupts | ||
− | not verified in V2.15. | + | not verified in V2.15.02 (but known bugs of older versions, may be still present): |
− | * without the full NextZXOS card image the esxdos services are provided by open source [https://github.com/mikedailly/CSpect CSpect plugin], the implementation is limited and crude - some of the returned values are incorrect/etc, but loading files works. | + | * default ULA palette after power on (quick boot without NextZXOS) is slightly different |
− | + | * (should be improved now, to be tested) without the full NextZXOS card image the esxdos services are provided by open source [https://github.com/mikedailly/CSpect CSpect plugin], the implementation is limited and crude - some of the returned values are incorrect/etc, but loading files works. | |
* direct loading of NEX files does not support all combinations of loading-screen type and palette on/off (but V2.12.9 does load more files than V2.12.5, all common ones should work) | * direct loading of NEX files does not support all combinations of loading-screen type and palette on/off (but V2.12.9 does load more files than V2.12.5, all common ones should work) | ||
* sprites: something something about default clipping... just set clip windows explicitly in your SW. | * sprites: something something about default clipping... just set clip windows explicitly in your SW. |
Revision as of 13:49, 31 March 2022
CSpect V2.15.02
- sprites: the collision bit is not implemented (intentional for performance reasons)
- sprites rendering is not one-scanline-buffer delayed and all changes in sprites affect current scanline (intentional for performance reasons)
- (changed a bit in 2.15.02) modifications to NextRegs done in copper propagate to rendering usually only once per scanline, the state for rendering is sampled around
end of right border area before h-blank areaafter h-blank area or in left-border, affecting previous line instead of next (palette changes, X/Y offsets, etc) (intentional for performance reasons) - modifications to NextRegs done by CPU propagate to rendering usually only once per scanline, usually retroactively for whole current scanline (mostly intentional for performance reasons)
- blending modes: quite wrong (worse than 2.14.08), but the test is not comprehensive (HW core 3.1.5 now blends Layer2+ULA in different way (details))
- sprites: 4bit relative patterns are incorrect in complex cases
- DMA: reading-registers are a bit off (for example status bit5+0 not reset correctly after LOAD, probably few more (but core 3.1.5 also reads bit0 wrongly, so always test own code with all target platforms))
- DMA: Zilog mode is not implemented (port 0x0B)
- NextZXOS streaming API doesn't work (the initialization of stream fails - rst 8 service 0x86 ; DISK_STRMSTART)
- there's still something not completely right about Enhanced ULA colours, maybe just default values are wrong, or even something is emulated wrongly? (test TFalBUla.sna)
- di : halt doesn't put CPU in infinite loop waiting for NMI, but proceeds further
- NextReg $02 implementation of soft/hard-reset does something, but not the same thing like HW yet (stuck in ROM03 infinite loop)
- sprites: the wrap-around the 512x512 coordinate space is only partially implemented in extreme cases (relative sprite so far from anchor that x8 scale wraps it back onto screen)
- default value: $6E and $6F are supposed to be fixed since V2.12.30, but the SNA test still reads zeroes
- some NextRegs read as zero until they are written into first (quick-boot mode with SNA file without full NextZXOS image) (for example regs $03, $12, $13, $14, $42, $4A, $4B, $4C)
- NextRegs $09, $34, $41, $8E read incorrectly (reads after certain writes produce wrong value) (but also the test is checking 3.1.5 behaviour, needs update to 3.1.10)
- Copper disassembler plugin does not open under ctrl+alt+c
- the initial file-import sequence of CP/M BIOS fails. (get cpm-a.p3d file from somebody with a working clean CP/M installation and copy that into c:/NextZXOS, or use other emulator to create the file)
- Z80: block of prefixes/instructions 0xDD/0xFD/EI does not inhibit masked interrupts
not verified in V2.15.02 (but known bugs of older versions, may be still present):
- default ULA palette after power on (quick boot without NextZXOS) is slightly different
- (should be improved now, to be tested) without the full NextZXOS card image the esxdos services are provided by open source CSpect plugin, the implementation is limited and crude - some of the returned values are incorrect/etc, but loading files works.
- direct loading of NEX files does not support all combinations of loading-screen type and palette on/off (but V2.12.9 does load more files than V2.12.5, all common ones should work)
- sprites: something something about default clipping... just set clip windows explicitly in your SW.
Platform Specific
- Mac: Mouse does not work / behaves erratically
- Mac: after launch keyboard being irresponsive - try "alt+tab" to other app and back
- Linux: the copper disassembly window added in 2.15.01 (ctrl+alt+c) does not draw its content and remains as empty frame (after debugging the plugin: the winform doesn't receive paint messages from the emulator, same winform code running as stand-alone app without emulator does draw in linux)