RevEng Posted January 26, 2014 Author Share Posted January 26, 2014 Excellent! I had another dasm update, so I'll probably update bB with the dummy "sed.exe" and the new dasm version (assuming it sticks) later today. 1 Quote Link to comment Share on other sites More sharing options...
RevEng Posted January 27, 2014 Author Share Posted January 27, 2014 Version 34 is in the first post. Its a small update. I added the dummy sed.exe and put in the latest dasm update. 1 Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted January 28, 2014 Share Posted January 28, 2014 The Getting Started section has been updated: randomterrain.com/atari-2600-memories-batari-basic-commands.html#gettingstarted 2 Quote Link to comment Share on other sites More sharing options...
RevEng Posted February 4, 2014 Author Share Posted February 4, 2014 Version 35 is in the first post. fixed a bug where dim and const would screw up if you used a : command separator after them. enhanced install_win.bat so it works if you try to switch back and forth between one bB directory and another. dropped in the latest dasm. 3 Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted February 4, 2014 Share Posted February 4, 2014 Version 35 is in the first post. fixed a bug where dim and const would screw up if you used a : command separator after them. Does that mean we can use rems after dims now: . dim _Monkey_Brains = a : rem Keeps track of how many brains have been eaten. Quote Link to comment Share on other sites More sharing options...
RevEng Posted February 5, 2014 Author Share Posted February 5, 2014 Yup. That's exactly what I was trying to do when I ran into the bug. I'm sure at some point I learned to avoid rems after dim's, and eventually forgot again. 1 Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted February 5, 2014 Share Posted February 5, 2014 Yup. That's exactly what I was trying to do when I ran into the bug. I'm sure at some point I learned to avoid rems after dim's, and eventually forgot again. Seems like we've been waiting a long time for that ability. Nice that it's finally here. I have a question. Is it correct to use a semicolon in place of a colon and rem after some code? For example, this compiles: . a = 5 ; I Like Pizza . If that is a legal use of a semicolon, then maybe we could use this too: . dim _Monkey_Brains = a ; Keeps track of how many brains have been eaten. Quote Link to comment Share on other sites More sharing options...
RevEng Posted February 5, 2014 Author Share Posted February 5, 2014 Yup, your usage of ";" is spot on, and it definitely works. Fixing dim and const separators was mostly for consistency, but it's worth mentioning there's a subtle difference between the two commenting styles. When you use ";" and "/* */" comments, the comments don't show up in the generated assembly code. When you use "rem" they do. So I personally tend to use "rem" for single-line comments, even though ";" is a lot easier to type. 1 Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted February 6, 2014 Share Posted February 6, 2014 Yup, your usage of ";" is spot on, and it definitely works. Fixing dim and const separators was mostly for consistency, but it's worth mentioning there's a subtle difference between the two commenting styles. When you use ";" and "/* */" comments, the comments don't show up in the generated assembly code. When you use "rem" they do. So I personally tend to use "rem" for single-line comments, even though ";" is a lot easier to type. Thanks. I'll update the bB page with that info and do some rearranging while I'm at it. I think this section should be deleted and the stuff from it should be moved here. Quote Link to comment Share on other sites More sharing options...
RevEng Posted February 6, 2014 Author Share Posted February 6, 2014 Not a problem, and that edit sounds right to me. Quote Link to comment Share on other sites More sharing options...
RevEng Posted May 1, 2014 Author Share Posted May 1, 2014 Version 36 is in the first post. fixed a bug where ; comments would sometimes eat the line below, and always threw off the line number used for error reporting. added var0->var8 variables to DPC+ include file. Your DPC+ programs can now use these variables. increased sub-statement size and count limits. this should push back the on...goto/gosub limits and allow for very long variable names. 3 Quote Link to comment Share on other sites More sharing options...
Byte Knight Posted May 2, 2014 Share Posted May 2, 2014 9 more variables is HUGE! Thanks Mike!! Quote Link to comment Share on other sites More sharing options...
iesposta Posted May 2, 2014 Share Posted May 2, 2014 Thank again, RevEng! I've starting saying that the batari Basic DPC+ kernel has 35 variables. (Now if only "stack" use routines, other than what is documented, could be programmed. ) Quote Link to comment Share on other sites More sharing options...
RevEng Posted May 2, 2014 Author Share Posted May 2, 2014 My pleasure, guys! 1 Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted May 2, 2014 Share Posted May 2, 2014 My pleasure, guys! I love more variables. I keep hoping that one day you'll find a way to have var0-var47. If that ever happens, I'll be able to make just about any game I can think of. Quote Link to comment Share on other sites More sharing options...
+Gemintronic Posted May 2, 2014 Share Posted May 2, 2014 I love more variables. I keep hoping that one day you'll find a way to have var0-var47. If that ever happens, I'll be able to make just about any game I can think of. Bah! Real men only use boolean values and scrape bytes from the joystick ports 2 Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted May 9, 2014 Share Posted May 9, 2014 added var0->var8 variables to DPC+ include file. Your DPC+ programs can now use these variables. See if you guys like the wording in these two sections: randomterrain.com/atari-2600-memories-batari-basic-commands.html#dpc_news randomterrain.com/atari-2600-memories-batari-basic-commands.html#dpc_variables 1 Quote Link to comment Share on other sites More sharing options...
+Gemintronic Posted May 9, 2014 Share Posted May 9, 2014 See if you guys like the wording in these two sections: randomterrain.com/atari-2600-memories-batari-basic-commands.html#dpc_news randomterrain.com/atari-2600-memories-batari-basic-commands.html#dpc_variables http://www.randomterrain.com/atari-2600-memories-batari-basic-commands.html#dpc_news I know this is anal but you specifically asked about the wording.. I think you changed the tone to be too much like a conversation. I'm not sure if I should be taking the information as a personal comment or instruction fact Quote Link to comment Share on other sites More sharing options...
RevEng Posted May 9, 2014 Author Share Posted May 9, 2014 I think the tone of the whole site is pretty informal, so I don't think it's out of place. But I found it was harder to parse than it might otherwise be because of historic information (Reveng found) being included in the good/bad distinction, and as someone learning the language I just want to know the current state of affairs. I also think it's a bit easier to read if you group good and bad together... The bad news is that there are only 35 variables - a to z, and var0 to var8 - though you may free up more memory by killing off sprites with dpcspritemax. Another slight bit of bad news is that we can't put data values directly into playfield variables. DPC+ uses ARM memory for the playfield and bB can't access the playfield without using playfield:, pfpixel, pfvline or pfhline. The good news is that pfpixel, pfvline, pfhline, pfread, pfclear, and pfscroll are now supported by the DPC+ kernel. Also, the DPC+ kernel has an ARM-based 32-bit LFSR for improved random numbers, so "dim rand16 = <var>" is no longer needed when using this kernel. That's one variable we don't have to waste. ...its also worth mentioning that both iesposta and bogax have been updating the DPC+ playfield without the pf functions. It's not exactly direct PF memory access like we have with the non-DPC+ kernels, but it's close. Hopefully one of them can provide a brief example. 2 Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted May 9, 2014 Share Posted May 9, 2014 I think the tone of the whole site is pretty informal, so I don't think it's out of place. But I found it was harder to parse than it might otherwise be because of historic information (Reveng found) being included in the good/bad distinction, and as someone learning the language I just want to know the current state of affairs. I also think it's a bit easier to read if you group good and bad together... The bad news is that there are only 35 variables - a to z, and var0 to var8 - though you may free up more memory by killing off sprites with dpcspritemax. Another slight bit of bad news is that we can't put data values directly into playfield variables. DPC+ uses ARM memory for the playfield and bB can't access the playfield without using playfield:, pfpixel, pfvline or pfhline. The good news is that pfpixel, pfvline, pfhline, pfread, pfclear, and pfscroll are now supported by the DPC+ kernel. Also, the DPC+ kernel has an ARM-based 32-bit LFSR for improved random numbers, so "dim rand16 = <var>" is no longer needed when using this kernel. That's one variable we don't have to waste. ...its also worth mentioning that both iesposta and bogax have been updating the DPC+ playfield without the pf functions. It's not exactly direct PF memory access like we have with the non-DPC+ kernels, but it's close. Hopefully one of them can provide a brief example. Thanks. Here's the updated section: randomterrain.com/atari-2600-memories-batari-basic-commands.html#dpc_news Does this also need to be changed: randomterrain.com/atari-2600-memories-batari-basic-commands.html#dpc_variables 3 Quote Link to comment Share on other sites More sharing options...
RevEng Posted May 9, 2014 Author Share Posted May 9, 2014 Yeah, I think it probably should be changed similarly. I really do appreciate that you try to attribute everything. In this case since it's a language feature we can skip it. 1 Quote Link to comment Share on other sites More sharing options...
iesposta Posted May 9, 2014 Share Posted May 9, 2014 About the direct PF updating. pfpixel probably compiles to what we are doing, although our advantage is doing a bit more a little faster, probably due to the fact you can change a whole byte, 8 pixels, at a time. Both ways use the ARM routines, and doing too much playfield at once will run over cycle and crash. Also our technique and pf[pixel] routines use lots of cycles and ROM space. You also have to remember that the 2nd & 4th PF columns are backwards in hardware, bBasic hides that by reversing bytes when needed. Quote Link to comment Share on other sites More sharing options...
devsmash Posted September 11, 2014 Share Posted September 11, 2014 How do you install it? Quote Link to comment Share on other sites More sharing options...
RevEng Posted September 11, 2014 Author Share Posted September 11, 2014 Check out the getting started section of Random Terrain's bB site. There's little more to installing than double-clicking the included batch file, but keep in mind bB is a command line program. RT's site also has info on the vbb GUI front-end IDE. Quote Link to comment Share on other sites More sharing options...
RevEng Posted February 22, 2015 Author Share Posted February 22, 2015 Version 37 is in the first post. This release incorporates the pfscroll+player1color bug fix. 3 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.