1.1 --- a/ULA.txt Tue Jun 07 13:40:38 2016 +0200
1.2 +++ b/ULA.txt Tue Jun 07 14:54:07 2016 +0200
1.3 @@ -378,6 +378,72 @@
1.4
1.5 See: http://pastraiser.com/computers/acornelectron/acornelectron.html
1.6
1.7 +Enhancement: Mode Layouts
1.8 +-------------------------
1.9 +
1.10 +Merely changing the screen memory mappings in order to have Archimedes-style
1.11 +row-oriented screen addresses (instead of character-oriented addresses) could
1.12 +be done for the existing modes, but this might not be sufficiently beneficial,
1.13 +especially since accessing regions of the screen would involve incrementing
1.14 +pointers by amounts that are inconvenient on an 8-bit CPU.
1.15 +
1.16 +However, instead of using a Archimedes-style mapping, column-oriented screen
1.17 +addresses could be more feasibly employed: incrementing the address would
1.18 +reference the vertical screen location below the currently-referenced location
1.19 +(just as occurs within characters using the existing ULA); instead of
1.20 +returning to the top of the character row and referencing the next horizontal
1.21 +location after eight bytes, the address would reference the next character row
1.22 +and continue to reference locations downwards over the height of the screen
1.23 +until reaching the bottom; at the bottom, the next location would be the next
1.24 +horizontal location at the top of the screen.
1.25 +
1.26 +In other words, the memory layout for the screen would resemble the following
1.27 +(for MODE 2):
1.28 +
1.29 + &3000 &3100 ... &7F00
1.30 + &3001 &3101
1.31 + ... ...
1.32 + &3007
1.33 + &3008
1.34 + ...
1.35 + ... ...
1.36 + &30FF ... &7FFF
1.37 +
1.38 +Since there are 256 pixel rows, each column of locations would be addressable
1.39 +using the low byte of the address. Meanwhile, the high byte would be
1.40 +incremented to address different columns. Thus, addressing screen locations
1.41 +would become a lot more convenient and potentially much more efficient for
1.42 +certain kinds of graphical output.
1.43 +
1.44 +One potential complication with this simplified addressing scheme arises with
1.45 +hardware scrolling. Vertical hardware scrolling by one pixel row (not supported
1.46 +with the existing ULA) would be achieved by incrementing or decrementing the
1.47 +screen start address; by one character row, it would involve adding or
1.48 +subtracting 8. However, the ULA only supports multiples of 64 when changing the
1.49 +screen start address. Thus, if such a scheme were to be adopted, three
1.50 +additional bits would need to be supported in the screen start register (see
1.51 +"Hardware Scrolling (and Enhancement)" for more details). However, horizontal
1.52 +scrolling would be much improved even under the severe constraints of the
1.53 +existing ULA: only adjustments of 256 to the screen start address would be
1.54 +required to produce single-location scrolling of as few as two pixels in MODE 2
1.55 +(four pixels in MODEs 1 and 5, eight pixels otherwise).
1.56 +
1.57 +More disruptive is the effect of this alternative layout on software.
1.58 +Presumably, compatibility with the BBC Micro was the primary goal of the
1.59 +Electron's hardware design. With the character-oriented screen layout in
1.60 +place, system software (and application software accessing the screen
1.61 +directly) would be relying on this layout to run on the Electron with little
1.62 +or no modification. Although it might have been possible to change the system
1.63 +software to use this column-oriented layout instead, this would have incurred
1.64 +a development cost and caused additional work porting things like games to the
1.65 +Electron. Moreover, a separate branch of the software from that supporting the
1.66 +BBC Micro and closer derivatives would then have needed maintaining.
1.67 +
1.68 +The decision to use the character-oriented layout in the BBC Micro may have
1.69 +been related to the choice of circuitry and to facilitate a convenient
1.70 +hardware implementation, and by the time the Electron was planned, it was too
1.71 +late to do anything about this somewhat unfortunate choice.
1.72 +
1.73 Enhancement: The Missing MODE 4
1.74 -------------------------------
1.75
1.76 @@ -887,18 +953,13 @@
1.77 at least make a limited 40-column multicolour mode available as a substitute
1.78 for MODE 7.
1.79
1.80 -Enhancement: High Resolution Graphics and Mode Layouts
1.81 -------------------------------------------------------
1.82 +Enhancement: High Resolution Graphics
1.83 +-------------------------------------
1.84
1.85 -Screen modes with different screen memory mappings, higher resolutions and
1.86 -larger colour depths might be possible, but this would in most cases involve
1.87 -the allocation of more screen memory, and the ULA would probably then be
1.88 -obliged to page in such memory for the CPU to be able to sensibly access it
1.89 -all. Merely changing the memory mappings in order to have Archimedes-style
1.90 -row-oriented screen addresses (instead of character-oriented addresses) could
1.91 -be done for the existing modes, but this might not be sufficiently beneficial,
1.92 -especially since accessing regions of the screen would involve incrementing
1.93 -pointers by amounts that are inconvenient on an 8-bit CPU.
1.94 +Screen modes with higher resolutions and larger colour depths might be
1.95 +possible, but this would in most cases involve the allocation of more screen
1.96 +memory, and the ULA would probably then be obliged to page in such memory for
1.97 +the CPU to be able to sensibly access it all.
1.98
1.99 Enhancement: Genlock Support
1.100 ----------------------------