Difference between revisions of "Timex Sinclair Video Mode Control"

Revision as of 07:01, 15 January 2019

Number	$xxFF
Decimal
Short desc.	Controls Timex Sinclair video modes and colours in hi-res mode.
Bit Mask	%---- ---- 1111 1111
Readable	No
Writable	Yes
Subsystem	Enhanced ULA

Bit	Function
0-2	000=Screen 0. 001=Screen 1. 010=Hi-colour. 110=Hi-res.
3-5	Sets screen color combination for hi-res mode. The bit pattern does set INK colour, PAPER+BORDER colour is deducted as complement value, both colours are of BRIGHT variant. I.e. only some combinations are possible, like White/Black, Yellow/Blue, ..
6	Disables interrupts. Does the same as DI, but cannot be turned on again with EI. Use with caution!
7	Used for memory paging on the Timex Sinclair, not relevant on the Next.

Ped7g (talk) 02:09, December 23, 2018 (UTC): I guess the hi-res colours are still fetched through ULANext palette, i.e. any two colours combination is possible through palette modification of the two colours (for example White/Black are 15/136 (bright variant, or maybe black paper is black 128)?).

Ped7g (talk) 07:01, January 15, 2019 (UTC) internally the HW "ULA" part is providing pixel byte and attribute byte, and attribute byte contains %01pppiii, where %iii is the ink colour set in bits 3-5 on this port, and %ppp is complement of it. The %01 part is "no flash, bright yes". If ULANext mode is enabled, this value is then decomposed into ink/paper values according to Enhanced ULA Ink Color Mask ($42), so for the White/Black example and INK-mask 15 the INK value is %0111 = 7, and PAPER/BORDER %0100 = 4 + 128 (132). For INK-mask 7 it would be INK 7, PAPER/BORDER = 8 + 128 (136) (not 15/136 as I guessed previously).

This is only theoretical reasoning, going by information provided by Jim Bagley in forums, and has to be yet confirmed with actual HW board (what I can confirm at the moment, that both available emulators ZEsarUX7.2 and CSpect2.2.0 are emulating HiRes in completely different way, not resembling this "pixel_byte -> ULA adds attrib byte -> ULANext translates into palette -> final pixel going into layer combining + transparency check" pipeline, so they can't be used to validate this).

@@ Line 13: / Line 13: @@
 |-
 | 3-5 || Sets screen color combination for hi-res mode.
-The bit pattern does set INK colour, PAPER colour is deducted as complement value, both colours are of BRIGHT variant. I.e. only some combinations are possible, like White/Black, Yellow/Blue, ..
+The bit pattern does set INK colour, PAPER+BORDER colour is deducted as complement value, both colours are of BRIGHT variant. I.e. only some combinations are possible, like White/Black, Yellow/Blue, ..
 |-
 | 6 || Disables interrupts. Does the same as DI, but cannot be turned on again with EI. Use with caution!
@@ Line 21: / Line 21: @@
 [[User:Ped7g|Ped7g]] ([[User talk:Ped7g|talk]]) 02:09, December 23, 2018 (UTC): I '''guess''' the hi-res colours are still fetched through ULANext palette, i.e. any two colours combination is possible through palette modification of the two colours (for example White/Black are 15/136 (bright variant, or maybe black paper is black 128)?).
+[[User:Ped7g|Ped7g]] ([[User talk:Ped7g|talk]]) 07:01, January 15, 2019 (UTC) internally the HW "ULA" part is providing pixel byte and attribute byte, and attribute byte contains %01pppiii, where %iii is the ink colour set in bits 3-5 on this port, and %ppp is complement of it. The %01 part is "no flash, bright yes". If ULANext mode is enabled, this value is then decomposed into ink/paper values according to {{NextRegNo|$42}}, so for the White/Black example and INK-mask 15 the INK value is %0111 = 7, and PAPER/BORDER %0100 = 4 + 128 (132). For INK-mask 7 it would be INK 7, PAPER/BORDER = 8 + 128 (136) (not 15/136 as I guessed previously).
+This is only theoretical reasoning, going by information provided by Jim Bagley in forums, and has to be yet confirmed with actual HW board (what I can confirm at the moment, that both available emulators ZEsarUX7.2 and CSpect2.2.0 are emulating HiRes in completely different way, not resembling this "pixel_byte -> ULA adds attrib byte -> ULANext translates into palette -> final pixel going into layer combining + transparency check" pipeline, so they can't be used to validate this).