>Af0l: Separated code blocks and fixed some special characters

2015-04-11T19:13:34Z

Separated code blocks and fixed some special characters

>Wongck at 03:33, 19 February 2012

2012-02-19T03:33:32Z

← Older revision		Revision as of 23:33, 18 February 2012
Line 713:		Line 713:
	Last edited 2002-06-14		Last edited 2002-06-14
	</pre>		</pre>
			<br/><br/>
			Go back to [[Perihelion tutorial 7]]<br/>
			Proceed to [[Perihelion tutorial 9]]

	[[Category: Perihelions Atari ST M68000 tutorial]]		[[Category: Perihelions Atari ST M68000 tutorial]]

>Wongck at 14:34, 12 October 2011

2011-10-12T14:34:21Z

← Older revision		Revision as of 10:34, 12 October 2011
Line 713:		Line 713:
	Last edited 2002-06-14		Last edited 2002-06-14
	</pre>		</pre>
	[[Category:~~Category~~ Perihelions Atari ST M68000 tutorial]]
	~~[[Category:Programming]]~~		[[Category: Perihelions Atari ST M68000 tutorial]]
	~~[[Category:Assembly Language~~]]

>Silver Surfer: clean up

2009-05-03T15:38:59Z

clean up

← Older revision		Revision as of 11:38, 3 May 2009
Line 715:		Line 715:
	[[Category:Category Perihelions Atari ST M68000 tutorial]]		[[Category:Category Perihelions Atari ST M68000 tutorial]]
	[[Category:Programming]]		[[Category:Programming]]
			[[Category:Assembly Language]]

>Silver Surfer: Added category

2009-05-02T19:52:53Z

Added category

← Older revision		Revision as of 15:52, 2 May 2009
Line 1:		Line 1:
	<pre>		<pre>
	~~[[Category:Category Perihelions Atari ST M68000 tutorial]]~~

	The Atari ST M68000 tutorial part 8 â€“ of scrolling 8 pixels per VBL using double buffer		The Atari ST M68000 tutorial part 8 â€“ of scrolling 8 pixels per VBL using double buffer
Line 714:		Line 713:
	Last edited 2002-06-14		Last edited 2002-06-14
	</pre>		</pre>
			[[Category:Category Perihelions Atari ST M68000 tutorial]]
			[[Category:Programming]]

>Zorro 2 at 15:34, 2 October 2006

2006-10-02T15:34:27Z

← Older revision		Revision as of 11:34, 2 October 2006
Line 1:		Line 1:
			<pre>
	[[Category:Category Perihelions Atari ST M68000 tutorial]]		[[Category:Category Perihelions Atari ST M68000 tutorial]]

Line 712:		Line 713:

	Last edited 2002-06-14		Last edited 2002-06-14
			</pre>

>Admin at 19:01, 31 January 2006

2006-01-31T19:01:10Z

New page

[[Category:Category Perihelions Atari ST M68000 tutorial]]

The Atari ST M68000 tutorial part 8 â€“ of scrolling 8 pixels per VBL using double buffer

In the last few days, Iâ€™ve had the great opportunity to get lots of introduction to the Atari scene. mOdmate of Checkpoint told me about #atariscne, and since then heâ€™s guided me through the stuff, giving me links to good sites and generally telling me what I need to know to orient myself. Iâ€™ve met some great people that have helped me understand things and being a better coder. Also, letâ€™s not forget the importance of Maarten Martens for converting this text file to html and banging me on the head whenever I take a wrong step. I could not write this stuff alone, lots of thanks to all of you who make this text possible. I also want to thank God, for giving me the luck and opportunity to be where I am, my mother for giving birth to me and always being there and all â€¦ (end of Hollywood speech)

In order to get an even better understanding of the bit planes, Iâ€™ve done an 8 pixel scroller. The thing with this is that you must be careful not to misalign the bit planes, which we didnâ€™t have to worry about when scrolling 16 pixels per VBL. Since not to much have changed since the 16 pixel scroller, I thought Iâ€™d cover some other stuff as well.

