johnnystarr

The code was actually my own, however I updated it to SpiceWare's specifications earlier in this thread. That and I copied the dragon sprites from the Dragonfire source. I think that I understand the 32p example a lot more now. I spent the rest of the afternoon going over SpiceWare's sourcecode for Medieval Mayhem. I was actually able to modify my 32 pixel code and I've ALMOST got the 48 pixel code to work. What I mean by almost is that I got it to work, all but the first graphic has a small "tear" at the bottom. Here's what I would like to know. I totally grasp the VDELPx method, and the pipeling makes sense. I understand the delay in the 32 pixel example because you are basically synchronizing the writes between GRP0 and GRP1. But, all the 48p examples I've seen everywhere all seem to have just about the same timing. I imagine that using indirect Y for each write has something to do with the time formula. Maybe you could take a look at the .bin and .asm for me and help me determine what needs to be changed. I've done my best to line up the sprite pairs and they seem to be lined up perfectly. I have attempted to modify the delay right before RESPx. If I reduce the "SLEEP" count just a bit, the tear goes away, but the sprites aren't in order. I feel like I'm 99% there, and have really enjoyed learning this stuff. sprite48p.bin sprite48p.asm

I've been digging through the archives on this site, and I can only find topics related to 48 pixel sprites and not so much 32. Is this one of those tricks that has a technical / mathematical equation? Or is it simply a hack that you have to fine-tune until it works and there isn't an exact formula? I've gotten it to work for me pretty well, but until I know why it's going to bug me! Updated the .bin to that mean old dragon. Haven't begun to figure out the "red eye" trick though. I'm assuming it involves changing the COLUBK register on certain clocks. sprite32p.bin

Thanks a lot SeaGTGruff. That's a good practice and makes more sense than what I had going on. I think everyone has done a great job explaining how horizontal placement and 32 \ 48 pixel sprites can be accomplished. And based on that, I'm sure I could get something to work if I tried enough combinations (like my sprite32p.bin example above) But, I would really like to understand why it works. I've attempted to used SeaGTGruff's notation here to see if someone can explain the SLEEP portion, and why we are wasting cycles there to begin with: Kernel: LDA (SP2),Y ; +5 ; 5 STA GRP1 ; +3 ; 8 LDA (SP1),Y ; +5 ; 13 STA GRP0 ; +3 ; 16 LDA (SP3),Y ; +5 ; 21 TAX ; +2 ; 23 LDA (SP4),Y ; +5 ; 28 SLEEP 12 ; +12 ; 40 ; 120; 52; 57 <-- ??? STX GRP0 ; +3 ; 43 STA GRP1 ; +3 ; 47 DEY STA WSYNC BNE Kernel So, the wasted SLEEP cycles between the write to SP4 and the write to GRP0 eludes me. It is 12 cyles, which puts our line MC count to 40, which puts our CC count to 120. If we subtract 68, this means that the color clock gap comes to 52. Since we're not writing to RESPx, I didn't know if 52 + 5 should be notated, thus the question marks. Ultimately, the goals seems to be to write to GRP0 at the exact moment that the beam reaches the first instance of GRP1. This would update the serial data right before the beam starts drawing the second copy of GRP0. I've ran the Stella debugger, and watched the CC counter right when GRP0 is written to. It is at CC 129 when we write GRP0. If we subtract 68, this equals 61. Now, if we do add +5 to the delay above which is 52, that would equal 57. Does this work because 61 and 57 are "close enough"? ALSO: I find it odd that the 48 pixel examples I've seen don't waste cycles between writes to GRPx. Is this because the horizontal positions aren't a factor because you are using VDELPx ?

That is very useful. I've tried to compare notes from the details in this thread with the details in http://atariage.com/forums/topic/222918-horizontal-placement-multiple-sprites/ I've taken a stab at calculating the timing, but I must be missing a thing or two. Here's what I've come up with so far. Where you see "CC +n" is just the notation I came up with on the fly to assess how far to the right the NOPs in the "Layout" section move the players. I fine position HMP1 to get it to line up as well, but didn't add those clocks as I wasn't sure if that is part of the equation. I also didn't add the clocks for the indirect Y loads as I didn't know if that was a factor. Is there a simple equation when using this technique? Like +n color clocks, +n HMPx = 32 pixel sprites? Layout NOP ; 2 | 2 NOP ; 2 | 4 NOP ; 2 | 6 NOP ; 2 | 8 NOP ; 2 | 10 NOP ; 2 | 12 NOP ; 2 | 14 NOP ; 2 | 16 NOP ; 2 | 18 NOP ; 2 | 20 NOP ; 2 | 22 - HBLANK stops here NOP ; 2 | 24 | CC +6 NOP ; 2 | 26 | CC +12 NOP ; 2 | 28 | CC +18 NOP ; 2 | 30 | CC +24 NOP ; 2 | 32 | CC +30 NOP ; 2 | 34 | CC +36 NOP ; 2 | 36 | CC +42 STA RESP0 ; 3 | 39| CC +51 after written STA RESP1 ; 3 | 42| CC +60 after written STA WSYNC LDA #%00010000 STA HMP1 STA HMOVE ; --- kernel 1 --- LDY #13 Kernel LDA (SP2),Y STA GRP1 LDA (SP1),Y STA GRP0 LDA (SP3),Y TAX LDA (SP4),Y NOP ; 2 | 2 | CC +6 NOP ; 2 | 4 | CC +12 NOP ; 2 | 6 | CC +18 NOP ; 2 | 8 | CC +24 NOP ; 2 | 10| CC +30 NOP ; 2 | 12| CC +36 STX GRP0 ; 3 | 15| CC +44 after written STA GRP1 ; 3 | 18| CC +53 after written DEY STA WSYNC BNE Kernel ; --- end ---

