zilog_z80a Posted February 27, 2018 Share Posted February 27, 2018 (edited) Hi, i'm really stuck with this subject. can't find a simple kernel where masked graphics are set.i mean animated ones, can't find really really, i can't, may be i'm not looking at the right place?google may be not showing good results or i'm doing perhaps the search with the wrong words?donno.... i will love to know how to set up masked graphics pointers in two simple scenarios.127 1LK AND 127 2LKplease, there are some examples but can't understand the kernel context.if somebody helps will be the push i need to try my first kernel. ty in advance. cheers. PS: I DON'T CARE IF IS AN EXAMPLE WITH A DIFFERENT KERNEL HEIGHT, JUST HELP. Edited February 28, 2018 by zilog_z80a Quote Link to comment Share on other sites More sharing options...
ZackAttack Posted February 28, 2018 Share Posted February 28, 2018 Don't have time to comment it for you. If the code isn't self explanatory, feel free to ask some follow up questions. I left out some optimizations for the sake of reduced complexity, if you intend to have a single kernel for the entire screen the mask could be reduced to 256 bytes. mask_draw_demo.asm mask_draw_demo.bin 1 Quote Link to comment Share on other sites More sharing options...
zilog_z80a Posted February 28, 2018 Author Share Posted February 28, 2018 (edited) Don't have time to comment it for you. If the code isn't self explanatory, feel free to ask some follow up questions. I left out some optimizations for the sake of reduced complexity, if you intend to have a single kernel for the entire screen the mask could be reduced to 256 bytes. mask_draw_demo.asm mask_draw_demo.bin Thank you very much for the code ZackAttack!!, i wanna do an asymmetrical playfield with six writes to PFX and two writes to GRPX per line in a 2LK, monochrome sprites. with your info once i have understood all.... then will try to implement this in Darrell Spice's 2LK Playfield found in COLLECT. this is what i was looking, i found it in other code but i was needing what you did a...... THIS IS ALL YOU NEED AND CLEAR. ScanLoop LDA (pGraphics),y AND (pMask),y STA GRP0 DEY STA WSYNC BNE ScanLoop not now.... but i think will need a bankswitching (ram/rom both) scheme, was looking them, but still looking cos will use MASKED SPRITES for all so i suspect that will need more ram and rom step by step, for now i will take a look at your code. ty again ZackAttack!! cheers! Edited February 28, 2018 by zilog_z80a Quote Link to comment Share on other sites More sharing options...
ZackAttack Posted February 28, 2018 Share Posted February 28, 2018 Happy to help. Just for fun I went ahead and optimized for the 1LK variant. The mask only takes 256 bytes because it exploits the natural wrap around of the 8 bit Y register. Keeping everything aligned properly is critical to avoiding a 1 cycle penalty for crossing pages. So the net is a couple bytes of RAM, 150 bytes of ROM, and 2 cycles during the kernel. Of course a 2LK will consume much less ROM space for mask and graphics and single colored sprites would save a bunch of resources too. mask_draw_demo.asm 1 Quote Link to comment Share on other sites More sharing options...
zilog_z80a Posted February 28, 2018 Author Share Posted February 28, 2018 (edited) wow, i'm learning the code from the first mask_draw_demo.asm about SPRITE... there is some kind of POINTERS OF POINTERS ARRAY OF POINTERS ZackaAttack, about memory space at $80.... this means..... FrameCount: DC.B ; always gonna be a byte? P0y: DC.B ; always gonna be a byte? pGraphics: DC.W ; always gonna be a word? pColors: DC.W ; always gonna be a word? pMask: DC.W ; always gonna be a word? AM I RIGHT? will continue reading. ty. cheers. Edited March 1, 2018 by zilog_z80a Quote Link to comment Share on other sites More sharing options...
ZackAttack Posted February 28, 2018 Share Posted February 28, 2018 Yeah it's using the frame count to index into the array of graphic pointers to produce the animation effect. You're correct, that's reserving ram for the different variables. Pointers need two bytes of course. 1 Quote Link to comment Share on other sites More sharing options...
zilog_z80a Posted February 28, 2018 Author Share Posted February 28, 2018 (edited) sorry i'm losing my brain lol isn't a sprite 8 bits long per slice? this sprite is 11 bits per slice!! bump i'm trying to compile the first mask_draw_demo.asm and there is an error about labels that i cannot solve. have changed the labels name but still can't compile. Edited March 1, 2018 by zilog_z80a Quote Link to comment Share on other sites More sharing options...
ZackAttack Posted February 28, 2018 Share Posted February 28, 2018 I'm not sure what you mean by slice. Atari doesn't have the notion of sprites built in. It keeps drawing the 8 bit wide player graphic every line. So you create a sprite by changing the GRP0 register each line, or every other line in 2lk. The height is controlled by the software you can make the Sprite as tall as the screen if you want. 1 Quote Link to comment Share on other sites More sharing options...
zilog_z80a Posted February 28, 2018 Author Share Posted February 28, 2018 (edited) hi, i mean not height, i mean width, is 11 bits wide the sprite in the source code you post first eg MegaMan_RunF03: BYTE %00000111100 ; <----- is not an 8 bit limit here? BYTE %00000110000 BYTE %01010111000 BYTE %01110110000 BYTE %00101100000 BYTE %11001110110 BYTE %11011110111 BYTE %01110000011 BYTE %00001111000 BYTE %00001000100 BYTE %00011111110 BYTE %00011001010 BYTE %00001001010 BYTE %00111111110 BYTE %00111110010 BYTE %00011100100 BYTE %00001001000 BYTE %00000000000 another thing is that source code gives me this error --- End of Symbol List. mask_draw_demo.asm (124): error: Label mismatch... --> MegaMan_Color f217 mask_draw_demo.asm (127): error: Label mismatch... --> MegaMan_Run_LowBytes f229 mask_draw_demo.asm (133): error: Label mismatch... --> MegaMan_Run_HighBytes f22d mask_draw_demo.asm (140): error: Label mismatch... --> MegaMan_RunF01 f231 mask_draw_demo.asm (160): error: Label mismatch... --> MegaMan_RunF02 f243 mask_draw_demo.asm (180): error: Label mismatch... --> MegaMan_RunF03 f255 mask_draw_demo.asm (200): error: Label mismatch... --> MegaMan_RunF04 f267 Unrecoverable error(s) in pass, aborting assembly! Complete. Edited February 28, 2018 by zilog_z80a Quote Link to comment Share on other sites More sharing options...
+SpiceWare Posted February 28, 2018 Share Posted February 28, 2018 dasm treats all numbers as 32 bit values. When outputting for byte it only uses the lowest 8 bits, so the left 3 bits are lost. You can see how that works if you generating a listing using dasm's -l option. mask_draw_demo.asm (120): error: Label mismatch... --> MegaMan_RunF01 f200 120 f300 00 00 00 00*MegaMan_RunF01 ALIGN 256 121 f300 1e BYTE.b %00000011110 122 f301 18 BYTE.b %00000011000 123 f302 9c BYTE.b %10110011100 124 f303 b8 BYTE.b %11110111000 125 f304 c0 BYTE.b %01011000000 126 f305 bf BYTE.b %00010111111 127 f306 7f BYTE.b %11001111111 128 f307 43 BYTE.b %11101000011 129 f308 38 BYTE.b %00000111000 130 f309 44 BYTE.b %00001000100 131 f30a fe BYTE.b %00011111110 132 f30b ca BYTE.b %00011001010 133 f30c 4a BYTE.b %00001001010 134 f30d fe BYTE.b %00111111110 135 f30e f2 BYTE.b %00111110010 136 f30f e4 BYTE.b %00011100100 137 f310 48 BYTE.b %00001001000 138 f311 00 BYTE.b %00000000000 The label mismatch means something moved during the compile process - first time it evaluated MegaMan_RunF01 it ended up at $F200 in the ROM, but on this last pass it ended up at $F300 for some reason. I took a quick look, but didn't see the source of the shift. Quote Link to comment Share on other sites More sharing options...
zilog_z80a Posted February 28, 2018 Author Share Posted February 28, 2018 (edited) dasm treats all numbers as 32 bit values. When outputting for byte it only uses the lowest 8 bits, so the left 3 bits are lost. You can see how that works if you generating a listing using dasm's -l option. mask_draw_demo.asm (120): error: Label mismatch... --> MegaMan_RunF01 f200 120 f300 00 00 00 00*MegaMan_RunF01 ALIGN 256 121 f300 1e BYTE.b %00000011110 122 f301 18 BYTE.b %00000011000 123 f302 9c BYTE.b %10110011100 124 f303 b8 BYTE.b %11110111000 125 f304 c0 BYTE.b %01011000000 126 f305 bf BYTE.b %00010111111 127 f306 7f BYTE.b %11001111111 128 f307 43 BYTE.b %11101000011 129 f308 38 BYTE.b %00000111000 130 f309 44 BYTE.b %00001000100 131 f30a fe BYTE.b %00011111110 132 f30b ca BYTE.b %00011001010 133 f30c 4a BYTE.b %00001001010 134 f30d fe BYTE.b %00111111110 135 f30e f2 BYTE.b %00111110010 136 f30f e4 BYTE.b %00011100100 137 f310 48 BYTE.b %00001001000 138 f311 00 BYTE.b %00000000000 The label mismatch means something moved during the compile process - first time it evaluated MegaMan_RunF01 it ended up at $F200 in the ROM, but on this last pass it ended up at $F300 for some reason. I took a quick look, but didn't see the source of the shift. Hi Darrell, ok just 8 bits are read. i`m lost again with this is like a naightmare lol ty. with the rest of errors i'm lost sorry. Edited March 1, 2018 by zilog_z80a Quote Link to comment Share on other sites More sharing options...
zilog_z80a Posted February 28, 2018 Author Share Posted February 28, 2018 (edited) Don't have time to comment it for you. If the code isn't self explanatory, feel free to ask some follow up questions. I left out some optimizations for the sake of reduced complexity, if you intend to have a single kernel for the entire screen the mask could be reduced to 256 bytes. mask_draw_demo.asm mask_draw_demo.bin Darrell there are two mask_draw_demo.asm i`m looking the first. Edited February 28, 2018 by zilog_z80a Quote Link to comment Share on other sites More sharing options...
+SpiceWare Posted February 28, 2018 Share Posted February 28, 2018 BYTE %00000111100 ; <----- is not an 8 bit limit here? Looking at dasm.txt, the manual for dasm: PSEUDOPS: ... [label] DC[.BWL] exp,exp,exp ... Declare data in the current segment. No output is generated if within a .U segment. Note that the byte ordering for the selected processor is used for each entry. The default size extension is a byte. #if OlafByte BYTE, WORD and LONG are synonyms for DC.B, DC.W and DC.L. #endif So the line BYTE %00000111100 is comprised of the pseudop BYTE (means same as DC.B) followed by the expression %00000111100. Elsewhere in dasm.txt: EXPRESSIONS: [] may be used to group expressions. The precedense of operators is the same as for the C language in almost all respects. Use brackets [] when you are unsure. The reason () cannot be used to group expressions is due to a conflict with the 6502 and other assembly languages. #if OlafBraKet It is possible to use () instead of [] in expressions following pseudo-ops, but not following mnemonics. So this works: if target & (pet3001 | pet4001), but this does not: lda #target & (pet3001 | pet4001). #endif Some operators, such as ||, can return a resolved value even if one of the expressions is not resolved. Operators are as follows: NOTE WELL! Some operations will result in non-byte values when a byte value was wanted. For example: ~1 is NOT $FF, but $FFFFFFFF. Preceding it with a < (take LSB of) will solve the problem. ALL ARITHMETIC IS CARRIED OUT IN 32 BITS. The final Result will be automatically truncated to the maximum handleable by the particular machine language (usually a word) when applied to standard mnemonics. Key bit of info there is ALL ARITHMETIC IS CARRIED OUT IN 32 BITS. So for binary numbers there can be a total of up to 32 1s and 0s after the %. If you have fewer than 32 digits it will pad 0s to the left of what you see. DC.B / BYTE will use the rightmost 8 bits of the 32 bit value, and ignore the rest. DC.W / WORD will use the rightmost 16 bits of the 32 bit value, and ignore the rest DC.L / LONG will use all 32 bits. 1 Quote Link to comment Share on other sites More sharing options...
zilog_z80a Posted February 28, 2018 Author Share Posted February 28, 2018 (edited) Looking at dasm.txt, the manual for dasm: PSEUDOPS:...[label] DC[.BWL] exp,exp,exp ... Declare data in the current segment. No output is generated if within a .U segment. Note that the byte ordering for the selected processor is used for each entry. The default size extension is a byte.#if OlafByte BYTE, WORD and LONG are synonyms for DC.B, DC.W and DC.L.#endif So the lineBYTE %00000111100 is comprised of the pseudop BYTE (means same as DC.B) followed by the expression %00000111100.Elsewhere in dasm.txt:EXPRESSIONS: [] may be used to group expressions. The precedense of operators is the same as for the C language in almost all respects. Use brackets [] when you are unsure. The reason () cannot be used to group expressions is due to a conflict with the 6502 and other assembly languages.#if OlafBraKet It is possible to use () instead of [] in expressions following pseudo-ops, but not following mnemonics. So this works: if target & (pet3001 | pet4001), but this does not: lda #target & (pet3001 | pet4001).#endif Some operators, such as ||, can return a resolved value even if one of the expressions is not resolved. Operators are as follows: NOTE WELL! Some operations will result in non-byte values when a byte value was wanted. For example: ~1 is NOT $FF, but $FFFFFFFF. Preceding it with a < (take LSB of) will solve the problem. ALL ARITHMETIC IS CARRIED OUT IN 32 BITS. The final Result will be automatically truncated to the maximum handleable by the particular machine language (usually a word) when applied to standard mnemonics. Key bit of info there is ALL ARITHMETIC IS CARRIED OUT IN 32 BITS. So for binary numbers there can be a total of up to 32 1s and 0s after the %. If you have fewer than 32 digits it will pad 0s to the left of what you see.DC.B / BYTE will use the rightmost 8 bits of the 32 bit value, and ignore the rest.DC.W / WORD will use the rightmost 16 bits of the 32 bit value, and ignore the restDC.L / LONG will use all 32 bits. I'm not sure what you mean by slice. Atari doesn't have the notion of sprites built in. It keeps drawing the 8 bit wide player graphic every line. So you create a sprite by changing the GRP0 register each line, or every other line in 2lk. The height is controlled by the software you can make the Sprite as tall as the screen if you want. can't make it work Edited March 1, 2018 by zilog_z80a Quote Link to comment Share on other sites More sharing options...
ZackAttack Posted February 28, 2018 Share Posted February 28, 2018 I took those sprites from the free sprites thread and didn't notice that they were more than 8 bits wide. So yeah, let's just call that a bug in the example code. Quote Link to comment Share on other sites More sharing options...
zilog_z80a Posted February 28, 2018 Author Share Posted February 28, 2018 (edited) I took those sprites from the free sprites thread and didn't notice that they were more than 8 bits wide. So yeah, let's just call that a bug in the example code. but i have changed them to 8 bits and can't make it work. please i need just one working example about this. can't understand the mismatch. Edited March 1, 2018 by zilog_z80a Quote Link to comment Share on other sites More sharing options...
+SpiceWare Posted February 28, 2018 Share Posted February 28, 2018 Quick update of Collect to replace DoDraw of the players with a Mask Collect_mask_20180228.zip 1 Quote Link to comment Share on other sites More sharing options...
zilog_z80a Posted March 1, 2018 Author Share Posted March 1, 2018 (edited) Quick update of Collect to replace DoDraw of the players with a Mask Collect_mask_20180228.zip THIS ARE THE ACTIONS AND PERSONS WHOM MAKES A NEW CHAPTER IN THE ATARI'S PROGRAMMING LIFE, A NEW STEP, MORE NEAR THAN EVER FOR US, FOR ALL THOSE PEOPLE THAT ARE TRYING TO LEARN. THANK YOU DARRELL SPICE JR. IF YOU NEED SOMETHING FROM ARGENTINA, WHAT EVER YOU NEED, JUST ASK, KIND KIND REGARS. AND TY AGAIN. THIS IS AN EXTRA HAPPY DAY. Edited March 1, 2018 by zilog_z80a Quote Link to comment Share on other sites More sharing options...
ZackAttack Posted March 1, 2018 Share Posted March 1, 2018 If you run into any more problems, please attach the asm file instead of pasting it's contents into your post. You have to use the "More Reply Options" to attach files to your post. DASM treats any line without white space as a label and wouldn't assemble what you pasted above because most of the indentation got lost. It appears as though all the leading tabs were removed at some point. 1 Quote Link to comment Share on other sites More sharing options...
zilog_z80a Posted March 1, 2018 Author Share Posted March 1, 2018 (edited) If you run into any more problems, please attach the asm file instead of pasting it's contents into your post. You have to use the "More Reply Options" to attach files to your post. DASM treats any line without white space as a label and wouldn't assemble what you pasted above because most of the indentation got lost. It appears as though all the leading tabs were removed at some point. hi ZackAttack!! I have tried to compile your first asm file please try it, i did a graphic cut for 8 bits and still it does not compile. ty. Edited March 1, 2018 by zilog_z80a Quote Link to comment Share on other sites More sharing options...
ZackAttack Posted March 1, 2018 Share Posted March 1, 2018 Interesting. I got those errors too, but didn't notice before because DASM keeps going and generates a working bin file for me. My build script automatically runs the bin so I don't bother looking at the output if stella pops open with a working program. The macro below couldn't be expanded in the first two passes, so it takes up 0 bytes. Then after SPRITE_HEIGHT is calculated it evaluates the REPEAT macro and causes an extra 18 bytes to be inserted into the bin, moving the location of everything after it. I've reordered things to prevent this problem. I assume you guys are using a different OS or different version of DASM, and that's why the error failed the build completely for you, but not me. REPEAT SPRITE_HEIGHT BYTE $ff REPEND Here's an updated asm file that should build for you too. mask_draw_demo3.asm 1 Quote Link to comment Share on other sites More sharing options...
zilog_z80a Posted March 1, 2018 Author Share Posted March 1, 2018 Interesting. I got those errors too, but didn't notice before because DASM keeps going and generates a working bin file for me. My build script automatically runs the bin so I don't bother looking at the output if stella pops open with a working program. The macro below couldn't be expanded in the first two passes, so it takes up 0 bytes. Then after SPRITE_HEIGHT is calculated it evaluates the REPEAT macro and causes an extra 18 bytes to be inserted into the bin, moving the location of everything after it. I've reordered things to prevent this problem. I assume you guys are using a different OS or different version of DASM, and that's why the error failed the build completely for you, but not me. REPEAT SPRITE_HEIGHT BYTE $ff REPEND Here's an updated asm file that should build for you too. mask_draw_demo3.asm DASM 2.20.11 20140304 Copyright © 1988-2008 by various authors (see file AUTHORS). License GPLv2+: GNU GPL version 2 or later (see file COPYING). DASM is free software: you are free to change and redistribute it. There is ABSOLUTELY NO WARRANTY, to the extent permitted by law. ty ZackAttack !! i will try your new source!! what version of dasm are you wearing? Quote Link to comment Share on other sites More sharing options...
+SpiceWare Posted March 1, 2018 Share Posted March 1, 2018 The macro below couldn't be expanded in the first two passes, so it takes up 0 bytes. See this blog entry(and comments) about using ds instead of repeat/byte/repend. Cleaner code & significantly shorter listings. 1 Quote Link to comment Share on other sites More sharing options...
zilog_z80a Posted March 1, 2018 Author Share Posted March 1, 2018 See this blog entry(and comments) about using ds instead of repeat/byte/repend. Cleaner code & significantly shorter listings. i must read all this posts of you, but ok, first COLLECT. is all so clear. cheers! Quote Link to comment Share on other sites More sharing options...
zilog_z80a Posted March 5, 2018 Author Share Posted March 5, 2018 (edited) HI, i'm doing some tests with all this but there is a weird situation i have a 127 lines HEIGHT kernel, one line kernel for now. 1LK, there is no cross page boundaries, all graphics are less than 200 lines and all of them comence with ALIGN 256 here is the kernel loop ( i have omitted SLEEP macros, STA WSYNC and other things) to let this clear and easy to read the weird thing is that if i'm using MASKED SPRITES i cannot make two of them fit in a single line with six writes to playfield. and it's weird cos there is time and still some cycles to waste? any clue? ty in advance. this is a nightmare lol. ; kerneloop lda PLAYF0,y ;+4 sta PF0 ;+3 7 lda PLAYF1,y ;+4 11 sta PF1 ;+3 14 lda PLAYF2,y ;+4 18 sta PF2 ;+3 21 lda PLAYF3,y ;+4 25 sta PF0 ;+3 28 lda PLAYF4,y ;+4 32 sta PF1 ;+3 35 lda PLAYF5,y ;+4 39 sta PF2 ;+3 42 LDA (player0),y ;+5 47 AND (mask0),y ;+5 52 sta GRP0 ;+3 55 LDA (player1),y ;+5 60 AND (mask1),y ;+5 65 sta GRP1 ;+3 68 dey BNE kerneloop ; ; Edited March 5, 2018 by zilog_z80a 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.