1.1 --- a/ULA.txt Sat Aug 22 22:42:18 2020 +0200
1.2 +++ b/ULA.txt Sun Aug 23 17:26:06 2020 +0200
1.3 @@ -719,6 +719,66 @@
1.4 Thus, for increasing mode numbers, the size of each mode would be the same or
1.5 less than the preceding mode.
1.6
1.7 +Enhancement: Display Mode Property Control
1.8 +------------------------------------------
1.9 +
1.10 +It is rather curious that the ULA supports the mode numbers directly in bits 3
1.11 +to 5 of &FE07 since these would presumably need to be decoded in order to set
1.12 +the fundamental properties of the display mode. These properties are as
1.13 +follows:
1.14 +
1.15 + * Screen data retrieval rate: number of fetches per pair of 2MHz cycles
1.16 + * Pixel colour depth
1.17 + * Text mode vertical spacing
1.18 +
1.19 +From these, the following properties emerge:
1.20 +
1.21 + * The number of bytes per character row
1.22 + * The size of the entire display in bytes
1.23 + * Pixel frequency or horizontal resolution
1.24 + * The number of character rows
1.25 +
1.26 +One can imagine a register bitfield arrangement as follows:
1.27 +
1.28 + * Pixel depth: log2(depth)
1.29 + (00 - 1 bit per pixel, 01 - 2 bits per pixel, 10 - 4 bits per pixel)
1.30 + * Retrieval rate: 2 - fetches per cycle pair
1.31 + (0 - twice, 1 - once)
1.32 + * Text mode enable
1.33 + (0 - disable, 1 - enable)
1.34 +
1.35 +This arrangement would require four bits. However, one bit in &FE07 is
1.36 +seemingly inactive and might possibly be reallocated.
1.37 +
1.38 +The resulting combination of properties would permit all of the existing modes
1.39 +plus some additional ones, including the missing MODE 4 mentioned above. With
1.40 +the bitfields above ordered from the most significant bits to the least
1.41 +significant bits providing the low-level "mode" values, the following table
1.42 +can be produced:
1.43 +
1.44 + Screen mode Depth Rate Text Size (K) Colours Rows Resolution
1.45 + ----------- ----- ---- ---- -------- ------- ---- ----------
1.46 + 0 (0000) 1 twice off 20 2 32 640x256 (MODE 0)
1.47 + 1 (0001) 1 twice on 16 2 24 640x256 (MODE 3)
1.48 + 2 (0010) 1 once off 10 2 32 320x256 (MODE 4)
1.49 + 3 (0011) 1 once on 8 2 24 320x256 (MODE 6)
1.50 + 4 (0100) 2 twice off 20 4 32 320x256 (MODE 1)
1.51 + 5 (0101) 2 twice on 16 4 24 320x256
1.52 + 6 (0110) 2 once off 10 4 32 160x256 (MODE 5)
1.53 + 7 (0111) 2 once on 8 4 24 160x256
1.54 + 8 (1000) 4 twice off 20 16 32 160x256 (MODE 2)
1.55 + 9 (1001) 4 twice on 16 16 24 160x256
1.56 + 10 (1010) 4 once off 10 16 32 80x256
1.57 + 11 (1011) 4 once on 8 16 24 80x256
1.58 +
1.59 +The existing modes would be covered in a way that is incompatible with the
1.60 +existing numbering, thus requiring a table in software, but additional text
1.61 +modes would be provided for MODE 1, MODE 5 and MODE 2. An additional two lower
1.62 +resolution modes would also be conceivable within this scheme, requiring the
1.63 +stretching of 16MHz pixels by a factor of eight to yield 80 pixels per
1.64 +scanline. The utility of such modes is questionable and such modes might not
1.65 +be supported.
1.66 +
1.67 Enhancement: 2MHz RAM Access
1.68 ----------------------------
1.69
1.70 @@ -990,6 +1050,12 @@
1.71 at the appropriate time. Throughput/bandwidth considerations might impose
1.72 restrictions on the practical length of such a list, however.
1.73
1.74 +A simple form of palette definition might be useful in text modes. Within the
1.75 +blank region between lines, the foreground palette could be changed to apply
1.76 +to the next line. Palette values could be read from a table in RAM, perhaps
1.77 +preceding the screen data, with 24 2-byte entries providing palette
1.78 +redefinition support in 2- and 4-colour modes.
1.79 +
1.80 Enhancement: Display Synchronisation Interrupts
1.81 -----------------------------------------------
1.82