Crazy timing. I actually just got it to work, although I'm not 100% sure how I've attached the source + bin. I'm still a bit unclear on the cycles, and how they match up in this case. All suggestions welcomed here. Thanks, sprite32p.asm sprite32p.bin

So, this is very odd. I've managed to get this to work, however I don't know how it works exactly. As you can see I have 4 unique sprites going on. I have set the NUSIZx to #%00000010 to allow 2 close copies. I've attached screenshots as well as source code. I originally tried positioning using HMPx and HMOVE, however it would reposition both sets of sprites. From what I gather from SpiceWare's source example, we are trying to change the GRPx registers at exactly the right moment when we start drawing the second copy. Somehow my wasted cycles match up at '34' and '42'? ;------------------------------------------------------------- ; 3 part Kernel ;------------------------------------------------------------- LDX #90 Top DEX STA WSYNC BNE Top Layout NOP ; 2 | 2 NOP ; 2 | 4 NOP ; 2 | 6 NOP ; 2 | 8 NOP ; 2 | 10 NOP ; 2 | 12 NOP ; 2 | 14 NOP ; 2 | 16 NOP ; 2 | 18 NOP ; 2 | 20 NOP ; 2 | 22 NOP ; 2 | 24 NOP ; 2 | 26 NOP ; 2 | 28 NOP ; 2 | 30 NOP ; 2 | 32 NOP ; 2 | 34 STA RESP0 STA RESP1 STA WSYNC ; --- kernel --- LDY #13 Kernel LDA SPRITE1,Y ; 4 | 4 STA GRP0 ; 3 | 7 LDA SPRITE2,Y ; 4 | 11 STA GRP1 ; 3 | 14 LDA SPRITE3,Y ; 4 | 18 TAX ; 2 | 20 LDA SPRITE4,Y ; 4 | 24 NOP ; 2 | 26 NOP ; 2 | 28 NOP ; 2 | 30 NOP ; 2 | 32 NOP ; 2 | 34 NOP ; 2 | 36 NOP ; 2 | 38 NOP ; 2 | 40 NOP ; 2 | 42 STX GRP0 STA GRP1 DEY STA WSYNC BNE Kernel ; --- end --- ; quickly turn off the player LDA #0 STA GRP0 STA WSYNC ; kill 1 line STA WSYNC ; kill 2nd LDX #86 Bottom DEX STA WSYNC BNE Bottom

I see where you're coming from, but I've sort of learned things out of order. I'm a newbie to the TIA but not 6502 assembly, and that is probably the most frustrating part! I'm working on a sprite demo right now and I have been playing with repositioning all morning and have had success doing exactly what you and others have described here. Next I'm going to try a 32 pixel mockup based on my current understanding. If I'm offbase, perhaps at that point you could review my source

Thanks, the source is well commented as well. One last clarification on the 32-pixel vs. 48-pixel sprites. Are they the same technique in general? The screenshot here is of the 32p dragon. Is the trick to load NUSIZ0 and NUSIZ1 with #1 so that it enables "two sprites (close)". Then, we use RESPx, HMx and HMOVE to get the lined up just right, and finally we use Spice's example code: Sorry for any redundancy, but this stuff is so arcane, it's like learning how to ride a unicycle blindfolded.

Interesting. Am I to understand that this code would be in place of the HMPx and HMOVE calls? From what I gather about the loop going on here, is that Y would set the height of our 4 graphics tables right? If Y = 16 and our sprite tables are each 16 bytes in length, than this kernel would draw 16 scanlines of parallel players. Is it that these instructions add up to 76 cycles? Or, would I strobe WSYNC just after DEY to make up the difference? For the time being, I can see myself using the 32p trick for various "bosses" and 1K score kernels. I would also love to memorize and fully comprehend 48p sprites, but I think 32 is a good place to start. Would you or anyone else be able to show a full kernel using the 32p trick? Thanks again!

