6502.org Forum Projects Code Documents Tools Forum
It is currently Sat Apr 27, 2024 11:06 am

View unanswered posts | View active topics


Board index » 6502.org Users Forum » Programming

All times are UTC




Post new topic Reply to topic  Page 1 of 2
  [ 19 posts ]  Go to page 1, 2  Next
  Previous topic | Next topic 
Author Message
DrkStarr
PostPosted: Wed Jan 17, 2024 4:13 pm 
Offline

Joined: Tue Jan 16, 2024 11:28 am
Posts: 6
Hello, this is my first time here.

I've been learning assembly language on the Apple. I'm exploring graphics using Apple Graphics & Arcade Game Design by Jeffrey Stanton, and I got lookup tables working. I'm using the code on page 136 to display the table, but the problem I'm having is it looks like it's corrupting the data at the end.

I can get it to work with 13 lines, 2 bytes wide. As long as I display the last line having pixels turn on. I'm using white, no colors. If I make the last line black, 00 00, it looks like it corrupts the data. Going up 3 lines, only displaying 10 lines properly. The displayed corrupted data looks like a $05, but when I go into the monitor and look at the code, everything is fine.

This is strange to me because it works with 13 lines filled in, but it won't pad the last line with black.

Does anybody know what I missing here?
Top
 Profile  
Reply with quote  
Dr Jefyll
PostPosted: Wed Jan 17, 2024 4:31 pm 
Offline
User avatar

Joined: Fri Dec 11, 2009 3:50 pm
Posts: 3346
Location: Ontario, Canada
Welcome. :)

You'll find many here who are willing to help. But please bear in mind that we are not zoomed in on the situation to the extent that you are. For most of us, "the code on page 136" means nothing. Each prospective helper would have to go find that code before he/she can even begin.

IOW, there's a needless duplication of effort. It's more productive -- also arguably more courteous -- if you do the legwork (once) and post the code so we all can see it.

This applies more generally in the sense that any help you can provide us -- meaning any and all relevant info; not just code -- will result in us being better able to help you. Cheers!

-- Jeff

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html
Top
 Profile  
Reply with quote  
BigEd
PostPosted: Wed Jan 17, 2024 4:45 pm 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10793
Location: England
Indeed welcome! As Jeff says, please do post code - even if all you can manage is a photo.

Note this: there's the code in the book, and there's the code in your computer. Most likely, you've made a transcription error. Just possibly, the book has a mistake. So there are two versions of the code to proof-read.
Top
 Profile  
Reply with quote  
DrkStarr
PostPosted: Wed Jan 17, 2024 5:50 pm 
Offline

Joined: Tue Jan 16, 2024 11:28 am
Posts: 6
This is the structure of the code I'm trying to get to work:
Code:
* DECLARE VARIABLES

  TVERT      EQU  $06
  HORIZ      EQU  $07
  DEPTH      EQU  $08
  LNGH       EQU  $09
  SLNGH      EQU  $FA
  TEMP       EQU  $FB
  HIRESL     EQU  $1D
  HIRESH     EQU  $HIRESL+$1
  SSHPL      EQU  $EB
  SSHPH      EQU  $SSHPL+$1

* DRAWING SUBROUTINE
  SXDRAW     LDY  TVERT     ; GET VERT VALUE
             JSR  GETADR
             LDX  #$00      ; X REG. SET TO 0. USED FOR INDEX
  SXDRAW2    LDA (SSHPL,X)  ; LOAD BYTE FROM TABLE
             STA (HIRESL),Y ; STORE RESULT ON SCREEN
             INC  SSHPL     ; NEXT BYTE IN TABLE
             INY            ; NEXT SCREEN POSITON IN ROW
             DEC  SLNGH     ; DECREMENT WIDTH
             BNE  SXDRAW2   ; FINISHED WITH ROW?
             INC  TVERT     ; IF SO, INCREMENT TO NEXT LINE
             DEC  DEPTH     ; DECREMENT ROW
             BNE  SXDRAW    ; FINISHED ALL ROWS?
             RTS

