Setting up the BITBLT struct for LINEA

GFA, ASM, STOS, ...

Moderators: simonsunnyboy, Mug UK, Zorro 2, exxos, Moderator Team

Re: Setting up the BITBLT struct for LINEA

Postby charles » Mon Apr 30, 2012 10:06 pm

i have a dead simple linea example in asm simon , i'll edit this after ,post here ,the code i have

maybe theres hope for multiple listings..

charles

edits::::::
Code: Select all
EG


Fast Basic By Computer Concepts
Copyright 1986, All Rights Reserved
Program: SPRITEXP.BSC
Length:  10 Kilobytes.
Requires 100 KBytes To Run


FHREM Move the sprite with the
REM joystick and press fire
REM to end
REM The backgrund colour is
REM displayed
ON ERROR GOTO clearup
PROCinitjoystick
TXTRECT 0,0,50,20
GRAFRECT 0,0,SCREENWIDTH,SCREENHEIGHT
CLG 0
PROCinitsprites
HIDEMOUSE
IF SCREENMODE=0 THEN
 PROCloadpic("A:\JOKEY.PIC",PHYSBASE)
 ELSE FILLCOL 2
 CIRCLE 150,100,80
 FILLCOL 3
 CIRCLE 250,70,70
ENDIF
xpos%=50:ypos%=50:oldsprx%=xpos%:oldspry%=ypos%

REPEAT
REM Delete the next 2 lines
REM to turn off the collision
REM detection and speed up the
REM program
colourhit%=FNcollision(1)
PRINT TAB(1,1)colourhit%
PROCinputmove
IF move=TRUE THEN PROCspriteon(1,xpos%,ypos%)
UNTIL quit=TRUE
OUT 4,8
SHOWMOUSE
END


DEFPROCloadpic(A$,A%)
LOCAL I%,P%
BLOAD A$,A%-128
FOR I%=0 TO 15
P%={A%-124+I%*2}&
SETCOL I%,P%>>8,P%>>4,P%
NEXT I%
ENDPROC


DEFPROCinputmove
move=FALSE
quit=FALSE
IF fire&=-1 THEN quit=TRUE:ENDPROC
oldxpos%=xpos%:oldypos%=ypos%
xpos%=xpos%+joyx&*5
ypos%=ypos%-joyy&*3
IF xpos%<0 THEN xpos%=0
IF xpos%>SCREENWIDTH-sw(1) THEN xpos%=SCREENWIDTH-sw(1)
IF ypos%<0 THEN ypos%=0
IF ypos%>SCREENHEIGHT-sh(1) THEN ypos%=SCREENHEIGHT-sh(1)
IF oldxpos%<>xpos% OR oldypos%<>ypos% THEN move=TRUE
ENDPROC




DEFPROCinitsprites
LOCAL cplane
IF SCREENMODE=0 THEN
 cplane=4
 ELSE IF SCREENMODE=1 THEN cplane=2 ELSE cplane=1
ENDIF
RESERVE screen,33000
screentwo=(screen+256)AND$FFFF00
screenone=PHYSBASE
LOGBASE=screentwo
GRAFRECT 0,0,SCREENWIDTH,SCREENHEIGHT
CLG 0
LOGBASE=screenone
DIM MFDB&(9)
MFDB&(0)=LOGBASE>>16
MFDB&(1)=LOGBASE AND $FFFF
MFDB&(2)=SCREENWIDTH
MFDB&(3)=SCREENHEIGHT
MFDB&(4)=SCREENWIDTH>>4
MFDB&(5)=0
MFDB&(6)=cplane
MFDB&(7)=0
MFDB&(8)=0
MFDB&(9)=0
DIM MFDB2&(9)
MFDB2&(0)=screentwo>>16
MFDB2&(1)=screentwo AND $FFFF
MFDB2&(2)=SCREENWIDTH
MFDB2&(3)=SCREENHEIGHT
MFDB2&(4)=SCREENWIDTH>>4
MFDB2&(5)=0
MFDB2&(6)=cplane
MFDB2&(7)=0
MFDB2&(8)=0
MFDB2&(9)=0
LOGBASE=screentwo
DIM sh(4),sw(4),oldsprx%(4),oldspry%(4)
RESTORE
REPEAT
READ sprite%
IF sprite%<>0 THEN
READ sh(sprite%),sw(sprite%)
sxpos%=(sprite%-1)*100
FOR sy%=1 TO sh(sprite%)
 FOR sx%=1 TO sw(sprite%)
 READ sdata%
 MARKCOL sdata%
 PLOT sx%+sxpos%-1,sy%-1
 IF sdata%=0 THEN MARKCOL 1 ELSE MARKCOL 0
 PLOT sx%+sxpos%-1,50+sy%-1
 NEXT sx%
