+Random Terrain Posted October 14, 2011 Share Posted October 14, 2011 When I compile my program, I get this: DASM V2.20.07, Macro Assembler ©1988-2003 bytes of ROM space left in bank 1 bytes of ROM space left in bank 2 bytes of ROM space left in bank 3 bytes of ROM space left in bank 4 bytes of ROM space left in bank 5 bytes of ROM space left in bank 6 bytes of ROM space left in bank 7 bytes of ROM space left in bank 8 480 bytes of ROM space left in bank 1 203 bytes of ROM space left in bank 2 3796 bytes of ROM space left in bank 3 415 bytes of ROM space left in bank 4 590 bytes of ROM space left in bank 5 3796 bytes of ROM space left in bank 6 1604 bytes of ROM space left in bank 7 --> vblk2 f600 708 bytes of ROM space left in bank 8 480 bytes of ROM space left in bank 1 203 bytes of ROM space left in bank 2 3796 bytes of ROM space left in bank 3 415 bytes of ROM space left in bank 4 590 bytes of ROM space left in bank 5 3796 bytes of ROM space left in bank 6 1604 bytes of ROM space left in bank 7 708 bytes of ROM space left in bank 8 Is it something bad or just some kind of information that I don't need to worry about? Thanks. Quote Link to comment Share on other sites More sharing options...
Robert M Posted October 14, 2011 Share Posted October 14, 2011 Its hard to say. Try this: When you compile your code add this option '-lmylisting.lst' . That's a lowercase L after the dash. DASM will produce a list file that has all the compiler information. Find the message in that listing file and you may more clearly see what is causing it. Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted October 14, 2011 Author Share Posted October 14, 2011 Its hard to say. Try this: When you compile your code add this option '-lmylisting.lst' . That's a lowercase L after the dash. DASM will produce a list file that has all the compiler information. Find the message in that listing file and you may more clearly see what is causing it. Thanks. Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted October 15, 2011 Author Share Posted October 15, 2011 Its hard to say. Try this: When you compile your code add this option '-lmylisting.lst' . That's a lowercase L after the dash. DASM will produce a list file that has all the compiler information. Find the message in that listing file and you may more clearly see what is causing it. That seems to make the same file as this: http://www.atariage.com/forums/topic/125734-writing-a-multispritemultibank-game-is-harder-than-i-thought/page__p__1520604#entry1520604 And the only mention of vblk2 is this: 32041 8600 vblk 32042 8600 ; run possible vblank bB code 32043 8600 ifconst vblank_bB_code 32044 8600 20 2a f6 jsr vblank_bB_code 32045 8603 endif 32046 8603 vblk2 32047 8603 ad 84 02 LDA INTIM 32048 8606 30 fb bmi vblk2 32049 8608 4c 00 f1 jmp kernel Still don't know if the message is good or bad. Quote Link to comment Share on other sites More sharing options...
GroovyBee Posted October 15, 2011 Share Posted October 15, 2011 If that section is taken from your code then vblk2 is at 0x8603 and not 0xF600. Allowing for a RORG it could be at 0xF603. Find the part in the listing that is telling you the space that is free in all the banks. As a side note the jsr is definitely in the code and calls something at address 0xF62A (however I'm not interested in that). Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted October 15, 2011 Author Share Posted October 15, 2011 If that section is taken from your code then vblk2 is at 0x8603 and not 0xF600. Allowing for a RORG it could be at 0xF603. Find the part in the listing that is telling you the space that is free in all the banks. As a side note the jsr is definitely in the code and calls something at address 0xF62A (however I'm not interested in that). Do you mean this: 34297 8cac c4 c4 c4 c4 .byte.b $C4, $C4, $C4, $C4 708 bytes of ROM space left in bank 8 34298 8cac echo " ",[(scoretable - *)]d , "bytes of ROM space left in bank 8") 34299 8cb0 34300 8cb0 34301 8cb0 ; feel free to modify the score graphics - just keep each digit 8 high 34302 8cb0 ; and keep the conditional compilation stuff intact 34303 8cb0 - ifconst ROM2k 34304 8cb0 - ORG $F7AC 34305 8cb0 else 34306 8cb0 ifconst bankswitch 34307 8cb0 - if bankswitch == 8 34308 8cb0 - ORG $2F94-bscode_length 34309 8cb0 - RORG $FF94-bscode_length 34310 8cb0 endif 34311 8cb0 - if bankswitch == 16 34312 8cb0 - ORG $4F94-bscode_length 34313 8cb0 - RORG $FF94-bscode_length 34314 8cb0 endif 34315 8cb0 if bankswitch == 32 34316 8f74 ORG $8F94-bscode_length 34317 8f74 RORG $FF94-bscode_length 34318 8f74 endif 34319 8f74 - else 34320 8f74 - ORG $FF9C 34321 8f74 endif 34322 8f74 endif 34323 8f74 34324 8f74 34325 8f74 scoretable Quote Link to comment Share on other sites More sharing options...
GroovyBee Posted October 15, 2011 Share Posted October 15, 2011 Nearly! Search for an "echo" statement that mentions vblk2. Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted October 15, 2011 Author Share Posted October 15, 2011 Nearly! Search for an "echo" statement that mentions vblk2. The only place that mentions vblk2 is here: 32041 8600 vblk 32042 8600 ; run possible vblank bB code 32043 8600 ifconst vblank_bB_code 32044 8600 20 2a f6 jsr vblank_bB_code 32045 8603 endif 32046 8603 vblk2 32047 8603 ad 84 02 LDA INTIM 32048 8606 30 fb bmi vblk2 32049 8608 4c 00 f1 jmp kernel Quote Link to comment Share on other sites More sharing options...
GroovyBee Posted October 15, 2011 Share Posted October 15, 2011 OK! I'm not sure where that message comes from then . Can you search for all the echo's? Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted October 15, 2011 Author Share Posted October 15, 2011 OK! I'm not sure where that message comes from then . Can you search for all the echo's? Yep: 24313 4e35 echo " ",[(start_bank4 - *)]d , "bytes of ROM space left in bank 4") 24343 4ff2 - echo "WARNING: size parameter in banksw.asm too small - the program probably will not work." 24344 4ff2 - echo "Change to",[(*-begin_bscode+1)&$FF]d,"and try again." 30403 5d86 echo " ",[(start_bank5 - *)]d , "bytes of ROM space left in bank 5") 30433 5ff2 - echo "WARNING: size parameter in banksw.asm too small - the program probably will not work." 30434 5ff2 - echo "Change to",[(*-begin_bscode+1)&$FF]d,"and try again." 30453 6100 echo " ",[(start_bank6 - *)]d , "bytes of ROM space left in bank 6") 30483 6ff2 - echo "WARNING: size parameter in banksw.asm too small - the program probably will not work." 30484 6ff2 - echo "Change to",[(*-begin_bscode+1)&$FF]d,"and try again." 4 718e - ECHO "MACRO ERROR: 'SLEEP': Duration must be > 1" 152 725e ;echo "critical code in 48x1 is ",(pf48x1_codeend-pf48x1_loop), " bytes long." 4 7305 - ECHO "MACRO ERROR: 'SLEEP': Duration must be > 1" 134 7394 ;echo "critical code #1 in 96x2_1 is ",(pf96x2_1_0codeend-pfline_96x2_1_frame0), " bytes long." 4 73ab - ECHO "MACRO ERROR: 'SLEEP': Duration must be > 1" 251 7468 ;echo "critical code #2 in 96x2_1 is ",(pf96x2_1_1codeend-pfline_96x2_1_frame1), " bytes long." I left out the 50 billion MACRO ERROR: 'SLEEP' things and when I saw that it was the same stuff over and over, I quit copying and pasting. Quote Link to comment Share on other sites More sharing options...
GroovyBee Posted October 15, 2011 Share Posted October 15, 2011 It looks like the echo of interest is between echo's ending in the text "bank 7" and "bank 8". You've only got "bank 4" to "bank 6" in the above search list. Quote Link to comment Share on other sites More sharing options...
Robert M Posted October 15, 2011 Share Posted October 15, 2011 That's a good mystery. Are you willing to post the entire list file, or the original asm file generated by the batari Basic compiler? Quote Link to comment Share on other sites More sharing options...
RevEng Posted October 15, 2011 Share Posted October 15, 2011 It's not from an echo statement. bB's uses a sed filter to get rid of extraneous warnings, and it's removing part of dasm's complaint. The actual unfiltered error looks something like this... myfile.bas.asm (32046): error: Label mismatch... --> vblk2 f600 Basically dasm is complaining about this label changing between passes. It looks like the "ifconst" in the bit of code above vblk2 (in std_overscan.asm) is inactive in one pass and active in another. That's why your dump shows vblk2 at f603 instead of f600 like the error. If you remove your binary and compile again, is it actually recreated RT? 1 Quote Link to comment Share on other sites More sharing options...
GroovyBee Posted October 15, 2011 Share Posted October 15, 2011 Thanks for clearing that up RevEng. I'm not a bB programmer. Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted October 15, 2011 Author Share Posted October 15, 2011 If you remove your binary and compile again, is it actually recreated RT? It does it when renaming my .bas file with Save As. There is no .bin file then. I'm guessing that it has to do with too much code in vblank. If I put a tiny amount of code in there, I don't get that weird message. You'd think the program would go over 262 if I was putting too much in there. Quote Link to comment Share on other sites More sharing options...
RevEng Posted October 15, 2011 Share Posted October 15, 2011 Thanks for clearing that up RevEng. I'm not a bB programmer. No worries Groovy. We appreciate having non-bB and bB grey cells focused on our problems. It does it when renaming my .bas file with Save As. There is no .bin file then. I'm guessing that it has to do with too much code in vblank. If I put a tiny amount of code in there, I don't get that weird message. You'd think the program would go over 262 if I was putting too much in there. If your code is compiling and whatever you put in vblank seems to be running, then I'm pretty sure it's harmless. The version of dasm I have under Linux is a bit less forgiving, for some reason. I run into this with any vblank code, and it's fatal. To work around it I have the following change to std_overscan.asm... vblk ; run possible vblank bB code ifconst vblank_bB_code jsr vblank_bB_code else nop nop nop endif vblk2 Its wastes 3 bytes when I'm not using vblank, but I'll invariably use vblank with a real project. 1 Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted October 15, 2011 Author Share Posted October 15, 2011 If your code is compiling and whatever you put in vblank seems to be running, then I'm pretty sure it's harmless. The version of dasm I have under Linux is a bit less forgiving, for some reason. I run into this with any vblank code, and it's fatal. To work around it I have the following change to std_overscan.asm... vblk ; run possible vblank bB code ifconst vblank_bB_code jsr vblank_bB_code else nop nop nop endif vblk2 Its wastes 3 bytes when I'm not using vblank, but I'll invariably use vblank with a real project. I wanted to wait until I wasn't sleepy to try that. So I just made that change and the message is gone! Thanks! You might want to tell batari about that so he can add it. New Question: When I turn on a bit to tell the code in vblank to run, does the code run at the exact place in the program where the bit is turned on or does it run at the end of the rest of the code? Quote Link to comment Share on other sites More sharing options...
RevEng Posted October 15, 2011 Share Posted October 15, 2011 No problem! I'll pass it on to batari in the bug thread. When I turn on a bit to tell the code in vblank to run, does the code run at the exact place in the program where the bit is turned on or does it run at the end of the rest of the code? The code doesn't run right away when the bit is turned on. It runs at the beginning of the next drawscreen command executed, right before the visible part of the screen is drawn. 1 Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted October 15, 2011 Author Share Posted October 15, 2011 (edited) The code doesn't run right away when the bit is turned on. It runs at the beginning of the next drawscreen command executed, right before the visible part of the screen is drawn. Thanks. I keep forgetting that code can run without drawscreen. I keep thinking that nothing happens until drawscreen is used. Can temporary variables be used within vblank or do they need to be changed to normal variables? Edited October 15, 2011 by Random Terrain Quote Link to comment Share on other sites More sharing options...
RevEng Posted October 15, 2011 Share Posted October 15, 2011 No problem, and temp variables can be used within the vblank section. 1 Quote Link to comment Share on other sites More sharing options...
+atari2600land Posted October 20, 2011 Share Posted October 20, 2011 I got the same message, too, unfortunately. Can anyone look through my code and find out what the problem is? Mine is at f523. 50celery9.bas Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted October 20, 2011 Author Share Posted October 20, 2011 I got the same message, too, unfortunately. Can anyone look through my code and find out what the problem is? Mine is at f523. If you make the change to std_overscan.asm mentioned below, the message will go away: http://www.atariage.com/forums/topic/189018-what-does-vblk2-f600-mean/page__view__findpost__p__2389581 Quote Link to comment Share on other sites More sharing options...
+atari2600land Posted October 20, 2011 Share Posted October 20, 2011 I was hoping it was the cause of my program being more than 262 scanlines. 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.