Another ASM newbie...

[DanielAllsopp]

... in need of some really basic help :-)

I'm currently trying my hand at some basic Amiga coding in assembler, purely as a hobbies exercise having written all of my previous Amiga programs in C, which were mainly OS UI applications etc.

So, I'm using Photon's MiniStartup code to get things going and trying to open a 7 bitplane display to mess around with AGA registers in the copper by changing colours and waiting for specific scanlines.

So far so good.

However, there's one issue which I can't seem to figure out, and that's a bunch of random data that's appearing in one position on the screen.



Here's my main bit of code, including the copper list. I have a startup.s file but that's just Photon's MiniStartup that saves the OS etc and jumps to Main in this file.

INCLUDE "registers.i"
	INCLUDE "startup.s"

  XDEF Main

*******************************************************************************

w	    = 320			     ;screen width, height, depth
h	    = 256
bpls  = 7
bpl	  = w/16*2			 ;byte-width of 1 bitplane line
bwid  = bpls*bpl		 ;byte-width of 1 pixel line (all bpls)

********** Macros **********

WAITBLIT:macro
	tst.w (a6)			;for compatibility with A1000
.wb\@:	btst #6,2(a6)
	bne.s .wb\@
	endm

********** Demo **********		;Demo-specific non-startup code below.

Main:					                ;a4=VBR, a6=Custom Registers Base addr
  *--- init ---*
	move.l #VBint,$6c(a4)
	move.w #$c020,INTENA(a6)
	move.w #$87c0,DMACON(a6)

  *--- clear screens ---*
	lea Screen,a1
	bsr.w ClearScreen

	lea Screen2,a1
	bsr.w ClearScreen

	bsr WaitBlitter

  *--- start copper ---*
	lea Screen,a0
	moveq #bpl,d0
	lea BplPtrs+2,a1
	moveq #bpls-1,d1
	bsr.w PokePtrs

	move.l #Copper,COP1LCH(a6)

; ********************  main loop  ********************
MainLoop:
	move.w #$12c,d0			;No buffering, so wait until raster
	bsr.w WaitRaster		;is below the Display Window.

  *--- swap buffers ---*
	movem.l DrawBuffer(PC),a2-a3
	exg a2,a3
	movem.l a2-a3,DrawBuffer	;draw into a2, show a3

  *--- show one... ---*
	move.l a3,a0
	moveq #bpl,d0
	lea BplPtrs+2,a1
	moveq #bpls-1,d1
	bsr.w PokePtrs

  *--- ...draw into the other(a2) ---*
	move.l a2,a1
	bsr ClearScreen
	bsr WaitBlitter

; do stuff here :)

    *--- main loop end ---*
	;move.w #$f00,COLOR00(a6)		 ;show rastertime left down to $12c
	btst #6,CIAAPORTA		         ;Left mouse button not pressed?
	bne.w MainLoop			         ;then loop
    *--- exit ---*
	rts

********** Demo Routines **********

PokePtrs:				                ;generic, poke ptrs into copper list
.bpll:	move.l a0,d2
	swap d2
	move.w d2,(a1)			          ;high word of address
	move.w a0,4(a1)			          ;low word of address
	addq.w #8,a1			            ;skip two copper instructions
	add.l d0,a0			              ;next ptr
	dbf d1,.bpll
	rts

ClearScreen:				            ;a1=screen destination address to clear
	bsr WaitBlitter
	clr.w BLTDMOD(a6)			        ;destination modulo
	move.l #$01000000,BLTCON0(a6)	;set operation type in BLTCON0/1
	move.l a1,BLTDPTH(a6)		      ;destination address
	move.l #h*bpls*64+bpl/2,BLTSIZE(a6)	;blitter operation size
	rts

VBint:					;Blank template VERTB interrupt
	movem.l d0/a6,-(sp)		;Save used registers
	lea $dff000,a6
	btst #5,$1f(a6)			;check if it's our vertb int.
	beq.s .notvb
    *--- do stuff here ---*
	moveq #$20,d0			;poll irq bit
	move.w d0,INTREQ(a6)
	move.w d0,INTREQ(a6)
.notvb:	movem.l (sp)+,d0/a6		;restore
	rte

********** Fastmem Data **********

DrawBuffer:	dc.l Screen2		;pointers to buffers to be swapped
ViewBuffer:	dc.l Screen

*******************************************************************************
	SECTION ChipData,DATA_C		;declared data that must be in chipmem
*******************************************************************************