First, I need to cover the shift command in order to be able to tell you about double buffering (there are more than one shift command, but they'll be covered later). The shift command will shift bits either left or right, as many â€œslotsâ€ as you want to. The command for shifting left is lsl, meaning Logical Shift Left, and right is lsr for Logical Shift Right. If you have a number in d0 and right shift, like so

move.l #%10110001,d0 d0 = 177
lsr.l #2,d0
Then d0 will contain
%00101100 44

All bits will jump two spaces to the right, and 0â€™s have moved in from the left. Also note that this was the same as dividing 177 by 4 and throwing away the remainder. Left shifting will move bits to the left, and move 0â€™s in from the right. Right shifting one is the same as dividing by 2. Thus a lsr.l #2 is the same as divu.l #4, and a lsl.l #2 is the same as a mulu.l #4. Only thing is that a shift is soooo much faster than a mulu or divu, but more on that later. Itâ€™s very important to note how big the shift area is, if you have a data register filled with bits, but only shift a byte, lsr.b, only the first 8 pixels will be affected. Like so

move.w #%1010101010101010,d0
lsr.b

#4,d0

Upper byte Lower byte
d0 = %1010101 %000001010

Note how the upper byte of the word was completely unchanged by the shift operation, since we used a lsr.b operation.

Now we can go on with double buffering. This is an extremely important technique. The screen is painted by an electron beam that goes from upper left, and then sweeps one horizontal line, down to the bottom right, just as the screen coordinates. Now, what happens if you start to make changes to the screen where the electron beam is painting? You will experience flicker or a distorted line or any other horrible thing. In short, when you write to screen memory, youâ€™ll most likely interrupt the electron beam in its work.

It is possible to change the area of memory that is the screen memory, any area of memory can be the screen memory actually. So for every VBL (or even often), we can change what area of memory is the screen memory. A solution begins to crystallize. We have to screen area sized areas of memory, one which is the actual screen memory (being shown on the monitor) and the other works as a buffer.

What we do is to update the buffer, while leaving the other screen alone, in this way, nothing will happen to the screen memory while the electron beam is painting. Then, just in the beginning of the next VBL, we make the buffer the screen memory and the screen memory the buffer. In this way, we will never paint to the actual screen memory. One can also all the memory that is being displayed for the physical base, and the area of memory not being displayed for the logical base. So far, weâ€™ve gotten the address to the physical base by calling trap #2 of the XBIOS, if you call trap #3, youâ€™ll get the logical base. Usually, both of these point to the same memory area.

Instead of getting the physical address from the Atari, we will now define our own area of memory and input that address directly into memory. Thereâ€™s only one important thing to know about the screen memory; it must be on a 256 byte boundary (unless you have a Ste). What this means is that the start address of the screen memory must be a multiple of 256. This can be achieved by clearing the lower byte of the address, meaning that youâ€™ll need 256 bytes extra memory for your screen memory, so you can clear the lower byte. Why? Because clearing away the byte will clear away anything not multipliable by 256, the size of a byte.

So, how do we make a memory area the screen memory? Smack up the memory.txt file, and search for something appropriate, like â€œscreenâ€. We see this.

$FF8201 |byte |Video screen memory position (high Byte) |R/W
$FF8203 |byte |Video screen memory position (mid Byte) |R/W
$FF820D |byte |Video screen memory position (low Byte) |R/W (STe)

Sure, ok, seems to be what we need. The low byte in $ff820d is for STeâ€™s only, and should be cleared at all times to avoid trouble. Then the middle byte of the screen address goes into $ff8203 and the high byte goes into $ff8201. In order to get the middle and high byte of the screen address, we shift the address. By shifting down the eight bits constituting the byte, we can easily move out bytes from the screen address by move.b commands.

High byte Middle byte Low byte
screen %00010111 %01001101 %10111110 $174dbe

First we clear the low byte in order to put it on a 256 boundary.
move.l #screen,d0
clr.b

d0

High byte Middle byte Low byte
screen %00010111 %01001101 %00000000

Now we need to move the middle byte into $ff8203
lsr.l

#8,d0

High byte Middle byte Low byte
screen

%00000000

%00010111

%01001101

move.b d0,$ff8203

As you see, the middle byte gets shifted into the lower byte. With a move.b command the only thing we move is the lowest byte of d0. Thus, we have isolated the middle byte by shifting it into a more convenient position. Now for the last one.

lsr.w

#8,d0

High byte Middle byte Low byte
screen

%00000000

%00000000

%00010111

move.b d0,$ff8201

And thatâ€™s it. We have now cleared the lowest byte of the screen address, and moved the middle and high bytes of it into the correct memory position. screen is now the screen memory. The compact code snippet looks like this.

move.l #screen1,d0 put screen1 address in d0
clr.b

d0

put on 256 byte boundary

clr.b $ffff820d clear STe extra bit
lsr.l #8,d0
move.b d0,$ffff8203 put in mid screen address byte
lsr.w #8,d0
move.b d0,$ffff8201 put in high screen address byte
section bss
ds.b 256 256 clear buffer
screen ds.b 32000 the screen

Now, this doesnâ€™t make for any double buffer at all, since weâ€™re only using one screen. In order to achieve double buffering, we need two screen areas, and two pointers to point to each area. In each VBL, one screen is made into screen memory, and then the pointers are flipped so that the other screen is made screen memory for next VBL. This really makes what you see on the screen appear 1/50th of a second slower than what you draw.

prepare addresses

make next and last point to screen1 and screen2

main

wait VBL

move.l next,d0

make address in d0 screen address

move.l last,a0

move.l next,a1 load screens

move.l a1,last and flip them for next time around

move.l a0,next double buffering :)

