chunky graphics mode |
|||||||||||||||||||||||||||
model-b
|
A chunky graphics mode has one byte per pixel, and pixels are arranged in a logical order. (Left to right, top to bottom.) The BBC only really supports chunky type addressing in Mode 7. This isn't a very good approximation, however. You can only really use CHR$(255), which is a solid block; this block doesn't extend to the edges of each character cell, however, unless you're willing to lose the first character of each line to a graphics code, and you can't change colours along the line very easily. For better chunky graphics, however, one can set up a graphics mode but set 6845 R12 and R13 as if using teletext. This gives a 40x25 (1,000 bytes) screen, with the bitmap corresponding to each byte repeated N times in its corresponding character cell, according to R9. By writing values to the screen corresponding to a solid colour, one can get solid blocks without any of the teletext faff. This works as-is in modes 4, 5 and 6. For the other bitmap modes, some 6845 tweaking is required. For the best balance between apparent chunkiness and size of screen, use mode mode 2 and set R9 to 4 rather than 8 -- now you have a square (but small) 80x25 display. Master 128 users should be able to set up the bottom half in shadow RAM, tweak the start address so the screen ends at &8000 rather than &8000-24, and swap the CRTC source at just the right point. (Conjecture follows...) Those of us stuck with a stock BBC will have to do it in software. 4 scanlines is easily enough time to refill the row that has just been rasterised. There's only 1000 bytes on the screen, so plenty of space for a very long list of instructions. LDA &7800 (and so on :) That's 4 cycles to read and 4 cycles to write, for a grand total of 8 cycles/byte. That's 320 cycles for a full row. Each scanline is 128 cycles, so we can fill the previous row (ready for when the start address wraps round) with 1.5 scanlines to spare. We'll need 192 cycles take up the slack, which we can do with a subroutine. Assuming the BNE won't cross a page boundary:
As for the memory usage: 6 bytes (LDA ABS + STA ABS) per byte; 40 bytes so 240 bytes per row, and 3 bytes for JSR. 243*25 is 6075. Even with PAGE at &1900, that only takes us up to &30BB. (I just ignored &400-&7FF and &900-&CFF too...) I've also ignored the wrapping of the start address. We'll need two routines, one for filling the screen starting at &8000-1000 and one for filling it from &7C00, which is where the CRTC starts reading once &8000 has been hit. If we write using absolute indexed mode, each byte takes 9 cycles, for a total cost of 360 cycles per row. That's just too many. Instead, one will have to suffer the loss of 13150 bytes of RAM. Vertical rupture would be one way of getting around this. I suspect you'd need |
||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||