tag:blogger.com,1999:blog-17487316.post5915454841689471419..comments2024-01-13T09:14:12.131+00:00Comments on The life of a Games Programmer: #CSpect V2.12.34Mikehttp://www.blogger.com/profile/15958965170878448339noreply@blogger.comBlogger5125tag:blogger.com,1999:blog-17487316.post-25674404623605781112020-08-23T09:06:38.075+00:002020-08-23T09:06:38.075+00:00After battling z88DK and performance I've deci...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.<br /><br />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 :) Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-17487316.post-60117459274337939922020-08-10T13:52:54.804+00:002020-08-10T13:52:54.804+00:00@bootleggger: that's not a real emulation bug,...@bootleggger: that's not a real emulation bug, only 5 bits are defined by the keyboard matrix.<br />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.<br /><br />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.Ped7gnoreply@blogger.comtag:blogger.com,1999:blog-17487316.post-31339244619476113022020-08-03T12:33:06.577+00:002020-08-03T12:33:06.577+00:00Definite bug found.
On using the Layer Erase comm...Definite bug found.<br /><br />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.<br /><br />I am running 2.12.34 on ZX Next OS 2.06M on a Windows 10 high end laptop.<br /><br />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.Leeorghttps://www.blogger.com/profile/01780454026090097271noreply@blogger.comtag:blogger.com,1999:blog-17487316.post-9559580468622247472020-07-18T10:21:44.656+00:002020-07-18T10:21:44.656+00:00Are there any plans to support bit 4 of port 123B,...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!Blugheshttps://www.blogger.com/profile/05332912137746558360noreply@blogger.comtag:blogger.com,1999:blog-17487316.post-44533856968369749192020-07-17T17:48:31.385+00:002020-07-17T17:48:31.385+00:00@jbullough: @mdf200 Think I have just found a bug ...@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 Bootleggerbootleggerhttps://www.blogger.com/profile/00015764947581790426noreply@blogger.com