1.1 --- a/ULA.txt Fri Mar 31 22:50:55 2017 +0200
1.2 +++ b/ULA.txt Tue Apr 11 15:46:32 2017 +0200
1.3 @@ -1031,7 +1031,17 @@
1.4 applied to them, although this would require the attribute data to be stored
1.5 in some kind of buffer. Thus, the following access pattern would be observed:
1.6
1.7 - Cycle: A B ... _ B ... _ B ... _ B ... _ B ... _ B ... _ B ... _ B ...
1.8 + Reads: A B _ B _ B _ B _ B _ B _ B _ B ...
1.9 +
1.10 +In modes 3 and 6, the blank display lines could be used to retrieve attribute
1.11 +data:
1.12 +
1.13 + Reads (blank): A _ A _ A _ A _ A _ A _ A _ A _ ...
1.14 + Reads (active): B _ B _ B _ B _ B _ B _ B _ B _ ...
1.15 + Reads (active): B _ B _ B _ B _ B _ B _ B _ B _ ...
1.16 + ...
1.17 +
1.18 +See below for a discussion of using this for character data as well.
1.19
1.20 A whole byte used for colour information for a whole character would result in
1.21 a choice of 256 colours, and this might be somewhat excessive. By only reading
1.22 @@ -1057,6 +1067,23 @@
1.23 208 26 x3 26 26 256 &62C0 -> &6200
1.24 208 26 x3 26 13 16 &6460 -> &6400
1.25
1.26 +Enhancement: Text-Only Modes using Cached Character and Attribute Data
1.27 +----------------------------------------------------------------------
1.28 +
1.29 +In modes 3 and 6, the blank display lines could be used to retrieve character
1.30 +and attribute data instead of trying to insert it between bitmap data accesses,
1.31 +but this data would then need to be retained:
1.32 +
1.33 + Reads: A C A C A C A C A C A C A C A C ...
1.34 + Reads: B _ B _ B _ B _ B _ B _ B _ B _ ...
1.35 +
1.36 +Only attribute (A) and character (C) reads would require screen memory
1.37 +storage. Bitmap data reads (B) would involve either accesses to memory to
1.38 +obtain character definition details or could, at the cost of special storage
1.39 +in the ULA, involve accesses within the ULA that would then free up the RAM.
1.40 +However, the CPU would not benefit from having any extra access slots due to
1.41 +the limitations of the RAM access mechanism.
1.42 +
1.43 Enhancement: MODE 7 Emulation using Character Attributes
1.44 --------------------------------------------------------
1.45
1.46 @@ -1074,6 +1101,32 @@
1.47 at least make a limited 40-column multicolour mode available as a substitute
1.48 for MODE 7.
1.49
1.50 +Using the text-only enhancement with caching of data, the storage requirements
1.51 +would be diminished substantially:
1.52 +
1.53 + Screen width Columns Rows Bytes (C) Bytes (A) Colours Screen start
1.54 + ------------ ------- ---- --------- --------- ------- ------------
1.55 + 320 40 25 40 20 16 &7A94 -> &7A00
1.56 + 320 40 25 40 10 4 &7B1E -> &7B00
1.57 + 320 40 25 40 5 2 &7B9B -> &7B00
1.58 + 320 40 25 40 0 (2) &7C18 -> &7C00
1.59 + 640 80 25 80 40 16 &7448 -> &7400
1.60 + 640 80 25 80 20 4 &763C -> &7600
1.61 + 640 80 25 80 10 2 &7736 -> &7700
1.62 + 640 80 25 80 0 (2) &7830 -> &7800
1.63 +
1.64 +Note that the colours describe the locally defined attributes for each
1.65 +character. When no attribute information is provided, the colours are defined
1.66 +globally.
1.67 +
1.68 +Enhancement: Compressed Character Data
1.69 +--------------------------------------
1.70 +
1.71 +Another observation about text-only modes is that they only need to store a
1.72 +restricted set of bitmapped data values. Encoding this set of values in a
1.73 +smaller unit of storage than a byte could possibly help to reduce the amount
1.74 +of storage and bandwidth required to reproduce the characters on the display.
1.75 +
1.76 Enhancement: High Resolution Graphics
1.77 -------------------------------------
1.78