Handling of 8-colors mode

Anything QL Software or Programming Related.
User avatar
grafvonb
Chuggy Microdrive
Posts: 70
Joined: Sat Jan 05, 2019 7:54 am
Location: Frankfurt/Germany

Handling of 8-colors mode

Postby grafvonb » Wed Feb 12, 2020 8:06 pm

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...


Loving QL & ZX Spectrum & Amiga...
User avatar
M68008
Bent Pin Expansion Port
Posts: 98
Joined: Sat Jan 29, 2011 1:55 am
Contact:

Re: Handling of 8-colors mode

Postby M68008 » Wed Feb 12, 2020 9:07 pm

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).


User avatar
tofro
QL Wafer Drive
Posts: 1935
Joined: Sun Feb 13, 2011 10:53 pm
Location: SW Germany

Re: Handling of 8-colors mode

Postby tofro » Wed Feb 12, 2020 9:17 pm

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 :D

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


ʎɐqǝ ɯoɹɟ ǝq oʇ ƃuᴉoƃ ʇou sᴉ pɹɐoqʎǝʞ ʇxǝu ʎɯ 'ɹɐǝp ɥO
tcat
Super Gold Card
Posts: 605
Joined: Fri Jan 18, 2013 5:27 pm
Location: Prague, Czech Republic

Re: Handling of 8-colors mode

Postby tcat » Fri Feb 14, 2020 8:50 am

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


User avatar
tofro
QL Wafer Drive
Posts: 1935
Joined: Sun Feb 13, 2011 10:53 pm
Location: SW Germany

Re: Handling of 8-colors mode

Postby tofro » Fri Feb 14, 2020 10:40 am

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


ʎɐqǝ ɯoɹɟ ǝq oʇ ƃuᴉoƃ ʇou sᴉ pɹɐoqʎǝʞ ʇxǝu ʎɯ 'ɹɐǝp ɥO
tcat
Super Gold Card
Posts: 605
Joined: Fri Jan 18, 2013 5:27 pm
Location: Prague, Czech Republic

Re: Handling of 8-colors mode

Postby tcat » Fri Feb 14, 2020 1:09 pm

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


User avatar
tofro
QL Wafer Drive
Posts: 1935
Joined: Sun Feb 13, 2011 10:53 pm
Location: SW Germany

Re: Handling of 8-colors mode

Postby tofro » Fri Feb 14, 2020 2:03 pm

tcat wrote: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


ʎɐqǝ ɯoɹɟ ǝq oʇ ƃuᴉoƃ ʇou sᴉ pɹɐoqʎǝʞ ʇxǝu ʎɯ 'ɹɐǝp ɥO
tcat
Super Gold Card
Posts: 605
Joined: Fri Jan 18, 2013 5:27 pm
Location: Prague, Czech Republic

Re: Handling of 8-colors mode

Postby tcat » Fri Feb 14, 2020 5:07 pm

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



Who is online

Users browsing this forum: No registered users and 11 guests