+DZ-Jay Posted January 24, 2015 Share Posted January 24, 2015 I was gonna say.... I didn't see how that was possible. Now, if you want to use the ORG hack to overwrite a default title in-place (ie. overwrite an actual string with another actual string), you could maybe make that work. But, that requires reserving a fixed amount of space for the title, which seems... short sighted. Yeah, no. I was thinking the same thing as you: make the code generator keep track of the title string and inject it at the end, and then patch the address pointer in. At first, I was trying to look for ways to avoid the jump after injecting the string in-line, to fit the code generator, and lost track of where to put it. Oh well. -dZ. Quote Link to comment Share on other sites More sharing options...
intvnut Posted January 24, 2015 Share Posted January 24, 2015 (edited) I was thinking the same thing as you: make the code generator keep track of the title string and inject it at the end, and then patch the address pointer in. At first, I was trying to look for ways to avoid the jump after injecting the string in-line, to fit the code generator, and lost track of where to put it. Oh well. Thankfully, the standard label resolution pass in AS1600 does just about everything we need here. I happened to think: If IntyBASIC did use the "generate in-line with branch around" approach, it could emit a sequence like the following, and not have to track anything itself: . IF (DEFINED _TITLE) = 0 B T1 _TITLE: STRING 115, "My Game Title", 0 JD _MAIN T1: ENDI . and then include a default title in intybasic_epilogue.asm: . IF (DEFINED _TITLE) = 0 _TITLE: STRING 115, "IntyBASIC 1.1", 0 ; or whatever.... JD _MAIN ENDI . Definitely simple to implement. EDIT: A clarification too. There's two different branches involved. The JD _MAIN or B _MAIN is always required if the _TITLE record doesn't appear immediately before _MAIN in the assembled program. If the _TITLE record gets emitted between two other BASIC statements, then you need an additional "branch around", which is the B T1 in the example in this post. That branch-around can be avoided by only outputting a _TITLE record at the end. The branch back to _MAIN can't really be avoided. Sure, you could move the bootup code at _MAIN into the intybasic_epilogue.asm file, but you'd still end up with a branch back to the first BASIC program statement. No matter what, you end up with one extra branch, wherever you push that lump in the rug. Edited January 24, 2015 by intvnut 1 Quote Link to comment Share on other sites More sharing options...
freewheel Posted January 25, 2015 Share Posted January 25, 2015 I think I can safely handle the overhead of an extraneous branch at startup of any game I write. Great dialogue on this, guys, it's really appreciated. I'm with intvnut - I've also had some thoughts on other metadata that could be encoded into ROMs. It would be awesome to have hooks in IntyBASIC if we do come up with other things. Quote Link to comment Share on other sites More sharing options...
freewheel Posted January 25, 2015 Share Posted January 25, 2015 I'd swear I've asked this, or people have discussed, but I just can't remember: does IntyBASIC have hooks into the 3rd and 4th controllers that the ECS brings? If not, is there a plan for it? Or is it simple enough to just add a few ASM statements as a temporary kludge? I've got a killer idea for a 4 player game that would be fine with AI for the remaining players - but I know I'd get crucified if I didn't include full 4 player support, by the 6 people on the planet with the requisite hardware and 3 other nearby friends to play with Quote Link to comment Share on other sites More sharing options...
GroovyBee Posted January 25, 2015 Share Posted January 25, 2015 You should just be able to PEEK the controller addresses in the ECS memory map. Quote Link to comment Share on other sites More sharing options...
freewheel Posted January 25, 2015 Share Posted January 25, 2015 You should just be able to PEEK the controller addresses in the ECS memory map. True. I'm essentially doing that anyway much of the time in IntyBASIC and using my own form of input calculation. How good is ECS support in jzintv? (not necessarily a question for you). Quote Link to comment Share on other sites More sharing options...
intvnut Posted January 25, 2015 Share Posted January 25, 2015 (edited) True. I'm essentially doing that anyway much of the time in IntyBASIC and using my own form of input calculation. How good is ECS support in jzintv? (not necessarily a question for you). jzIntv models the alphabetic keyboard, synth keyboard and 3rd/4th controllers. For the alphabetic keyboard, it even models the peculiar ghosting behavior that the real keyboard has. See jzintv/doc/jzintv/kbdhackfile.txt for information on how to bind inputs to the ECS keyboards / controllers. PD1L_xx and PD1R_xx event inputs are the ECS left/right controllers KEYB_xx are ECS alphabetic keyboard inputs SYNTH_xx are ECS synthesizer keyboard inputs. That last bullet was missing from kbdhackfile.txt. I apparently added those after I wrote that file, and didn't go back and update it. Just fixed this in the SVN copy. I've attached that version to this post. You can use 'handdemo' that comes with jzIntv to test the 3rd and 4th controllers once you've set up your key mappings to stimulate them. Just use the -s1 flag to enable ECS in jzIntv. Note that bits 6 and 7 of $F8 control the I/O direction for I/O ports on the ECS. Make sure to set these both to 0 to read hand controllers. The ECS-connected hand controllers are at $FE and $FF. More information in this article which I'm certain you've seen: Reading the ECS Keyboards. kbdhackfile.txt Edited January 25, 2015 by intvnut Quote Link to comment Share on other sites More sharing options...
First Spear Posted January 25, 2015 Share Posted January 25, 2015 I have a MOB sitting the middle of the screen. If the player moves right, I am trying to determine the tile number (GROM or GRAM) that is in the location the MOB is going to be in (and its FG/BG color), before he actually goes there. What is the right way to do that in IntyBASIC 1.0.1? Thanks. Quote Link to comment Share on other sites More sharing options...
+nanochess Posted January 25, 2015 Author Share Posted January 25, 2015 I have a MOB sitting the middle of the screen. If the player moves right, I am trying to determine the tile number (GROM or GRAM) that is in the location the MOB is going to be in (and its FG/BG color), before he actually goes there. What is the right way to do that in IntyBASIC 1.0.1? Thanks. Technically a MOB could be over four tiles at same time. I would prefer to think that the center pixel of a MOB is what interests to me. row = (y_pixel + 3) / 8 col = (x_pixel + 3) / 8 tile = peek($0200 + row * 20 + col) Note this is by no means optimized Quote Link to comment Share on other sites More sharing options...
+nanochess Posted January 25, 2015 Author Share Posted January 25, 2015 BTW, just updated IntyBASIC to v1.0.2 (check first post) Now you can change the title of your game!!!! Also a few other useful enhancements, like checking both controller with one simple test (use CONT) or the support for Cuttle Cart 3. Even ON FRAME GOSUB if your mind works different for coding games And command-line usage is now more clearly documented, just run without arguments. 3 Quote Link to comment Share on other sites More sharing options...
intvnut Posted January 25, 2015 Share Posted January 25, 2015 (edited) Technically a MOB could be over four tiles at same time. I would prefer to think that the center pixel of a MOB is what interests to me. row = (y_pixel + 3) / 8 col = (x_pixel + 3) / 8 tile = peek($0200 + row * 20 + col) Note this is by no means optimized Only thing I would add is that you need to add an offset to the address for the direction the object's traveling if you want to "look ahead". +1 if traveling right, -1 if traveling left, +20 if traveling down, -20 if traveling up. Oh, and those biases need to be -3, not +3. Edited January 25, 2015 by intvnut 1 Quote Link to comment Share on other sites More sharing options...
+5-11under Posted January 25, 2015 Share Posted January 25, 2015 Nano, can I assume the -cc3 option has RAM at the same location as the -jlp RAM ($8040 to $9F7F)? Also, with the -cc3 option, can I use both 8 bit and 16 bit variables without thinking about them (for example using 2000 8 bit variables plus 2000 16 bit variables)? 1 Quote Link to comment Share on other sites More sharing options...
+nanochess Posted January 25, 2015 Author Share Posted January 25, 2015 Nano, can I assume the -cc3 option has RAM at the same location as the -jlp RAM ($8040 to $9F7F)? Also, with the -cc3 option, can I use both 8 bit and 16 bit variables without thinking about them (for example using 2000 8 bit variables plus 2000 16 bit variables)? Yes, same memory location as JLP. With the --cc3 option the 16-bits variables space is expanded, the 8-bits space remains same. So you should use variables names starting with # (hashtag? I've forgot the name) 1 Quote Link to comment Share on other sites More sharing options...
freewheel Posted January 26, 2015 Share Posted January 26, 2015 (edited) Technically a MOB could be over four tiles at same time. I would prefer to think that the center pixel of a MOB is what interests to me. Highlighting this for First Spear (and intvnut has already made the appropriate math corrections - now you just need to pull the FG/BG bits out of "tile" and construct the colors). The "it could be over 4 tiles at the same time" is something that is very obvious in hindsight, but it will bite you in the ass again and again. And even though you *think* you're allowing for it, it'll still bite you in the ass later on. I find this one of the more vexing problems with the INTV. Quadruple-check your code and test the living hell out of it. Every time I think I have it nailed, I run into some weird edge case and suddenly I realize I didn't nail it. Maybe it's just me and how I think (or don't!) Some of it is that I'm trying to do position detection not necessarily one pixel in size, and/or not at the center of a MOB - which makes things "interesting". Thanks again for the goodies, guys. Between the info and the new features, down the rabbit hole I go again... sigh... and I'm away from a keyboard for 5 days next week. Torture! Edited January 26, 2015 by freeweed 1 Quote Link to comment Share on other sites More sharing options...
freewheel Posted January 26, 2015 Share Posted January 26, 2015 Now you can change the title of your game!!!! Is this the final state, or are you still looking at allowing the title to be set within the source code itself? I'm happy with either, just curious Also YAY on the simplified controller reading. To me it's just the default behaviour of so many games. Plus it helps out people who have a flaky P1 controller on their console and are too lazy/inexperienced to swap them. 1 Quote Link to comment Share on other sites More sharing options...
+5-11under Posted January 26, 2015 Share Posted January 26, 2015 Yes, same memory location as JLP. With the --cc3 option the 16-bits variables space is expanded, the 8-bits space remains same. So ,you should use variables names starting with # (hashtag? I've forgot the name) Thanks for the clarification. If I'm doing simple stuff like addition, subtraction, bit rotating, and stuff like that, do instructions on 16 bit numbers run the same speed as on 8 bit numbers? Quote Link to comment Share on other sites More sharing options...
+nanochess Posted January 26, 2015 Author Share Posted January 26, 2015 Is this the final state, or are you still looking at allowing the title to be set within the source code itself? I'm happy with either, just curious Also YAY on the simplified controller reading. To me it's just the default behaviour of so many games. Plus it helps out people who have a flaky P1 controller on their console and are too lazy/inexperienced to swap them. Because my syntax-directed translation I don't think to implement title as a statement. I'm glad you liked CONT. It will save you a lot of code Thanks for the clarification. If I'm doing simple stuff like addition, subtraction, bit rotating, and stuff like that, do instructions on 16 bit numbers run the same speed as on 8 bit numbers? Yes. Same speed for 8 and 16 bits. CP1610 always operates in 16 bits 1 Quote Link to comment Share on other sites More sharing options...
freewheel Posted January 26, 2015 Share Posted January 26, 2015 Because my syntax-directed translation I don't think to implement title as a statement. I'm glad you liked CONT. It will save you a lot of code Well it just saves me a quick c1=CONT1:c2=CONT2:c=c1+c2, but it's still nice to have Especially so that I can avoid decoding the keypad manually I thought the guys (intvnut and DZ) had come up with an in-code solution for title that works. It's your call obviously; I'm now at the point where I'm trying to future-proof some of my code/scripts. We almost need a wiki for "upcoming releases" because you add so much so quickly that I wanna plan for it 1 Quote Link to comment Share on other sites More sharing options...
First Spear Posted January 29, 2015 Share Posted January 29, 2015 Premature Optimization is the Root of All Evil OK. Now I got that out of my system, I am still curious... 1. Is it more memory-efficient to use an array with n integers in it, or is it smarter to declare/use n integers? Bonus - how can I discover that for myself? 2. Is there a more efficient (in terms of speed or memory use) way to perform an operation based on a value, other than an IF...THEN construct? Thanks. Quote Link to comment Share on other sites More sharing options...
+DZ-Jay Posted January 29, 2015 Share Posted January 29, 2015 (edited) Premature Optimization is the Root of All Evil OK. Now I got that out of my system, I am still curious... 1. Is it more memory-efficient to use an array with n integers in it, or is it smarter to declare/use n integers? Bonus - how can I discover that for myself? 2. Is there a more efficient (in terms of speed or memory use) way to perform an operation based on a value, other than an IF...THEN construct? Thanks. On #1, it depends on the implementation of array access in IntyBASIC. In Assembly, iterating through an array may be made cheaper than accessing them directly from memory by using counter registers, which automatically advance after indirect memory access. Since indirect memory access use a couple of CPU cycles less than direct memory access, this may result in an optimized loop. That said, I think IntyBASIC puts all variables in memory, and access them directly from there, every time. On "bonus," you can compile and then take a look at the resulting Assembly Language file (*.asm). On #2, it depends on the operation. Can you post some sample code? Perhaps we can help in optimizing it. -dZ. Edited January 29, 2015 by DZ-Jay Quote Link to comment Share on other sites More sharing options...
First Spear Posted January 29, 2015 Share Posted January 29, 2015 Sorry for being dense. Can you restate that with sample code for one of the directions? Only thing I would add is that you need to add an offset to the address for the direction the object's traveling if you want to "look ahead". +1 if traveling right, -1 if traveling left, +20 if traveling down, -20 if traveling up. Oh, and those biases need to be -3, not +3. Quote Link to comment Share on other sites More sharing options...
First Spear Posted January 29, 2015 Share Posted January 29, 2015 I was thinking about other platforms where it can be faster to act based on the existence/absence of something in a collection, I was wondering if in IntyBASIC something similar exists. I didn't have any sample code, just something I was thinking about. Not a big deal and I am even having a hard time thinking through how to phrase the question, actually... [snip] On #2, it depends on the operation. Can you post some sample code? Perhaps we can help in optimizing it. -dZ. Quote Link to comment Share on other sites More sharing options...
+DZ-Jay Posted January 29, 2015 Share Posted January 29, 2015 Sorry for being dense. Can you restate that with sample code for one of the directions? He means that the code he provided would give you the card right underneath the sprite. If you want to "look ahead" (i.e., get the card right in front, behind, or at the sides of the sprite) you will need to adjust the tile formula: REM Get address to background tile under sprite row = (y_pixel + 3) / 8 col = (x_pixel + 3) / 8 tile = peek($0200 + row * 20 + col) REM Get address to background tile in front of sprite REM Looking right: (add one column) tile = peek($0200 + row * 20 + col) + 1 REM Looking left: (subtract one column) tile = peek($0200 + row * 20 + col) - 1 REM Looking up: (subtract one row = 20 columns) tile = peek($0200 + row * 20 + col) - 20 REM Looking down: (add one row = 20 columns) tile = peek($0200 + row * 20 + col) + 20 1 Quote Link to comment Share on other sites More sharing options...
+DZ-Jay Posted January 29, 2015 Share Posted January 29, 2015 I was thinking about other platforms where it can be faster to act based on the existence/absence of something in a collection, I was wondering if in IntyBASIC something similar exists. I didn't have any sample code, just something I was thinking about. Not a big deal and I am even having a hard time thinking through how to phrase the question, actually... Sure, and it depends on the implementation. I can't speak about that, and since I haven't used IntyBASIC for more than the cursory look, I'm not familiar with the generated code. Let's see what nanochess has to say. Quote Link to comment Share on other sites More sharing options...
intvnut Posted January 29, 2015 Share Posted January 29, 2015 (edited) He means that the code he provided would give you the card right underneath the sprite. If you want to "look ahead" (i.e., get the card right in front, behind, or at the sides of the sprite) you will need to adjust the tile formula: REM Get address to background tile under sprite row = (y_pixel + 3) / 8 col = (x_pixel + 3) / 8 tile = peek($0200 + row * 20 + col) REM Get address to background tile in front of sprite REM Looking right: (add one column) tile = peek($0200 + row * 20 + col) + 1 REM Looking left: (subtract one column) tile = peek($0200 + row * 20 + col) - 1 REM Looking up: (subtract one row = 20 columns) tile = peek($0200 + row * 20 + col) - 20 REM Looking down: (add one row = 20 columns) tile = peek($0200 + row * 20 + col) + 20 ... and change both of the + 3s to - 3s. REM Get address to background tile under sprite row = (y_pixel - 3) / 8 col = (x_pixel - 3) / 8 tile = peek($0200 + row * 20 + col) REM Get address to background tile in front of sprite REM Looking right: (add one column) tile = peek($0200 + row * 20 + col) + 1 REM Looking left: (subtract one column) tile = peek($0200 + row * 20 + col) - 1 REM Looking up: (subtract one row = 20 columns) tile = peek($0200 + row * 20 + col) - 20 REM Looking down: (add one row = 20 columns) tile = peek($0200 + row * 20 + col) + 20 Edited January 29, 2015 by intvnut 1 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.