Jump to content

DigitalAnthony

New Members
  • Content Count

    7
  • Joined

  • Last visited

Community Reputation

0 Neutral

About DigitalAnthony

  • Rank
    Combat Commando

Profile Information

  • Location
    Silicon Valley

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Your explanation helped tremendously! Thank you for taking the time and effort to respond back to my messages. This stuff is very interesting/complex and every bit of information helps build my understanding and chip away at the mysteries. Much appreciated!
  2. DirtyHairy, thank you for the response! You showed me that the table confusion boiled down to a frame of reference problem that took me a while to wrap my head around. I'm still a bit confused on the point you bring up regarding the technical details surrounding HMOVE. You say to regard the sprites as counters from 0 to 159 that receive a pulse during every visible color clock. Are these pulses only sent during the parts of the screen when the sprites are visible, or do they receive 159 pulses regardless of visibility? You say visible color clock, so I assume the former. I'm guessing the tia needs to know how many pulses to send during the HBLANK, before HMOVE is strobed? To confirm my understanding, the 8 extra color clocks added to HBLANK provide a buffer that allows the positioning of the sprites to be fine tuned since it could "draw" from the 8 tia clocks provided and return to "zero" position. But it could also consume more than the added tia clocks during this period if you wanted to move the sprite positive pixels to the left, and these are the extra pulses that need to be accounted for and the reason why HMOVE is strobed at the beginning of HBLANK? So in theory, say you only used the player 0 sprite, and wanted either a no shift, or negative shifts to the left (right movement). Then could HMOVE not be strobed until tia color clock 68, since it would only pull from the now extended 8 clock HBLANK buffer of 76? Or are there other technical reasons besides accounting for the extra pulses that enforce the strict timing requirement?
  3. Following the link you posted to the discussion earlier, I experimented with your resptest.asm file. Originally in the file, you had: sta WSYNC SLEEP 20 sta RESP0 This positioned P0 at position #6, which makes sense and coincides with the explanation you provided in the comments. However, when I changed 20 to 19, as it has been done in the attached file, and loaded up the debugger and selected the TIA tab, it states that the position of P0 is #3. It would seem somehow the delay is starting 2 cycles deep into the blank section. The file I attached is titled playfield.asm but it is the same as your file except for that one change I mentioned. This is a real stumper... 🤔 playfield.asm
  4. Thanks for the detailed explanation Jeff! I finally got a chance to read through the discussion you linked and it definitely covers some very "to the metal" concepts involving digital design that I would love to one day gain a deep understanding of. One thing that still confuses me, however, is that you say there is a five-cycle delay when drawing player objects caused not by the RESP0 instruction, but rather within the TIA itself. This leads me to believe that the closest to the extreme left you would be able to start a player pixel (without HMxx) would be at pixel position 5 (color clock 73). But in practice, I'm finding that the earliest position is actually pixel position 3 (color clock 70). This coincides with my understanding of the programming techniques, but contradicts my understanding I came to after reading the technical details of the hardware you explained. Am I missing something here?
  5. Thank you very much for the help. I realized now that I accidentally typed "68 lines". What I meant by that was the number of TIA Clock Counts you have in the horizontal blank area (-68 pixel position). I've attached the zipped binary file to this response. When I run it on Stella, the debugger shows that the "sta RESP0" instruction happens on machine cycle 20 (color clock 60/pixel position -8). This seems weird to me that the code would strobe the RESP0 register when the TIA is still in the horizontal blank. Does this cause player0 to be positioned 6 pixels into the display, and then that explains why the HMP0 is set to $60 to offset this and start the pixel at the far left? https://atariage.com/forums/topic/208473-resp0-while-pixel-position-is-negativelow/ timing2.a.rom.zip
  6. *Accidentally didn't post this in the right sub-forum. Hello, Atari VCS programmers. I am confused with regards to the exercise for Chapter 9 on 8bitworkshop.com. I've been following along with the companion book, "Making Games for the Atari 2600" and I'm finding discrepancies between the Javatari and Stella debugger. Using both debuggers, I set a breakpoint at the blue highlighted line (included at end of post). When I step past the first sta WSYNC instruction, the Javatari debugger shows 62 lines of the horizontal blank remaining, while Stella shows 68. The Stella one made sense to me since my understanding is that the instruction pauses the 6507's execution until the start of the next scanline, and then you have a fresh 68 color clocks of horizontal blank to work with. Is this incorrect? Are the 3 cycles required for the instruction consumed on the previous scanline or the next scanline? Both emulators display the same image, however, when the programs are executed. Also, when using the HMxx register, I have noticed some sources show a table like so: while other sources (Stella programmer's guide) say it goes from -8 to +7 and the values are reversed. Which one is it? Using the table shown above and assuming there are only 62 lines left in the horizontal blank, the sprite position makes sense for the Javatari program, but the 62 doesn't make sense. I appreciate any help you guys can provide to clear this confusion. ; Instead of representing the horizontal position in CPU clocks, ; we're going to use TIA clocks. lda counter ; load the counter as horizontal position and #$7f ; force range to (0-127) ; We're going to divide the horizontal position by 15. ; The easy way on the 6502 is to subtract in a loop. ; Note that this also conveniently adds 5 CPU cycles ; (15 TIA clocks) per iteration. sta WSYNC ; 35th line sta HMCLR ; reset the old horizontal position DivideLoop sbc #15 ; subtract 15 bcs DivideLoop ; branch until negative ; A now contains (the remainder - 15). ; We'll convert that into a fine adjustment, which has ; the range -8 to +7. eor #7 asl ; HMOVE only uses the top 4 bits, so shift by 4 asl asl asl ; The fine offset goes into HMP0 sta HMP0 ; Now let's fix the coarse position of the player, which as you ; remember is solely based on timing. If you rearrange any of the ; previous instructions, position 0 won't be exactly on the left side. sta RESP0 ; Finally we'll do a WSYNC followed by HMOVE to apply the fine offset. sta WSYNC ; 36th line sta HMOVE ; apply offset
  7. Hello, Atari VCS programmers. Not sure if this is the right place, but I am confused with regards to the exercise for Chapter 9 on 8bitworkshop.com. I've been following along with the companion book, "Making Games for the Atari 2600" and I'm finding discrepancies between the Javatari and Stella debugger. Using both debuggers, I set a breakpoint at the blue highlighted line (included at end of post). When I step past the first sta WSYNC instruction, the Javatari debugger shows 62 lines of the horizontal blank remaining, while Stella shows 68. The Stella one made sense to me since my understanding is that the instruction pauses the 6507's execution until the start of the next scanline, and then you have a fresh 68 color clocks of horizontal blank to work with. Is this incorrect? Are the 3 cycles required for the instruction consumed on the previous scanline or the next scanline? Both emulators display the same image, however, when the programs are executed. Also, when using the HMxx register, I have noticed some sources show a table like so: while other sources (Stella programmer's guide) say it goes from -8 to +7 and the values are reversed. Which one is it? Using the table shown above and assuming there are only 62 lines left in the horizontal blank, the sprite position makes sense for the Javatari program, but the 62 doesn't make sense. I appreciate any help you guys can provide to clear this confusion. ; Instead of representing the horizontal position in CPU clocks, ; we're going to use TIA clocks. lda counter ; load the counter as horizontal position and #$7f ; force range to (0-127) ; We're going to divide the horizontal position by 15. ; The easy way on the 6502 is to subtract in a loop. ; Note that this also conveniently adds 5 CPU cycles ; (15 TIA clocks) per iteration. sta WSYNC ; 35th line sta HMCLR ; reset the old horizontal position DivideLoop sbc #15 ; subtract 15 bcs DivideLoop ; branch until negative ; A now contains (the remainder - 15). ; We'll convert that into a fine adjustment, which has ; the range -8 to +7. eor #7 asl ; HMOVE only uses the top 4 bits, so shift by 4 asl asl asl ; The fine offset goes into HMP0 sta HMP0 ; Now let's fix the coarse position of the player, which as you ; remember is solely based on timing. If you rearrange any of the ; previous instructions, position 0 won't be exactly on the left side. sta RESP0 ; Finally we'll do a WSYNC followed by HMOVE to apply the fine offset. sta WSYNC ; 36th line sta HMOVE ; apply offset
×
×
  • Create New...