+Muddyfunster Posted April 1, 2020 Share Posted April 1, 2020 (edited) I spent some time coding some extra things into the "combat" airplane demo today. I got to the point where, even though the compile message is telling me I have space left (over 3,500 bytes in the main area), if I add any code, the first graphics that I load in the program, become intermittently corrupted when I display them. The video attached shows what I mean, a few seconds in, at certain sprite frames, I get random pixel at the bottom of the sprite frame. In the vid the sprites are the same but with a different palette. I changed the load order (as i've prepared some additional airplane graphics) and it happens no matter which sprite I load first. (i'm trying to load things optimally). The code I added sits alone and isn't called anywhere. As I said, I can even delete the code and place it somewhere else, isolated, and the the same result. The piece of code I added is nothing to do with the main loop and just controls some menu items on the title page. I tried just adding any piece of code and got the same result, corruption on the first sprite in graphics block zero. If I remove the code the corruption goes away again. I'm using a regular 48KB cart setting with no bankswitching If I add dmahole calls through out the code, it also goes away, which makes me think my program body is somehow "leaking" into graphics block zero causing the corruption even though I have 3,532 bytes left in the main area. Block0 has 0 bytes, block 1 has 48 bytes, block 2 has 256 bytes and block 3 has 1680 bytes. As I said, I can work around it and I have dmahole 0,1 and 2 currently not being used so 12,228 bytes to use up but it struck me as odd to behave that way. I'm not sure if i'm doing something obviously wrong and any pointers or advice would be appreciated. A7800_ Atari 7800 (NTSC) Cool [a7800] 2020-04-01 20-37-16.mp4 Edited April 1, 2020 by Muddyfunster Quote Link to comment Share on other sites More sharing options...
RevEng Posted April 2, 2020 Share Posted April 2, 2020 The 7800 doesn't implement dma holes for ROM below 8000, and it needs dma holes (or alternatively rom with all zeros in non-sprite areas) for displaying sprites that move vertically smoothly. So if you have sprite graphics below 8000, then your program code can show up during vertical sprite movement. That's my best guess as to what's happening here, without more info. If you have the 48k rom stuffed with graphics, try putting charactersets first in the ROM. Characters don't need DMA holes, since they don't move vertically in sub-zone sized movements. Double-check the compilation messages to make sure the sprites aren't below 8000. Quote Link to comment Share on other sites More sharing options...
+Muddyfunster Posted April 2, 2020 Author Share Posted April 2, 2020 (edited) Thanks @RevEng. Compilation message shows that gfx block #0 starts at $8000, block #1 A000 and so on, doesn't look like anything is below $8000. I moved the character sets to load first but the result was the same. Edited April 2, 2020 by Muddyfunster Quote Link to comment Share on other sites More sharing options...
Mord Posted April 2, 2020 Share Posted April 2, 2020 As a suggestion perhaps check to make sure you're actually returning properly from all routines. If moving code around makes it go away this might be the cause. Essentially look for places where a return isn't being done as intended so extra code gets done that might not actually do anything useful beyond waste time until it eventually hits a completely unrelated return. I'd take a close look at where you're plotting the sprites though. The errors seem to pop up regularly based on the Y coordinate so might have a zone issue? Do you mess with lockzone/unlockzone while plotting? 1 Quote Link to comment Share on other sites More sharing options...
+Muddyfunster Posted April 2, 2020 Author Share Posted April 2, 2020 Thanks for the suggestions Mord. I had a line by line run though, all the returns seems to be present and in the right places, no slip-through's to unintended code. The code block I moved is simply a menu control block on the titlepage and it doesn't matter where I put it, the problem stays, so it's seeming more to do with the overall size and code going in certain memory locations. I also tried removing it and replacing it with dummy code to flash the screen and it's definitely not being executed and the problem remains. Zone issue was not one i'd considered. I'm not using any lockzone or unlock zones when plotting (not got that advanced yet! ). The glitching does only happen on vertical movement as @RevEng noted. if I plot the sprite and rotate through the same angles but without moving it, no glitch. Quote Link to comment Share on other sites More sharing options...
RevEng Posted April 2, 2020 Share Posted April 2, 2020 Ok, it's probably going to be easiest if you share code, either here or PM. I still think it's related to dma holes, based on your earlier description, so it looks like either they haven't been enabled correctly or somehow have been disabled. Quote Link to comment Share on other sites More sharing options...
+mksmith Posted April 2, 2020 Share Posted April 2, 2020 Are the sprites all the same height and on 8/16 pixel boundaries? 1 Quote Link to comment Share on other sites More sharing options...
+Muddyfunster Posted April 2, 2020 Author Share Posted April 2, 2020 58 minutes ago, RevEng said: Ok, it's probably going to be easiest if you share code, either here or PM. I still think it's related to dma holes, based on your earlier description, so it looks like either they haven't been enabled correctly or somehow have been disabled. Thanks @RevEng, appreciate your help. I'll shoot it over to you later. Quote Link to comment Share on other sites More sharing options...
RevEng Posted April 4, 2020 Share Posted April 4, 2020 Ok, I had a look at Muddyfunster's code, and know the cause of the issue. It is the fact that Maria doesn't implement DMA Holes below $8000, which is a problem for vertically moving sprites that are also stored at $8000, not just those below $8000 as I originally stated. In this case, if Maria doesn't see zeroes from $6000-$7fff (assuming zoneheight=16) it will copy over whatever is stored in that area (code or non sprite-data) when a sprite is positioned lower than the beginning of a zone. I should have clued into this earlier, but I've never had a game with sprite data all the way from the back of the rom to $8000, so it's always just been a theoretic sort of knowledge, rather than something I've personally dealt with. Anyway, the workaround would either be to only use non-sprite graphics at $8000 and below (not an option here) or to use 7800basic DMA holes to ensure the area from $6000-$7fff remains empty. 2 1 Quote Link to comment Share on other sites More sharing options...
+SmittyB Posted April 4, 2020 Share Posted April 4, 2020 Another mystery solved. That's useful to know seeing as while it makes perfect sense it's a problem without an immediately obvious solution if someone doesn't know the signs. 2 Quote Link to comment Share on other sites More sharing options...
TailChao Posted April 4, 2020 Share Posted April 4, 2020 Yep, the useful range for unaligned graphics is effectively $A000 - $AFFF, $C000 - $CFFF, and $E000 - $EFFF. That's still 12KB of space, though. 2 Quote Link to comment Share on other sites More sharing options...
RevEng Posted April 4, 2020 Share Posted April 4, 2020 1 hour ago, SmittyB said: Another mystery solved. That's useful to know seeing as while it makes perfect sense it's a problem without an immediately obvious solution if someone doesn't know the signs. Yeah, agreed. I'll add a note somewhere in the 7800basic manual, probably under incgraphic, to highlight it. 1 Quote Link to comment Share on other sites More sharing options...
+Muddyfunster Posted April 5, 2020 Author Share Posted April 5, 2020 6 hours ago, RevEng said: Ok, I had a look at Muddyfunster's code, and know the cause of the issue. It is the fact that Maria doesn't implement DMA Holes below $8000, which is a problem for vertically moving sprites that are also stored at $8000, not just those below $8000 as I originally stated. In this case, if Maria doesn't see zeroes from $6000-$7fff (assuming zoneheight=16) it will copy over whatever is stored in that area (code or non sprite-data) when a sprite is positioned lower than the beginning of a zone. I should have clued into this earlier, but I've never had a game with sprite data all the way from the back of the rom to $8000, so it's always just been a theoretic sort of knowledge, rather than something I've personally dealt with. Anyway, the workaround would either be to only use non-sprite graphics at $8000 and below (not an option here) or to use 7800basic DMA holes to ensure the area from $6000-$7fff remains empty. Thanks @RevEng appreciate review. I do have some graphics that I load with incbanner for the titlescreen and if I load those first at $8000 the problem seems to be solved. Plan b would be use the DMA holes as you noted Quote Link to comment Share on other sites More sharing options...
RevEng Posted April 5, 2020 Share Posted April 5, 2020 You're welcome. Carry on, but I think that's a temporary measure, as it will buy you less than 256 bytes of code, if there are still sprites residing in $8000 that need to move vertically. 1 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.