Jump to content

Photo

I'm getting 3 different results


9 replies to this topic

#1 Kiwi ONLINE  

Kiwi

    Stargunner

  • 1,591 posts

Posted Mon Oct 23, 2017 3:47 PM

I start messing with 8bitworkshop.  I'm learning how to use the motion register.  Just last night I figured that the Atari doesn't know where the H position of the sprites,I'm 100% not sure about that.  So I used    
sta RESM1
sta RESP0

After CLEANSTART to get them to 0.

In 8bitworkshop, I got the desire result.

bouncymessage.gif

In Stella 4 and 5, they are at the wrong position.  Just curious why that is.

 

wrongposition.png

I'm still learning asm coding and figured out how to do branching without putting the code outside the loop, and found out there's limited range that you can branch out from.  So much to learn. ;-)

code:
 

	processor 6502
        include "vcs.h"
        include "macro.h"
        include "xmacro.h"

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; Variables segment

        seg.u Variables
	org $80
	
Temp		.byte
PFPtr	word	; pointer to playfield data
SPPtr	word
Xpos	byte
Flower  byte
Message byte
MesColor byte
MesColor2 byte
Waterfallcolor byte
Waterfallcolor2 byte
MessageXPos byte
MessageDir byte
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; Code segment

	seg Code
        org $f000

Start
	CLEAN_START
	sta RESM1
	sta RESP0
        lda MesColor2
        sta COLUP0
;        sta Waterfallcolor
	lda #$9e
        sta COLUP1
        sta Waterfallcolor2
	LDA #$68
        STA COLUBK
	lda #$60
	sta COLUPF
	LDA #$FF
        STA PF0
	lda #%00000101
	sta CTRLPF
        lda #<PFdata
        sta PFPtr
        lda #>PFdata
        sta PFPtr+1
        lda #<PLAYER0data
        sta SPPtr
        lda #>PLAYER0data
        sta SPPtr+1
        lda #%00110101
	sta NUSIZ0
        lda #%00110100
	sta NUSIZ1
        lda #3
	sta WSYNC
	sta ENAM1
	ldx #$21
MoveMissile	
	lda #$f0
	sta HMM1
        STA HMOVE
	sta HMCLR
	sta WSYNC
	dex
        bne MoveMissile
	ldx #$32
MovePlayer
	lda #$f0
	sta HMP0
        STA HMOVE
	inc MessageXPos
;	sta HMCLR
	sta WSYNC
	dex
        bne MovePlayer

	
;	ldx #3
;        lda #$0
;	jsr SetHorizPos 
;        lda #50
;        sta Xpos
	sta HMCLR
	lda #$FF
	sta GRP0
	lda #$f0
	sta HMP0
	
	inc MessageXPos
	lda #0
	sta MessageDir
	jmp NextFrame
Start2
	jmp Start
MoveRight
	inc MessageXPos
        jmp RMMRight
MoveLeft
	dec MessageXPos
	jmp RMMLeft
;	lda #$00
;	sta HMP0
ReversePlayerMotion
	lda #$10
	sta HMP0
	lda #1
	sta MessageDir
        jmp ReturnRPM

VersePlayerMotion
	lda #$f0
	sta HMP0
	lda #0
	sta MessageDir
        jmp ReturnVPM
NextFrame
        lsr SWCHB	; test Game Reset switch
3        bcc Start2	; reset?
; 3 lines of VSYNC
	VERTICAL_SYNC
; 37 lines of underscan
	TIMER_SETUP 37
;	lda #%00000010
;        STA VBLANK
	
	sta HMOVE
	ldx MessageDir
	cpx #0
	beq MoveRight
RMMRight
	cpx #1
	beq MoveLeft
RMMLeft
	ldx MessageXPos
	cpx #$50
	beq ReversePlayerMotion
ReturnRPM
	ldx MessageXPos
	cpx #$1a
	beq VersePlayerMotion
