paul@0 | 1 | Hardware Scrolling
|
paul@0 | 2 | ------------------
|
paul@0 | 3 |
|
paul@0 | 4 | On the standard ULA, &FE02 and &FE03 map to a 9 significant bits address with
|
paul@0 | 5 | the least significant 5 bits being zero, thus limiting the scrolling
|
paul@0 | 6 | resolution to 64 bytes. An enhanced ULA could support a resolution of 2 bytes
|
paul@0 | 7 | using the same layout of these addresses.
|
paul@0 | 8 |
|
paul@0 | 9 | |--&FE02--------------| |--&FE03--------------|
|
paul@0 | 10 | XX XX 14 13 12 11 10 09 08 07 06 XX XX XX XX XX
|
paul@0 | 11 |
|
paul@0 | 12 | XX 14 13 12 11 10 09 08 07 06 05 04 03 02 01 XX
|
paul@0 | 13 |
|
paul@4 | 14 | Arguably, a resolution of 8 bytes is more useful, since the mapping of screen
|
paul@4 | 15 | memory to pixel locations is character oriented. A change in 8 bytes would
|
paul@4 | 16 | permit a horizontal scrolling resolution of 2 pixels in MODE 2, 4 pixels in
|
paul@4 | 17 | MODE 1 and 5, and 8 pixels in MODE 0, 3 and 6. This resolution is actually
|
paul@4 | 18 | observed on the BBC Micro (see 18.11.2 in the BBC Microcomputer Advanced User
|
paul@4 | 19 | Guide).
|
paul@4 | 20 |
|
paul@4 | 21 | One argument for a 2 byte resolution is smooth vertical scrolling. A pitfall
|
paul@4 | 22 | of changing the screen address by 2 bytes is the change in the number of lines
|
paul@4 | 23 | from the initial and final character rows that need reading by the ULA, which
|
paul@4 | 24 | would need to maintain this state information. Another pitfall is the
|
paul@4 | 25 | complication that might be introduced to software writing bitmaps of character
|
paul@4 | 26 | height to the screen.
|
paul@4 | 27 |
|
paul@4 | 28 | Region Blanking
|
paul@4 | 29 | ---------------
|
paul@4 | 30 |
|
paul@4 | 31 | The problem of permitting character-oriented blitting in programs whilst
|
paul@4 | 32 | scrolling the screen by sub-character amounts could be mitigated by permitting
|
paul@4 | 33 | a region of the display to be blank, such as the final lines of the display.
|
paul@4 | 34 | Consider the following vertical scrolling by 2 bytes that would cause an
|
paul@4 | 35 | initial character row of 6 lines and a final character row of 2 lines:
|
paul@4 | 36 |
|
paul@4 | 37 | 6 lines - initial, partial character row
|
paul@4 | 38 | 248 lines - 31 complete rows
|
paul@4 | 39 | 2 lines - final, partial character row
|
paul@4 | 40 |
|
paul@4 | 41 | If a routine were in use that wrote 8 line bitmaps to the partial character
|
paul@4 | 42 | row now split in two, it would be advisable to hide one of the regions in
|
paul@4 | 43 | order to prevent content appearing in the wrong place on screen (such as
|
paul@4 | 44 | content meant to appear at the top "leaking" onto the bottom). Blanking 6
|
paul@4 | 45 | lines would be sufficient, as can be seen from the following cases.
|
paul@4 | 46 |
|
paul@4 | 47 | Scrolling up by 2 lines:
|
paul@4 | 48 |
|
paul@4 | 49 | 6 lines - initial, partial character row
|
paul@4 | 50 | 240 lines - 30 complete rows
|
paul@4 | 51 | 4 lines - part of 1 complete row
|
paul@4 | 52 | -----------------------------------------------------------------
|
paul@4 | 53 | 4 lines - part of 1 complete row (hidden to maintain 250 lines)
|
paul@4 | 54 | 2 lines - final, partial character row (hidden)
|
paul@4 | 55 |
|
paul@4 | 56 | Scrolling down by 2 lines:
|
paul@4 | 57 |
|
paul@4 | 58 | 2 lines - initial, partial character row
|
paul@4 | 59 | 248 lines - 31 complete rows
|
paul@4 | 60 | ----------------------------------------------------------
|
paul@4 | 61 | 6 lines - final, partial character row (hidden)
|
paul@4 | 62 |
|
paul@4 | 63 | Thus, region blanking would impose a 250 line display with the bottom 6 lines
|
paul@4 | 64 | blank. The height of the screen could be configurable still further.
|
paul@0 | 65 |
|
paul@0 | 66 | Palette Definition
|
paul@0 | 67 | ------------------
|
paul@0 | 68 |
|
paul@0 | 69 | Since all memory accesses go via the ULA, an enhanced ULA could employ more
|
paul@0 | 70 | specific addresses than &FE*X to perform enhanced functions. For example, the
|
paul@0 | 71 | palette control is done using &FE*8-F and merely involves selecting predefined
|
paul@0 | 72 | colours, whereas an enhanced ULA could support the redefinition of all 16
|
paul@0 | 73 | colours using specific ranges such as &FE18-F (colours 0 to 7) and &FE28-F
|
paul@0 | 74 | (colours 8 to 15), where a single byte might provide 8 bits per pixel colour
|
paul@0 | 75 | specifications similar to those used on the Archimedes.
|
paul@0 | 76 |
|
paul@4 | 77 | The principal limitation here is actually the hardware: the Electron has only
|
paul@4 | 78 | a single output line for each of the red, green and blue channels, and if
|
paul@4 | 79 | those outputs are strictly digital and can only be set to a "high" and "low"
|
paul@4 | 80 | value, then only the existing eight colours are possible. If a modern ULA were
|
paul@4 | 81 | able to output analogue values, it would still need to be assessed whether the
|
paul@4 | 82 | circuitry could successfully handle and propagate such values.
|
paul@4 | 83 |
|
paul@4 | 84 | Palette Definition Lists
|
paul@4 | 85 | ------------------------
|
paul@4 | 86 |
|
paul@4 | 87 | It can be useful to redefine the palette in order to change the colours
|
paul@4 | 88 | available for a particular region of the screen, particularly in modes where
|
paul@4 | 89 | the choice of colours is constrained, and if an increased colour depth were
|
paul@4 | 90 | available, palette redefinition would be useful to give the illusion of more
|
paul@4 | 91 | than 16 colours in MODE 2. Traditionally, palette redefinition has been done
|
paul@4 | 92 | by using interrupt-driven timers, but a more efficient approach would involve
|
paul@4 | 93 | presenting lists of palette definitions to the ULA so that it can change the
|
paul@4 | 94 | palette at a particular display line.
|
paul@4 | 95 |
|
paul@4 | 96 | One might define a palette redefinition list in a region of memory and then
|
paul@4 | 97 | communicate its contents to the ULA by writing the address and length of the
|
paul@4 | 98 | list, along with the display line at which the palette is to be changed, to
|
paul@4 | 99 | ULA registers such that the ULA buffers the list and performs the redefinition
|
paul@4 | 100 | at the appropriate time. Throughput/bandwidth considerations might impose
|
paul@4 | 101 | restrictions on the practical length of such a list, however.
|
paul@4 | 102 |
|
paul@4 | 103 | Palette-Free Modes
|
paul@4 | 104 | ------------------
|
paul@4 | 105 |
|
paul@4 | 106 | Palette-free modes might be defined where bit values directly correspond to
|
paul@4 | 107 | the red, green and blue channels, although this would mostly make sense only
|
paul@4 | 108 | for modes with depths greater than the standard 4 bits per pixel, and such
|
paul@4 | 109 | modes would require more memory than MODE 2 if they were to have an acceptable
|
paul@4 | 110 | resolution.
|
paul@4 | 111 |
|
paul@4 | 112 | Display Suspend
|
paul@4 | 113 | ---------------
|
paul@4 | 114 |
|
paul@4 | 115 | Especially when writing to the screen memory, it could be beneficial to be
|
paul@4 | 116 | able to suspend the ULA's access to the memory, instead producing blank values
|
paul@4 | 117 | for all screen pixels until a program is ready to reveal the screen. This is
|
paul@4 | 118 | different from palette blanking since with a blank palette, the ULA is still
|
paul@4 | 119 | reading screen memory and translating its contents into pixel values that end
|
paul@4 | 120 | up being blank.
|
paul@4 | 121 |
|
paul@4 | 122 | This function is reminiscent of a capability of the ZX81, albeit necessary on
|
paul@4 | 123 | that hardware to reduce the load on the system CPU which was responsible for
|
paul@4 | 124 | producing the video output.
|
paul@4 | 125 |
|
paul@0 | 126 | Hardware Sprites
|
paul@0 | 127 | ----------------
|
paul@0 | 128 |
|
paul@0 | 129 | An enhanced ULA might provide hardware sprites, but this would be done in an
|
paul@0 | 130 | way that is incompatible with the standard ULA, since no &FE*X locations are
|
paul@0 | 131 | available for allocation. In a special ULA mode, one might allocate a pair of
|
paul@0 | 132 | locations (for example, &FE20 and &FE21) as a pair of registers referencing a
|
paul@0 | 133 | region of memory from which a sprite might be found and potentially copied
|
paul@0 | 134 | into internal RAM, with other locations (for example, &FE22 and &FE23)
|
paul@4 | 135 | providing the size of the region. Alternatively, one might write the region
|
paul@4 | 136 | location and size through a single ULA location, with the ULA being put into a
|
paul@4 | 137 | particular state after each write. For example: read LSB of region, read MSB
|
paul@4 | 138 | of region, read size, read height.
|
paul@0 | 139 |
|
paul@0 | 140 | Enhanced Graphics
|
paul@0 | 141 | -----------------
|
paul@0 | 142 |
|
paul@0 | 143 | Screen modes with different screen memory mappings, higher resolutions and
|
paul@0 | 144 | larger colour depths might be possible, but this would in most cases involve
|
paul@0 | 145 | the allocation of more screen memory, and the ULA would probably then be
|
paul@0 | 146 | obliged to page in such memory for the CPU to be able to sensibly access it
|
paul@0 | 147 | all. Merely changing the memory mappings in order to have Archimedes-style
|
paul@0 | 148 | row-oriented screen addresses (instead of character-oriented addresses) could
|
paul@0 | 149 | be done for the existing modes, but this might not be sufficiently beneficial,
|
paul@0 | 150 | especially since accessing regions of the screen would involve incrementing
|
paul@0 | 151 | pointers by amounts that are inconvenient on an 8-bit CPU.
|
paul@0 | 152 |
|
paul@0 | 153 | Enhanced Sound
|
paul@0 | 154 | --------------
|
paul@0 | 155 |
|
paul@0 | 156 | The standard ULA reserves &FE*6 for sound generation and cassette
|
paul@0 | 157 | input/output, thus making it impossible to support multiple channels within
|
paul@0 | 158 | the given framework. The BBC Micro ULA employs &FE40-&FE4F for sound control,
|
paul@0 | 159 | and an enhanced ULA could adopt this interface.
|
paul@0 | 160 |
|
paul@0 | 161 | Waveform Upload
|
paul@0 | 162 | ---------------
|
paul@0 | 163 |
|
paul@0 | 164 | As with a hardware sprite function, waveforms could be uploaded or referenced
|
paul@0 | 165 | using locations as registers referencing memory regions.
|
paul@0 | 166 |
|
paul@0 | 167 | BBC ULA Compatibility
|
paul@0 | 168 | ---------------------
|
paul@0 | 169 |
|
paul@0 | 170 | Although some new ULA functions could be defined in a way that is also
|
paul@0 | 171 | compatible with the BBC Micro, the BBC ULA is itself incompatible with the
|
paul@0 | 172 | Electron ULA: &FE00-7 is reserved for the video controller in the BBC memory
|
paul@0 | 173 | map, but controls various functions specific to the 6845 video controller;
|
paul@0 | 174 | &FE08-F is reserved for the serial controller. It therefore becomes possible
|
paul@0 | 175 | to disregard compatibility where compatibility is already disregarded for a
|
paul@0 | 176 | particular area of functionality.
|
paul@0 | 177 |
|
paul@0 | 178 | &FE20-F maps to video ULA functionality on the BBC Micro which provides
|
paul@0 | 179 | control over the palette (using address &FE21, compared to &FE07-F on the
|
paul@0 | 180 | Electron) and other system-specific functions. Since the location usage is
|
paul@0 | 181 | generally incompatible, this region could be reused for other purposes.
|