* SHIP SETUP SUBROUTINE
  SSETUP     LDA  #<SHIP    ; LOCATION OF TABLE
             STA  SSHPL
             LDA  #>SHIP
             STA SSHPH
             LDA  #$0D      ; DEPTH 13
             STA  DEPTH
             LDA  #$09      ; STARTING HORIZ POS
             STA  HORIZ
             LDA  #$32      ; STARTING VERT POS
             STA  TVERT
             LDA  #$02       ; TABLE 2 BYTES WIDE
             STA  SLNGH
             STA  TEMP
             RTS

* GETADR SUBROUTINE
  GETADR     LDA  YVERTL,Y  ; LOOK UP LO BYTE OF LINE
             CLC
             ADC  HORIZ     ; ADD DIPLACEMENT INTO LINE
             STA  HIRESL
             LDA  YVERTH,Y  ; LOOK UP HI BYTE OF LINE
             STA  HIRESH
             LDA  TEMP
             STA  SLNGH     ; RETORE VARIABLE FROM SETUP
             LDY  #$00
             RTS



The YVERTL and YVERTH are big lookup tables. Each byte is a location on the screen. So, the bitmap lookup table is directly loaded to the screen when drawn.

I hope this helps explain it a little better. :)

Also, the book comes with a disk over on Asimov's. So I ran that too, and I still have the same problem when it tries to pad the last line with black.


Last edited by DrkStarr on Wed Jan 17, 2024 11:07 pm, edited 3 times in total.

Top
 Profile  
Reply with quote  
resman
PostPosted: Wed Jan 17, 2024 8:00 pm 
Offline

Joined: Sat Dec 12, 2015 7:48 pm
Posts: 122
Location: Lake Tahoe
Your code looks fine from a cursory examination, but you’ll have to know the address of your ship’s table. The drawing code only increments the low address pointer, so if the shape table straddles a page crossing it will get drawn incorrectly when the address goes from $XXFF to $XX00. FYI there is a Facebook group (yeah, I know) that is focused on this book. Many of us learned about the secrets of the Apple II from this book back in the day
Top
 Profile  
Reply with quote  
DrkStarr
PostPosted: Wed Jan 17, 2024 8:29 pm 
Offline

Joined: Tue Jan 16, 2024 11:28 am
Posts: 6
The table is declared at $EB. It is all in HEX, like the book. I found $EB and $EC a good place to stick it. I did notice that it's only incrementing the low address pointer, but it worked with a full sprite that uses all the rows. Since it looks good with a full sprite, I would think the code is working properly. Something else seems to be going on when I pad the line on the bottom with zeros. I guess I could redraw the sprites so the padding is at the top. Black at the top works fine, but then I'd have to move the spirit up and down to get the animation to work correctly. Maybe this is what I have to do, but I was trying to skip that step in code, and have it handle in the sprite.

Too bad it's a Facebook group. I don't have the Facebooks. :)
Top
 Profile  
Reply with quote  
BigDumbDinosaur
PostPosted: Wed Jan 17, 2024 9:46 pm 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8144
Location: Midwestern USA
Code:
  GETADR     LDA  YVERTL,Y  ; LOOK UP LO BYTE OF LINE
             CLC
             ADC  HORIZ     ; ADD DIPLACEMENT INTO LINE
             STA  HIRESL
             LDA  YVERTH,Y  ; LOOK UP HI BYTE OF LINE
             ADC #0         ;handle carry from LSB addition <<<———
             STA  HIRESH
             LDA  TEMP
             STA  SLNGH     ; RETORE VARIABLE FROM SETUP
             LDY  #$00
             RTS

The highlighted instruction appears to be missing.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!
Top
 Profile  
Reply with quote  
DrkStarr
PostPosted: Wed Jan 17, 2024 11:19 pm 
Offline

Joined: Tue Jan 16, 2024 11:28 am
Posts: 6
I added the ADC, but it didn't help. I'm not sure what is stored in #0. $0 blacks the screen.

I also redesigned the sprite so there's no black padding at the bottom, but it's still corrupting the last few lines when drawn. So the first one works fine, but the second one fails. Kind of strange. I'm not sure how a HEX table could do something like that as long as the high bit doesn't go over 7. It should be okay.
Top
 Profile  