* loads the screen addresses and flips them around

do your stuff, like putting graphics to the address in a1

repeat main loop

section data

last dc.l 0

next dc.l 0

section bss

ds.b 256

screen1 ds.b 32000

screen2 ds.b 32000

I also thought we might mention timing as well. This is quite the issue really, as you must have understood, you canâ€™t perform an infinite number of instructions. Included here should be two text files, called CYCTIMES.TXT and PIXELTIM.TXT. The CYCTIMES.TXT explains how much time it takes to do each instruction. This can vary greatly, for example, a division takes way over 100 clock cycles, and a shift takes under 10, so you see, itâ€™s a good thing to replace your divuâ€™s with lslâ€™s if possible. Also, when you can, work with byte or word size, instead of long, since this saves some time also. Clock cycle is the quantity in which â€œtimeâ€ is measured. Each instruction takes a certain amount of clock cycles.

The PIXELTIM.TXT was extracted by me from the ST Internals text file by Jim Boulton. One interesting thing to note there is the amount of clock cycles per VBL; 160256. This is a very exact number, and if your main loop ever takes more time than that, youâ€™re screwed (if you work with VBL main loops as weâ€™ve done so far that is). One way to get a graphical pointer of how much time your main routine does take, is to change the background colour just at the start of the routine, then change it back in the end.

Letâ€™s say we have a routine that takes 80000 clock cycles, our original background is black, but in the beginning of our main loop, we set it to red. What will happen is that the electron beam will paint red background, but when our 80000 clock cycles worth of instructions have taken place, the background is switched back to black, which means that for the time it takes to wait for the next VBL, the electron beam will paint black. So, in this case, the screen would be half red background and half black background. If we use this technique, weâ€™ll see exactly how much time our main routine takes. The example program in this tutorial takes up most of the processor, which leaves little time for other stuff to be done. Granted, the scroller is completely un-optimized.

Phew, now we have covered lots of small things of big importance. Finally, now comes the 8 pixel scroller part. Just look at the source code, itâ€™s well commented. Nah, Iâ€™m just kidding with you, of course Iâ€™ll explain. Since we now want to scroll 8 pixels, this means for starters that we need to move bytes. The first byte represents the first 8 pixels, and the second the coming 8 pixels. Then, the third word again has to do with the first 8 pixels, and the fourth word has to do with the 8 coming pixels and so on. Thus, we cannot simply barge in and do some scroll loop. We need to move every second byte.

Index First byte Index Second byte
0 %11000000 1 %00000000 first word
2 %11000000 3 %00000101 second word
4 %01000000 5 %00000110 third word
6

%01100000

7

%00000000

fourth word

0-7

$3F800000

8-15

$00000642

pixels

Index First byte Index Second byte
8 %00000110 9 %00100000 first word
10 %00000010 11 %00100100 second word
12 %00000000 13 %10000010 third word
14 %00100010 15 %00010000 fourth word
16-23 $008001B0 24-31 $40380240 pixels

It is tempting to read the memory top down, but this is not so, it is to be read from left to right. So index 5 for example is the second byte in the third word, and affects pixels 8 â€“ 15. The memory without comments look like this, split into bytes for ease of reading.

