Understanding the Copper

[JackAsser]

@pcm: Indeed of Instinct.

Well, it simply didn't wait at all. I checked the HRM aswell and found an example. They use:

dc.w $80e3,$80fe

And that works.

However, annoyingly, the top-most bit must be set for it to work for scanlines >= $80, and cleared for scanlines < $80 otherwise it simply won't wait at all. Which is weird, since no of the vertical mask bits are set. Are the top most vertical raster position always used in the compare independant of mask bits or is this a winuae "feature"?

(Just learning some amiga stuff, and started with the copper and wanted to make a simple copper loop example. Next step is to port the sierpinski zoomer from Andropolis just to teach myself some Amiga)

[Toni Wilen]

You need to wait for last horizontal position (I think DF should work) because comparison is equal or larger.

(EDIT: I really need to learn to refresh before posting next time)

[JackAsser]

@Tony:

Yeps, understood. What about the top-most bit? Why does that matter? How come it isn't vertically independant when all the vertical mask bits are set to 0?

[pmc]

You're gonna do the Sierpinski zoomer on Amiga?

Cool

I promised myself I'd try to make one of those on Amiga after I saw how cool it looked on the C64.

I wonder if an alternate approach could be done with a couple of waits. Something like: wait for any vert pos that ends in binary 0 (ie. all even lines) and wait for any vert pos that ends in binary 1 (ie. all odd lines) + horiz pos $01 might work? Just speculating really.

[pmc]

Whoops - no need to speculate when Toni is around... or after re-reading previous posts!

[Toni Wilen]

Originally Posted by JackAsser

@Tony:

Yeps, understood. What about the top-most bit? Why does that matter? How come it isn't vertically independant when all the vertical mask bits are set to 0?

Because bit 15 is not part of the mask (which also means it is impossible to use same WAIT for scanlines < 0x80 and >= 0x80). Check HRM and/or previous posts more carefully

[JackAsser]

Yeps, RTFM indeed. Clear as crystal now. Thanx guys.

[Lonewolf10]

An old, but useful thread

Now I need some help. I have set up a working copperlist - well the screen displays ok. However I am having trouble displaying a sprite. I have set the registers as follows:


move ADDRESS_H,SPR0PTH
move ADDRESS_L,SPR0PTL
move ACTMOUS,SPR0POS
move $A000,SPR0CTL

MOVE #$120,DMACON


ADDRESS_H and ADDRESS_L are 2 16-bit values which together make up the longword that points to the starting address of the sprite data.
ACTMOUS is calculated using the X Mouse and Y Mouse positions, but for an example position it is set to $B118. Which is in the middle of the screen, right?


Regards,
Lonewolf10

[Leffmann]

When you use sprite DMA you don't have to set the POS and CTL registers manually, they are to be inserted at the top of the sprite data pointed to, in that order.

The sprite coordinates correspond to those of the display window, so the center of a standard 320*256 screen would be about X 288 and Y 172.

Also, writing $120 to DMACON will turn off bitplane and sprite DMA, you need to set the highest bit as well, and write $8120.

[Toni Wilen]

Setting POS and CTL manually does work (some games and demos does it) but note that DMA internally does first POS and CTL fetch at line 25 (PAL) or 20 (NTSC) (if DMA is enabled)

[Big-Byte]

Many years ago I released all my devpac source code disks and one of them contains my first ever demo - bouncing copper bar(s)

I still remember the rush I got when I first got it working. It was about 4 in the morning as Id been experimenting all night.

Unfortunately I dont have the disks in adf format anymore but I think Ian may have them

[pmc]

Here's your stuff Big-Byte

A few years back you were kind enough to share your .adf source code disks with me.

Sorry to hear you lost them yourself - hope you enjoy seeing the fruits of all your hard work again.

[Lonewolf10]

Thanks for all the tips.

I DL'ed "Big-Byte.rar" and will look at it over the weekend


Regards,
Lonewolf10

[Lonewolf10]

