DEBRO Posted November 13, 2019 Share Posted November 13, 2019 (edited) Hi there, I know the title mentions the 7800 and I posted this in the 2600 programming forum but this has to do with the 2600. I've been looking at Bob Whitehead's games lately. I started with reverse engineering Football at the start of the football season. My home team isn't doing so hot this season so I've had a lot of free time to look into this. I'm practically done but I'm proofreading it to try to make sure it's correct. This would be the first time I've looked at Bob Whitehead's work so I've also looked at other works to get an idea of his structure and patterns. Looking at his other work, I've come to Homerun and Boxing. Both of these store the sprites separated by n-number of bytes. As an example he would start the number fonts with the top of the zero sprite. Then the next byte would be the top of the one sprite. The next would would be the top of the two sprite...and so on. It's sort of similar to how the 7800 sprites are separated by pages. To make things look nice in the disassembly, I thought it would be nice to create a MACRO that could take the values grouped together in the text file but separate them when the file was assembled. My first attempt was to do... ScoreBoardFonts CHARACTER_SET $07, ; |.....XXX| $05, ; |.....X.X| $05, ; |.....X.X| $05, ; |.....X.X| $07 ; |.....XXX| DASM didn't like this because it looked at the hex values as literals and complained they weren't defined. Then I went with... ScoreBoardFonts CHARACTER_SET 7, 5, 5, 5, 7 ; |.....XXX| ; |.....X.X| ; |.....X.X| ; |.....X.X| ; |.....XXX| DASM accepts this but my MACRO is having issues. I was hoping to use a REPEAT loop to produce these values. It appears DASM doesn't let you reference a label as an argument. Also, DASM is having an issue with separating the bytes. I'm getting the "Origin Reverse-indexed" error. I thought I'd post my MACRO here and see if anyone had any ideas. One problem I foresee is the ORG at the end. It was to set to next byte however when the character set is done, the code needs to proceed to the next ROM location. MAC CHARACTER_SET .ITERATION SET 0 .ORIGIN SET . REPEAT 5 ORG .ORIGIN + (15 * .ITERATION) .ITERATION SET .ITERATION + 1 .byte {.ITERATION} REPEND ORG .ORIGIN + 1 ENDM Edited November 13, 2019 by DEBRO 2 Quote Link to comment Share on other sites More sharing options...
+Andrew Davie Posted November 14, 2019 Share Posted November 14, 2019 So, you either need to know in advance how many sprites you are going to define, OR your "block size" is big enough to not overflow, and thus wastes bytes. Right? Quote Link to comment Share on other sites More sharing options...
+Andrew Davie Posted November 14, 2019 Share Posted November 14, 2019 This is ugly. It avoids ORG and just rearranges the bytes. SPRITE_DEF_BLOCK_SIZE = 5 MAC SPR IF {1} = 0 .byte {2} ENDIF IF {1} = 1 .byte {3} ENDIF IF {1} = 2 .byte {4} ENDIF IF {1} = 3 .byte {5} ENDIF IF {1} = 4 .byte {6} ENDIF ; etc... we need SPRITE_DEF_BLOCK_SIZE of them ENDM P SET 0 REPEAT SPRITE_DEF_BLOCK_SIZE SPR P, 0,1,2,3,4 ; sprite 1 on a single line SPR P, 10,11,22,13,24 ; sprite 2 on a single line P SET P + 1 REPEND 2 Quote Link to comment Share on other sites More sharing options...
DEBRO Posted November 14, 2019 Author Share Posted November 14, 2019 Hi Andrew, 13 hours ago, Andrew Davie said: This is ugly. It avoids ORG and just rearranges the bytes. Thanks! This works perfectly and looks nicer in the text file. I think this would make it easier if anyone would then want to modify the graphics later as well. This is what Homerun would look like... ScoreBoardFonts ITERATION SET 1 REPEAT 5 SPRITE ITERATION, $07, $05, $05, $05, $07 ; |.....XXX| $F700 ; |.....X.X| $F70F ; |.....X.X| $F71E ; |.....X.X| $F72D ; |.....XXX| $F73C SPRITE ITERATION, $22, $22, $22, $22, $22 ; |..X...X.| $F701 ; |..X...X.| $F710 ; |..X...X.| $F71F ; |..X...X.| $F72E ; |..X...X.| $F73D SPRITE ITERATION, $77, $44, $77, $11, $77 ; |.XXX.XXX| $F702 ; |.X...X..| $F711 ; |.XXX.XXX| $F720 ; |...X...X| $F72F ; |.XXX.XXX| $F73E SPRITE ITERATION, $77, $11, $33, $11, $77 ; |.XXX.XXX| $F703 ; |...X...X| $F712 ; |..XX..XX| $F721 ; |...X...X| $F730 ; |.XXX.XXX| $F73F SPRITE ITERATION, $11, $11, $77, $55, $55 ; |...X...X| $F704 ; |...X...X| $F713 ; |.XXX.XXX| $F722 ; |.X.X.X.X| $F731 ; |.X.X.X.X| $F740 SPRITE ITERATION, $77, $11, $77, $44, $77 ; |.XXX.XXX| $F705 ; |...X...X| $F714 ; |.XXX.XXX| $F723 ; |.X...X..| $F732 ; |.XXX.XXX| $F741 SPRITE ITERATION, $77, $55, $77, $44, $77 ; |.XXX.XXX| $F706 ; |.X.X.X.X| $F715 ; |.XXX.XXX| $F724 ; |.X...X..| $F733 ; |.XXX.XXX| $F742 SPRITE ITERATION, $11, $11, $11, $11, $77 ; |...X...X| $F707 ; |...X...X| $F716 ; |...X...X| $F725 ; |...X...X| $F734 ; |.XXX.XXX| $F743 SPRITE ITERATION, $77, $55, $77, $55, $77 ; |.XXX.XXX| $F708 ; |.X.X.X.X| $F717 ; |.XXX.XXX| $F726 ; |.X.X.X.X| $F735 ; |.XXX.XXX| $F744 SPRITE ITERATION, $77, $11, $77, $55, $77 ; |.XXX.XXX| $F709 ; |...X...X| $F718 ; |.XXX.XXX| $F727 ; |.X.X.X.X| $F736 ; |.XXX.XXX| $F745 SPRITE ITERATION, $00, $00, $00, $00, $00 ; |........| $F70A ; |........| $F719 ; |........| $F728 ; |........| $F737 ; |........| $F746 SPRITE ITERATION, $FF, $99, $FF, $AA, $EE ; |XXXXXXXX| $F70B ; |X..XX..X| $F71A ; |XXXXXXXX| $F729 ; |X.X.X.X.| $F738 ; |XXX.XXX.| $F747 SPRITE ITERATION, $EE, $44, $44, $EE, $00 ; |XXX.XXX.| $F70C ; |.X...X..| $F71B ; |.X...X..| $F72A ; |XXX.XXX.| $F739 ; |........| $F748 SPRITE ITERATION, $EE, $AA, $AA, $EE, $00 ; |XXX.XXX.| $F70D ; |X.X.X.X.| $F71C ; |X.X.X.X.| $F72B ; |XXX.XXX.| $F73A ; |........| $F749 SPRITE ITERATION, $FF, $11, $FF, $88, $FF ; |XXXXXXXX| $F70E ; |...X...X| $F71D ; |XXXXXXXX| $F72C ; |X...X...| $F73B ; |XXXXXXXX| $F74A ITERATION SET ITERATION + 1 REPEND 1 Quote Link to comment Share on other sites More sharing options...
JeffJetton Posted November 16, 2019 Share Posted November 16, 2019 On 11/13/2019 at 3:12 PM, DEBRO said: Looking at his other work, I've come to Homerun and Boxing. Both of these store the sprites separated by n-number of bytes. As an example he would start the number fonts with the top of the zero sprite. Then the next byte would be the top of the one sprite. The next would would be the top of the two sprite...and so on. Wait... so the sprite data is all interleaved together? Seems needlessly complicated... Is there any advantage to doing it that way? I guess the offset of a number's sprite (from the beginning of the sprite data) would actually equal that very number, which might possibly be useful. Any other good reason for it? Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
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.