# HG changeset patch # User Paul Boddie # Date 1598196366 -7200 # Node ID 2636c1a88ee2e8215b38848296aa4f0f18f59a6e # Parent 97a40f11dd1c9d76075f42a450a08c668ca04859 Added notes about mode numbering and selection in the ULA, suggesting an alternative scheme. Also added a note about palette redefinition for text modes. diff -r 97a40f11dd1c -r 2636c1a88ee2 ULA.txt --- a/ULA.txt Sat Aug 22 22:42:18 2020 +0200 +++ b/ULA.txt Sun Aug 23 17:26:06 2020 +0200 @@ -719,6 +719,66 @@ Thus, for increasing mode numbers, the size of each mode would be the same or less than the preceding mode. +Enhancement: Display Mode Property Control +------------------------------------------ + +It is rather curious that the ULA supports the mode numbers directly in bits 3 +to 5 of &FE07 since these would presumably need to be decoded in order to set +the fundamental properties of the display mode. These properties are as +follows: + + * Screen data retrieval rate: number of fetches per pair of 2MHz cycles + * Pixel colour depth + * Text mode vertical spacing + +From these, the following properties emerge: + + * The number of bytes per character row + * The size of the entire display in bytes + * Pixel frequency or horizontal resolution + * The number of character rows + +One can imagine a register bitfield arrangement as follows: + + * Pixel depth: log2(depth) + (00 - 1 bit per pixel, 01 - 2 bits per pixel, 10 - 4 bits per pixel) + * Retrieval rate: 2 - fetches per cycle pair + (0 - twice, 1 - once) + * Text mode enable + (0 - disable, 1 - enable) + +This arrangement would require four bits. However, one bit in &FE07 is +seemingly inactive and might possibly be reallocated. + +The resulting combination of properties would permit all of the existing modes +plus some additional ones, including the missing MODE 4 mentioned above. With +the bitfields above ordered from the most significant bits to the least +significant bits providing the low-level "mode" values, the following table +can be produced: + + Screen mode Depth Rate Text Size (K) Colours Rows Resolution + ----------- ----- ---- ---- -------- ------- ---- ---------- + 0 (0000) 1 twice off 20 2 32 640x256 (MODE 0) + 1 (0001) 1 twice on 16 2 24 640x256 (MODE 3) + 2 (0010) 1 once off 10 2 32 320x256 (MODE 4) + 3 (0011) 1 once on 8 2 24 320x256 (MODE 6) + 4 (0100) 2 twice off 20 4 32 320x256 (MODE 1) + 5 (0101) 2 twice on 16 4 24 320x256 + 6 (0110) 2 once off 10 4 32 160x256 (MODE 5) + 7 (0111) 2 once on 8 4 24 160x256 + 8 (1000) 4 twice off 20 16 32 160x256 (MODE 2) + 9 (1001) 4 twice on 16 16 24 160x256 + 10 (1010) 4 once off 10 16 32 80x256 + 11 (1011) 4 once on 8 16 24 80x256 + +The existing modes would be covered in a way that is incompatible with the +existing numbering, thus requiring a table in software, but additional text +modes would be provided for MODE 1, MODE 5 and MODE 2. An additional two lower +resolution modes would also be conceivable within this scheme, requiring the +stretching of 16MHz pixels by a factor of eight to yield 80 pixels per +scanline. The utility of such modes is questionable and such modes might not +be supported. + Enhancement: 2MHz RAM Access ---------------------------- @@ -990,6 +1050,12 @@ at the appropriate time. Throughput/bandwidth considerations might impose restrictions on the practical length of such a list, however. +A simple form of palette definition might be useful in text modes. Within the +blank region between lines, the foreground palette could be changed to apply +to the next line. Palette values could be read from a table in RAM, perhaps +preceding the screen data, with 24 2-byte entries providing palette +redefinition support in 2- and 4-colour modes. + Enhancement: Display Synchronisation Interrupts -----------------------------------------------