Stella Stuck

Just Jeff · May 27, 2017

Hi.. I'm trying to get this simple paddle routine going, but nothing shows up in Stella. When I hit the debugger, I see only RAM addresses with crazy op codes.

I thought it was my attempt at using a macro that was doing it, but I commented it out and there is no difference. Reset vector looks right, and when I read through from there, I can't see where it goes off track.

Any ideas?

Thanks for any help!

JS.bin

JS.asm

Just Jeff · May 27, 2017

And here's the code:

; dasm JS.asm -f3 -v0 -sJS.sym -lJS.lst -oJS.bin

PROCESSOR 6502
 

TIA_BASE_READ_ADDRESS = $30
        include vcs.h
        include macro.h
	
	SEG.U VARS
	ORG $80

Paddle1:      ds 1

        ;MAC READ_PADDLE_1
        ;lda INPT0         ; 3   - always 9
        ;bpl .save         ; 2 3
        ;.byte $2c         ; 4 0
;.save   sty Paddle1       ; 0 3
        ;ENDM

	SEG CODE
	
	org $F000

InitSystem:
	CLEAN_START
	
VerticalBlank:
        lda #$82
        sta WSYNC
        sta VSYNC         ; 3    start vertical sync, D1=1
        sta VBLANK        ; 3  6 start vertical blank and dump paddles to ground
        lda #$2C          ; 2  8 set timer for end of Vertical Blank
        sta TIM64T        ; 4 12
        sta WSYNC         ; 1st line of vertical sync
        sta WSYNC         ; 2nd line of vertical sync
        lda #0
        sta WSYNC         ; 3rd line of vertical sync
        sta VSYNC         ; stop vertical sync, D1=0
        ;ldx #3
  
PosObjectLoop
        lda Paddle1		   ;+4    9
        sta WSYNC
DivideLoop
        sbc #15
        bcs DivideLoop   ;+4   13
        eor #7
        asl
        asl
        asl
        asl         
        sta.wx HMP0  ;+4   17
        sta RESP0      ;+4   23
	
	sta WSYNC
	sta HMOVE

	lda #$0f    ; set color for paddle 1 display
	sta COLUP0
	 
	;ldx Paddles2Read
	lda #153       ; prep paddle results with highest possible value
	sta Paddle1 ;,x  ; our initial paddle results will be 1-153
	;sta Paddle3,x  ; and will be adjusted to 0-152 in overscan
	ldx #0
	
VblankWait
        lda INTIM
        bpl VblankWait
	
	sta WSYNC
	sta HMCLR         ; clear hmoves for next time around
        stx VBLANK        ; turn on video output & remove paddle dump to ground
        ldy #152
ReadLoop
	sta WSYNC
	sty COLUBK
	;READ_PADDLE_1 ; reads the paddles
	    lda INPT0         ; 3   - always 9
        bpl .save         ; 2 3
        .byte $2c         ; 4 0
.save   sty Paddle1       ; 0 3

	dey
	bne ReadLoop
	
; display Paddle 1's value by using Player 0
	sta WSYNC
	lda #$FF
	sta GRP0
	ldy #24
P0loop	
	sta WSYNC
	dey
	bne P0loop
	
	lda #$26   ; prep overscan delay
	sta WSYNC
	sta TIM64T ; set overscan delay
	
	;sty ENAM1
	
OSwait	
	lda INTIM
	bpl OSwait
	jmp VerticalBlank

	
	org $FFFA
        .word InitSystem ; NMI
        .word InitSystem ; RESET
        .word InitSystem ; IRQ

Just Jeff · May 27, 2017

So if the RAM is full of random values when it should be mostly zeros, and the code segment of my program doesn't even seem to exist, then...

+SpiceWare · May 27, 2017

I see you made a listing (always a good idea!). Did you by chance take a look at it? Whenever I encounter something odd I'll open up the listing and search for "error".

First error is on line 3:

JS.asm (3): error: Unknown Mnemonic '6502'.
      3  0000 ????			   PROCESSOR  6502

later on you'll see more errors that tie into it:

JS.asm (112): error: Unknown Mnemonic 'lda'.
    112  f001					      lda	INTIM
JS.asm (113): error: Unknown Mnemonic 'bpl'.
    113  f001					      bpl	OSwait
JS.asm (114): error: Unknown Mnemonic 'jmp'.
    114  f001					      jmp	VerticalBlank

dasm supports a number of processors, if it doesn't know you're coding for a 6502 it won't recognize the opcodes (mnemonics).

