Basic program fails on machine language routine.

[gs80065xe]

I'm trying an example program testing PM Collisions. The program has a machine language routine it calls to speed up moving the player vertically. But it isn't working for me. And I still don't have a good grasp of assembly to under stand why. One thing I noticed is the book had two PLA statements at the start of the routine. That caused the program to hang. Removing one of them stops it from hanging. But the player doesn't appear to move. In fact I don't see the player at all. The line it is called on is

 

st=usr(adr(dli),pb+512+y)

DLI HEX: 68,68,85,cc,68,85,85,cb,a0,14,b1,cb,c8,91,cb,88,88,c0,ff,d0,f5,60

[+skr]

A shot into the dark from a not very experienced programmer ( oh, that´s me! ) :

 

Are you reading the Values with READ from DATA-lines? If so, I think you should use decimal values.

[TGB1718]

having a look, I think the second $85 shouldn't be there

 

this is the assembler code see 607

0600   PLA   68
0601   PLA    68
0602   STA  CC   85 CC
0604   PLA    68
0605   STA  85   85 85
0607   ***  CB   CB
0608   LDY  #14  A0 14
060A   LDA  (CB),Y    B1 CB
060C   INY     C8
060D   STA  (CB),Y     91 CB
060F   DEY                88
0610   DEY            88
0611   CPY  #FF       C0 FF
0613   BNE  060A      D0 F5
0615   RTS            60

 

this is the fixed code

0600   PLA            68
0601   PLA            68
0602   STA  CC        85 CC
0604   PLA            68
0605   STA  CB        85 CB
0607   LDY  #14       A0 14
0609   LDA  (CB),Y    B1 CB
060B   INY            C8
060C   STA  (CB),Y    91 CB
060E   DEY            88
060F   DEY            88
0610   CPY  #FF       C0 FF
0612   BNE  0609      D0 F5
0614   RTS            60

 

The PLA 's should be there, first PLA is the number of params passed to the USR call, the next 2 PLS'a get the address passed in (high Byte, then low Byte)

 

here's the BASIC data statements to fix it

 

130 DATA 104,104,133,204,104,133,203,160,20,177
140 DATA 203,200,145,203,136,136,192,255,208,245,96

 

Edited January 5, 2021 by TGB1718
Update

[gs80065xe]

SKR, I was reading the hex values in memory using Altira's debugger.

 

TGB1718, thanks for the help. I added the PLA back to the beginning. Your Data statements are the same as what's in the book. But it still hangs. I've attached my FastBasic program. I ported it from Atari basic. Tried the program in Atari Basic as it is in the book, and it works. Not sure what I've done wrong.

 

collision.atr

[TGB1718]

Had a look, although I don't use FB, I think I understand how it's working and it sort of looks ok, the only

thing I'm not sure about is does FB make USR calls the same way Atari BASIC does ?

 

Will try find the manual tomorrow and have a look

[dmsc]

Hi!

Quote

SKR, I was reading the hex values in memory using Altira's debugger.

 

TGB1718, thanks for the help. I added the PLA back to the beginning. Your Data statements are the same as what's in the book. But it still hangs. I've attached my FastBasic program. I ported it from Atari basic. Tried the program in Atari Basic as it is in the book, and it works. Not sure what I've done wrong.

Ah, you are using FastBasic. Great!

 

FastBasic is not 100% compatible with Atari BASIC, you already saw the first difference: you don't need the first PLA at the start of the ASM routine, so simply remove the first PLA. and it will be ok.

 

And the second problem, FastBasic already supports PM graphics, and it *reset* the Player/Missiles on any "GRAPHICS" statement, this is the reason you don't see anything. Simply move the "GR.2" statement just before the "POKE 54279,A" and the program will show your balloon.

 

Now, the collision won't work (same as the Atari BASIC version) because you don't have any portion with "color 3" on the screen (the blue text window does not count as PF2). And you don't see the HIT values because you are printing it *before* they are displayed, you must put the "? PEEK(53252)" after the PAUSE.

 

