ASM6 Compile Problems

Are you new to 6502, NES, or even programming in general? Post any of your questions here. Remember - the only dumb question is the question that remains unasked.

Moderator: Moderators

User avatar
Lucradan
Posts: 101
Joined: Wed Sep 21, 2016 12:08 pm

ASM6 Compile Problems

Post by Lucradan » Wed Apr 05, 2017 4:43 pm

I'm trying to compile some code using ASM6 but it is not working and I can't seem to figure out why.

In the attached code, when ASM6 hits the block

Code: Select all

LBL.GameState.Initialize:
  JSR LBL.Scene.Initialize.Launcher
  LDA VAR.GameState.Construct
  STA VAR.GameState
  RTS
It converts it to the following when disassembled in NESREVPlus v0.3b

.DB $20,$7A,$C0,$A5,$01,$85,$03,$60

Any insight as to what I am doing wrong would be greatly appreciated.

Thank you.
Attachments
mario.chr
(8 KiB) Downloaded 100 times
Test3.txt
(18.5 KiB) Downloaded 104 times

hackfresh
Posts: 100
Joined: Sun May 03, 2015 8:19 pm

Re: ASM6 Compile Problems

Post by hackfresh » Wed Apr 05, 2017 4:54 pm

What isn't working specifically?

User avatar
tokumaru
Posts: 11998
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: ASM6 Compile Problems

Post by tokumaru » Wed Apr 05, 2017 6:03 pm

The opcodes look correct to me... Are the addresses wrong or something?

User avatar
Lucradan
Posts: 101
Joined: Wed Sep 21, 2016 12:08 pm

Re: ASM6 Compile Problems

Post by Lucradan » Wed Apr 05, 2017 7:15 pm

Honestly, I'm thinking the problem is more me and my lack of understanding of asm6. Somewhere the code is not doing what it suppose to, even though it compiled. Going to work on it more tonight.

User avatar
dougeff
Posts: 2820
Joined: Fri May 08, 2015 7:17 pm
Location: DIGDUG
Contact:

Re: ASM6 Compile Problems

Post by dougeff » Wed Apr 05, 2017 7:32 pm

I only spent a few seconds looking at your code...noticed one thing at least...

.enum $0300
BUF.Sprites

Then later,

LBL.CopySprites:
LDA BUF.Sprites + 1
STA $4014
RTS

this will evaluate to...
LDA $0301 ; from the absolute address
STA $4014

I think what you wanted was...
lda #$00
sta $2003
lda #>BUF.Sprites ; lda immediate the upper byte of the sprite buffer
sta $4014



And your controller reads has a bug. It will read from controller 2 256 times, since X = 0 entering this loop.

LBL.ReadController2.Loop:


EDIT

and this...

LBL.LoadBackground.Loop:
LDA PTR.Background, y

should probably be an indirect addressing mode

LBL.LoadBackground.Loop:
LDA (PTR.Background), y ; the parenthesis is necessary

otherwise, without the parenthesis, it evaluates to...

LDA $0006, y ; an absolute address, somewhere in the zero page

rather than the thing pointed to by that address.

(note, there is no 'zero-page, y' addressing on the 6502, so it must be absolute, y)
nesdoug.com -- blog/tutorial on programming for the NES

User avatar
Lucradan
Posts: 101
Joined: Wed Sep 21, 2016 12:08 pm

Re: ASM6 Compile Problems

Post by Lucradan » Thu Apr 06, 2017 12:34 am

After spending a few hours making adjustments and fixes to the code, I was able to make significant progress. I still have a graphics bug that I am not able to pinpoint the root cause. I have attached the current version of the code and an image that shows the problem.
Comparison.png
The left image is what my code is returning. The right image is what it should look like.
Attachments
Test4.txt
(18.25 KiB) Downloaded 100 times

User avatar
Lucradan
Posts: 101
Joined: Wed Sep 21, 2016 12:08 pm

Re: ASM6 Compile Problems

Post by Lucradan » Thu Apr 06, 2017 10:10 am

I found the problem, and it had to do with indirect addressing.

I was able to fix most of the graphics issues, but I still have some sprite pixels in the upper left corner of my screen that I cannot account for.

It's probably something with my Sprite Buffer and OAM Copy code, but I can't pinpoint what is the exact cause. Any help would be greatly appreciated.