This is an instance where whitespace is very important - due to missing whitespace, dasm thinks "processor" is a label in your program.

Just Jeff · May 27, 2017

DirtyHairy · May 27, 2017

Your "PROCESSOR 6502" is missing a tab If you inspect your reset vectors in memory, you'll find that they are stored as big endian, not as little endian, which is the reason why Stella shows garbage: it is disassembling at 0x0070 (not 0x7000).

Just Jeff · May 28, 2017

I see you made a listing (always a good idea!). Did you by chance take a look at it? Whenever I encounter something odd I'll open up the listing and search for "error".

First error is on line 3:
JS.asm (3): error: Unknown Mnemonic '6502'.
      3  0000 ????			   PROCESSOR  6502
later on you'll see more errors that tie into it:
JS.asm (112): error: Unknown Mnemonic 'lda'.
    112  f001					      lda	INTIM
JS.asm (113): error: Unknown Mnemonic 'bpl'.
    113  f001					      bpl	OSwait
JS.asm (114): error: Unknown Mnemonic 'jmp'.
    114  f001					      jmp	VerticalBlank
dasm supports a number of processors, if it doesn't know you're coding for a 6502 it won't recognize the opcodes (mnemonics).

This is an instance where whitespace is very important - due to missing whitespace, dasm thinks "processor" is a label in your program.

Oooohhh.. I was convinced it was my syntax somewhere... I looked at that over and over and never picked up on that. Thanks!

I've never looked at the list file. I guess I had to learn that hard way. I don't see "error", It shows "????" instead. I can see where it included VCS registers though from include vcs.h

      1  10000 ????						; dasm JS.asm -f3 -v0 -sJS.sym -lJS.lst -oJS.bin
      2  10000 ????
      3  10000 ????				       PROCESSOR	6502
      4  10000 ????						; paddle game
      5  10000 ????						; Jeff Haber
      6  10000 ????						; 27 May 2017
      7  10000 ????
      8  10000 ????						;
      9  10000 ????						;

Just Jeff · May 28, 2017

Your "PROCESSOR 6502" is missing a tab If you inspect your reset vectors in memory, you'll find that they are stored as big endian, not as little endian, which is the reason why Stella shows garbage: it is disassembling at 0x0070 (not 0x7000).

Interesting. Did you use DiStella or something?

+SpiceWare · May 28, 2017

I've never looked at the list file. I guess I had to learn that hard way. I don't see "error", It shows "????" instead.

That's odd - what version of dasm are you using? If you just type dasm it'll be the first thing it outputs:

Darrells-Mac-Pro:~ darrellspice$ dasm
DASM 2.20.11
Copyright (c) 1988-2008 by various authors (see file AUTHORS).
License GPLv2+: GNU GPL version 2 or later (see file COPYING).
DASM is free software: you are free to change and redistribute it.
There is ABSOLUTELY NO WARRANTY, to the extent permitted by law.
...

Just Jeff · May 28, 2017

Looks the same...

C:\Atari\dasm>dasm
DASM 2.20.11 20140304
Copyright © 1988-2008 by various authors (see file AUTHORS).
License GPLv2+: GNU GPL version 2 or later (see file COPYING).
DASM is free software: you are free to change and redistribute it.
There is ABSOLUTELY NO WARRANTY, to the extent permitted by law.

RevEng · May 28, 2017

Looks the same...

C:\Atari\dasm>dasm

DASM 2.20.11 20140304

Copyright © 1988-2008 by various authors (see file AUTHORS).

License GPLv2+: GNU GPL version 2 or later (see file COPYING).

DASM is free software: you are free to change and redistribute it.

There is ABSOLUTELY NO WARRANTY, to the extent permitted by law.

Slightly different - it's the 20140304 updated version.

I have the same version, but I actually do get the "error" line in the listing, if I use your source with the un-indented "PROCESSOR 6502".

Thomas Jentzsch · May 28, 2017

-v0 suppresses quite some messages, maybe try -v1

Just Jeff · May 28, 2017

Here it is with v1:

------- FILE JS.asm LEVEL 1 PASS 1

1 0000 ???? ; dasm JS.asm -f3 -v0 -sJS.sym -lJS.lst -oJS.bin

2 0000 ????

JS.asm (3): error: Unknown Mnemonic '6502'.

3 0000 ???? PROCESSOR 6502

4 0000 ????

But I did notice the output in the command prompt shows two unknown symbols where v0 just says "Complete"

