SAM Coupé SCREEN$ viewer for ZX Spectrum Next

I've prepared a dot command called .SSX for viewing SAM MODE 3 and MODE 4 screens using ZX Next's LAYER 2.
Download
Source files: ssx.asm
Requires Next core 3.0.6 or later
Vote
Polls are open! Cast your vote now! 🗳️
Usage
To install this command as the NextZXOS file handler for .ss3 .ss4 files, first add it to the c:/dot directory and then add the following line to your c:/nextzxos/browser.cfg file:
SS3,SS4<.ssx |
The viewer can also be invoked from the command line with .ssx example.ss4. Note that quote marks around the file name are not accepted. To use the viewer in a program use .$, as follows:
10 a$="example.ss4" 20 .$ ssx a$
Screen type detection
Files with names ending with a "4" will be treated as MODE 4 (and those with a "3" as MODE 3). Alternatively you can pass "3" or "4" as a parameter after the filename (separated by a single space).
10 a$="logo 4" 20 .$ ssx a$
The ".ssx" file standard uses the total file size to determine the type, so files of exactly 24,580 bytes (24K of bitmap data + 4 palette bytes) will be treated as MODE 3. For anything else we'll just assume MODE 4.
💡 SAM's MODE 3 screens are 512x192 so I'm displaying them with Layer 2's 640x256 overscan mode, so it will require Next core 3.0.6 or later.
Files may optionally have a +3DOS header (if so it will be ignored).
Colours and line interrupt palette changes
SAM screens are saved with palette information (usually 40 bytes) and optionally a series of palette changes to be made at certain screen lines. And hopefully a $FF byte as an end-marker. As mentioned, some files will truncate that down to just 4 bytes for MODE 3, and 16 bytes for MODE 4—and usually no end-marker.
For our purposes, the palette entries are mapped accross to Next's 9-bit RGB colour space using a lookup table. (I'm grateful to Simon N Goodwin for helping me to interpret the "half bright" bit correctly). The line palette changes are implemented as Copper instructions. (This is not really necessary on Next and in a future version we could remap the bitmap data line-by-line to use all 128 SAM colours with no need for dynamic changes). FLASHing colours are not supported.
The BORDER area is automatically set to PAPER 0 (typically black by convention, but not always). On SAM the palette changes extend into the BORDER area but in this case it will not be affected by the Copper pallete changes, since that's currently concerned with Layer 2, and the border is part of ULA Layer 0 (and uses a separate palette index anyway) but this could be reorganised. MODE 3 screens don't use the full 640x256 so the remaining space around the edges does give a pseudo-border (potentially with palette stripes too).
🚨 I probably haven't trapped every error or handled every exception, so beware! ☠️
BASIC demo
Here's a BASIC program that demonstrates the viewer by loading random MODE 4 screens from ZXArt.ee:
zxart.tap | zxart.bas | zxart.txt
#program zxart.bas #autostart 10 REM fetch/display images from ZXArt 20 h$="tnfs.robertmorrison.me" 30 u$="/api/zxart/sam4/random.php" 40 f$= "/tmp/zxart.ss4" 50 CLS : PRINT "loading..." 60 .http -h h$ -u u$ -f f$ 70 .$ ssx f$ 80 PAUSE 0: GO TO %50 9090 SAVE "zxart.bas" LINE %10
SAM screens from ZXArt.ee
Showing ten random SAM mode 4 screens from the zxart.ee database — click the image to download the .ss4 file, or click the caption for more information about each picture.
rwm | | updated