Ok, that's pretty cool. I've been going over your source in the Show48graphic sub. I think this would be very handy down the line. I'm curious, is this trick used every time you need to lineup P0 and P1? What if I only needed 32p vs. 48p (4 consecutive sprites)? Would I modify the code, or is this to get the extra 16 pixels? Very cool app from Mr. Crane BTW!

Spice, I can't thank you enough for all the pointers. This stuff is going to help with quite a few gaps in my understanding of the TIA. While we're on the subject of RESPx, perhaps someone could clarify this image for me. After learning how to use the 'debug colors' I've been able to review how designers utilized GRP0 and GRP1 in tandem. (I know this has been mentioned in some of my other posts, so bear with me) Take for instance the score uses GRP0 and GRP1 every other digit. According to my recent understanding, this must be one of two things: A) - This is an example of using RESP0 and RESP1 at just the right moment to achieve multiple sprites per line B) - Or, this is using NUSIZ0 and NUSIZ1 to duplicate the sprites If this is an example of "A": Is this an example of using RESPx, HMPx, and HMOVE? If this is an example of "B": How does one go about changing the GRPx register between copies? I'm not even sure if "B" is possible. Everyone has provided great resources and details, so I really appreciate it. Perhaps a small code sample would bridge the gap for me. I would really like to review the portion of a kernel that draws GRP0, strobes RESP0 and then draws different sprite serial data on the same line. Thanks again!

Spice, thanks again for the cool tips. I was looking again at Dragon Fire just now, and I wanted to clarify something about HBLANK. On this screen there are 3 HBLANK lines. I'm guessing the top two are repositioning P0 for the man and the gargoyles on the right? And the bottom one is for the Score?

Spice, in your presentation, you highlight the different sections of games and the graphics used (IE P0, P1, M0, M1, BL, PF, BK) Is there a way to do this in the Stella emulator, or are these values inferred based on your studies?

Wow, thank you for the copious amount of details on that subject. I will probably have to revisit this as a reference until I dedicate this stuff to memory. Great resource as well.

That's an interesting point. I would like to know as well. I guess it depends if the cart validation is software or hardware driven. Doesn't the 7800 have a BIOS?

I think that I'm having a hard time understanding RESP0 / RESP1. From what I understand, it's used to position a sprite at a certain color clock, but is it used for anything else?

Awesome, I live in Denton and that's only about 30 minutes away!

I'm starting to grasp how the TIA works on a more complex level. I understand that updating the registers on different lines can allow for multiple instances of GRP0 and GRP1. I've attached a screenshot of Dragonfire as a good example of this technique. Now, how exactly do you "place" these objects in certain positions horizontally? Is this a matter of using HMOVE during the drawing of the frame? Obviously I need a solution that is very brief in cycles. I want enough time to have multi-colored sprites just like this example. I've read over the Dragonfire source code, but it's a bit dense to find the portion that I am referring to.

Thank you all for the nice comments. I am a bit torn on how far I want to take this. Part of me wants to host a site that allows full collaboration both private / public. Yet, the minimalistic part of me wants to keep it simple and local and put it up on GitHub for developers to take and customize.

@Random Terrain: No, I hadn't seen that before. Very cool indeed. I am interested in the sound editor on that link as well. Can't get myself to use BBASIC though. 6502 Assembly has been a general hobby of mine for the last few years on several systems.

BTW, I fully plan to be able to output to multiple formats. I will be adding an animation portion and the ability to collaborate on different sprites.

Here's a clip of my most recent project. I wanted a sprite editor that was specifically for the VCS, handling 8-bit lines and TIA colors. My wife is designing all the art so I figured I would give her something web based. After a few days I've come up with this and I'm starting to wonder if this is worth making public. Your feedback is appreciated. http://youtu.be/pyDsh78tym8?hd=1

Looks pretty good man. I noticed if you scroll the character across the screen horizontally the color mode goes to black and white. If this is unintentional, you might have some self-modifying code somewhere? I like what you did the the playfields. Looks like you are on the right track.

@TMR & carlsson Very cool guys! I wasn't around in those days. My first language was QBASIC in 1996. I think it's really cool that Tanrunomad and others are picking up 6502 assembly. After years of C and C++ I find it relaxing. I can see why they used two machines for "rapid" development, but I'm in no rush. This might be a dumb opinion, but I think that machine language is sort of "zen like" in nature. So many people these days are in such a hurry that they don't like to take the time to really learn something well.

@TMR Sure. Pretty much every 6502 based system has a cross compiler solution. I'm not discouraging the OP from using one either. I just think that it's super cool to write assembly within a 6502 based environment. What do you mean by "second instance of the same machine, a different 8-bit entirely"? As far as I remember, the Motorola 68000 (both used for the Amiga and Atari ST) is a 16 bit CPU. And DOS can run in 16-bit Real Mode as well as 32 bit protected mode. Not trolling here I promise I'm just trying to figure out what you mean exactly.