ReturnVPM
        inc MesColor2
        lda MesColor2
	sta MesColor
        sta COLUP0
	inc Waterfallcolor2
	lda Waterfallcolor2
	sta Waterfallcolor
	sta COLUP1
	tay
	cpy #$a0
	beq RestoreWFcolor2
ReWFc2
	TIMER_WAIT
	STA WSYNC
        lda #%00110000
	STA VBLANK
;        lda #$00
;        sta Flower
        ldx #96
        ldy #$7
	sty Flower
	ldy #94
	sty Message
; 192 lines of frame
;	TIMER_SETUP 192
Loop

	STA WSYNC
        ldy Flower
	lda (PFPtr),y
	sta PF1
	dey
	beq Loadnumber 	
Backhere
	sty Flower
	ldy Waterfallcolor
	sty COLUP1
	dec Waterfallcolor
	cpy #$90
	beq RestoreWFcolor
ReWFc

 	dec MesColor
        lda MesColor
        sta COLUP0
	sta WSYNC
       	ldy Waterfallcolor
	sty COLUP1
	dec Waterfallcolor
	cpy #$90
	beq RestoreWFcolor3
ReWFc3
        ldy Message
        lda (SPPtr),y
        sta GRP0
        dey
        sty Message
 
 	dec MesColor
        lda MesColor
        sta COLUP0
        
        
	dex
	BNE Loop        
;	TIMER_WAIT
; 30 lines of overscan
	TIMER_SETUP 30
;        STA VBLANK
	lda #%00000010
        STA VBLANK 
        TIMER_WAIT

; go to next frame
        jmp NextFrame


        
Loadnumber
	ldy #$7
	jmp Backhere

RestoreWFcolor
	ldy #$9e
	sty Waterfallcolor
	jmp ReWFc

RestoreWFcolor3
	ldy #$9e
	sty Waterfallcolor
	jmp ReWFc3
        
RestoreWFcolor2
	ldy #$90
	sty Waterfallcolor2
	jmp ReWFc2        
SetHorizPos
	sta WSYNC	; start a new line
	sta HMOVE	; apply the previous fine position(s)
	sta HMCLR	; reset the old horizontal position(s)
	sec		; set carry flag
DivideLoop
	sbc #15		; subtract 15
	bcs DivideLoop	; branch until negative
	eor #7		; calculate fine offset
	asl
	asl
	asl
	asl
	sta RESP0,x	; fix coarse position
	sta HMP0,x	; set fine offset
	rts		; return to caller




	align $100
PFdata
        .byte  #%01111110
        .byte  #%11000011
        .byte  #%10011001
        .byte  #%00101001
        .byte  #%00100001
        .byte  #%00111101
        .byte  #%10000001
        .byte  #%01000010

