Timex Sinclair Video Mode Control: Difference between revisions
No edit summary |
Added extra technical info, how the board is expected to handle Timex Hi-Res colouring vs ULANext-palette enabled. |
||
| 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). | |||
Revision as of 07:01, 15 January 2019
| Number | PortNumber::$xxFF |
|---|---|
| Decimal | NumberDec:: |
| Short desc. | ShortDesc::Controls Timex Sinclair video modes and colours in hi-res mode. |
| Bit Mask | PortMask::%---- ---- 1111 1111 |
| Readable | Readable::No |
| Writable | Writable::Yes |
| Subsystem | 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 {{#ask: TBRegisterNumber::$42 }} ($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).