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.
- Requires Next core 3.0.6 or later.
- Uses Copper (co-processor) for line palette changes
- Uses Layer 2 256x192 for SAM "MODE 4"
- Uses Layer 2 in 640x256 overscan mode for SAM "MODE 3"
- Uses 9-Bit colour space
- Uses esxDOS for file access
- Uses IDEDOS/Plus3DOS APIs for memory allocation
- Uses dot-command structure and error handling for integration with NextZXOS
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<.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$
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).
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 across 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. FLASHing colours are not supported.
The BORDER colour (Next ULA palette index 16) is set to match the first colour-index of the image.
On SAM, the palette changes can extend into the BORDER but in this case the border area will not be affected by the Copper palette changes. (The Copper's attention is directed to Layer 2, and the border is part of Layer 0). MODE 3 screens, however, use only 512x192 of the full 640x256 so the remaining space around the edges does give a pseudo-border that is subject to palette changes.
Here's a BASIC program that demonstrates the viewer by loading random MODE 4 screens from ZXArt.ee:
(Requires Remy's .HTTP dot-command).
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
- Next Tech by Simon N Goodwin
- ZX Spectrum Next Assembly Guide by Tomaž Kragelj
- NextZXOS and esxDOS APIs by SpecNext Ltd.
- SAM Pixel and Palette Data annotated by Anton Javorček
- .bmpload by Jim Bagley
- .sync by Jari Komppa
- Dotfile examples by Chris Taylor