PLAYER0data
    
        .byte #%00000000
        .byte #%00010000        
        .byte #%00000000
        .byte #%00010000        
        .byte #%00010000
        .byte #%00010000        
        .byte #%00010000
	.byte #%00000000
	.byte #%01010100
	.byte #%01010100
	.byte #%01010100        
	.byte #%01101100        
	.byte #%00000000        
	.byte #%00111000        
	.byte #%01000100        
	.byte #%01000100        
	.byte #%01000100        
	.byte #%00000000        
	.byte #%00111100        
       	.byte #%01000100
       	.byte #%01000000
	.byte #%00111100        
       	.byte #%00000000;day
        .byte #%00000000
        .byte #%00000000;t
        .byte #%00111010
        .byte #%01000100
        .byte #%01000100
        .byte #%00111000
        .byte #%00100100
        .byte #%00100100
        .byte #%00011000
        .byte #%00000000      
        .byte #%00000000
        .byte #%01111000
        .byte #%00001100
        .byte #%01110000
        .byte #%00111100  
        .byte #%00000000
        .byte #%00010000
        .byte #%00010000
        .byte #%00010000
        .byte #%01111100      
        .byte #%00000000
        .byte #%01111100
        .byte #%01000000
        .byte #%01110000
        .byte #%01111100
        .byte #%00000000
        .byte #%01111100
        .byte #%01000000
        .byte #%01110000
        .byte #%01111100      
        .byte #%00000000
        .byte #%00101000
        .byte #%01010100
        .byte #%01010100
        .byte #%01010100
        .byte #%00000000
        .byte #%01111000
        .byte #%00001100
        .byte #%01110000
        .byte #%00111100      
        .byte #%00000000
        .byte #%00000000
        .byte #%00010000
        .byte #%00010000
        .byte #%00101000
        .byte #%01000100
        .byte #%00000000
        .byte #%01111000
        .byte #%01000100
        .byte #%01000100      
        .byte #%01111000
        .byte #%00000000
        .byte #%01000100
        .byte #%01000100
        .byte #%01000100
        .byte #%01111000
        .byte #%00000000
        .byte #%01000100
        .byte #%01111100
        .byte #%01000100      
        .byte #%00111000
        .byte #%00000000
        .byte #%00111100
        .byte #%01000000
        .byte #%01000000
        .byte #%00111100
        .byte #%00000000
        .byte #%10111101
        .byte #%01111110
        .byte #%01111110      
        .byte #%10111101        
        .byte #%00000000

        
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; Epilogue
	org $fffc
        .word Start	; reset vector
        .word Start	; BRK vector



#2 stephena OFFLINE  

stephena

    River Patroller

  • 3,294 posts
  • Stella maintainer
  • Location:Newfoundland, Canada

Posted Mon Oct 23, 2017 7:41 PM

Stella 5 is correctly emulating the behaviour I see on my light-sixer with a Harmony cart.  Stella 4 is obsolete and has incorrect TIA emulation that has been fixed in version 5.  So it looks like 8bitworkshop is wrong here.

 

6502.ts correctly emulates this too (not surprising, since its TIA core was ported to Stella).  MAME, Javatari and z26 are all incorrect (in slightly different ways).

 

I suggest you test your code in Stella/6502.ts.  And also, it might be better in the future to post a binary; I had to look around for a while to find the xmacro.h file.

 

EDIT: To clarify, Stella 4 and MAME give the same (incorrect) output.  z26 seems to be doing something completely different.  And Javatari is acting like 8bitworkshop (also incorrect).



#3 Kiwi ONLINE  

Kiwi

    Stargunner

  • Topic Starter
  • 1,591 posts

Posted Tue Oct 24, 2017 6:36 AM

The site allow for the ROM to be downloaded, so I can use Stella 5 to view the result if 8bitworkshop is incorrect.  So I was able to make a game Logo screen.

KiwiAtari.png

Yay for my first 2 HMOVE bars.

Questions:
I am using SetHorizPos subroutine to set the sprite's location. It seems to offset every 8 or 10 colorclock pixels. How do you get higher precision?  For example, below the Kiwi, the sprites suppose to move 4 pixels away from each other.  I used NUSIZ x2 to double size the sprites to get around the limitation, but I prefer the x1 version. 

Source:Attached File  KiwiLogo.asm   5.11KB   31 downloads


Edited by Kiwi, Tue Oct 24, 2017 6:38 AM.


#4 stephena OFFLINE  

stephena

    River Patroller

  • 3,294 posts
  • Stella maintainer
  • Location:Newfoundland, Canada

Posted Tue Oct 24, 2017 7:01 AM

I will have to leave the specifics of your code to someone with more knowledge in that area.  I can only confirm or deny that a binary works in different emulators and/or real hardware.



#5 Kiwi ONLINE  

Kiwi

    Stargunner

  • Topic Starter
  • 1,591 posts

Posted Wed Oct 25, 2017 3:36 AM

Just an update:

I got it now. 

Kiwi.a (5)_1.png