%11000000 %00000000 %11000000 %00000101 %01000000
%00000110 %01100000 %00000000 %00000110 %00100000
%00000010 %00100100 %00000000 %10000010 %00100010
%00010000 â€¦

So in order to scroll 8 pixels, index 0, 2, 4 and 6 will de dropped, because they represent the first 8 pixels. Then index 1, 3, 5 and 7 will be moved into index 0, 2, 4 and 6. Then index 8, 10, 12 and 14 will be moved into index 1, 3, 5 and 7. Then index 9, 11, 13 and 15 will be moved into index 8, 10, 12 and 14. This will make pixels 0-7 to drop, 8-15 to be moved into 0-7, 16-23 will be moved into 8-15 and 24-31 will move into 16-23. After these move instructions, the memory will look like this

Index First byte Index Second byte
0 %00000000 1 %00000110 first word
2 %00000101 3 %00000010 second word
4 %00000110 5 %00000000 third word
6

%00000000

7

%00100010

fourth word

0-7

$00000642

8-15

$008001B0

pixels

Index First byte index Second byte
8 %00100000 9 â€¦ first word
10 %00100100 11 â€¦ second word
12 %10000010 13 â€¦ third word
14

%00010000

15

â€¦

fourth word

16-23 $40380240 24-31 â€¦ pixels

It is of the utmost importance that you realize why this is so. If you do not, set yourself down and work it out until you get it and understand it 100%. Without understanding this, youâ€™ll not understand bit planes, without understanding bit planes, you canâ€™t understand how the graphics on the Atari works. Expressed in code, this will be (a0 points to screen memory)

move.b 1(a0),(a0)

move.b 3(a0),2(a0)

move.b 5(a0),4(a0)

move.b 7(a0),6(a0) 8 pixels moved

move.b 8(a0),1(a0) watch carefully!

move.b 10(a0),3(a0)

move.b 12(a0),5(a0)

move.b 14(a0),7(a0) first 4 word area filled

move.b 9(a0),8(a0) start of second 4 word area

move.b 11(a0),10(a0)

â€¦

and so on. So first, four bytes are moved just one step to the left, but then you need to go into the next 4 word area, to fetch the bytes that go into the second area of the first 4 word area and so on. This is the theory behind 8 pixel scrolling, I donâ€™t think I can explain it better than that. This is the source code for the scroller.

jsr initialise
move.l #screen1,d0 put screen1 address in d0
clr.b d0 put on 256 byte boundary
move.l d0,next store address
add.l #32000,d0 next screen area
move.l

d0,last

store address

movem.l font+2,d0-d7
movem.l

d0-d7,$ff8240

palette moved in

main
move.w #37,-(sp) wait vbl
trap #14
addq.l

#2,sp

move.l

next,d0

clr.b $ffff820d clear STe extra bit
lsr.l #8,d0
move.b d0,$ffff8203 put in mid screen address byte
lsr.w #8,d0
move.b

d0,$ffff8201

put in high screen address byte

move.w

#$707,$ff8240

too see clock cycles

cmp

#0,font_counter

check if new character in message

bne has_character if not, skip get new character
move.w #4,font_counter reset font_counter
* we need to point to a new characetr in the font

move.l message_pointer,a0 pointer into the message
clr.l d0 clear, just to be sure
move.b

(a0),d0

put letter ascii value in d0

cmp #0,d0 end of message?
bne

not_end

if not, branch

move.l #message,message_pointer reset message_pointer
move.l message_pointer,a0
clr.l d0 clear, just to be sure
move.b (a0),d0 put letter ascii value in d0
not_end
* now we have a character in d0 for sure
add.l

#1,message_pointer

point to next character

add.b #-$20,d0 align ascii with font number
divu

#10,d0

10 letters per row

move.w d0,d1 d1 contains y value
swap d0
move.w

d0,d2

d2 contains x value

mulu #16,d2 16 bytes for each letter
mulu #32,d1 32 lines per row
mulu

#160,d1

160 bytes per row

move.l

#font+34,a0

put font screen start in a0

add.l d2,d1 add x and y value together
add.l

d1,a0

a0 points to correct letter

move.l

a0,font_address

store calculated pointer

has_character
add.w

