# HG changeset patch # User Paul Boddie # Date 1323127696 -3600 # Node ID d8c0798e4acd06593f28efefefae7e8d7242d44c # Parent 69e7ee0e99dd530760ecb6359ef40573d156bd5d Fixed the screen size calculation for modes employing line spacing. Added notes about various scrolling, palette and display features. diff -r 69e7ee0e99dd -r d8c0798e4acd ULA.txt --- a/ULA.txt Mon Dec 05 01:20:39 2011 +0100 +++ b/ULA.txt Tue Dec 06 00:28:16 2011 +0100 @@ -11,11 +11,57 @@ XX 14 13 12 11 10 09 08 07 06 05 04 03 02 01 XX -In practice, a resolution of 8 bytes is more useful, since the mapping of -screen memory to pixel locations is character oriented. A change in 8 bytes -would permit a scrolling resolution of 2 pixels in MODE 2, 4 pixels in MODE 1 -and 5, and 8 pixels in MODE 0, 3 and 6. This resolution is actually observed -on the BBC Micro (see 18.11.2 in the BBC Microcomputer Advanced User Guide). +Arguably, a resolution of 8 bytes is more useful, since the mapping of screen +memory to pixel locations is character oriented. A change in 8 bytes would +permit a horizontal scrolling resolution of 2 pixels in MODE 2, 4 pixels in +MODE 1 and 5, and 8 pixels in MODE 0, 3 and 6. This resolution is actually +observed on the BBC Micro (see 18.11.2 in the BBC Microcomputer Advanced User +Guide). + +One argument for a 2 byte resolution is smooth vertical scrolling. A pitfall +of changing the screen address by 2 bytes is the change in the number of lines +from the initial and final character rows that need reading by the ULA, which +would need to maintain this state information. Another pitfall is the +complication that might be introduced to software writing bitmaps of character +height to the screen. + +Region Blanking +--------------- + +The problem of permitting character-oriented blitting in programs whilst +scrolling the screen by sub-character amounts could be mitigated by permitting +a region of the display to be blank, such as the final lines of the display. +Consider the following vertical scrolling by 2 bytes that would cause an +initial character row of 6 lines and a final character row of 2 lines: + + 6 lines - initial, partial character row + 248 lines - 31 complete rows + 2 lines - final, partial character row + +If a routine were in use that wrote 8 line bitmaps to the partial character +row now split in two, it would be advisable to hide one of the regions in +order to prevent content appearing in the wrong place on screen (such as +content meant to appear at the top "leaking" onto the bottom). Blanking 6 +lines would be sufficient, as can be seen from the following cases. + +Scrolling up by 2 lines: + + 6 lines - initial, partial character row + 240 lines - 30 complete rows + 4 lines - part of 1 complete row + ----------------------------------------------------------------- + 4 lines - part of 1 complete row (hidden to maintain 250 lines) + 2 lines - final, partial character row (hidden) + +Scrolling down by 2 lines: + + 2 lines - initial, partial character row + 248 lines - 31 complete rows + ---------------------------------------------------------- + 6 lines - final, partial character row (hidden) + +Thus, region blanking would impose a 250 line display with the bottom 6 lines +blank. The height of the screen could be configurable still further. Palette Definition ------------------ @@ -28,6 +74,55 @@ (colours 8 to 15), where a single byte might provide 8 bits per pixel colour specifications similar to those used on the Archimedes. +The principal limitation here is actually the hardware: the Electron has only +a single output line for each of the red, green and blue channels, and if +those outputs are strictly digital and can only be set to a "high" and "low" +value, then only the existing eight colours are possible. If a modern ULA were +able to output analogue values, it would still need to be assessed whether the +circuitry could successfully handle and propagate such values. + +Palette Definition Lists +------------------------ + +It can be useful to redefine the palette in order to change the colours +available for a particular region of the screen, particularly in modes where +the choice of colours is constrained, and if an increased colour depth were +available, palette redefinition would be useful to give the illusion of more +than 16 colours in MODE 2. Traditionally, palette redefinition has been done +by using interrupt-driven timers, but a more efficient approach would involve +presenting lists of palette definitions to the ULA so that it can change the +palette at a particular display line. + +One might define a palette redefinition list in a region of memory and then +communicate its contents to the ULA by writing the address and length of the +list, along with the display line at which the palette is to be changed, to +ULA registers such that the ULA buffers the list and performs the redefinition +at the appropriate time. Throughput/bandwidth considerations might impose +restrictions on the practical length of such a list, however. + +Palette-Free Modes +------------------ + +Palette-free modes might be defined where bit values directly correspond to +the red, green and blue channels, although this would mostly make sense only +for modes with depths greater than the standard 4 bits per pixel, and such +modes would require more memory than MODE 2 if they were to have an acceptable +resolution. + +Display Suspend +--------------- + +Especially when writing to the screen memory, it could be beneficial to be +able to suspend the ULA's access to the memory, instead producing blank values +for all screen pixels until a program is ready to reveal the screen. This is +different from palette blanking since with a blank palette, the ULA is still +reading screen memory and translating its contents into pixel values that end +up being blank. + +This function is reminiscent of a capability of the ZX81, albeit necessary on +that hardware to reduce the load on the system CPU which was responsible for +producing the video output. + Hardware Sprites ---------------- @@ -37,7 +132,10 @@ locations (for example, &FE20 and &FE21) as a pair of registers referencing a region of memory from which a sprite might be found and potentially copied into internal RAM, with other locations (for example, &FE22 and &FE23) -providing the size of the region. +providing the size of the region. Alternatively, one might write the region +location and size through a single ULA location, with the ULA being put into a +particular state after each write. For example: read LSB of region, read MSB +of region, read size, read height. Enhanced Graphics ----------------- diff -r 69e7ee0e99dd -r d8c0798e4acd ula.py --- a/ula.py Mon Dec 05 01:20:39 2011 +0100 +++ b/ula.py Tue Dec 06 00:28:16 2011 +0100 @@ -81,9 +81,11 @@ row_size = (self.width * self.depth * LINES_PER_ROW) / 8 # bits per row -> bytes per row # Memory access configuration. + # Note the limitation on positioning the screen start. - self.screen_size = row_size * rows - self.screen_start = (SCREEN_LIMIT - self.screen_size) & 0xff00 # limitation on positioning + screen_size = row_size * rows + self.screen_start = (SCREEN_LIMIT - screen_size) & 0xff00 + self.screen_size = SCREEN_LIMIT - self.screen_start # Scanline configuration.