Reply with quote  
resman
PostPosted: Thu Jan 18, 2024 12:23 am 
Offline

Joined: Sat Dec 12, 2015 7:48 pm
Posts: 122
Location: Lake Tahoe
DrkStarr wrote:
The table is declared at $EB. It is all in HEX, like the book. I found $EB and $EC a good place to stick it. I did notice that it's only incrementing the low address pointer, but it worked with a full sprite that uses all the rows. Since it looks good with a full sprite, I would think the code is working properly. Something else seems to be going on when I pad the line on the bottom with zeros. I guess I could redraw the sprites so the padding is at the top. Black at the top works fine, but then I'd have to move the spirit up and down to get the animation to work correctly. Maybe this is what I have to do, but I was trying to skip that step in code, and have it handle in the sprite.

Too bad it's a Facebook group. I don't have the Facebooks. :)

$EB-$EC is where the *pointer* to the shape table is declared. You need to know the actual address of the shape table to make sure it doesn't straddle a page boundary.
Top
 Profile  
Reply with quote  
resman
PostPosted: Thu Jan 18, 2024 12:29 am 
Offline

Joined: Sat Dec 12, 2015 7:48 pm
Posts: 122
Location: Lake Tahoe
BigDumbDinosaur wrote:
Code:
  GETADR     LDA  YVERTL,Y  ; LOOK UP LO BYTE OF LINE
             CLC
             ADC  HORIZ     ; ADD DIPLACEMENT INTO LINE
             STA  HIRESL
             LDA  YVERTH,Y  ; LOOK UP HI BYTE OF LINE
             ADC #0         ;handle carry from LSB addition <<<———
             STA  HIRESH
             LDA  TEMP
             STA  SLNGH     ; RETORE VARIABLE FROM SETUP
             LDY  #$00
             RTS

The highlighted instruction appears to be missing.

The way the Apple II screen memory is laid out you don't have to worry about carry out per scanline. One of the few consolations to the Apple II video memory organization.
Top
 Profile  
Reply with quote  
DrkStarr
PostPosted: Thu Jan 18, 2024 1:12 am 
Offline

Joined: Tue Jan 16, 2024 11:28 am
Posts: 6
resman wrote:
$EB-$EC is where the *pointer* to the shape table is declared. You need to know the actual address of the shape table to make sure it doesn't straddle a page boundary.

Okay, I think I know what you mean. When I compile it, it looks like the first table is at $61D2, it works fine. The second table is at $61EC. Which should be 26 bytes away. That's the one I'm having problems with. Also, if I move the second table up to $61D2, it works fine. So something is going on when I go from $61FF to $6200. Is this the split you're talking about? Do I have to start the second sprite at $6200? Or do I have to take into account another variable shift that I'm missing? And if I'm just flooding the code with HEX, how do I set where the HEX table starts?

Thanks for all the help
Top
 Profile  
Reply with quote  
resman
PostPosted: Thu Jan 18, 2024 2:20 am 
Offline

Joined: Sat Dec 12, 2015 7:48 pm
Posts: 122
Location: Lake Tahoe
DrkStarr wrote:
resman wrote:
$EB-$EC is where the *pointer* to the shape table is declared. You need to know the actual address of the shape table to make sure it doesn't straddle a page boundary.

Okay, I think I know what you mean. When I compile it, it looks like the first table is at $61D2, it works fine. The second table is at $61EC. Which should be 26 bytes away. That's the one I'm having problems with. Also, if I move the second table up to $61D2, it works fine. So something is going on when I go from $61FF to $6200. Is this the split you're talking about? Do I have to start the second sprite at $6200? Or do I have to take into account another variable shift that I'm missing? And if I'm just flooding the code with HEX, how do I set where the HEX table starts?

Thanks for all the help

You have a coupe of options: One, use your assembler to locate your shape table so it doesn't cross a page boundary. Another is to fix the drawing code to adjust the MSB when the LSB of the shape pointer wraps around (hint, this is the right answer).

This, as the old saying goes, is an exercise left to the student. Oh, and you may want to check your hex math.
Top
 Profile  
Reply with quote  
leepivonka
PostPosted: Thu Jan 18, 2024 2:38 am 
Offline

