ASM6 Compile Problems

[Lucradan]

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.

[hackfresh]

What isn't working specifically?

[tokumaru]

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

[Lucradan]

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.

[dougeff]

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)

[Lucradan]

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.

The left image is what my code is returning. The right image is what it should look like.

[Lucradan]

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

[rainwarrior]

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).

[Lucradan]

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!

[tokumaru]

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.

[Lucradan]

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

[tepples]

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.

[rainwarrior]

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

[tokumaru]

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.

[rainwarrior]

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...