NEXT sy%
ENDIF
UNTIL sprite%=0
LOGBASE=screenone
PROCassemblecollision
ENDPROC
REM data for each sprite
REM replace with your own data
DATA 1,16,16
DATA 0,0,0,0,1,1,1,1,1,1,1,0,0,0,0,0
DATA 0,0,0,1,1,1,15,15,1,1,1,1,0,0,0,0
DATA 0,0,0,1,15,4,4,15,4,4,15,1,0,0,0,0
DATA 0,0,0,0,15,4,4,15,4,4,15,0,0,0,0,0
DATA 0,0,0,0,15,1,15,2,15,1,15,0,0,15,0,0
DATA 0,0,0,0,15,15,1,1,1,15,15,0,15,15,15,0
DATA 0,0,0,0,0,15,15,15,15,15,0,0,15,15,15,0
DATA 0,0,0,0,0,0,15,15,15,0,0,0,2,2,0,0
DATA 0,0,0,0,0,0,0,15,0,0,0,2,2,0,0,0
DATA 0,0,0,0,0,0,0,15,0,0,2,2,0,0,0,0
DATA 0,0,0,0,2,2,2,2,2,2,2,0,0,0,0,0
DATA 0,0,0,2,2,0,2,2,2,0,0,0,0,0,0,0
DATA 15,15,2,2,0,0,2,2,2,0,0,2,0,0,0,0
DATA 15,15,2,0,0,0,2,2,2,0,2,2,0,0,0,0
DATA 15,0,0,0,0,0,2,2,2,2,2,0,0,0,0,0
DATA 0,0,0,0,0,0,0,2,2,2,0,0,0,0,0,0
DATA 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
DATA 0




DEFPROCspriteon(sprite%,sprx%,spry%)
REM Adjust the position and number
REM of the "WAIT"s for better
REM syncronisation with the screen
WAIT
BLIT @MFDB2&(0),100*(sprite%-1),100,sw(sprite%),sh(sprite%),@MFDB&(0),oldsprx%(sprite%),oldspry%(sprite%),3
BLIT @MFDB&(0),sprx%,spry%,sw(sprite%),sh(sprite%),@MFDB2&(0),100*(sprite%-1),100,3
WAIT
BLIT @MFDB2&(0),100*(sprite%-1),50,sw(sprite%),sh(sprite%),@MFDB&(0),sprx%,spry%,1
BLIT @MFDB2&(0),100*(sprite%-1),0,sw(sprite%),sh(sprite%),@MFDB&(0),sprx%,spry%,7
oldsprx%(sprite%)=sprx%:oldspry%(sprite%)=spry%
ENDPROC

DEFFNcollision(sprite%)
LOCAL P&,collision%,xpos&,ypos&,swidth&,sheight&
swidth&=sw(sprite%):sheight&=sh(sprite%)
collision%=0
LOGBASE=screentwo
xpos&=100*(sprite%-1)
ypos&=100
CALL gpix
collision%=P&
LOGBASE=screenone
=collision%



DEFPROCassemblecollision
RESERVE gpix,$200
FOR pass=1 TO 2
[ OPT pass,"L-,W-"
ORG gpix
Intin EQU 8
Ptsin EQU 12
DC.W $A000
MOVE.L Intin(A0),A3
MOVE.L Ptsin(A0),A4
MOVE.L #0,D4
gyloop
ADD.L #3,D4
MOVE.L #0,D3
gloop
ADD.L #3,D3
MOVE @xpos&,(A4)
ADD.W D3,(A4)
MOVE @ypos&,2(A4)
ADD.W D4,2(A4)
DC.W $A002
CMP.W #0,D0
BNE gend
CMP.W @swidth&,D3
BLO gloop
CMP.W @sheight&,D4
BLO gyloop
gend
MOVE.W D0,@P&
RTS
]
NEXT pass
ENDPROC


clearup:
OUT 4,8
LASTERROR


DEFPROCinitjoystick
ON ERROR GOTO clearup
joyx&=0:joyy&=0:port&=0:fire&=0
RESERVE code%,$100
FOR pass=1 TO 2
[ OPT pass,"L-,W-"
ORG code%
MOVE.W #34,-(SP)
TRAP #14
ADDQ.L #2,SP
MOVE.L D0,A0
LEA joyvector(PC),A1
MOVE.L A1,24(A0)
RTS
joyvector
MOVEQ  #0,D0
MOVE.B 2(A0),D0
ASL.W #2,D0
LEA table(PC),A1
MOVE.W 0(A1,D0),@joyx&
MOVE.W 2(A1,D0),@joyy&
MOVE.B (A0),D0
ANDI.W #1,D0
MOVE.W D0,@port&
LEA @fire&(PC),A2
MOVE.B 2(A0),D0
ANDI.W #128,D0
SNE.B (A2)
SNE.B 1(A2)
RTS
table DC.W 0,0
DC.W 0,1
DC.W 0,-1
DC.W 0,0
DC.W -1,0
DC.W -1,1
DC.W -1,-1
DC.W 0,0
DC.W 1,0
DC.W 1,1
DC.W 1,-1
EVEN
]
NEXT
CALL code%
OUT 4,$14:OUT 4,$12
ENDPROC