Joined: Fri Apr 15, 2016 1:03 am
Posts: 135
Looking at SXDRAW:
Code:
* DRAWING SUBROUTINE
  SXDRAW     LDY  TVERT     ; GET VERT VALUE
             JSR  GETADR
             LDX  #$00      ; X REG. SET TO 0. USED FOR INDEX
  SXDRAW2    LDA (SSHPL,X)  ; LOAD BYTE FROM TABLE
             STA (HIRESL),Y ; STORE RESULT ON SCREEN
             INC  SSHPL     ; NEXT BYTE IN TABLE
             INY            ; NEXT SCREEN POSITON IN ROW
             DEC  SLNGH     ; DECREMENT WIDTH
             BNE  SXDRAW2   ; FINISHED WITH ROW?
             INC  TVERT     ; IF SO, INCREMENT TO NEXT LINE
             DEC  DEPTH     ; DECREMENT ROW
             BNE  SXDRAW    ; FINISHED ALL ROWS?
             RTS

Consider what happens at "INC SSHPL" when SSHPH:SSHPL contains $61ff.
"INC SSHPL" increments the lo byte, but the hi byte remains unchanged, giving $6100 as the pointer to the next table byte. You probably wanted $6200.

This breaks only when a table crosses a page boundary. You could arrange for your tables to never straddle a page boundary, or you could modify the code to handle incrementing across a page boundary:
Code:
             INC  SSHPL     ; NEXT BYTE IN TABLE
             BNE NoCarry   ; if zero
             INC SSHPH     ;   increment the hi byte to propagate the carry from the lo byte
NoCarry:


edit: I see resman beat me to it!
Top
 Profile  
Reply with quote  
DrkStarr
PostPosted: Thu Jan 18, 2024 3:33 am 
Offline

Joined: Tue Jan 16, 2024 11:28 am
Posts: 6
leepivonka wrote:
Consider what happens at "INC SSHPL" when SSHPH:SSHPL contains $61ff.
"INC SSHPL" increments the lo byte, but the hi byte remains unchanged, giving $6100 as the pointer to the next table byte. You probably wanted $6200.

This breaks only when a table crosses a page boundary. You could arrange for your tables to never straddle a page boundary, or you could modify the code to handle incrementing across a page boundary:
Code:
             INC  SSHPL     ; NEXT BYTE IN TABLE
             BNE NoCarry   ; if zero
             INC SSHPH     ;   increment the hi byte to propagate the carry from the lo byte
NoCarry:



I was trying to do something like this, and I was able to get the computer to beep once when the number wrapped, but horribly inefficient, and it still didn't draw properly.

Thanks so much. It works. :)

Oh yeah. I also tried using ORG to stick them in different memory locations, but that failed horribly as well. Not sure why. I used, $300, $1000, $6200, $8000, $9000. But the image was different every time.
Top
 Profile  
Reply with quote  
BigDumbDinosaur
PostPosted: Thu Jan 18, 2024 4:03 pm 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8144
Location: Midwestern USA
resman wrote:
BigDumbDinosaur wrote:
Code:
  GETADR     LDA  YVERTL,Y  ; LOOK UP LO BYTE OF LINE
             CLC
             ADC  HORIZ     ; ADD DIPLACEMENT INTO LINE
             STA  HIRESL
             LDA  YVERTH,Y  ; LOOK UP HI BYTE OF LINE
             ADC #0         ;handle carry from LSB addition <<<———
             STA  HIRESH
             LDA  TEMP
             STA  SLNGH     ; RETORE VARIABLE FROM SETUP
             LDY  #$00
             RTS

The highlighted instruction appears to be missing.

The way the Apple II screen memory is laid out you don't have to worry about carry out per scanline. One of the few consolations to the Apple II video memory organization.

OIC.  I'm not familiar with the Apple II hardware.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!
Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  Page 1 of 2
  [ 19 posts ]  Go to page 1, 2  Next

Board index » 6502.org Users Forum » Programming

All times are UTC


Who is online

Users browsing this forum: No registered users and 27 guests

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
6502.org is an ongoing project by Mike Naberezny and contributors.