# HG changeset patch # User Paul Boddie # Date 1465304047 -7200 # Node ID cc151c813762bccb8d9890cc08e5e602f7b09fe5 # Parent da88a2fa37d8473595cdb01309264c6249a8be55 Separated out the screen layout section and described a column-oriented layout. diff -r da88a2fa37d8 -r cc151c813762 ULA.txt --- a/ULA.txt Tue Jun 07 13:40:38 2016 +0200 +++ b/ULA.txt Tue Jun 07 14:54:07 2016 +0200 @@ -378,6 +378,72 @@ See: http://pastraiser.com/computers/acornelectron/acornelectron.html +Enhancement: Mode Layouts +------------------------- + +Merely changing the screen memory mappings in order to have Archimedes-style +row-oriented screen addresses (instead of character-oriented addresses) could +be done for the existing modes, but this might not be sufficiently beneficial, +especially since accessing regions of the screen would involve incrementing +pointers by amounts that are inconvenient on an 8-bit CPU. + +However, instead of using a Archimedes-style mapping, column-oriented screen +addresses could be more feasibly employed: incrementing the address would +reference the vertical screen location below the currently-referenced location +(just as occurs within characters using the existing ULA); instead of +returning to the top of the character row and referencing the next horizontal +location after eight bytes, the address would reference the next character row +and continue to reference locations downwards over the height of the screen +until reaching the bottom; at the bottom, the next location would be the next +horizontal location at the top of the screen. + +In other words, the memory layout for the screen would resemble the following +(for MODE 2): + + &3000 &3100 ... &7F00 + &3001 &3101 + ... ... + &3007 + &3008 + ... + ... ... + &30FF ... &7FFF + +Since there are 256 pixel rows, each column of locations would be addressable +using the low byte of the address. Meanwhile, the high byte would be +incremented to address different columns. Thus, addressing screen locations +would become a lot more convenient and potentially much more efficient for +certain kinds of graphical output. + +One potential complication with this simplified addressing scheme arises with +hardware scrolling. Vertical hardware scrolling by one pixel row (not supported +with the existing ULA) would be achieved by incrementing or decrementing the +screen start address; by one character row, it would involve adding or +subtracting 8. However, the ULA only supports multiples of 64 when changing the +screen start address. Thus, if such a scheme were to be adopted, three +additional bits would need to be supported in the screen start register (see +"Hardware Scrolling (and Enhancement)" for more details). However, horizontal +scrolling would be much improved even under the severe constraints of the +existing ULA: only adjustments of 256 to the screen start address would be +required to produce single-location scrolling of as few as two pixels in MODE 2 +(four pixels in MODEs 1 and 5, eight pixels otherwise). + +More disruptive is the effect of this alternative layout on software. +Presumably, compatibility with the BBC Micro was the primary goal of the +Electron's hardware design. With the character-oriented screen layout in +place, system software (and application software accessing the screen +directly) would be relying on this layout to run on the Electron with little +or no modification. Although it might have been possible to change the system +software to use this column-oriented layout instead, this would have incurred +a development cost and caused additional work porting things like games to the +Electron. Moreover, a separate branch of the software from that supporting the +BBC Micro and closer derivatives would then have needed maintaining. + +The decision to use the character-oriented layout in the BBC Micro may have +been related to the choice of circuitry and to facilitate a convenient +hardware implementation, and by the time the Electron was planned, it was too +late to do anything about this somewhat unfortunate choice. + Enhancement: The Missing MODE 4 ------------------------------- @@ -887,18 +953,13 @@ at least make a limited 40-column multicolour mode available as a substitute for MODE 7. -Enhancement: High Resolution Graphics and Mode Layouts ------------------------------------------------------- +Enhancement: High Resolution Graphics +------------------------------------- -Screen modes with different screen memory mappings, higher resolutions and -larger colour depths might be possible, but this would in most cases involve -the allocation of more screen memory, and the ULA would probably then be -obliged to page in such memory for the CPU to be able to sensibly access it -all. Merely changing the memory mappings in order to have Archimedes-style -row-oriented screen addresses (instead of character-oriented addresses) could -be done for the existing modes, but this might not be sufficiently beneficial, -especially since accessing regions of the screen would involve incrementing -pointers by amounts that are inconvenient on an 8-bit CPU. +Screen modes with higher resolutions and larger colour depths might be +possible, but this would in most cases involve the allocation of more screen +memory, and the ULA would probably then be obliged to page in such memory for +the CPU to be able to sensibly access it all. Enhancement: Genlock Support ----------------------------