SCN colour device driver for Spectrum Next and compatibles Implements block operations and text output from QDOS to Lion's 64K MODE 256 Copyright 2025 Simon N Goodwin - released under the CC-BY-NC-SA version 4 License $VER: SCN 1:48, last updated 29th April 2025 SCN is a free QDOS colour display driver. It works like Sinclair’s SCR, with many of the same SuperBASIC commands and 31 standard I/O TRAPs, but instead of output to a fixed-size 4 or 8 colour screen it drives a 256 colour display with configurable size and addresses. It was written for the Next QL but should work with any other QDOS-compatible system that uses byte-per-pixel screen RAM. This is an update of the early-April beta release. It has been tested on the latest Next QL FPGA versions for Spartan and Artix hardware, and on the first release of the QL core in late 2024. Some features, including new MODE commands and functions, are not fully implemented on the 2024 system. To make the code work on all current Nexts, and easy to adapt, simple SuperBASIC procedures Q and D can switch the new display modes on and off. TOP TIP FOR OLD FPGA USERS IF YOU CAN'T SEE WHAT YOU'RE DOING, press Ctrl SPACE to break into the current program and type Q followed by ENTER to turn off the new display modes and revert to the standard QL display. Since KS1 systems use the same 64K memory for Sinclair and Next display modes, weird patterns may appear when you switch between them. The new MODE commands will tidy this up (without clearing other screens needlessly on a KS2 system) but hardware changes and improvements mean they need the 2025 FPGA updates I have been testing for Lion (twelve in the last fortnight) to work as intended. Overview of features and compatibility The SCN driver supports a large subset of the SuperBASIC commands and output TRAPs offered by the SCR device written for Sinclair by GST, then incorporated into QDOS. Programs that PRINT text and update blocks of pixels can be redirected to new more colourful Next QL screen modes by opening a SCN channel from BASIC or any other language, including 68K machine-code. You just open a channel to SCN rather than SCR, with the same parameters e.g. OPEN #3,SCN_448x200a32x2 then continue as for any QL device. * Supports all WINDOW, CLS, SCROLL, PAN and BORDER options. * Supports 256 INK and PAPER colours (in lieu of stipples). * Supports two founts consistently with CON and SCR drivers. * Offers UNDER 0 or 1, OVER 0, 1 and -1 (EOR) output options. * Like MODE 8, CSIZEs 0,0 and 1,0 are treated as 2,0 and 3,0. * AT and CURSOR keywords can position text at character or pixel positions, but not floating-point graphics coordinates. * Double-height characters (CSIZE x,1) are fully supported. The files include the driver, source code, and some of my Toolkit commands to test and demonstrate it. The SCNDEV_BAS program loads the driver, toolkits (other than Toolkit 2 which should be pre-loaded by the standard Next QL BOOT program) and a handful of demo procedures. Most of these require that a 2024 Next FPGA is started up in Minerva's twin screen mode. This limitation is lifted on new Artix FPGA cores made in 2025, as they use a separate 128K screen area for the new 16 and 256 colour modes. There is no support for pixel graphics, POINT, LINE, CIRCLE, FILL etc. However extended versions of the DIY Toolkit PLOT and DRAW commands can be used to plot pixels and lines in MODE 12 and MODE 256, but without floating-point offsets, scaling or TV-type aspect correction. This does make them quite a lot quicker, especially for short lines and single points. BLOCK is fully supported and always faster for single-pixel-width vertical or horizontal lines. Supported SuperBASIC commands BLOCK, BORDER, CLOSE, CLS, CSIZE, CURSOR (pixels or chars), INK, OPEN, OPEN_NEW, OVER, PAN, PAPER, PRINT, RECOL, SCROLL, STRIP, TO, UNDER, WINDOW Toolkit extensions: CHAR_INC, _XINC, _YINC, CHAR_USE/SET_FONT/_FOUNT, etc. Supported Qdos functions IO.OPEN IO.CLOSE IO.SBYTE IO.SSTRG SD.EXTOP SD.PXENQ SD.CHENQ SD.BORDR SD.WDEF SD.CURE SD.CURS SD.SCROL SD.SCRTP SD.SCRBT SD.PAN SD.PANLN SD.PANRT SD.CLEAR SD.CLRTP SD.CLRBT SD.CLRLN SD.CLRRT SD.RECOL SD.SETPA SD.SETST SD.SETIN SD.FILL SD.SETMD SD.FOUNT SD.SETUL SD.SETSZ The current omissions are pixel graphics operations, and FLASH. Screen modes on QL Next Sinclair hardware only supports two display formats, MODE 4 (512x256 pixels in black, red, green or white) and MODE 8 (256x256 pixels in black, blue, red, magenta, green, cyan, yellow or white, with optional flashing). Both use 32K of video memory, interpreting the bits differently to trade colours for resolution. The Sinclair MODE command also accepts the horizontal resolution values 256 or 512 as equivalent to the colour-counts 4 or 8. In the case of MODE 256 (meaning mode 8) this is confusing but luckily the larger numbers are rarely used by programmers; indeed at the hardware level MODE 4 is selected as mode 0. Subsequent non-Sinclair systems claiming QL compatibility have allocated several less mnemonic numbers to displays with different resolutions and colour-depths. In 1988 CST set the ball rolling with MODE 12, matching MODE 8 in resolution but with dimmer versions of each colour (including two greys) by dropping the flash capability and reusing the fourth bit for each pixel for digital intensity control. This still used 32K of RAM at the Sinclair-standard addresses 131072 to 163839. New colours were selected with halves and quarters fractions, using a capability of CST’s ARGOS system. QDOS uses values from 0 to 15, 7 and 8 being greys and 9 to 14 brighter versions of QL colours 1 to 6. The Next QL supports MODE 12 with suitable software, e.g. DIY Toolkit PLOT and DRAW commands, at the same RAM addresses chosen by Sinclair and CST. The mode is not directly supported by QDOS or Minerva ROMs. Every Next QL has two extra display modes, similar to those on other extended QDOS systems. These use twice as much memory, 64K, giving 16 or 256 colours at the resolutions of MODE 4 or MODE 8. They are called MODE 16 and MODE 256. MODE 32 is also supported by SCN on KS2 Nexts. Since Sinclair’s MODE command and the underlying QDOS and ZX8301 hardware don’t know about new modes, and have been incompatibly patched in the meantime, the SCN driver includes new MODE commands that combine the number into the name, with no space after MODE. These work with the 2025 FPGA but not the original Next QL release, so the beta release includes temporary SuperBASIC PROCs called D and Q to switch between Sinclair and Lion screens, and PROC N which brings up the Next screen until a key is pressed, then reverts to the Sinclair mode. MODE 16 combines MODE 4 coordinates and resolution but with 16 instead of four colours, packing two pixels into each byte where Sinclair stored eight in each adjacent byte pair. MODE 256 uses one byte per pixel, for 256 lines of 256 columns of 256 colours. This allows limited support for MODE 16 via the SCN driver. Small characters and odd window dimensions are not supported in MODE 16 since SCN always writes a byte at a time to display memory. 240 stipple patterns are available in MODE16, using adjacent pairs chosen from the 16 colours. The initial QL Next release in 2024 mapped these modes to address 131072, requiring a less-compatible optional configuration of the Minerva operating system to reserve the second 32K where all Sinclair ROMs store vital system variables. In 2025 FPGA maestro Lion moved them to $4C0000, with the still-undocumented option of a second 64K screen at $4D0000 for flicker-free double-buffered updates, at the request of your scribe Simon N Goodwin. Unfinished work to support the second screen includes the SCN_USE toolkit command, SCN_NUM function, and two demo procedures SCR2 and SCREEN2. These are not yet working in the 1.48 release documented here, but will be added once the new FPGA is in public circulation. The SCN_VER$ function returns the version of the SCN driver. Support for shorter, narrow or extra-wide character spacing Truncated or spaced-out characters can be output, with less efficiency, if CHAR_INC or similar Toolkit commands are used to adjust SD.XINC and SD.YINC to non-standard values. With custom founts up to 85x51 barely-legible characters may be squeezed into a 254x255 pixel window, ZX Tasword 2 style, with CHAR_INC 3,5, but a pixel gap between characters is recommended, limiting the ransom note to 64x42 characters. To illustrate the flexibility of the driver I have used the information in Chapter 13 of Next Tech to pull Garry Lancaster's three and five-pixel wide founts out of Next ZX BANK 8, and converted them into the QL fount format for 4x8 and 6x8 pixel test output (on any QDOS display device, not just SCN). Other examples use an 8x8 'fantasy' fount and the 'short' fount from the NTSC version of the QL made by Samsung. X (horizontal) increments for SCN channels are always measured in PIXELS whereas QDOS SCR and CON counts pixels in MODE 4 and half-pixels in MODE 8. So when converting programs from MODE 8 or MODE 12 to MODE 256, custom XINC values need to be halved! If SD.XINC is reduced to a value between 2 and 5 only that number of pixels from the high-order bits of the fount are output. Zero and single-pixel increments are not supported. If there is no room in the window for a character of the size implied by SD.XINC or SD.YINC, no error is reported and nothing is printed. This is consistent with Minerva. If SD.XINC is 7 or 8 (equivalent to CSIZE 3,y) additional low-order bits from the fount are rendered, consistent with Speedscreen, Minerva and most Sinclair ROMs. Since QL fount rows are only a byte wide, a dditional STRIP-colour pixels are output to the right of the glyph if SD.XINC exceeds 8. Vertically, SD.YINC may be 4..9, the default 10 pixels, or more. If <10 the blank first line is skipped first, then later lines of the fount may be ignored to make room, e.g. only the first six fount lines (preceded by a one pixel-line gap) are drawn when SD.YINC is 6, allowing 42x42 small characters (1764 in total) in a 64K byte-per-pixel display. This means that 8x8 character glyphs from other systems e.g. ZX Spectrum can be output without blank lines, or standard QL fount 6x9 or 8x9 glyphs can be used to build up larger images. YINC values lower than 4 are unsupported. If YINC exceeds 10, blank pixel lines are left between characters, rather than additional rows filled with the STRIP colour, which only occurs for the first row of full-height or taller characters. Deliberate and intentional design limitations: There is no support in SCN for keyboard input, hence no line-editing. This is mainly because the large and ROM-dependent EDIT subroutine cannot be called by programs except as part of the CON device driver. 256 (or limited 16) colour RECOL requires the new keyword RECOL256, as Sinclair's RECOL is limited to eight colours. This can also recolour MODE 32, and 16 colour MODE 16 screens via the RECOL16 PROC included in the SCNDEVBAS loader and example program file. No support for pixel graphics, POINT, LINE, CIRCLE, FILL etc. However extended versions of the DIY Toolkit PLOT and DRAW commands can be used to plot pixels and lines in MODE 12 and MODE 256, but without floating-point offsets, scaling or TV-type aspect correction. This does make them quite a lot quicker, especially for short lines and single points. BLOCK is fully supported and always faster for single-pixel-width vertical or horizontal lines. An update of the original QL World commands, adapted for 256-colour Next screens, was released by the author in January 2025. Future versions will support 16 and 65,536 colour screens, when available. CTRL-F5 is tested only at the start of string output, not for every character. You will see the whole string, or none of it. If this becomes unwieldy, print smaller groups of characters. Known bugs, edge-cases and peculiarities: Windows must be wide & tall enough for at least one character. XINC values are set in pixels not half-pixels as in QL MODE 8. For Sinclair ROM compatibility, coordinates in OPEN and WINDOW commands use MODE 4 units (512 units per line) although only 256 pixels are addressable, at even coordinates 0 to 510, just like SCR in MODE 8. Odd numbers are rounded down. Double-height characters are not expanded for a custom YINC of 10, which would otherwise use only the top 5 rows from the fount, if the XINC is 6, as they get sifted out into the fastpath for small characters in OVER 0 or OVER -1. To work round this use a YINC of 11, XINC <> 6, or the unoptimised OVER 1. The MODE64 command does not work yet; 16-bit colour will will not be supported for text output from SCN, but vector PLOT and DRAW operations are in the works; the new command INK64K allows 65536 colours to be specified for such operations, with the SCN device and updates of the PLOT/DRAW Toolkit commands. Example procedures SCNDEV_BAS is a loader and collection of test and demo PROCs. They expect SuperToolkit 2 to have been preloaded, as is done by the Next QL WIN1_BOOTS program. Some of these use Turbo Toolkit (TURBO_TK_CODE) or DIY Toolkit (QBASE_CODE, supplied) extensions. Three single-letter PROCs control which screen the Next QL core displays. They are used in conjunction with Sinclair MODE commands, to set the resolution, and switch without clearing the screen. These PROCs, Turbo Toolkit, Toolkit 2, and the CHBASE extensions from DIY Toolkit, are used in the following demo and test routines. On other hardware, e.g. Q68 or Aurora, replace PROC D with whatever incantation brings your extra-colour screen area to the foreground. On Next this will be MODE 256 when starting from MODE 8 or CST MODE 12, and MODE 16 (hires) if previously in Sinclair’s MODE 4. PROC Q reselects the default QL screen, again without clearing it. PROC N is used while testing to flip from Sinclair to the other (64K+) screen until a key is pressed. Since the Sinclair MODE command knows nothing of Next hardware, and the original Next QL associated the resolution of new screens with the Sinclair MODE 4 or MODE 8 hardware, it is temporarily necessary to put the system into low (MODE 8) or high resolution (MODE 4) to access MODE 256 or MODE 16 respectively. Once we all have the new FPGA, commands like MODE4, MODE8, MODE12, MODE16, MODE32 and MODE256 can be used instead. The NEXT_MODE fucntion will then return the number of the current mode, and NEW_MODE commands can set any mode when passed a suitable parameter. PROC RC demonstrates RECOL256 using synthetic data. The 2025 KS2 Next can recolour a million pixels per second; the old FPGA is slower but still runs rings around Sinclair's commands. MINFOUNT and MINHEX display the characters of both Minerva founts or a packed display of multicoloured hexadecimal. CHECK tests various combinations of CSIZE, OVER and UNDER. PROC XI tests and shows the effect of adjusting XINC the horizontal interval between characters, with Toolkit 2’s CHAR_INC command. PROC YI adjusts vertical YINC spacing likewise. PROC TC stands for Tall Characters and checks CSIZE n,1 output. FF stands for fat fount, using the 8-pixel wide FANTASY_FOUNT. SF tests SHORT_FOUNT output. GF loads and displays small characters converted from the Spectrum Next ROM. ST is a tweakable Speed Test, writing a million characters of text in a chosen style without scrolling. The fastest routines output 6x10 pixel characters, giving a maximum of 1100 (42 25) full characters visible at once, in OVER 0 with or without underlining or OVER -1 UNDER 0 (only). OVER 1 is never optimised, always using nested X and Y loops. Even so output is quick as pixel data is never spread between bytes as it must be for output to Sinclair's d isplay modes. Character output is faster than in Sinclair MODEs, though falling well short of SpeedScreen performance. Scrolling and panning is relatively slow even compared with original GST routines, as the extra colours demand twice as much video RAM. However the Next RAM and TG68K CPU core more than makes up for that, at least compared with Motorola 68008 or 68000-based systems. M32 shows this, by scrolling the example program listing through a 128K MODE 32 screen. This only works on Artix (KS2) FPGA systems. Adapting the driver for other systems or changes to the Next QL FPGA The source code SCNDEV_ASM uses conditional assembly to support old and new systems. The 1.48 release is a compromise between them, so some functions must be implemented via POKEs from SuperBASIC for the 2024 Next QL release. The symbol PENDY enables pending newline handling, recently added to the driver. TESTBED builds a rudimentary driver with support for QBLOCK and QPRINT commands. This is left over from before the time the SCN driver was ready. The NEXTRES symbol switches the way the driver detects low and high resolutions from the Sinclair MC.STAT to the new NsVideo register. This was in rapid flux before the release of SCN 1.48. In general there is some redundant, sub-optimal or redundant code in the driver. This will be tidied up. Like Speedscreen, but unlike QDOS or Minerva, SCN includes several different rendering routines optimised for various character sizes. The code to select between them runs more often than it will need to once recent FPGA changes are in common use. This will also speed up MODE adaption in the PLOT and DRAW commands. The first version of those, NDRAW for MODE 12 and MODE 256 only, can be downloaded from http://simon.mooli.org.uk/QL/next/ alongside various other early utilities and examples that were shared by me, Simon N Goodwin. Customising screen addresses and dimensions The extension SCN_DEFL adjusts defaults for the loaded SCN driver, by setting one of four long word values in the SCN device definition: The first parameter is the index, 0, 1, 2 or 3 of long words that are user-configurable for later OPEN "SCN" operations. The second parameter is the arbitrary 32-bit address to set. * SCN_DEFL 0,f0 Sets the default SCN fount0 address to F0. * SCN_DEFL 1,f1 Sets the default SCN fount1 address to F1. * SCN_DEFL 2,addr Sets the start address of SCN screen RAM. * SCN_DEFL 3,xy Sets the screen width and height in pixels * where XY = pixels per row * 65536 + rows. Default ADDR is $20000 for the 2024 Next QL (in the Sinclair and Minerva screen address space) and $4C0000 since, the 64K area defined by Aurora, or $4D0000 for a second 64K screen. If the driver can detect an old FPGA it will automatically select $20000 for you. The start of the SCNDEV_BAS program shows how to detect later PFGAs and customise their screen addresses when the driver loads. Default MODE 256 or 16 XY is $01000100 (256 bytes 256 rows). These values are configurable to support increased screen dimensions or double-buffered output in new hardware. Until these are changed, screens are assumed to be 256 x 256 single-byte pixels in a 64K area starting at scrbase (set with SCN_DEFL 2) using the same founts as channel #0 was using when this driver was loaded. Once a channel is open its founts can be changed with CHAR_USE (TK2), SET_FONT (TTK) or POKE_L to offsets 42 or 46 on the address returned by the DIY Toolkit function CHBASE(#) for that channel. The base address for pixel output to a given channel N can be set to ADDR with POKE_L CHBASE(#N)+50,ADDR or read with PEEK_L(CHBASE(#N)+50), consistently with Sinclair's SCR and CON channels. Sinclair and GST made no provision for screens larger than 32K. This driver defaults to a 64K area giving extra colours at the original QL resolutions, implemented by Lion for the Next QL FPGA. To customise the dimensions this byte-per-pixel driver uses on a given channel, POKE_W CHBASE(#n)+100,X sets a width of X bytes/pixels, and use POKE_W CHBASE(#n)+102,Y to indicate that the screen RAM consists of Y contiguous rows each of X pixels, with the last (lower right) pixel stored at ADDR+(X * Y)-1. Higher resolutions or colour depths will require more RAM! Some only work on later Artix FPGAs, for that reason. The current defaults, or custom settings, can be PEEKed from an open SCN channel at offsets 42, 46, 50 and 100 on CHBASE. The driver contains several new MODE commands and a query function. These will be fully documented when the 2025 FPGA is released, as they rely upon some of its features. They are not intended for use on the initial QL Next FPGA, Q68, Aurora etc. Support for two screens (for flicker-free animation) will also appear in the new FPGA for KS2 Nexts, and be supported by SCN updates. Please don't ask me about SMS, Emulators etc. I don't use them. Simon N Goodwin, 30th April 2025