From sa666666 at gmail.com Sat Aug 1 16:38:39 2009 From: sa666666 at gmail.com (Stephen Anthony) Date: Sat, 1 Aug 2009 19:08:39 -0230 Subject: [stella] Explanation of the following NUSIZx code Message-ID: <200908011908.39759.sa666666@gmail.com> Would someone be able to trace the following few lines of code and describe what's going on (and what should be going) wrt writing to NUSIZ0? This is for improvements to Stella. For clarity, I'll step through three lines of code with 3 snapshots from the Stella debugger: 1) A '1' has just been stored in the X register (see debug1.png). 2) The '1' from the X register is stored in NUSIZ0. Two CPU cycles have passed, and more of the graphic is drawn (see debug2.png). 3) The DEX instruction has executed in another CPU cycle. But the problem is, more of the graphic has been drawn, which isn't happening on a real console (see debug3.png). There seems to be an issue of when NUSIZx is written and when its contents are applied to the screen. Note that when I force the copy to '0' before stepping to DEX, the graphical garbage disappears. Obviously I'm misunderstanding what's going on here. Could someone explain what should be happening?? Thanks, Steve -------------- next part -------------- A non-text attachment was scrubbed... Name: debug1.png Type: image/png Size: 32266 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: debug2.png Type: image/png Size: 29006 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: debug3.png Type: image/png Size: 28857 bytes Desc: not available URL: From rob-stellalist at kudla.org Sat Aug 1 18:46:56 2009 From: rob-stellalist at kudla.org (Rob) Date: Sat, 1 Aug 2009 19:46:56 -0400 Subject: [stella] Whence the Dig? Message-ID: <200908011946.57384.rob-stellalist@kudla.org> On Tuesday 28 July 2009 09:03 pm, Ruffin Bailey wrote to Glenn: > Yeah, but the AA forums have too much noise for an old man like me to > keep up with, and it's not like programming on Mac OS 8 & 9 are bringing > in thousands of hits either. ;^) Yeah, I don't have time for programming forums that don't come to me, myself. The pro-forum people always said, "Nothing's stopping you from staying on the mailing list and letting the people who don't understand email use forums". But as I expected based on my Maxim experience, there are more browser-wielding functional illiterates interested in Atari than there are people who are capable of writing an email, so it was only a matter of time before the critical mass shifted. And in another few years or decades, when Albert gets tired of running AtariAge, they'll all be on some other forum going, "Did anyone ever grab a backup of AtariAge?" Luckily, most Linux-related groups are still lists because most of us have a superiority complex, so I have plenty to read and do. But I do miss being part of the Atari community sometimes, like when I heard someone had run with Ballblazer about six months after the fact. > Re: The Dig -- It was my understanding that you had taken its contents > and put it into a database. Do you have an archive of the original > static Dig or a backup of your db? I remember finding The Dig I have a mirror of The Dig circa 2004-05-19. It's about 160MB (split evenly between www.homebrewgames.net and www.atari2600.com directories, so I assume there's a lot of redundancy) if anyone feels like hosting it. If not, I'll probably throw it on my own site once it's moved to my company's new colo, assuming my backup doesn't die before then. It's not nicely extracted or databased, so there are a lot of ZIP files with names like "index.html?action=attachment.download&attachment_id=234" and I'd probably have to write a script to mimic the behavior of the original. But hopefully it would be navigable on the web. Rob (second try, wrong address the first time) (third try, for some reason DNS couldn't resolve atari2600.org last night) From rob-stellalist at kudla.org Sat Aug 1 13:51:25 2009 From: rob-stellalist at kudla.org (Rob) Date: Sat, 1 Aug 2009 14:51:25 -0400 Subject: [stella] Whence the Dig? Message-ID: <200908011451.26466.rob-stellalist@kudla.org> On Tuesday 28 July 2009 09:03 pm, Ruffin Bailey wrote to Glenn: > Yeah, but the AA forums have too much noise for an old man like me to > keep up with, and it's not like programming on Mac OS 8 & 9 are bringing > in thousands of hits either. ;^) Yeah, I don't have time for programming forums that don't come to me, myself. The pro-forum people always said, "Nothing's stopping you from staying on the mailing list and letting the people who don't understand email use forums". But as I expected based on my Maxim experience, there are more browser-wielding functional illiterates interested in Atari than there are people who are capable of writing an email, so it was only a matter of time before the critical mass shifted. And in another few years or decades, when Albert gets tired of running AtariAge, they'll all be on some other forum going, "Did anyone ever grab a backup of AtariAge?" Luckily, most Linux-related groups are still lists because most of us have a superiority complex, so I have plenty to read and do. But I do miss being part of the Atari community sometimes, like when I heard someone had run with Ballblazer about six months after the fact. > Re: The Dig -- It was my understanding that you had taken its contents > and put it into a database. Do you have an archive of the original > static Dig or a backup of your db? I remember finding The Dig I have a mirror of The Dig circa 2004-05-19. It's about 160MB (split evenly between www.homebrewgames.net and www.atari2600.com directories, so I assume there's a lot of redundancy) if anyone feels like hosting it. If not, I'll probably throw it on my own site once it's moved to my company's new colo, assuming my backup doesn't die before then. It's not nicely extracted or databased, so there are a lot of ZIP files with names like "index.html?action=attachment.download&attachment_id=234" and I'd probably have to write a script to mimic the behavior of the original. But hopefully it would be navigable on the web. Rob (second try, wrong address the first time) (third try, for some reason DNS couldn't resolve atari2600.org last night) From rob-stellalist at kudla.org Sat Aug 1 16:58:30 2009 From: rob-stellalist at kudla.org (Rob) Date: Sat, 1 Aug 2009 17:58:30 -0400 Subject: [stella] test Message-ID: <200908011758.31875.rob-stellalist@kudla.org> I've tried to make a post to the list 3 times in the last 24 hours and none of my attempts have shown up. I did get one "unable to deliver your mail due to DNS failure on atari2600.org" but I figured that had to be momentary and I see other posts are making it. If this test makes it, I should be able to see it, so please ignore. Rob From seagtgruff at aol.com Sun Aug 2 01:21:51 2009 From: seagtgruff at aol.com (seagtgruff at aol.com) Date: Sun, 02 Aug 2009 02:21:51 -0400 Subject: [stella] Explanation of the following NUSIZx code In-Reply-To: <200908011908.39759.sa666666@gmail.com> References: <200908011908.39759.sa666666@gmail.com> Message-ID: <8CBE150A57ACA3A-BBC-35E0@webmail-de04.sysops.aol.com> I think I can help with describing what the code's doing, although I'm not sure if I?can correctly explain the exact *timing* of the instructions. First, here's a general description of what's being done: The first two lines of the radar screen are drawn with player0 in double-size mode, so that each bit?is 2 color clocks wide. Then player0 is switched to a two-copy mode, with the second copy at the "near" distance, or 8 color clocks from the main copy. The bulk of the radar screen is drawn this way, with player0 being switched to the reflected mode after the main copy has been drawn, but before the near copy is drawn, so that the right side of the radar screen is a mirror of the left side (not including what's being shown *on* the radar-- which isn't being drawn with player0-- just the outline of the screen itself). After the right side has been drawn with the reflected near copy of player0, the reflected mode is turned off again for the next line. I haven't followed the code down to the bottom of the radar screen, but I assume that the last two lines are being drawn the same way the top two lines are, with player0 in the double-size mode. There are a couple of questions we might have about this code. For one thing, player0 is being shifted left *3* color clocks after drawing the first two lines, rather than *4* color clocks, even though when we look at the graphics data on the TIA debug tab, it looks like the double-size player0 is 4 color clocks to the right of where the main copy of player0 is on the other lines: ....0011223344556677 01234567........01234567 That's because there's a kind of "virtual bit" just before bit 0 that doesn't get drawn. (In the "illustrations" shown above and below, the periods represent color clocks, the digits represent the player bits-- 0 to 7-- and the dashes represent the "virtual bit.") Now, there isn't actually a bit there (which is why I'm calling it a "virtual bit"), but the TIA requires an extra color clock before it can start drawing player0. I'm not really explaining this well, but it's described in the "Atari 2600 TIA Hardware Notes" by Andrew Towers, which you should read for a more technical explanation about some of the TIA's features. I find it easiest to think of this in terms of?a "virtual bit" that doesn't get drawn, but that's just to help me wrap my brain around something that I don't fully understand the technical aspects of. ;) Anyway, when player0 is being drawn in the double-size mode, this virtual bit is also stretched, such that the beginning of the virtual bit is actually only 3 color clocks to the right of where it is on the other lines-- and thus, we need to shift player0 only *3* color clocks to the left for the other lines: ...--0011223344556677 -01234567.......-76543210 By the way, from what I've seen, the "virtual bit" is still stretched to only twice its size with quadruple-size players, even though the player is drawn quadruple-size: --00001111222233334444555566667777 instead of ----00001111222233334444555566667777 I'll come back to this in a moment. The second question-- which is the one you're stumped on-- is concerning what happens when NUSIZ0 is changed from double-size mode to two-copy near mode while player0 is being drawn. Or rather, the question is about what *isn't* happening-- why isn't the second copy being drawn on a real Atari, when it *is* being drawn in the new pre-3.0 version of the emulator that you're currently working on? I believe the answer has to do with *when* the TIA begins the player0 drawing process. As described by Andrew Towers, the "start drawing player0" command occurs during one "tick" of the counter, but the TIA doesn't actually begin to draw player0 until the next "tick" of the counter, which is 4 color clocks later (since each "tick" of the counter lasts for 4 color clocks). In the next "illustration," I've placed a star at the color clock where the "start drawing" command occurs. The fact that's key to answering this second question (at least, if I'm understanding everything correctly) is that the TIA will *not* draw the next copy of player0 if the value of NUSIZ0 at the time the next "start drawing" command would occur doesn't indicate that another copy is supposed to be drawn. In this next "illustration," I've added another row between the other two, to indicate where the main copy and the near copy of player0 would be if player0 weren't shifted to the left 3 color clocks: ...*...--0011223344556677 ...*...-01234567...*...-01234567 *...-01234567...*...-76543210 So basically, the change in NUSIZ0 is being timed just right so that it lets both of the "on" bits be drawn in the double-size mode, but by the time NUSIZ0 has been changed, the "start drawing" command for the near copy has already occurred-- but since the value of NUSIZ0 at the moment (indicated by the second star) didn't indicate that another copy should be drawn, the TIA does *not* draw the near copy, even though it might appear that the RGB scanning beams haven't yet reached the place where the near copy would be drawn. I hope that answers your question correctly. As for what I said about the size of the "virtual bit" in the double-size and quadruple-size modes, if you do a RESP0 at a specific color clock on the screen, the main copy of player0 will appear 5 color clocks later in normal-size mode-- 4 color clocks for the "start drawing" command to take effect, plus 1 additional color clock for the TIA to latch onto the player graphics (or something like that). But if player0 is being drawn in double-size mode, then the main copy of player0 will appear *6* color clocks after the color clock where the RESP0 occurred-- 4 color clocks for the "start drawing" command to take effect, plus *2* additional color clocks, rather than the usual *1* additional color clock. And if player0 is being drawn in quadruple-size mode, then the?delay between RESP0 and the actual start of player0 is still 6 color clocks, as if the "virtual bit" were stretched to double-size rather than quadruple-size. So it isn't really a "virtual bit," just a brief delay that the TIA requires to latch onto the player's graphics data, although I don't understand the technical details of it. The extra delay is 1 color clock for nornal-size players, and 2 color clocks for double-size or quadruple-size players. Michael -----Original Message----- From: Stephen Anthony To: Atari 2600 programming list Sent: Sat, Aug 1, 2009 5:38 pm Subject: [stella] Explanation of the following NUSIZx code Would someone be able to trace the following few lines of code and describe what's going on (and what should be going) wrt writing to NUSIZ0? This is for improvements to Stella. For clarity, I'll step through three lines of code with 3 snapshots from the Stella debugger: 1) A '1' has just been stored in the X register (see debug1.png). 2) The '1' from the X register is stored in NUSIZ0. Two CPU cycles have passed, and more of the graphic is drawn (see debug2.png). 3) The DEX instruction has executed in another CPU cycle. But the problem is, more of the graphic has been drawn, which isn't happening on a real console (see debug3.png). There seems to be an issue of when NUSIZx is written and when its contents are applied to the screen. Note that when I force the copy to '0' before stepping to DEX, the graphical garbage disappears. Obviously I'm misunderstanding what's going on here. Could someone explain what should be happening?? Thanks, Steve _______________________________________________ Stella mailing list Stella at atari2600.org http://atari2600.org/mailman/listinfo/stella -------------- next part -------------- An HTML attachment was scrubbed... URL: