Handling of 8-colors mode

[grafvonb]

Could someone please, from the QL design team or similar explain this "crazy" idea for the design of the QL's screen memory...

Code: Select all

   lea  $20000,a0
    
    move.w  #%0000000000000001,(a0)+    ;one point blue
    move.w  #%0000000000000010,(a0)+    ;one point red
    move.w  #%0000000000000011,(a0)+    ;one point magenta
    move.w  #%0000001000000000,(a0)+    ;one point green
    move.w  #%0000001000000001,(a0)+    ;one point cyan
    move.w  #%0000001000000010,(a0)+    ;one point yellow
    move.w  #%0000001000000011,(a0)+    ;one point white

    move.w  #%0000000001010101,(a0)+    ;line of 4-points blue
    move.w  #%0000000010101010,(a0)+    ;line of 4-points red
    move.w  #%0000000011111111,(a0)+    ;line of 4-points magenta
    move.w  #%1010101000000000,(a0)+    ;line of 4-points green
    move.w  #%1010101001010101,(a0)+    ;line of 4-points cyan 
    move.w  #%1010101010101010,(a0)+    ;line of 4-points yellow
    move.w  #%1010101011111111,(a0)+    ;line of 4-points white

    clr.l   d0
    rts

How can I easily e.g. scroll some texts or graphics using this schema?
It is a little bit better as this one of ZX Spectrum (you know what I mean) but I still do no get the reason for such decision.
And I just wanted to use "shift left" to scroll some bits...

[M68008]

I don't think anybody from the QL design team is on this forum.
Not sure why the bits for the same pixel span two bytes. The difference between mode 4 and mode 8 makes sense, though: 2 bits (and 2 bytes) represent the same amount of horizontal space in the scanline in either mode.

Anyways, you CAN use shifts to shift left/right, the MOVEP instruction can be used to simplify the code.
e.g (from memory, 100% untested) for scrolling left 64 pixels in mode 4 (mode 8 is similar, just repeat twice the lsl/roxl instructions in the middle!):

Code: Select all

; read
movep.l  0(a0),d0    ; read 32 bits, green
movep.l  8(a0),d1    ; next 32 bits green
movep.l  1(a0),d2    ; 32 bits, red
movep.l  9(a0),d3    ; next 32 bits, red

; scroll
lsl.l    #1,d1       ; scroll green
roxl.l   #1,d0
lsl.l    #1,d3       ; scroll red
roxl.l   #1,d2

; write
movep.l  d0,0(a0)    ; write back scrolled pixels
movep.l  d1,8(a0)
movep.l  d2,1(a0)
movep.l  d3,9(a0)

This is relatively efficient, except for the MOVEP instruction having a longer encoding than MOVE.

The QL is slow for scrolling or any other full-screen animation, but I think the Spectrum had similar limitations (plus the funny screen row order).

[tofro]

I can't give you an answer to the "why" other than that Sinclair's design goals have always been saving cost on hardware rather than making programmers happy. Today we need to live with these decisions. In other words: Where's the fun with old computers if they don't put one or the other challenge on you

The easy way:

Scroll in 4 Pixel increments. That is, move pixels word-wise up or down in memory. That's sort of cheating, but fast and easy to program.

If that's too jerky for your purposes, you need to grasp the nettle and scroll pixel-wise - use the above MOVEP method, it's the fastest, if I remember right.

Tobias

[tcat]

Hi,

What is the quality of `MOVEP' instruction here, I never used, just reading about in MC68008 reference book. It is `move peripheral' aiding communication with 8-bit peripherals, since QL is 8-bit data bus, I miss the point.