atari is my lifestyle,not a hobby.
User avatar
charles
10 GOTO 10
10 GOTO 10
 
Posts: 1853
Joined: Tue Aug 17, 2004 12:11 am
Location: ont. Canada

Re: Setting up the BITBLT struct for LINEA

Postby tcat » Tue Aug 13, 2013 12:46 pm

Hi,

I have been following this dicussion, I am more on a learning side, so I may not be able to ask properly. Yet I am quite interested, I thought BLITTER a piece of hardware, do I have to care whether blitter is present or not, when writing code using these A-line routines?

Many thanks
tcat
Atari User
Atari User
 
Posts: 37
Joined: Fri May 03, 2013 6:00 am

Re: Setting up the BITBLT struct for LINEA

Postby Frank B » Tue Aug 13, 2013 8:08 pm

tcat wrote:Hi,

I have been following this dicussion, I am more on a learning side, so I may not be able to ask properly. Yet I am quite interested, I thought BLITTER a piece of hardware, do I have to care whether blitter is present or not, when writing code using these A-line routines?

Many thanks


No. You don't apart from one very important thing. Do not call the linea routines from an interrupt handler at the same time as your main code.
The hardware has state which means the linea isn't re-entrant.
User avatar
Frank B
Atari Super Hero
Atari Super Hero
 
Posts: 546
Joined: Wed Jan 04, 2006 1:28 am
Location: Not so sunny Paris (again)

Re: Setting up the BITBLT struct for LINEA

Postby dml » Wed Aug 14, 2013 9:13 am

'LINEA' is a weird 68000 processor instruction extension group - like FPU extension instructions - which can be vectored to some normal code elsewhere. These instructions are encoded as words beginning with $Axxx (FPU instructions are encoded with $Fxxx).

On an ST the $Axxx instructions are configured (vectored) to point at ROM code which implements a bunch of graphics routines (one of them being BITBLT).

So when you initiate a linea exception for BITBLT, it's just calling some ROM graphics routines via an unusual route - instead of a generic trap call which is normally used for that stuff. The result is the same though. I don't remember the reason for this, if there ever was a good one. Perhaps they calculated linea ops are a bit quicker for graphics than trap calls because they don't need a function argument.

Anyway BITBLT does the check for blitter hardware and uses it if available, but it is not a blitter device interface exactly since it works without one present. You could say it is emulated in software, but this behaviour is what you'd expect of a normal OS drawing function with some hardware acceleration.

If you want to use the blitter device itself without going through all those layers, you have to hit the hardware registers directly and do your own checking. If you want to blit many small things, that's the fastest way. (IIRC the BITBLT state setup looks a lot like the hardware registers - but I haven't looked at this function in more than 20 years)

As Frank says - resist the temptation to blit stuff from an interrupt :-) Such as mouse cursors etc. Too many things which can go wrong.
User avatar
dml
Atari God
Atari God
 
Posts: 1964
Joined: Sat Jun 30, 2012 9:33 am

Re: Setting up the BITBLT struct for LINEA

Postby Dio » Wed Aug 14, 2013 9:58 am

dml wrote:I don't remember the reason for this, if there ever was a good one. Perhaps they calculated linea ops are a bit quicker for graphics than trap calls because they don't need a function argument.

Denser code, since the param is implicit. Slower, though, because the called code needs to go fetch the source instruction. Code density was a big thing in the ST ROM, because it was about 20KB over budget, hence things like line-f.
Dio
Captain Atari
Captain Atari
 
Posts: 446
Joined: Thu Feb 28, 2008 3:51 pm

Re: Setting up the BITBLT struct for LINEA

Postby dml » Wed Aug 14, 2013 10:11 am

Dio wrote:Denser code, since the param is implicit. Slower, though, because the called code needs to go fetch the source instruction. Code density was a big thing in the ST ROM, because it was about 20KB over budget, hence things like line-f.


So it was a size thing. That makes more sense.
User avatar
dml
Atari God
Atari God
 
Posts: 1964
Joined: Sat Jun 30, 2012 9:33 am

Previous

Return to Coding

Who is online

Users browsing this forum: CommonCrawl [Bot] and 1 guest