Copper:
  dc.w FMODE,$0003              ;x4 fetch mode
  dc.w DIWSTRT,$2c81			      ;238h display window top, left
  dc.w DIWSTOP,$2cc1			      ;and bottom, right.
  dc.w DDFSTRT,$38			        ;Standard bitplane dma fetch start
  dc.w DDFSTOP,$d0			        ;and stop for standard screen.

  dc.w BPLCON3,$0c00			      ;(AGA compat. if any Dual Playf. mode)
  dc.w BPL1MOD,bwid-bpl		      ;modulos
  dc.w BPL2MOD,bwid-bpl

  dc.w BPLCON0,bpls*$1000+$200	;enable bitplanes
  dc.w BPLCON1,$ff00	          ;Scroll register (and playfield pri)

Palette:				                ;Some kind of palette (3 bpls=8 colors)
  dc.w COLOR00,$0e94
  dc.w BPLCON3,$0200
  dc.w COLOR00,$0978
  dc.w BPLCON3,$0000

  dc.w $9007,$fffe
  dc.w COLOR00,$0f00
  dc.w BPLCON3,$0200
  dc.w COLOR00,$0f00
  dc.w BPLCON3,$0000

  dc.w $A007,$fffe
  dc.w COLOR00,$04A4
  dc.w BPLCON3,$0200
  dc.w COLOR00,$0190
  dc.w BPLCON3,$0000

  dc.w $B007,$fffe
  dc.w COLOR00,$0e94
  dc.w BPLCON3,$0200
  dc.w COLOR00,$0978
  dc.w BPLCON3,$0000

BplPtrs:
  dc.w BPL1PTH,0
  dc.w BPL1PTL,0
  dc.w BPL2PTH,0
  dc.w BPL2PTL,0
  dc.w BPL3PTH,0
  dc.w BPL3PTL,0
  dc.w BPL4PTH,0
  dc.w BPL4PTL,0
  dc.w BPL5PTH,0
  dc.w BPL5PTL,0
  dc.w BPL6PTH,0
  dc.w BPL6PTL,0
  dc.w BPL7PTH,0
  dc.w BPL7PTL,0

  dc.w $ffdf,$fffe		;allow VPOS>$ff
  dc.w $ffff,$fffe		;magic value to end copperlist
CopperE:

*******************************************************************************
	SECTION ChipBuffers,BSS_C	;BSS doesn't count toward exe size
*******************************************************************************

Screen:	ds.b h*bwid		;Define storage for buffer 1
Screen2:ds.b h*bwid			;two buffers

  END

[roondar]

The problem I've spotted is that your screen buffers are not aligned correctly. You're using the AGA 4x display fetch mode, which requires your screen buffers to be aligned to multiples of 8 bytes (for each plane).

I.E. try something like

CNOP 0,8 
Screen: <blah> 
CNOP 0,8 
Screen2: <blah>

If you're not using VASM, replace CNOP 0,8 with the correct assembler directive for alignment here.

Note: I haven't read your code in depth so I may have missed something else, but the above is definitely needed for AGA 4x fetch mode to work correctly.

[Toni Wilen]

DDFSTOP is wrong (too large), $d0 only works if FMODE is 0.

[rcman]

I'm not an expert but I remember when I did program ASM all the sprites need to be initialized.

RC

[DanielAllsopp]

Awesome, thanks for the quick responses guys. I am indeed using VASM so I'll get that added in as soon as possible.

Toni, as I'm totally out of my depth here, why is it too large, and what does it need to be changed to? I'm aiming for 320x256x7 dual playfield setup, so anything to help along those lines would be great.

Thanks again!

[roondar]

I've not done enough AGA stuff to know all about it, but my guess here is that the problem stems from the way the 4x fetch is done.

What I mean here is that the OCS chipset reads new data every '16 pixels', whereas AGA in 4x mode reads four times the data every '64 pixels'. Having a DDFSTOP that is too large will make the chipset fetch 64 (or more) extra pixels every scanline.