Note that this program could be written entirely in FastBasic, using the P/M support and using "MOVE" instead of the USR routine.

 

Have Fun!

Edited January 5, 2021 by dmsc

[gs80065xe]

1 hour ago, dmsc said:

Now, the collision won't work (same as the Atari BASIC version) because you don't have any portion with "color 3" on the screen (the blue text window does not count as PF2). And you don't see the HIT values because you are printing it *before* they are displayed, you must put the "? PEEK(53252)" after the PAUSE.

 

Thanks. It's mostly working now. Collision detection is a little weird. Watching the value displayed once P0 collides with the playfield's text, changes to 1 instead of 4. So changed the repeat to check 53252 = 1. But it stops when y=21 because it changes to 1 there. So changed the repeat to 53252=1 and y>21. And it works fine. Don't understand why it is set to 1 after the first loop. But is 0 for all the rest.

 

I know FastBasic offers PM support. But, I'm  trying to learn two languages at the same time. Assembly from an old assembly book which has examples in Atari Basic. And FastBasic by converting Atari Basic programs to FastBasic. I chose to not use the PM features in FastBasic because they won't be available in Assembly.

Edited January 5, 2021 by gs80065xe

[dmsc]

Hi!

1 hour ago, gs80065xe said:

Thanks. It's mostly working now. Collision detection is a little weird. Watching the value displayed once P0 collides with the playfield's text, changes to 1 instead of 4. So changed the repeat to check 53252 = 1. But it stops when y=21 because it changes to 1 there. So changed the repeat to 53252=1 and y>21. And it works fine. Don't understand why it is set to 1 after the first loop. But is 0 for all the rest.

Collision registers work by "latching" when the screen tries to draw a player/missile over other elements. The Atari computer draws the screen top to bottom, and each line left to right, 50 (on PAL) or 60 (on NTSC) times per second. When drawing, each line in which a player or missile should appear on screen, ANTIC sends the data to GTIA. GTIA then counts pixels up to the right horizontal position and instead of drawing the playfield (the graphics data), writes each "1" bit of a player or missile on top. At this time, if GTIA sees any graphics data in that spot, it sets one bit on the collision register to 1, and the bit keeps at 1 forever (this is the "latching" part). To clear all the bits, you must write any number (not only 255 as your program does, a 0 will suffice) to the register 53278 (HITCLR).

 

So, the proper way to use collision registers is to poke HITCLR at the top of the screen, just before the screen starts to draw, and then read it after all the screen is drawn. This can be accomplished on FastBasic using code like:

 

REPEAT
  ' Waits for the screen to be drawn
  PAUSE 0
  ' Read collisions
  hit = PEEK(53252)
  ' Clear collisions
  POKE 53278, 0
  ' Now, perform the game logic - move players, etc.

UNTIL KEY()

 

In assembly, you can write exactly the same:

game_loop:
  ; Waits for VBI
  lda 20
delay
  cmp 20
  beq delay

  ; Read collision register
  LDA 53252
  ; And clear collisions
  STA 53278

  ; Now, do the game loop....

  ; And go next frame
  lda 764
  eor #255
  bne game_loop

  ; End
  rts

 

1 hour ago, gs80065xe said:

I know FastBasic offers PM support. But, I'm  trying to learn two languages at the same time. Assembly from an old assembly book which has examples in Atari Basic. And FastBasic by converting Atari Basic programs to FastBasic. I chose to not use the PM features in FastBasic because they won't be available in Assembly.

You can use the PM features in FastBasic and then simply read the FastBasic sources to see how it was implemented ? 

 

Have Fun!

 

[gs80065xe]

I refactored the program to take advantage of FastBasic's built in PMGraphics functions. I didn't have to do the special test on row 21 for the collision test. And using MSET and MOVE are very fast at making vertical changes. Negating the need for the machine language routine.

 

Thanks again for the help.