#-1,font_counter

move.l last,a0
move.l next,a1 load screens
move.l a1,last and flip them for next time around
move.l a0,next doubble buffering :)
move.l font_address,a2 font address
move.l #31,d1 32 lines to scroll
move.l #18,d0 19 16 pixel clusters + font part
scroll
move.b 1(a0),(a1)
move.b 3(a0),2(a1)
move.b 5(a0),4(a1)
move.b 7(a0),6(a1) 8 pixels moved
move.b 8(a0),1(a1) watch carefully!
move.b 10(a0),3(a1)
move.b 12(a0),5(a1)
move.b

14(a0),7(a1)

first 4 word area filled

add.l #8,a0 jump to next 4 word area
add.l #8,a1 jump to next 4 word area
dbf

d0,scroll

keep moving 16 pixel clusters

move.l

#18,d0

reset loop counter

move.b 1(a0),(a1)
move.b 3(a0),2(a1)
move.b 5(a0),4(a1)
move.b

7(a0),6(a1)

152 pixels scrolled

move.b (a2),1(a1) now last 8 pixels from font
move.b 2(a2),3(a1)
move.b 4(a2),5(a1)
move.b

6(a2),7(a1)

8 pixels from font

add.l #8,a0 point to beginning of next line
add.l #8,a1 point to beginning of next line
add.l #160,a2 next line of font
dbf

d1,scroll

do another line

add.l #1,font_address next byte in font
cmp #2,font_counter see if it's time to change
bne font_increment
add.l #6,font_address align to next 16 pixels
font_increment

move.w #$0,$ff8240 black background again
cmp.b #$39,$fffc02 space pressed?
bne

main

if not, repeat main

jsr

restore

clr.l -(a7)
trap

#1

include

initlib.s

section data
font incbin font.pi1
screen dc.l 0
font_address dc.l 0
font_counter dc.w 0
message dc.b "A COOL SCROLLER! MOVING 8 PIXELS PER VBL "
dc.b

"AND USING DOUBBLE BUFFERING ",0

message_pointer

dc.l

message

next dc.l 0
last

dc.l

0

section bss
ds.b 256
screen1 ds.b 32000
screen2 ds.b 32000

Not too much has been changed since the 16 pixel scroller. In the beginning, thereâ€™s the code for setting up two screen areas. Then, in the main routine, we put one screen address in. Notice also how the font_counter is now 4 instead of 2, because we only need new font data every fourth VBL. The scroller part however is completely new, not surprising is it? It begins with loading both screen areas into a0 and a1, and then flips them for next time around. Data is moved as described above for 19 loops, this means 304 pixels are moved, the last 16 need special care though.

First 8 pixels scrolled as usual, but the last 8 must come from the font. This is also not to strange, since every second byte is moved into the second bytes of the words on the screen. Then 1 is added to the font address, to point to the second bytes in the words. However, this wonâ€™t quite do, as you may know. The step from the second byte of the first 16 pixels to the first byte of the coming 16 pixels is a bigger jump than 1, as described above.

In order to make this bigger step, I test the font_counter, to see if itâ€™s time, and then add another extra 6 to the font, making it point to the right place. If we donâ€™t do this extra addition, 16 pixels will be moved in from the font ok, but when pixels 16 â€“ 24 are about to be moved, the font address will point to index 2 (meaning the first 8 pixels again) instead of index 8 into the font memory. Just scroll up to the memory example, then work through the scroll loop on a piece of paper or in your head and it will hopefully become obvious. If it doesnâ€™t, mail me.

That, I think, was that. The big problem here is the understanding and alignment of bytes in the bit plane. What to keep in mind really is that first, take every second byte, then jump a bit to get on the next 16 pixel boundary, then continue in that way. Indexing goes like 0, 1, 8, 9, so to speak. Thus, every second time thereâ€™s a little gap. Since I didnâ€™t do any timers this tutorial, maybe weâ€™ll do them next time.

Warrior Munk of poSTmortem, 2002-05-05

â€œBe formless, shapeless, like water. Now you put water into a cup; it becomes the cup. You put water into a bottle; it becomes the bottle. You put it into a tea pot; it becomes the tea pot. Now water can flow, or it can crash. Be water my friend.â€

- Bruce Lee

Last edited 2002-06-14