Timex Sinclair Video Mode Control - Revision history

Ped7g at 11:50, 4 May 2020

2020-05-04T11:50:35Z

← Older revision		Revision as of 12:50, 4 May 2020
Line 1:		Line 1:
	{{Port		{{Port
	\|Number=$xxFF		\|Number=$xxFF
			\|NumberDec=255
	\|ShortDesc=Controls Timex Sinclair video modes and colours in hi-res mode.		\|ShortDesc=Controls Timex Sinclair video modes and colours in hi-res mode.
	\|Readable=No		\|Readable=No

Ped7g at 00:35, 16 April 2020

2020-04-16T00:35:52Z

← Older revision		Revision as of 01:35, 16 April 2020
Line 6:		Line 6:
	\|Subsystem=Enhanced ULA		\|Subsystem=Enhanced ULA
	}}		}}
	This port is also readable when {{NextRegNo\|$08}} bit 2 is set to one (otherwise "floating bus" values are read at port $FF).		This port is also readable when {{NextRegNo\|$08}} bit 2 is set to one (otherwise "floating bus" values are read at port $FF) (soft reset = 0).

	{\| class="wikitable"		{\| class="wikitable"

Ped7g: fixing the description Enhanced ULA mechanics, and overall adding info

2019-12-31T09:29:18Z

fixing the description Enhanced ULA mechanics, and overall adding info

← Older revision		Revision as of 10:29, 31 December 2019
Line 5:		Line 5:
	\|Writable=Yes		\|Writable=Yes
	\|Subsystem=Enhanced ULA		\|Subsystem=Enhanced ULA
	~~\|PortMask=%---- ---- 1111 1111~~
	}}		}}
			This port is also readable when {{NextRegNo\|$08}} bit 2 is set to one (otherwise "floating bus" values are read at port $FF).

	{\| class="wikitable"		{\| class="wikitable"
	! Bit !! Function		! Bit !! Function
Line 19:		Line 20:
	\| 7 \|\| Used for memory paging on the Timex Sinclair, not relevant on the Next.		\| 7 \|\| Used for memory paging on the Timex Sinclair, not relevant on the Next.
	\|}		\|}

	~~''UPDATE: the index of border colour is under investigation and to be confirmed (core2.00.25 is different from 2.00.24 in this aspect).''~~

	The hi-res mode (and some parts also about other Timex modes) HW implementation details:		The hi-res mode (and some parts also about other Timex modes) HW implementation details:

	~~The~~ border colour is identical to paper (including the brightness)~~, so everything described for paper does apply to border too (~~the hi-res mode overrides port 254 border colour~~, which gets ignored while hi-res mode is selected)~~.		In classic ULA mode the border colour is identical to paper (including the brightness!) - the hi-res mode overrides port 254 border colour.

	The Next display pipeline starts at reading the pixel data from "bank 5", which resides in BRAM of FPGA, and is mapped to $4000 and $6000 in default memory mapping (the display data are read from the BRAM, so mapping different ram into $4000..$8000 Z80 address space does not modify the screen output, to modify screen output you have to map "bank 5" to some memory and write there). These pixel data are half of "ULA" ~~result~~, other half is attribute byte, which is composed as "01pppiii" value, where "iii" are the bits 3-5 from (this) $FF port, and "ppp" are complement of "iii".		The Next display pipeline starts at reading the pixel data from "bank 5", which resides in BRAM of FPGA, and is mapped to $4000 and $6000 in default memory mapping (the display data are read from the BRAM, so mapping different ram into $4000..$8000 Z80 address space does not modify the screen output, to modify screen output you have to map "bank 5" to some memory and write there). These pixel data are half of input for "ULA", other half is attribute byte, which is composed as "01pppiii" value, where "iii" are the bits 3-5 from (this) $FF port, and "ppp" are complement of "iii".

	For example for bits set as %100 the ULA does accompany every pixel byte with attribute byte %01011100, i.e. "INK 4, PAPER 3, BRIGHT 1".		For example for bits set as %100 the ULA does accompany every pixel byte with attribute byte %01011100, i.e. "INK 4, PAPER 3, BRIGHT 1".

	If ~~ULANext~~ mode is enabled (bit 0 in {{NextRegNo\|$43}}), this attribute byte is decomposed by ink-mask ({{NextRegNo\|$42}}) into ink-index and paper-index, then the selected ULA palette is used to fetch particular colours (the constant 128 is added to paper and border index ~~as in normal ULA modes~~), so in the example above with attribute byte %01011100 and ink-mask 7 the resulting colour will be current-ULA-palette[4] for filled-pixels, ~~and~~ current-ULA-palette[128+11] for paper (empty pixel) and border (with ~~default~~ ink-mask 15 the indices will be 12 for ink and 128+5 for paper+border).		If [https://wiki.specnext.dev/Video_Modes#Enhanced_ULA Enhanced ULA] mode is enabled (bit 0 in {{NextRegNo\|$43}}), this attribute byte is decomposed by ink-mask ({{NextRegNo\|$42}}) into ink-index and paper-index, border-index is (paper-index AND %111), then the selected ULA palette is used to fetch particular colours (the constant 128 is added to paper and border index), so in the example above with attribute byte %01011100 and ink-mask 7 the resulting colour will be current-ULA-palette[4] for filled-pixels, current-ULA-palette[128+11] for paper (empty pixel) and current-ULA-palette[128+3] for border (with ink-mask 15 the indices will be 12 for ink and 128+5 for paper+border).

			(the default ink-mask of Enhanced ULA did change from 15 to 7, since one of 3.0 cores, can't recall precise version)

	If the colour in palette is a match with {{NextRegNo\|$14}}, the colour is treated as transparent, and the final output will display non-transparent pixel belonging to other layer (Layer2 or Sprites) - if there is some non-transparent pixel in other layers, or {{NextRegNo\|$4A}} colour (of course if the layer priorities put Layer2/Sprites above ULA layer, and there's non-transparent pixel already there, it is displayed over hi-res pixels).		If the colour in palette is a match with {{NextRegNo\|$14}}, the colour is treated as transparent, and the final output will display non-transparent pixel belonging to other layer (Layer2 or Sprites) - if there is some non-transparent pixel in other layers, or {{NextRegNo\|$4A}} colour (of course if the layer priorities put Layer2/Sprites above ULA layer, and there's non-transparent pixel already there, it is displayed over hi-res pixels).

Xalior at 22:59, 19 April 2019

2019-04-19T22:59:36Z

← Older revision		Revision as of 23:59, 19 April 2019
Line 1:		Line 1:
	{{Port		{{Port
	\|Number=$xxFF		\|Number=$xxFF
	~~\|PortMask=%---- ---- 1111 1111~~
	\|ShortDesc=Controls Timex Sinclair video modes and colours in hi-res mode.		\|ShortDesc=Controls Timex Sinclair video modes and colours in hi-res mode.
	\|Readable=No		\|Readable=No
	\|Writable=Yes		\|Writable=Yes
	\|Subsystem=Enhanced ULA		\|Subsystem=Enhanced ULA
			\|PortMask=%---- ---- 1111 1111
	}}		}}
	{\| class="wikitable"		{\| class="wikitable"

Specnext: 11 revisions imported

2019-04-14T10:00:22Z

11 revisions imported

← Older revision	Revision as of 11:00, 14 April 2019
(No difference)

wiki>Ped7g: updated picture to better quality + more recent core version

2019-01-16T15:11:27Z

updated picture to better quality + more recent core version

← Older revision		Revision as of 16:11, 16 January 2019
Line 38:		Line 38:

	The various mixing modes and results can be seen for example in "LayersMixingHiRes" test of [https://github.com/MrKWatkins/ZXSpectrumNextTests ZXSpectrumNextTests] project, the resulting image (the cyan pixels are drawn by Timex hi-res layer, green are part of Layer2 and yellow are from Sprites) (colours are selected by Next ULA palette, allowing any two ink/paper colours combination from the total 512-colour space even for hi-res mode):		The various mixing modes and results can be seen for example in "LayersMixingHiRes" test of [https://github.com/MrKWatkins/ZXSpectrumNextTests ZXSpectrumNextTests] project, the resulting image (the cyan pixels are drawn by Timex hi-res layer, green are part of Layer2 and yellow are from Sprites) (colours are selected by Next ULA palette, allowing any two ink/paper colours combination from the total 512-colour space even for hi-res mode):
	[[File:~~LmxHiRes~~.~~jpg~~\|400px]]		[[File:LmxHiRes_v2.00.25.png\|400px]]

wiki>Ped7g at 12:26, 16 January 2019

2019-01-16T12:26:11Z

← Older revision		Revision as of 13:26, 16 January 2019
Line 20:		Line 20:
	\|}		\|}

	UPDATE: the index of border colour is under investigation and to be confirmed (core2.00.25 is different from 2.00.24 in this aspect).		''UPDATE: the index of border colour is under investigation and to be confirmed (core2.00.25 is different from 2.00.24 in this aspect).''

	The hi-res mode (and some parts also about other Timex modes) HW implementation details:		The hi-res mode (and some parts also about other Timex modes) HW implementation details:

wiki>Ped7g at 12:25, 16 January 2019

2019-01-16T12:25:30Z

← Older revision		Revision as of 13:25, 16 January 2019
Line 19:		Line 19:
	\| 7 \|\| Used for memory paging on the Timex Sinclair, not relevant on the Next.		\| 7 \|\| Used for memory paging on the Timex Sinclair, not relevant on the Next.
	\|}		\|}

			UPDATE: the index of border colour is under investigation and to be confirmed (core2.00.25 is different from 2.00.24 in this aspect).

	The hi-res mode (and some parts also about other Timex modes) HW implementation details:		The hi-res mode (and some parts also about other Timex modes) HW implementation details:

wiki>Ped7g: Final confirmation of how ZXN internally composes the Timex hi-res mode image for display + added photo with example.

2019-01-16T11:22:32Z

Final confirmation of how ZXN internally composes the Timex hi-res mode image for display + added photo with example.

← Older revision		Revision as of 12:22, 16 January 2019
Line 20:		Line 20:
	\|}		\|}

	~~[[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~~)~~?).~~		The hi-res mode (and some parts also about other Timex modes) HW implementation details:

	~~[[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).		The border colour is identical to paper (including the brightness), so everything described for paper does apply to border too (the hi-res mode overrides port 254 border colour, which gets ignored while hi-res mode is selected).

	~~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~~).		The Next display pipeline starts at reading the pixel data from "bank 5", which resides in BRAM of FPGA, and is mapped to $4000 and $6000 in default memory mapping (the display data are read from the BRAM, so mapping different ram into $4000..$8000 Z80 address space does not modify the screen output, to modify screen output you have to map "bank 5" to some memory and write there). These pixel data are half of "ULA" result, other half is attribute byte, which is composed as "01pppiii" value, where "iii" are the bits 3-5 from (this) $FF port, and "ppp" are complement of "iii".

			For example for bits set as %100 the ULA does accompany every pixel byte with attribute byte %01011100, i.e. "INK 4, PAPER 3, BRIGHT 1".

			If ULANext mode is enabled (bit 0 in {{NextRegNo\|$43}}), this attribute byte is decomposed by ink-mask ({{NextRegNo\|$42}}) into ink-index and paper-index, then the selected ULA palette is used to fetch particular colours (the constant 128 is added to paper and border index as in normal ULA modes), so in the example above with attribute byte %01011100 and ink-mask 7 the resulting colour will be current-ULA-palette[4] for filled-pixels, and current-ULA-palette[128+11] for paper (empty pixel) and border (with default ink-mask 15 the indices will be 12 for ink and 128+5 for paper+border).

			If the colour in palette is a match with {{NextRegNo\|$14}}, the colour is treated as transparent, and the final output will display non-transparent pixel belonging to other layer (Layer2 or Sprites) - if there is some non-transparent pixel in other layers, or {{NextRegNo\|$4A}} colour (of course if the layer priorities put Layer2/Sprites above ULA layer, and there's non-transparent pixel already there, it is displayed over hi-res pixels).

			I.e. the "pipeline" is like:
			hi-res VRAM data (or "empty" for border area) + attribute composed from port $FF -> ULANext palette conversion -> transparency check -> Next layers mixer -> final output to display.

			The various mixing modes and results can be seen for example in "LayersMixingHiRes" test of [https://github.com/MrKWatkins/ZXSpectrumNextTests ZXSpectrumNextTests] project, the resulting image (the cyan pixels are drawn by Timex hi-res layer, green are part of Layer2 and yellow are from Sprites) (colours are selected by Next ULA palette, allowing any two ink/paper colours combination from the total 512-colour space even for hi-res mode):
			[[File:LmxHiRes.jpg\|400px]]

wiki>Ped7g: Added extra technical info, how the board is expected to handle Timex Hi-Res colouring vs ULANext-palette enabled.

2019-01-15T07:01:14Z

Added extra technical info, how the board is expected to handle Timex Hi-Res colouring vs ULANext-palette enabled.

← Older revision		Revision as of 08:01, 15 January 2019
Line 13:		Line 13:
	\|-		\|-
	\| 3-5 \|\| Sets screen color combination for hi-res mode.		\| 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!		\| 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]]) 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).