Edit: Fixed a minor issue where hex editing was case sensitive... so you needed to press SHIFT+letter... doh.
Edit: Updated for a couple of new dev features
#CSpect V2.12.34 changes
- Fixed HEX editing in the memory window so that it's case insensitive. (don't have to press SHIFT)
- ReadMe.txt now holds the "manual" part of this text file, and this is now "just" the version info.
#CSpect V2.12.33 changes
- You can now click on the memory window to edit bytes directly by typing HEX values into it ENTER or click off to stop
- You can now press KEYPAD_ENTER to display the game screen while in the debugger
#CSpect V2.12.32 changes
- Fixed reg $8E bit 3 usage - don't change RAM mapping
- Fixed Layer 2 palette colour offsets (NextReg $70)
- NextRegs $6E and $6F now return top 2 bits as 0
5 comments:
@jbullough: @mdf200 Think I have just found a bug in cspect. When running an IN read from the keyboard matrix, the next returns 191 on no key press but cspect returns 31. Easily fixed by ORing result or checking first 5 bits but it appears on the next that bit 8 is set also. Rgds Bootlegger
Are there any plans to support bit 4 of port 123B, (it's a new feature added in core 3.0.7 that sets a bank offset for layer 2 memory read/write mapping) I'm wanting to use this for the 640x256x4 graphics mode. I've tested my code on Hardware and it works fine, so it would be handy to have this in CSpect too!
Definite bug found.
On using the Layer Erase command - the emulated Next 'hangs'. This was observed from within my program which I then replicated from a fresh start using LAYER 2,1:LAYER ERASE 1,1,50,50. The accompanying tile scrolling demo program also crashes.
I am running 2.12.34 on ZX Next OS 2.06M on a Windows 10 high end laptop.
Following discussion within the Basic On The ZX Spectrum Next Facebook group - this was also replicated by another CSpect user running 2.12.30 and ZX Next OS 2.06L.
@bootleggger: that's not a real emulation bug, only 5 bits are defined by the keyboard matrix.
The top bits may be set/reset depending on different things, it's not even stable between different classic Spectrum revisions, there's extra setting in Next to emulate "Issue 2" board (original ZX, not Next Issue 2) in keyboard readings affecting how the top 3 bits are set, but generally the Spectrum programmer is expected to deal with "any" value in them.
I think what CSpect does with returning 31 is precisely what the early ZX boards did, but I'm too lazy to verify this claim (it may be also the opposite and maybe 255 was the common value). But generally speaking it should not matter, if it affects outcome of your code, you should fix the code to be not sensitive to the top three bits.
After battling z88DK and performance I've decided its time for snasm. Oddly after months of that z80 assembler now seems a lot more fluid than what I remember and snasm is fast to assemble.
One thing I noted (which I found in the code examples) is "opt nextreg" as its not in the snasm.rtf. Spent a good 1/2 trying to work out why my dma code didn't assemble but the examples did until I saw that example :)
Post a Comment