Thank You
Untitled.png
Attachments
Test4.txt
(18.6 KiB) Downloaded 98 times

User avatar
rainwarrior
Posts: 8002
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: ASM6 Compile Problems

Post by rainwarrior » Thu Apr 06, 2017 10:22 am

Looks like you've probably filled the unused part of your OAM data buffer with 0s?

Sprite data of 0,0,0,0 will put a sprite at X=0, Y=1, tile=0, palette=0, so with the top 8 lines cropped off (normal for NTSC NES) you'll see 1 row of pixels peeking out the bottom.

Use $FF in the Y coordinate field for unused sprites instead (places them off the bottom of the screen).

User avatar
Lucradan
Posts: 101
Joined: Wed Sep 21, 2016 12:08 pm

Re: ASM6 Compile Problems

Post by Lucradan » Thu Apr 06, 2017 10:27 am

rainwarrior wrote:Looks like you've probably filled the unused part of your OAM data buffer with 0s?
Yeap, That is exactly what I did!

It works perfect now. Thank you!

User avatar
tokumaru
Posts: 11998
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: ASM6 Compile Problems

Post by tokumaru » Thu Apr 06, 2017 10:31 am

rainwarrior wrote:with the top 8 lines cropped off (normal for NTSC NES)
Some of you guys keep saying that it's normal for the top and bottom 8 scanlines to be hidden in NTSC, but in my own experience these numbers can change a lot from TV to TV. My 21" CRT crops about 12 scanlines from the top, but a little less than 8 at the bottom IIRC.

As a developer, you should configure your emulators to show the full picture (FCEUX for example is configured to hide scanlines by default), so you can see everything your programs output. Even if you plan on ultimately having the TV hide glitches in those areas (which may or may not happen, depending on the TV), as a developer you should make sure that even the glitches are behaving as intended.

User avatar
Lucradan
Posts: 101
Joined: Wed Sep 21, 2016 12:08 pm

Re: ASM6 Compile Problems

Post by Lucradan » Thu Apr 06, 2017 10:49 am

Just so I'm understanding. There are always 64 sprites being drawn, but some are offscreen?

tepples
Posts: 22281
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: ASM6 Compile Problems

Post by tepples » Thu Apr 06, 2017 10:52 am

Correct.

The NES PPU offers no way to hide sprites other than to set the Y coordinate such that the sprite doesn't overlap any scanlines. This means the Y coordinate should be at least 239.

User avatar
rainwarrior
Posts: 8002
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: ASM6 Compile Problems

Post by rainwarrior » Thu Apr 06, 2017 11:42 am

tokumaru wrote:
rainwarrior wrote:with the top 8 lines cropped off (normal for NTSC NES)
Some of you guys keep saying that it's normal for the top and bottom 8 scanlines to be hidden in NTSC, but in my own experience these numbers can change a lot from TV to TV. My 21" CRT crops about 12 scanlines from the top, but a little less than 8 at the bottom IIRC.
I'm not sure what "guys" I'm being lumped with here, but it's normal/default in almost all NES emulators, including FCEUX which was the specific case we were looking at a screenshot of.

If you wanna do a deep dive into it, though, we've got a wiki article about the topic:
http://wiki.nesdev.com/w/index.php/Overscan

User avatar
tokumaru
Posts: 11998
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: ASM6 Compile Problems

Post by tokumaru » Thu Apr 06, 2017 1:43 pm

I honestly can't remember who the "guys" are, but I often see it stated as a fact here in the forums that in NTSC the top and bottom 8 scanlines are hidden, as if things were really as simple and exact as this.

This can actually be a pretty significant source of confusion for beginners, to the point where some people are still not sure about what the vertical resolution of the NES is, or that it can switch between 240 and 224.

User avatar
rainwarrior
Posts: 8002
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: ASM6 Compile Problems

Post by rainwarrior » Thu Apr 06, 2017 2:06 pm

Also. Lucradan, I highly recommend switching to FCEUX's "New PPU" mode, which is a lot more accurate and better suited for development. (The legacy "Old PPU" is unfortunately the default setting.)

Config > PPU > New PPU

If you do want to eliminate the overscan, as well, the option is here:

Config > Video...

Post Reply