C:\Atari\dasm>dasm JS.asm -f3 -v0 -sJS.sym -lJS.lst -oJS.bin
Complete.

C:\Atari\dasm>dasm JS.asm -f3 -v1 -sJS.sym -lJS.lst -oJS.bin

START OF PASS: 1

----------------------------------------------------------------------
SEGMENT NAME                 INIT PC  INIT RPC FINAL PC FINAL RPC
CODE                         f000                            f000
VARS                     [u] 0080                            0080
                             0000 ????                       0000 ????
RIOT                     [u] 0280                            0280
TIA_REGISTERS_READ       [u] 0030                            0030
TIA_REGISTERS_WRITE      [u] 0000                            0000
INITIAL CODE SEGMENT         0000 ????                       0000 ????
----------------------------------------------------------------------
2 references to unknown symbols.
0 events requiring another assembler pass.

Complete.

DirtyHairy · May 28, 2017

Interesting. Did you use DiStella or something?

I used the 6502.ts debugger at https://6502ts.github.io/dev/stella.html

The dump of the last 6 bytes from 0xFFFA -- 0xFFFF shows your vectors. Also, the CPU state after boot shows that execution indeed starts from 0x00F0.

However, you can also use the Stella debugger for this (start with "stella -debug" to begin debugging right away)

The dump shows the vectors, and the CPU state shows the initial value of PC (program counter).

You can also just look at your image using a hex editor.

You can see the vectors at the end of the image, and you can also see that dasm hasn't output anything other than 0xFF

Edited May 28, 2017 by DirtyHairy

Just Jeff · May 28, 2017

Sweet.. I'll look into that in a minute.. In the meantime.. I hate to ask because I really am trying to figure it out myself... But can anybody figure out why the player is not moving? I've played with Stella's paddle settings but I get nothing.. and I thought I'd be a little farther along on this at this point in a three day weekend.

JS.bin

JS.asm

+stephena · May 28, 2017

However, you can also use the Stella debugger for this (start with "stella -debug" to begin debugging right away)

stella1.png

This indicates a bug in the 'dump' command; it should stop after $FFFF

DirtyHairy · May 28, 2017

This indicates a bug in the 'dump' command; it should stop after $FFFF

Or wrap, this is what 6502.ts does.

RevEng · May 28, 2017

Sweet.. I'll look into that in a minute.. In the meantime.. I hate to ask because I really am trying to figure it out myself... But can anybody figure out why the player is not moving? I've played with Stella's paddle settings but I get nothing.. and I thought I'd be a little farther along on this at this point in a three day weekend.

Works for me. Maybe you're not getting the paddles selected correctly in stella?

+SpiceWare · May 28, 2017

Works for me too. After changing the controller in Stella you have to reload the ROM (hit CONTROL-R).

Just Jeff · May 28, 2017

OK thanks.. Reloading ROM seems to work... But.. are you getting smooth movement? Mine is jumping 15 pixels or so.

Edited May 28, 2017 by BNE Jeff

RevEng · May 28, 2017

OK thanks.. Reloading ROM seems to work... But.. are you getting smooth movement? Mine is jumping 15 pixels or so.

Look at your object positioning code.

sta.wx HMP0

...is the same thing to dasm as this...

sta.w HMP0,x

And you've got x=3 heading into the object positioning code, so the fine-positioning/motion is getting set for the wrong object.

Just Jeff · May 28, 2017

Dang it.. I've been staring at the positioning routine for half an hour because of the fact that it looked like 15 pixel increments. I guess I've forgotten what .wx means. I was thinking it meant "word" and couldn't figure out why it was used here. I'm rusty.. Thanks!

Just Jeff · May 28, 2017

Smooth...

JS.asm

JS.bin

Kylearan · May 29, 2017

This is an instance where whitespace is very important - due to missing whitespace, dasm thinks "processor" is a label in your program.

I've made the same mistake in the past as well, multiple times with different variations in fact, and I profoundly hate how most assemblers (and dasm in particular) require whitespace in certain areas. That's so anachronistic!

It's also one of the reasons I started to develop a new 650x assembler of my own which is completely whitespace-agnostic. It's written in C++, and funnily enough I got stuck for almost an hour debugging my Makefile - only to find out that make expects tabs in certain places instead of spaces. Whitespace silliness strikes again... :twisted:

It's 2017, for crying out loud! :mad:

Thomas Jentzsch · May 29, 2017

Long live the whitespace!

Stella Stuck

Recommended Posts

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Join the conversation

Recently Browsing 0 members