Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

14 Good

About Mikes360

  • Rank
    Chopper Commander
  • Birthday 05/01/1987

Profile Information

  • Gender
  • Location
    Mansfield, United Kingdom
  1. This is a very nice idea, I like anything like this that can be used as a level of abstraction from counting bytes to ensure things are lined up properly. If one where to use these overlays would you define each overlay as you need it or define them all in one block?
  2. Hi ZackAttack, Thanks for your recommendation that now works ok now. Nice 3 sprite demo by the way!
  3. Hi ZackAttack, That is a valid point I was aware of this. In my case I always want to jump back to the first bank so its not been a problem I should just replace the return logic with a ldx #0 for my needs. However the problem I am describing is different and its all to do with how the program counter is being incremented by two of three bytes depending on the contents of the address after brk Here is the failed brk in stella (notice the program counter is being incremented by three which is causing it to go wrong) PC = F0A6 PC = F0A9 And here is the successful brk (program counter being incremented by two PC = F0A6 PC = F0A8 So am I modifying the return address in my hotspot code incorrectly?
  4. Hi Guys, I have written a bank switching scheme similar to many others around that use brk followed by the address of a routine. Here is the macro I created MAC BSR // takes routine address as argument BSR_ORIGIN_BANK SET CURRENT_BANK ldx #BANK_{1} brk .word {1} ENDM To make this work you need to make the interrupt vector point to a hotspot bankswitch routine and this is my version. MAC BANK_HOTSPOT ORG BANK_ORIGIN + $FD3 RORG $FFD3 Hotspot dec $FE ldy #1 lda ($FE),y pha dey lda ($FE),y pha dec $FB sta hotspot,x rts ReturnSpot sta hotspot,x rti BYTE_COUNT Hotspot, "Hotspot" ENDM For completeness here is the macro for retuning from a bankswitch routine MAC RBS ldx #BSR_ORIGIN_BANK jmp ReturnSpot ENDM I have found that when using this my code is very sensitive to the address of the routine after the brk instruction for example a brk .word{$F0F4} works fine and brk .word{$F0EF} does not. The difference is the lower byte $EF gets resolved to the following 3 byte illegal opcode: EF *ISC abs 6 $EF: bytes: 3 cycles: 6 A___P=>A___P RW abs and $F4 gets resolved to a two byte illegal opcode: F4 *NOP zpx 4 $F4: bytes: 2 cycles: 4 _____=>_____ R_ zpx Now from looking at stella in the case where it works then I return to the origin bank the program counter gets incremented by two so the next inscription after the brk .word{$F0F4} is executed correctly and everything is fine. However in the case where it is not working brk .word{$F0EF} the program counter is getting incremented by three so subsequent instructions are not executed correctly. Can someone look at my macros and see what I might be doing wrong to cause this behaviour? I hope I have given enough detail to describe the issue I am getting. Thanks, Mike
  5. Reading around this thread it seems you are using a ball sprite to smooth out the pf scrolling? Seems neat.
  6. I assume the floating blocks are drawn with the play field. It looks like they are scrolling with single pixel accuracy is that the case? Very nice btw.
  7. Ok thanks in my case I will just force the kernel to cross a page boundary to get the 4 cycles. I thought it would be worth asking however.
  8. Hi Guys, I have a situation where forcing a 4 cycle branch without actually crossing a page boundary would really help me out with my main drawing kernel. I know you can do a sta.w to force that extra cycle is there an equivalent for the branch opcodes? Thanks, Mike
  9. I wonder if its my scrolling logic being slightly incorrect, ill take a look tonight.
  10. Hi Guys, I am having issues with a scrolling reflected playfield. I cannot get the timing quite right for the second PF2 update. I have tried to follow the timings covered in the below topic: http://atariage.com/forums/topic/149228-a-simple-display-timing-diagram/?hl=%2Bmirrored+%2Bplayfield+%2Btiming&do=findComment&comment=1820187 To be honest I couldn't quite conclude if I needed the second PF2 update to complete at the start of cycle 48 or the end (i.e. cycle 49) either way its not quite right I have attached a binary showing the jump I get on this boundary. If anyone has any recommendations I would be very grateful. Demo.bin
  11. I have tested it out on my 2600 and it works great, I am not using CRT though my TV is LED. One thing I have noticed is that the playfield and rail look a bit strange on the right hand side: But it looks fine on the left:
  12. I decided to go ahead and give VBLANK a go as I have only just discovered this concept. I have managed to incorporate it into my existing kernel with a bit of rejigging to get the timings correct. For my needs I had to enable VBLANK at cycle 25 and disable it again at cycle 67 this hides my rails on both the left and right hand side of the screen when they wrap. I will be trying this out on real hardware just to see if stella emulates this properly. I know if your TV brightness is set incorrectly you can see the VBLANK regions are a different colour. Here is a demo binary if anyones interested. The rail and playfield are not in synch but it dosent matter for the purpose of the demo. Demo.bin And here is the drawing kernel code. ;=========================== .drawLoop sta HMOVE ; 3 - *first scanline lda pfBuffer,x ; 4 sta PF1 ; 3 lda pfBuffer+1,x ; 4 sta PF2 ; 3 - 14 Sleep 6 lda #0 sta VBLANK ; cycle 25 dey ; 2 lda (playerGfxPtr),y ;5 and (playerMaskPtr),y ;5 sta GRP0 ;3 - 13 lda pfBuffer+2,x ; 4 sta PF2 ; 3 - 14 lda pfBuffer+3,x ; 4 sta PF1 ; 3 Sleep 5 lda (railDataPtr),y ; 5 sta VBLANK ; cycle 67 and (railMaskPtr),y ; 5 sta ENAM1 ; 3 sta HMM1 ; 3 rol ; 2 sta ENAM0 ; 3 rol ; 2 and #%00110000 ; 2 sta NUSIZ1 ; 3 - 28 Sleep 3 lda #0 sta PF1 sta VBLANK ; cycle 25 sta PF2 ; 3 - 8 dey ; 2 beq Endframe ; 2 lda (playerGfxPtr),y ;5 and (playerMaskPtr),y ;5 sta GRP0 ;3 - 13 ldx XTable,y ; 4 Sleep 13 lda #%00000010 sta VBLANK ; cycle 67 Sleep 3 jmp .drawLoop ; 3 - 13
  13. Thanks Omega. One of my first thoughts was just to shift the mask so it only draws as many rows as need displaying.However that alone would not work for the top portion of the rail where the vertical and kinked portion of the rail are drawn together. For that I need a form of blanking or a custom kernel like the ones you mentioned.
  14. It doesn't look too bad but when you use cycle 74 HMOVE's you can only shift objects left.... So I would need to reverse the scrolling of that game that might be a bit of a bummer!
  15. Yes I am looking into making it a solid colour instead it docent look quite as nice and I will need to do a cycle 73/74 HMOVE to hide the lines if I use that too.
  • Create New...