BANK 5 - the screen memory

[TMD2003]

I am hacking my way through the jungle of the Next Issue 1 manual, and the densest jungle yet is chapter 16, dealing with colours.

Something that I always think of when tackling new computers is whether or not I can POKE directly to the screen memory. It's easy on the Spectrum and ZX81, almost as easy on the QL, wasn't too hard on the Commodore machines, trickier on the SAM Coupé (especially if I'm trying to do it via Z80 .asm), I think I've cracked it for the Amstrad CPC as well, and now... it's easy on the Next, because it's all there in BANK 5.

So far, so good. I already know about two blocks of 6K (DISP_FILE1 and DISP_FILE2), and two blocks of attributes (COLOUR_FILE1 and COLOUR_FILE2, though I've yet to see an example of how the second of these is used).

There must have been a good reason that each DISP_FILE starts at the beginning or the midpoint of the memory bank. But it does leave what looks to be a gap of 1280 bytes between the end of COLOUR_FILE1 and the start of DISP_FILE2 (i.e. 6192-8191) and a second 1280-byte gap at the end of COLOUR_FILE2 (i.e. 15104-16383).

Is this potentially useful? I've reached the PALETTE pages, and these gaps look like the perfect place to store custom palettes. LAYER 2 won't touch them as that uses BANKs 9-11. Am I on the right track, or am I going to get a nasty surprise in future chapters?

(I might try to fill a LAYER 1,3 screen with shash and then see if there's anything in the gaps.)

I realise I may need an even bigger machete in the next couple of chapters.

[Seven.FFF]

Historical reasons related to the 1980s Timex Spectrum clones and the ZX-UNO, and how the 48K RAM was already laid out for sysvars and channel data, which have always lived at $5C00..$5BFF. https://skoolkid.github.io/rom/buffers/sysvars.html.

The Timex machines introduced hi-color and hi-res modes. Pixels in both modes were the same as the classic 48K Spectrum, stored in screen thirds at $4000..5AFF. Hi-color had 8x1 attributes instead of 8x8, so need 8x as much attribute RAM. Instead of storing them it at $5B00 (which would have extended into an area already in use by sysvars and channels), it stored them at $6000..7AFF. Hi-res had a single foreground and single background colour for the whole screen, which was written with OUT 255 rather than stored in RAM. It had twice as many pixels (512x192), and again so as not to overwrite existing sysvars it stored odd column pixel data at $4000..5AFF, and even column pixel data at $6000..7AFF.

Some modern Spectrum clones have added timex modes even if they weren't a complete Timex model, as the modes are quite nice and useful. Including the ZX-UNO. A while ago a ZX-UNO user called Radastan invented a new low res mode (128x96). This used a palette of 16 colours, and stored two pixels in one byte. The four upper bits of a byte represented one of 16 colours for a pixel in odd columns, and four lower bits of the byte represented one of 16 colours for a the adjacement even column pixel. These scheme only needs to use the pixel area at $4000..5AFF. so was a nice compact mode with some specialist uses.

The Next implemented the Timex modes from the start, so already had the concept and supporting circuity for a separate VRAM area at $6000..7AFF.

Unwilling to implement the Radastan mode verbatim at the beginning, the Next added a different lowres (128x96) mode using a palette of 256 colours, all 8 bits in a byte represented one of 256 colours. Taking inspiration from the Timex modes, odd column pixel bytes were stored at $4000..5AFF, and even column pixel bytes $6000..7AFF. Much later, the Radastan mode was added too.

Switching between $4000 and $6000 is quite cheap, as is switching between $4000 and $C000 (the 128K/+2/+2A/+3 shadow screen). Both of them involve flipping only one bit in the address. This is a very beneficial thing for the underlying hardware, as it uses the minimum of logic gates. Also in machine code where bit operations are cheap.

[TMD2003]

Unwilling to implement the Radastan mode verbatim at the beginning, the Next added a different lowres (128x96) mode using a palette of 256 colours, all 8 bits in a byte represented one of 256 colours. Taking inspiration from the Timex modes, odd column pixel bytes were stored at $4000..5AFF, and even column pixel bytes $6000..7AFF. Much later, the Radastan mode was added too.

"Much later" meaning, I assume, after the publication of the Issue 1 manual.

Is there a LAYER command for Radastan's mode (LAYER 1,4 maybe?) or is it only accessible via machine code, as LAYER 3 is... or was... or still is?

Meanwhile, I have a program running to see if there is anything else hidden in BANK 5. One thing's for sure: BANK 5 ERASE 0,16384,0 crashed CSpect.

System variables, maybe?

[Seven.FFF]

"Much later" meaning, I assume, after the publication of the Issue 1 manual.

Is there a LAYER command for Radastan's mode (LAYER 1,4 maybe?) or is it only accessible via machine code, as LAYER 3 is... or was... or still is?

Meanwhile, I have a program running to see if there is anything else hidden in BANK 5. One thing's for sure: BANK 5 ERASE 0,16384,0 crashed CSpect.

System variables, maybe?

None of Radastan, hardware tilemap (layer 3), Layer 2 320x256 or Layer 2 640x256 are supported in NextBASIC yet. Garry still has plans to do it, but he's just worked through a huge refactor in the file system code for 2.07, which he needed to do first to free up more space.

I believe it was a deliberate decision to omit those modes from the manual because they didn't have NextBASIC support at the time of final edition. There was huge pressure to keep the number of pages and amount of info down to something physically able to fit into the cardboard boxes, which were one of the first things manufactured in 2017.

Preserving sysvars if you want to interact with or return to BASIC is a really common thing since 1982. Most of this memory map chapter from the 48K manual applies to the Next. https://worldofspectrum.org/ZXBasicManu ... hap24.html. The 128K/+3 models got rid of the ZX Printer buffer and put a few more sysvars there, and the Next has added a few more - there's a list of the ones that differ from the +3 on page 34 here (which is also on your SD card): https://gitlab.com/thesmog358/tbblue/-/ ... atures.pdf

[TMD2003]

At least I found that the system variables were occupying that first gap between COLOUR_FILE1 and DISP_FILE2 on BANK 5. The second gap above COLOUR_FILE2 appears to be unused... though I'll bet it gets overwritten when programs start getting long.