Kiwi Posted October 23, 2017 Share Posted October 23, 2017 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 RESM1sta RESP0After CLEANSTART to get them to 0.In 8bitworkshop, I got the desire result.In Stella 4 and 5, they are at the wrong position. Just curious why that is. 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 Quote Link to comment Share on other sites More sharing options...
+stephena Posted October 24, 2017 Share Posted October 24, 2017 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). Quote Link to comment Share on other sites More sharing options...
Kiwi Posted October 24, 2017 Author Share Posted October 24, 2017 (edited) 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.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:KiwiLogo.asm Edited October 24, 2017 by Kiwi Quote Link to comment Share on other sites More sharing options...
+stephena Posted October 24, 2017 Share Posted October 24, 2017 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. Quote Link to comment Share on other sites More sharing options...
Kiwi Posted October 25, 2017 Author Share Posted October 25, 2017 Just an update:I got it now. 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. Quote Link to comment Share on other sites More sharing options...
TheHoboInYourRoom Posted October 25, 2017 Share Posted October 25, 2017 Before/after(?) that you set your HMPx for fine position, Either way works as long as you have CPU time available for it. Quote Link to comment Share on other sites More sharing options...
Kiwi Posted October 26, 2017 Author Share Posted October 26, 2017 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. Quote Link to comment Share on other sites More sharing options...
TheHoboInYourRoom Posted October 26, 2017 Share Posted October 26, 2017 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. 1 Quote Link to comment Share on other sites More sharing options...
alex_79 Posted October 26, 2017 Share Posted October 26, 2017 (edited) 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 October 26, 2017 by alex_79 1 Quote Link to comment Share on other sites More sharing options...
Kiwi Posted October 27, 2017 Author Share Posted October 27, 2017 (edited) I really appreciate the HMOVE information. The object position is now working. 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 October 27, 2017 by Kiwi Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.