the way the spectrum arranges the screen

[ParadigmShifter]

It's much easier in hex and in machine code the representation is the same (unless you do something silly like not use an assembler and have to build the operand bytes manually, which are in low byte then high byte order in). The CPU knows nothing about the base (radix) of the numbers or what an ascii character means it's all binary in the end.

Stick to hex though when working with the screen first third is $4000, middle third is $4800, final third is $5000. Each third is $800 = 2048 bytes long. 32 bytes per pixel row. Attribs start at $5800 and is $300 = 768 bytes in length.

To move down 1 scanline in a row in each third you add one to the high byte so the first scanline is $4000 to $401F, 2nd scanline is $4100 to $411F.

I usually use a lookup table of size 24x2 bytes for each character cell or sometimes 192x2 bytes for each scanline. Otherwise you have to have a slower address calculation routine than a table lookup and if you cross a screen third boundary that makes it more complicated as well.

This is what my row to base address lookup table looks like:

Code: Select all

	ALIGN 256
tbl_rows dw #4000, #4020, #4040, #4060, #4080, #40A0, #40C0, #40E0
              dw #4800, #4820, #4840, #4860, #4880, #48A0, #48C0, #48E0
              dw #5000, #5020, #5040, #5060, #5080, #50A0, #50C0, #50E0

where the first entry is the top row, 2nd entry is 1 8x8 cell lower, etc.

The 192 word entry, 2 bytes for each scanline would start like this

Code: Select all

	ALIGN 256
tbl_scanlines dw #4000, #4100, #4200, #4300, #4400, #4500, #4600, #4700
                    dw #4020, #4120, #4220, #4320, #4420, #4520, #4620, #4720 
                    ; etc.

Note I use sjasmplus which allows # instead of $ for hex values and has the handy ALIGN directive to align data (here, to an address that is a multiple of 256 which makes my routine for lookup a bit faster). I know the ZX Spin assembler does not like either # or ALIGN though.