Also, what use is ROXL, (`rotate with extend'), why we need extend flag here?

I recall there was a `copy block' frame buffer routine coded by Linus Torvalds, that can move arbitrary display area pixelwise with overlap, any direction. Not sure can be used for this purpose.

Tomas

[tofro]

Tomas,

MOVEP is useful here because it can be employed to read every other byte from memory into a long word in a register and thus match the specific layout of the QL's screeen memory.

(shows MODE 4 layout)

Code: Select all

+--------+--------+--------+--------+--------+--------+--------+--------+
|GGGGGGGG|RRRRRRRR|GGGGGGGG|RRRRRRRR|GGGGGGGG|RRRRRRRR|GGGGGGGG|RRRRRRRR|         Video Memory
|76543210|76543210|76543210|76543210|76543210|76543210|76543210|76543210|
+--------+--------+--------+--------+--------+--------+--------+--------+
    |                  |                |                 |
    |                  |                |                 |
    |                  |                |                 |
    |       +----------+ +--------------+      +----------+
    |       |       +----+  +------------------+
    |       |       |       |
 GGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGG             Register
 76543210765432107654321076543210         

So, the MOVEP 0(a0),d0 moves all green bits from alternating bytes in the video memory into one single long word, no shifting involved. We do this twice and have two longwords full of (made) consecutive green bits from video memory in d0 and d1.

The next instruction, LSL.L #1,d1 shifts the right "green" long word one position to the left, the bit shifted out on top ends up in the C and X flags.
The next instruction, ROXL.l #1,d0 shifts d0 to the left just as well as the above, but instead of shifting in a "0" bit on the lower, (rightmost in terms of pixels) end like LSL does, it takes this new rightmost bit from the X flag, thus the one we shifted out with the previous LSL. This allows you to shift bits across register boundaries. (At this point, we should save the X flag somewhere, otherwise we loose this bit just shifted out)

Next thing we do is MOVEP the two shifted registers back to video memory into their proper places. Voilá, 64 green pixels shifted to the left.

Tobias

[tcat]

Hi Tobias,

Voilá, 64 green pixels shifted to the left.

This is rather ingenious, packing lower bytes of 4 words into a single long.
This applies to MODE 4, how about MODE 8. I guess this way we can shift only half of the pixels, i.e. 32, but they have to be rotated/shifted by 2 bits a time. Right?

Can we see an example for MODE 8?

Tomas

[tofro]

Hi Tobias,
Can we see an example for MODE 8?

Tomas

Well you esentially do the same thing - You simply divide the screen memory in a green/flash and red/blue longword, which have to be shifted by two bits instead of one. Note the shifts/rotates must come in pairs to work properly as there is only one X flag .

The downside of MOVEP is a bit of a memory access penalty (which I don't think really matters on the 68008) and that it's not supported on all CPU variants (68060, SMSQ/E emulates the instruction there with severe penalties).

The other thing is it's a bit of an esoteric instruction, so always the last thats supported properly on FPGA cores.

Tobias

[tcat]

Hi,

The QL is slow for scrolling or any other full-screen animation, but I think the Spectrum had similar limitations (plus the funny screen row order).

This may be slightly off topic. `ZX funny row addressing' was ever mind boggling for me, until recently, I came across a good reasoning found in print `Advanced Spectrum Machine Language, by David Webb'.

Code: Select all

8K screen buffer starts at $4000
|       HI-BYTE          |     LO-BYTE        |
|010 | xxx | row no=0..7 | xxx | col no=0..31 |
     |      LINE NO 0..23      |

The CHARS routine just needs to increment HI-BYTE when putting out a 8x8 fount character onto the screen. So is the speed reason. Also it may be user perceived as faster to display a SCREEN$ file from the microdrive, rather line by line.

As for QL, the ZX successor, code named `ZX83', marvel of technology at its days. I found it easy to code, displaying 8x8 chars from ZX fount set on the QL in MODE 4, but that is only 64 chars across. Perhaps that was initial design thought, that evolved then.

QL beats IBM PC XT in terms of speed at a fraction of the cost, to do that, it also needed more than 64 chars across. That was Sir. Clive leaping over IBM, Mac, and other desktops, in that TV advert, anyone seen? Renaming machine to the QL (Quantum Leap) for effective marketing.
https://www.youtube.com/watch?v=hc3kGyYyqgQ
Just my thinking, not sure.

Tom