This means you're showing parts of RAM you've not cleared (and don't really want to use). Sadly, I don't actually know the correct values for AGA by heart so I can't help you there.

[ross]

The bug is due to something completely different from what has been written so far (even if they are good tips)

[mcgeezer]

The problem possibly lies in the modulo registers for the bitplanes in your copper. When FMODE is x2 or x4 the modulo needs to be compensated.

So for example in 5 bitplane mode with FMODE x2 your modulo needs compensating by 32 bits:

((BITPLANE_WIDTH*BITPLANES)-BITPLANE_WIDTH)+4

or for FMODE x4 it needs compensating by 64 bits

((BITPLANE_WIDTH*BITPLANES)-BITPLANE_WIDTH)+8

I'm trying to dig out where I know about this as it explains clearly but I'm having trouble finding it.

Also ... Are you absolutely sure that ClearScreen() function is working correctly? Perhaps create a CPU based routine and check it or setup the A register and load BLTADAT with $ff00 and see if it fills properly (you should see striped lines).

I'll try your code tonight when I get in to see if I can nail it down for sure.

[ross]

Other good tips, but no.

I have a sort of deja vu here because the error is very similar to that of another beginner of some time ago.

EDIT: but Graeme went very very close to it

[mcgeezer]

Ohhh...

One thing.... you are setting your bitplane addresses in the copper after waiting for the vertical lines.

You need to set those up right near the start.

Graeme

[ross]

Ok ok, I stop this silly game..

Watch the ClearScreen routine carefully.

[roondar]

Doh.

I completely missed that. The Blitter size calculation doesn't work. First, it's written as a longword which is wrong (register is word sized) and second, that value is way too big to fit.

[ross]

Originally Posted by roondar

Doh.

I completely missed that. The Blitter size calculation doesn't work. First, it's written as a longword which is wrong (register is word sized) and second, that value is way too big to fit.

On Aga is not a bad idea using BLTSIZV/H to clear big zones.

[DanielAllsopp]

Ha, that's one of the only things I changed from Photon's code. So, from this lesson I see that I shouldn't use longwords for accessing registers.

I only did so because the number was too big when I pushed my bitplanes up to 7.

Leave it with me as a little exercise and I'll see if I can figure it out.

I will be back though, with less hair, just you watch ;-)

Thanks Graeme for the other pointers too, I'll make sure I apply all of that knowledge too.

[mcgeezer]

Originally Posted by ross

Ok ok, I stop this silly game..

Watch the ClearScreen routine carefully.

ahhhhhh... I did suspect that ClearScreen() function though!

@DanielAllsopp - Using long words on registers is fine... perhaps write your value to a place in memory instead of the register and see what happens.

[roondar]

Originally Posted by mcgeezer

a
@DanielAllsopp - Using long words on registers is fine...

True and untrue
It all depends on the register(s) you're trying to set.

[mcgeezer]

Originally Posted by roondar

True and untrue
It all depends on the register(s) you're trying to set.

I agree

[DanielAllsopp]

So, another lunch time used constructively figuring out this lovely little language :-)

I've managed to get rid of my dirty lines, which has inevitably caused some more questions. Here's what I did first though:

As Graeme pointed out, I put the calculation for the blittersize into memory:

BlitterSize: dc.l h*bpls*64+bpl/2

and used it thus:

ClearScreen:
  bsr WaitBlitter
  clr.w BLTDMOD(a6)
  move.l #$01000000,BLTCON0(a6)
  move.l a1,BLTDPTH(a6)
  move.w BlitterSize,BLTSIZE(a6)
  rts

I also changed the DDFSTOP value:

dc.w DDFSTOP,$b0

I based this off the size of the fetches in 4x mode, basically it fetches 64bits instead of the normal 16bits (hence the 4x).

However, I know this is short of the full display width using my rudimentary table:

Address Locations: $38 $40 $48 $50 $58 $60 $68 $70 $78 $80 $88 $90 $98 $a0 $a8 $b0 $b8 $c0 $c8 $d0 $d8 $e0 $e8 $f0
x1 fetch mode: SRT|       |       |       |       |       |       |       |       |       |       |STP
x4 fethc mode: SRT|                               |                               |                               |

So the fetch (for DMA?) is 32bits short?

Shoot me down for the stupid assumptions and questions but:

1. How do I ensure that the fetch actually fetches to the end of the screen. I've already determined stopping later causes issues. Do we use $98?

2. I had a look at the BLTSIZV and BLTSIZH register documentation but couldn't find any examples. Can someone explain how they work? I think one is the width, and one the height. But in what? I'm assuming bits?

Thanks again for any help!

[phx]

Originally Posted by DanielAllsopp

BlitterSize: dc.l h*bpls*64+bpl/2

(...)

  move.w BlitterSize,BLTSIZE(a6)

No. This won't work. Writing bits 16-31 of your calculated blit-size to BLTSIZE does not want you want.

2. I had a look at the BLTSIZV and BLTSIZH register documentation but couldn't find any examples. Can someone explain how they work? I think one is the width, and one the height. But in what? I'm assuming bits?

Here you find the meaning of all bits in the registers:
http://www.winnicki.net/amiga/memmap/BLTSIZV.html

I have no experience with AGA myself, but BLZSIZH certainly defines the width in words, as with BLTSIZE. The hardware always operates on words.

[DanielAllsopp]

No. This won't work. Writing bits 16-31 of your calculated blit-size to BLTSIZE does not want you want.

No, I guess not, not if it's expecting 16 bits of data and I'm shoving 32bits in there. Something will be getting trashed somewhere I suppose.

I'll take a look at the docs.

Thanks for the info too :-)