Have to waste cycles until you hit RESPx to get your desire position.  Before/after(?) that you set your HMPx for fine position, then HMOVE apply the HMPx to the sprite.

The result match both emulator.  The HMOVE bar is a bit taller on 8bitworkshop, but that's ok. 

Sorry, I was a bit too excited. I'm off to learn and experiment more. Now logo screen's done. Then title screen, and a game.



#6 TheHoboInYourRoom OFFLINE  

TheHoboInYourRoom

    Moonsweeper

  • 405 posts
  • Whackadoo thingamajig
  • Location:Illinois

Posted Wed Oct 25, 2017 4:15 PM

Before/after(?) that you set your HMPx for fine position,

Either way works as long as you have CPU time available for it.



#7 Kiwi ONLINE  

Kiwi

    Stargunner

  • Topic Starter
  • 1,591 posts

Posted Thu Oct 26, 2017 6:11 AM

Either way works as long as you have CPU time available for it.

I just realized that the if the VBLANK is on, then it's not drawing anything.  Which strobing RSYNC, HMP0, and HMOVE does nothing.  Gotta position sprite at line 38, after the underscan period.



#8 TheHoboInYourRoom OFFLINE  

TheHoboInYourRoom

    Moonsweeper

  • 405 posts
  • Whackadoo thingamajig
  • Location:Illinois

Posted Thu Oct 26, 2017 10:02 AM

Not at all, you can absolutely use HMOVE in vertical blank. Combat does it, for instance: if you run Combat in Stella and open the debugger, type "trapwrite HMOVE" into the command prompt; exit the debugger and it will reappear after HMOVE has been written to, at line 21 while the screen is still blank.



#9 alex_79 OFFLINE  

alex_79

    Stargunner

  • 1,171 posts
  • Location:Italy

Posted Thu Oct 26, 2017 2:19 PM

Yup, there's no issue in positioning the sprites during vertical blank.

 

There are timing constraints for HMOVE, though.

 

The effect of strobing HMOVE is not immediate; instead, a series of "motion pulses" are generated (one every 4 TIA clocks) and each of them moves the sprite by one pixel. Not only that, but those motion pulses only cause motion if they occurr during the horizontal blank (the first 68 TIA clocks on each scanline, which correspond to the first 22,66 CPU cycles).

 

This means that HMOVE must be strobed early during the horizontal blank (typically right after a "sta WSYNC"), and that the HMxx registers must not be modifyed (by writing another value or by clearing them with HMCLR) before HMOVE finishes its operastions (The official "Stella Programmer's Guide" recommends to wait at least 24 CPU cycles)

Strobing HMOVE will move ALL the objects by the amount stored in their respective HMxx registers. If you're positioning more than one sprite, you can issue HMOVE just once after you did all the coarse positioning (with RESxx) and set the HMxx registers for all the sprites.

 

 

[...] strobing RSYNC, HMP0, and HMOVE [...]

I guess you meant RESP0? Strobing RSYNC is of no practical use (and will instead mess up the video signal by resetting the counters and starting a new scanline before the previous one was completed). Don't do that!
 


Edited by alex_79, Thu Oct 26, 2017 2:22 PM.


#10 Kiwi ONLINE  

Kiwi

    Stargunner

  • Topic Starter
  • 1,591 posts

Posted Fri Oct 27, 2017 3:04 AM

I really appreciate the HMOVE information.  The object position is now working.  :D  I was having trouble using SetHorizPos subroutine.


I guess you meant RESP0? Strobing RSYNC is of no practical use (and will instead mess up the video signal by resetting the counters and starting a new scanline before the previous one was completed). Don't do that!
 

Yes, I did mean RESP0.

I got the bouncy rainbow picture working on both 8bitworkshop and Stella.  Now off to work on game logic.
 


Edited by Kiwi, Fri Oct 27, 2017 3:04 AM.





0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users