Saturday, September 14, 2019

#CSpect V2.11.1

This update is to add in (most) of the new hardware/registers that the latest Spectrum Next firmware has added - along with the new OS which uses some of it. There are some amazing advancements in this firmware. 14Mhz CPU speed all the time, 28Mhz copper and 14Mhz DMA, along with things like smooth scrolling the ULA screen. Brilliant update from the Next team.

#CSpect V2.11.1 changes
  • Fixed extra pixel in wrapping scroll of ULA
  • Fixed label on/off
  • Fixed lowres vertex clip "smear"

#CSpect V2.11.0 changes
  • Fixed -tv command line, and made it actually switch off all shader usage
  • if bit 6 in attrib 3 is not set, #CSpect now properly ignores attribute 4
  • Copper now runs at 28Mhz
  • The CPU no longers slows down over the screen
  • ULA can now scroll in 1/2 pixels
  • ULA Shadow screen now works with Layer 2
  • Reg 0x69 added (Layer 2 enable, ULA shadow mirror, and port bits 0-5 goto port 0xFF)
  • Copper Reg 0x63 added
  • DMA is now always 14Mhz...
  • 4 bit lowres mode added (reg 0x6A)
  • Added $123b Read mode
  • Added $123b 48K mapping mode
  • Reg 7 is now R/W, and bits 4/5 now set correctly
  • Window regsiters are now R/W


David said...

I think CSpect has a bug with either interrupts, or the halt instruction.
e.g. the program:


does not halt the processor.

mute said...

so what is the benefit of 28Mhz Copper and is there a new gfx mode Layer2 320x256 /?/ or ULA 320x256 with fine scroll .. not a coder here.

Hendrikk said...

Is it possible to use my hdd to have a folder that can be used as a mmc. I do not have a mmc card reader on my laptop

Anonymous said...

don't work on my pentium G630 with integrated intel video. Just black screen. cspect 2.10 don't work too.
version 2.9.2 works fine

Unknown said...

Possible bug with sprite clipping, according to the default clip window in nextreg 0x19 should be 0,255,0,191 but appears to be 0,255,0,255 ... sprites by default in CSpect can "fall out" of the bottom of the ULA area. Explicitly writing the "default values" to reg 0x19 fixes this.
Furthermore, setting bit 0 of nextreg 0x1C should reset the sprite clip window to the stated defaults, and does not appear to do so.

Ped7g said...

"Furthermore, setting bit 0 of nextreg 0x1C should reset the sprite clip window to the stated defaults, and does not appear to do so."

No, the 0x1C bit 0 does reset "index" for next write into 0x18 (Layer 2 clip window), i.e. following first write to 0x18 will set "X1 position".

There is no bit to reset the values-themselves of clip window, only the write-index.

There are some bugs with sprite clipping (over-border mode cuts 1 pixel too early), not sure about the default window, can't recall if I did test it, but I think as long as you don't enable "over border" sprites, the paper-area is correctly clipped. If you did enable both over-border-draw sprites + over-border-clipping, then ... I'm actually not sure, what is supposed to happen by default, but you should rather set up explicit coordinates in such case (the valid ranges are 0..159 for X and 0..255 for Y to cover whole 320x256 area in the "over border" mode)

About "di + halt" yep, that bug is in CSpect since the earliest version I have seen and was reported before by me (maybe got lost in the heap of other bugs reported).