For those using WinUAE like me (both my Amiga 600's are down right now), you can cheat a little and examine registers by pressing PageUp (activates a limited version of HRTmon). WARNING: There is no way back to what you were doing so make sure you save everything before hitting PageUp.
Now simply type the letter "E" and you can go through all the registers and the values at the time you pressed PageUp. It only lists 6 or so registers at a time, so keep typing "E" to list the next few. You can press the down key to list them one at a time, but when you reach the last one and do this it tries to continue where it left off when you pressed PageUp - it normally crashes the emulated Amiga at this point.

I have found it useful to compare my register values with say, those used by workbench. Obviously, certain ones will be different (depending on screen size, depth, etc.).


@Leffmann

Still no joy with the sprite. I tried it by not setting the POS and CTL registers and with setting them manually, but made no difference. Is there anything specific required for the sprite data, or is it just a bunch of bitplane data?


Regards,
Lonewolf10

[Toni Wilen]

"Limited version of hrtmon"? I guess you mean Action Replay 1200? Full hrtmon is also supported (check ROM panel)

If you want to see true and full custom register contents (even write-only ones), use built-in debugger (Shift+F12)

[Leffmann]

Here's an example. You can't assemble it in ASM-One directly but it's short enough to get the jist of:

                    include   customregisters.i
                    include   macros.i



;-------------------------------------------------------------------------------
                    section   code_p

Start               moveq     #-1, d0
                    moveq     #-1, d1
                    moveq     #0, d2
                    moveq     #2, d3
                    jsr       SetSystem
                    tst.b     d4
                    beq       .exit

                    bsr       MousepointerTest

                    jsr       RestoreSystem
.exit               moveq     #0, d0
                    rts



;-------------------------------------------------------------------------------

MousepointerTest    lea       $dff000, a6
                    bsr       Setup

                    ; Read the initial counter values to prevent the pointer
                    ; from blinking around when we start

                    move.w    joy0dat(a6), Mousecounters

.mainloop           WaitFrame

                    bsr       GetMousepos
                    bsr       SetSpritepos

                    btst      #6, $bfe001
                    bne       .mainloop

                    rts




; This routine keeps track of the mouse counter values and uses them to
; to calculate how much the pointer has moved each image frame.
; We think of the screen as 1280*1024 units in order to get some precision, and
; divide these coordinates by 4 to obtain the pointer's position in screen
; pixel coordinates

GetMousepos         ; Get the previous counter values and store the new ones

                    move.w    Mousecounters(pc), d2
                    move.w    joy0dat(a6), d1
                    move.w    d1, Mousecounters

                    ; Calculate X counter difference

                    move.b    d1, d0
                    sub.b     d2, d0
                    ext.w     d0

                    ; Calculate new X position and clamp against screen edges

                    add.w     .mousepos(pc), d0
                    bpl       .xok
                    moveq     #0, d0
.xok                cmp.w     #319*4 + 3, d0
                    bls       .calcy
                    move.w    #319*4 + 3, d0

                    ; Calculate Y difference

.calcy              clr.b     d2
                    sub.w     d2, d1
                    asr.w     #8, d1
                    
                    ; Calculate new Y position

                    add.w     .mousepos+2(pc), d1
                    bpl       .yok
                    moveq     #0, d1
.yok                cmp.w     #255*4 + 3, d1
                    bls       .posok
                    move.w    #255*4 + 3, d1

.posok              ; Store the new values and return pixel coordinates in D0-D1

                    movem.w   d0-d1, .mousepos
                    lsr.w     #2, d0
                    lsr.w     #2, d1

                    rts

.mousepos           dc.w      500, 500
Mousecounters       dc.w      0




; Take pixel coordinates in D0-D1 and place sprite

SetSpritepos        ; X 128 Y 44 will be the upper left corner in sprite
                    ; coordinates. They correspond to the coordinates used for
                    ; the display window minus 1 pixel in X

                    add.w     #$80, d0
                    add.w     #$2c, d1

                    ; Get bit 0 of the X position and place in D2

                    moveq     #0, d2
                    lsr.w     #1, d0
                    addx.b    d2, d2
                    
                    ; Check bit 8 of the Y start position and set in D2
                    
                    btst      #8, d1
                    beq       .novstart
                    addq.b    #4, d2

.novstart           move.b    d1, Sprite

                    ; Add sprite height to get Y stop position and set in D2

                    addq.w    #8, d1
                    btst      #8, d1
                    beq       .novstop
                    addq.b    #2, d2

.novstop            ; Write POS and CTL into sprite data

                    move.b    d0, Sprite+1
                    move.b    d1, Sprite+2
                    move.b    d2, Sprite+3
                    
                    rts




Setup               move.w    #bpl_1bpl | bpl_color, bplcon0(a6)

                    ; Set video priorities to 7 so sprites appear in front of
                    ; bitplanes

                    move.w    #7<<3 | 7, bplcon2(a6)

                    ; 320*256 large display starting at X $81 Y $2C

                    move.w    #0, bplcon1(a6)
                    move.w    #0, bpl1mod(a6)
                    move.w    #$38, ddfstrt(a6)
                    move.w    #$d0, ddfstop(a6)
                    move.w    #$2c81, diwstrt(a6)
                    move.w    #$2cc1, diwstop(a6)

                    move.w    #$89a, color00(a6)
                    move.w    #$eef, color01(a6)
                    move.w    #$000, color17(a6)
                    move.w    #$e48, color18(a6)
                    move.w    #$fcd, color19(a6)
                    
                    ; Write the bitplane pointer into the copper program

                    move.l    #Bitplane, d0
                    move.w    d0, Bitplaneptr+4
                    swap      d0
                    move.w    d0, Bitplaneptr
                    
                    ; and the sprite pointers

                    lea       .sprites(pc), a0
                    lea       Spriteptrs, a1
                    moveq     #8-1, d0
.setsprites         move.w    (a0)+, (a1)
                    move.w    (a0)+, 4(a1)
                    addq.w    #8, a1
                    dbf       d0, .setsprites
                    
                    ; Set copper program pointer and load immediately

                    move.l    #Copperprog, cop1lc(a6)
                    move.w    d0, copjmp1(a6)

                    ; Start all DMA

                    move.w    #dma_set | dma_en | dma_bpl | dma_spr | dma_cop, dmacon(a6)
                    rts

.sprites            dc.l      Sprite
                    rept      7
                     dc.l     BlankSprite
                    endr



;-------------------------------------------------------------------------------
                    section   data_c

                    ; Bitplane data for a 320*256 frame

Bitplane            blk.b     40, %11111111
                    rept      254
                     dc.b         %10000000
                     blk.b    38, %00000000
                     dc.b         %00000001
                    endr
                    blk.b     40, %11111111


                    ; 8*8 pixel sprite. The first two words are the POS and CTL
                    ; control words which the sprite DMA will read and
                    ; set automatically every frame, so are the last two words
                    ; which we set to 0 to mark that the sprite is not to be
                    ; redisplayed again further down the screen.

Sprite              dc.w      0, 0
                    dc.w      %1111111000000000, %0000000000000000
                    dc.w      %1100000100000000, %0111111000000000
                    dc.w      %1000000100000000, %0111111000000000
                    dc.w      %1000001000000000, %0111110000000000
                    dc.w      %1000010000000000, %0111100000000000
                    dc.w      %1000100000000000, %0111000000000000
                    dc.w      %1001000000000000, %0110000000000000
                    dc.w      %0110000000000000, %0000000000000000
BlankSprite         dc.w      0, 0


                    ; We don't need to use the copper to display some sprites
                    ; but it's convenient to delegate f.ex reseting bitplane
                    ; and sprite pointers to it

Copperprog
Bitplaneptr = *+2   cmove     0, bpl1pth, 0, bpl1ptl

Spriteptrs = *+2    cmove     0, spr0pth, 0, spr0ptl
                    cmove     0, spr1pth, 0, spr1ptl
                    cmove     0, spr2pth, 0, spr2ptl
                    cmove     0, spr3pth, 0, spr3ptl
                    cmove     0, spr4pth, 0, spr4ptl
                    cmove     0, spr5pth, 0, spr5ptl
                    cmove     0, spr6pth, 0, spr6ptl
                    cmove     0, spr7pth, 0, spr7ptl

                    cend

[Lonewolf10]

Thanks for the code. I decided to RTM and now have a better understanding of sprites. It's good to have a working example I can compare mine against. I probably set one of the registers up wrong, doh!
I think the Sprite data might be wrong... can sprites start with word values of 0,0? I though the hardware looked for 0,0 to mark the end of the sprite, or doesn't that count when you initialise the sprite?


Regards,
Lonewolf10

[Leffmann]

The control words can be 0, which is interpreted as a sprite both starting and ending at line 0. This is how you stop a sprite from showing on the screen, and is why you set the next pair of control words at the end to 0, so the sprite doesn't appear again further down the screen.

Those control words get filled in right away by the SetSpritepos routine anyway so I just left them as 0 instead of some appropriate values. In worst case the pointer is simply not visible during the first frame.

The structure of the sprite data is a pair of control words followed by its bitmap data, then comes a new pair of control words followed by more bitmap data (if needed), and so on. This is to allow you to reuse the same sprite channel to display more sprites.

Each new sprite must be placed further down and completely separated from the previous by at least 1 scanline, so it's possible to f.ex create a column of sprites using the same sprite channel, but not a circle. The horizontally scrolling starfields you can see in many demos on the Amiga can be made by reusing a single sprite channel.

This is all explained in the HRM, but I can write up a new example if you'd like.

[Lonewolf10]

Originally Posted by Leffmann

This is all explained in the HRM, but I can write up a new example if you'd like.

Thanks, but I don't need it. I believe I understand how it all works now, and thanks for the help


Regards,
Lonewolf10