carlsson Posted December 2, 2016 Share Posted December 2, 2016 The good thing is that you don't have to update the SDK for IntyBASIC versions 1.2.0 to 1.2.7, you can jump directly from the old version to 1.2.8! A lot of work saved! 1 Quote Link to comment Share on other sites More sharing options...
+DZ-Jay Posted December 4, 2016 Share Posted December 4, 2016 The good thing is that you don't have to update the SDK for IntyBASIC versions 1.2.0 to 1.2.7, you can jump directly from the old version to 1.2.8! A lot of work saved! Releasing a new version of the SDK is not really as trivial as updating the compiler version. All the tools have been re-written to be more robust, fix problems, and support new features. Plus I need to test all distributed samples and libraries with the new tool chain and make sure everything works. That said, I had done most of that last year when I created an updated version for Windows. Since then, there have been a few more compiler versions and newer features added that I need to test, then repackage it for distribution and we're done. -dZ. 2 Quote Link to comment Share on other sites More sharing options...
GroovyBee Posted December 15, 2016 Share Posted December 15, 2016 A suggestion for a simple peep hole optimisation. If code in a loop does the following :- #a=peek #readAddress ... poke #writeAddress, #b ... #readAddress=#readAddress+1 ... #writeAddress=#writeAddress+1 Then the compiler should load register r4 with the target/source address and not register r1 and then proceed to make use of the fact that mvo@/mvi@ will auto increment r4 to save a mvi/incr/mvo code sequence. The caveat being that there must not be any code that breaks out of the loop between the poke/peek and the associated address incrementing e.g. goto/gosub etc. 2 Quote Link to comment Share on other sites More sharing options...
GroovyBee Posted January 7, 2017 Share Posted January 7, 2017 (edited) The following code:- #a=#a+0.001 Does not load any constant into r0 before moving r0 into the memory for variable a. It just does a "mov r0, xxx" and uses whatever is in r0 at the time. It would be better if the compiler checked to see if the floating point number can be converted into the IntyBASIC internal format and issue a warning if it can't. The following code:- #fred=#fred+0.1 #jim=#jim+0.1 #bill=0.0 #bill=#jim+#fred Does not perform an "adcr" after computing "#bill=#jim+#fred" but it can clearly see that "#bill", "#fred" and "#jim" are all fixed point variables from their previous manipulation history. Edit: Even the "#jim=#jim+0.1" does not generate an "adcr" to cater for overflow. Edited January 7, 2017 by GroovyBee 2 Quote Link to comment Share on other sites More sharing options...
+nanochess Posted January 8, 2017 Author Share Posted January 8, 2017 The following code:- #a=#a+0.001 Does not load any constant into r0 before moving r0 into the memory for variable a. It just does a "mov r0, xxx" and uses whatever is in r0 at the time. It would be better if the compiler checked to see if the floating point number can be converted into the IntyBASIC internal format and issue a warning if it can't. The following code:- #fred=#fred+0.1 #jim=#jim+0.1 #bill=0.0 #bill=#jim+#fred Does not perform an "adcr" after computing "#bill=#jim+#fred" but it can clearly see that "#bill", "#fred" and "#jim" are all fixed point variables from their previous manipulation history. Edit: Even the "#jim=#jim+0.1" does not generate an "adcr" to cater for overflow. Added to the TODO list. 3 Quote Link to comment Share on other sites More sharing options...
+nanochess Posted January 20, 2017 Author Share Posted January 20, 2017 Here is a patch for the IntySmap utility if you're using debugging. It prevents strange crashes when using it. To be included in future versions of IntyBASIC. intysmap_20012017.zip 3 Quote Link to comment Share on other sites More sharing options...
Kiwi Posted February 13, 2017 Share Posted February 13, 2017 I think I found a minor bug doing comparison with 16 bit numbers. if #objHP(i)>30000 then objID(i)=objID(i)+32:objb(i)=0 This won't trigger the event. however #objHP(i)=0 works but not ideal if your attack power is more than 1 Changing the #objHP to 8-bit variable objHP will trigger the code. if objHP(i)>240 then objID(i)=objID(i)+32:objb(i)=0 works. My idea of using 16-bit variable that your character get stronger in the game so doing #objHP(i)>30000 will ensure enemy death without skipping the non-hot spot of the 8-bit variable. I am not sure if it is a bug with IntyBASIC or am I doing something incorrect. Quote Link to comment Share on other sites More sharing options...
GroovyBee Posted February 13, 2017 Share Posted February 13, 2017 I think I found a minor bug doing comparison with 16 bit numbers. Did you do the following (for example) :- dim #objHP(10) unsigned #objHP Then the compiler will treat the variable #objHp as an unsigned 16 bit integer. Perhaps Oscar can add unsigned as a valid parameter to the dim command in a future version. 2 Quote Link to comment Share on other sites More sharing options...
Kiwi Posted February 13, 2017 Share Posted February 13, 2017 Did you do the following (for example) :- dim #objHP(10) unsigned #objHP Then the compiler will treat the variable #objHp as an unsigned 16 bit integer. Perhaps Oscar can add unsigned as a valid parameter to the dim command in a future version. That makes sense. Once the HP is below zero, then I think #objHP(i)>-30000 would work. I understood why now. I did the above suggestion, declaring that variable as unsigned and it triggered the event! Thanks groovybee. 1 Quote Link to comment Share on other sites More sharing options...
GroovyBee Posted February 13, 2017 Share Posted February 13, 2017 That makes sense. Once the HP is below zero, then I think #objHP(i)>-30000 would work. I understood why now. I did the above suggestion, declaring that variable as unsigned and it triggered the event! Thanks groovybee. Don't forget that when using two's complement, a signed 16bit variable can only contain numbers from −32768 to 32767. When its unsigned, the range is 0 to 65535. Quote Link to comment Share on other sites More sharing options...
mmarrero Posted March 28, 2017 Share Posted March 28, 2017 Hi Nanochess,I found odd behavior with PEEK(#addr) in IntyBasic v1.2.8. When I increment #addr after PEEK, the next instruction reads previous #addr value, and if next instruction is peek, it reads wrong data. It won't happen if the next instruction doesn't use it, for example, adding a wait before print, or, in a function call. I hope the example helps. OPTION EXPLICIT ON:OPTION WARNINGS ON DIM #addr, #addr2, #x, #y #addr=VARPTR DataZ(0):#addr2=#addr PRINT AT 20,"A:",<>#addr," ",<>#addr2 '---prints wrong #addr #x=PEEK(#addr):#addr=#addr+1:#addr2=#addr2+1 PRINT AT 60,"1:",<>#addr," ",<>#addr2," ",<>#x #x=PEEK(#addr):#addr=#addr+1:#addr2=#addr2+1 PRINT AT 80,"2:",<>#addr," ",<>#addr2," ",<>#x '---this one below works GOSUB GetVal PRINT AT 100,"3:",<>#addr," ",<>#addr2," ",<>#x '---read wrong data #x=PEEK(#addr):#addr=#addr+1 #y=PEEK(#addr):#addr=#addr+1 PRINT AT 140,"4,5: #x:",<>#x," #y:",<>#y '---should skip a number #x=PEEK(#addr):#addr=#addr+1 #y=PEEK(#addr+1) PRINT AT 160,"6,8: #x:",<>#x," #y:",<>#y Infi: WAIT:GOTO Infi GetVal: PROCEDURE #x=PEEK(#addr):#addr=#addr+1:#addr2=#addr2+1 END DataZ: DATA 1,2,3,4,5,6,7,8 1 Quote Link to comment Share on other sites More sharing options...
GroovyBee Posted March 28, 2017 Share Posted March 28, 2017 This smaller program shows the problem too :- #addr=varptr Foo(0) #x=peek(#addr) #addr=#addr+1 #y=peek(#addr) #BACKTAB(0)=((#x+"0")*+7 ' Should display "1" #BACKTAB(2)=((#y+"0")*+7 ' Should display "2" loop: wait goto loop Foo: data 1,2,3 Looks like a peep hole optimizer bug because the register used for the pointer (obtained from #addr) is not marked as "dirty" after the increment. 1 Quote Link to comment Share on other sites More sharing options...
+nanochess Posted March 28, 2017 Author Share Posted March 28, 2017 Solved it, it was a bug happening because two registers contained the same variable and peephole optimizer though one of these was still current. To be available in next version of IntyBASIC. In the meanwhile use this syntax: #x = peek(#addr) #y = peek(#addr + 1) #addr = #addr + 2 Thanks for reporting it! Quote Link to comment Share on other sites More sharing options...
+DZ-Jay Posted March 29, 2017 Share Posted March 29, 2017 Solved it, it was a bug happening because two registers contained the same variable and peephole optimizer though one of these was still current. To be available in next version of IntyBASIC. In the meanwhile use this syntax: #x = peek(#addr) #y = peek(#addr + 1) #addr = #addr + 2 Thanks for reporting it! I think you mean "+ 1" on that last line. -dZ. Quote Link to comment Share on other sites More sharing options...
+nanochess Posted March 29, 2017 Author Share Posted March 29, 2017 I think you mean "+ 1" on that last line. -dZ. Nope, I've put the behavior that mmarrero was looking for. Quote Link to comment Share on other sites More sharing options...
+DZ-Jay Posted March 29, 2017 Share Posted March 29, 2017 Nope, I've put the behavior that mmarrero was looking for. Hmm... I must have missed something. The complaint was that using PEEK on a variable, then incrementing the variable by 1, then using PEEK again on it, would read the old address. #x = peek(#addr) #addr = #addr + 1 #y = peek(#addr) ' Reads previous addr No? Quote Link to comment Share on other sites More sharing options...
+nanochess Posted March 29, 2017 Author Share Posted March 29, 2017 Hmm... I must have missed something. The complaint was that using PEEK on a variable, then incrementing the variable by 1, then using PEEK again on it, would read the old address. #x = peek(#addr) #addr = #addr + 1 #y = peek(#addr) ' Reads previous addr No? No, he is trying to read pairs of coordinates Quote Link to comment Share on other sites More sharing options...
mmarrero Posted March 30, 2017 Share Posted March 30, 2017 Nanochess is correct. Dz-Jay's answer is what IntyBasic is doing! Maybe the confusion it's because my code sample doesn't seem logical, what I was doing is something like x=peek(a++), y=peek(a++), do, i=peek(a++), loop while i<>0. Quote Link to comment Share on other sites More sharing options...
GroovyBee Posted March 30, 2017 Share Posted March 30, 2017 If you don't want to rework your code then include the following assembly language function (treat it like any high level procedure):- asm PEEK: PROC asm movr r0, r1 asm mvi@ r1, r0 asm movr r5, pc asm ENDP And change the "peeking" code to:- #x=usr PEEK(#addr) Then, when IntyBASIC is fixed, you can run through your code in an editor and delete the usr part. It should still work as expected and be slightly quicker too. 1 Quote Link to comment Share on other sites More sharing options...
+DZ-Jay Posted March 30, 2017 Share Posted March 30, 2017 Nanochess is correct. Dz-Jay's answer is what IntyBasic is doing! Maybe the confusion it's because my code sample doesn't seem logical, what I was doing is something like x=peek(a++), y=peek(a++), do, i=peek(a++), loop while i<>0. I guess I am really stupid because, as far as I know, x = peek(a++) is the same as, x = peek(a) a = a + 1 Quote Link to comment Share on other sites More sharing options...
mmarrero Posted March 30, 2017 Share Posted March 30, 2017 I guess I am really stupid because, as far as I know... Nooo... What I meant is code context. Without knowing there was a loop ahead, your code makes more sense than mine. Was my previous reply out of context too? GroovyBee, thanks for the ASM code. I don't have immediate use, but it's great reference - I can't get rid of x86 habits (which is all backwards), mvi@ r1,r0 ;mov r0,[r1]. Quote Link to comment Share on other sites More sharing options...
GroovyBee Posted May 24, 2017 Share Posted May 24, 2017 Sometimes, I like to add additional data to the end of the bitmaps section in a file generated by intycolor. To save manually editing files (not ideal in a complex build process), is it possible that a suitable command line parameter, e.g. -i, could be added? For example, if you added "-i aFileName" that would generate a line with an include "aFileName" in the resultant output file. 1 Quote Link to comment Share on other sites More sharing options...
+nanochess Posted May 24, 2017 Author Share Posted May 24, 2017 Sometimes, I like to add additional data to the end of the bitmaps section in a file generated by intycolor. To save manually editing files (not ideal in a complex build process), is it possible that a suitable command line parameter, e.g. -i, could be added? For example, if you added "-i aFileName" that would generate a line with an include "aFileName" in the resultant output file. I'll think about it. Quote Link to comment Share on other sites More sharing options...
dragonHunter Posted August 17, 2017 Share Posted August 17, 2017 Copying this from another thread, because I think it may be useful to IntyBASIC programmers. TL;DR: With the attached tweaks to IntyBASIC 1.2.5's intybasic_prologue.asm, intybasic_epilogue.asm and the new file intybasic_cart.mac, you have a cleaner alternative to ORG statements for large games. The assembler will also detect ROM overflows and tell you just how much room is left in every ROM segment. This is a lightly-tested proof of concept, and I think it's a great starting point for extending IntyBASIC to make it easier to make games larger than 8K words if nanochess and others want to run with it. _____________________________ Ok, I did a quick conversion of IntyBASIC to cart.mac again, and wrote up an example based on the existing 42K.BAS example in the contrib folder. When you assemble this example, you'll get a summary from the assembler: . $ as1600 -o 40k_cartmac.bin -l 40k_cartmac.lst 40k_cartmac.asm ================================================================= Program size: $0375 (885 dec) words ROM available: $9A8B (39563 dec) words ----------------------------------------------------------------- Range Start End : Used Avail 0: $5000 - $6FFF : $026F $1D91 1: $8100 - $BFFF : $0084 $3E7C 2: $C100 - $FFFF : $0082 $3E7E ================================================================= ERROR SUMMARY - ERRORS DETECTED 0 - WARNINGS 0 . If I did everything correctly, the assembler will put all of the library code in intybasic_epilog.asm into the ROM segments where there's room, automatically. No more "leaving some room in the last segment" trickery. To change ROM segments, you just insert the statement "asm ROMSEG x", where x is 0, 1 or 2, to start assembling in that segment. You can switch ROM segments as often as you like; the ROMSEG directive keeps track of how full each segment is, and won't assemble over any existing code. And, if you overflow the memory map, you'll get an error at assembly time, rather than a silent crash. This is an update to an earlier tweak I had made of this form. This time, I used IntyBASIC 1.2.5 as my base, so you should be able to drop in these files on a fresh IntyBASIC 1.2.5 folder and start experimenting. All this is released to the public domain / free for everyone to use for whatever purpose. It can be extended to other memory maps, better integrated in IntyBASIC and so on. This is just a good starting point. :-) Please, try it and let me know how it works for you. EDIT: There was a big bug in the version I posted a few minutes ago. I think I've fixed it. Please download it again. Has this been updated to work with INTYBasic 1.2.8? I noticed the .asm files are a bit smaller and older than the 1.2.8 ones. I'm working on a big game and starting out using the 42k example, but was getting a lot of random emulator failures (the emu would immediately crash when the game was started; even though I was careful with segment sizes). So, I tried your 40k cart.mac, and it seemed to fix the random emulator crashes. But a couple of days ago, they started up again. I'm hoping newer .asm files will have bug fixes that stop these crashes.... Quote Link to comment Share on other sites More sharing options...
+nanochess Posted August 21, 2017 Author Share Posted August 21, 2017 Has this been updated to work with INTYBasic 1.2.8? I noticed the .asm files are a bit smaller and older than the 1.2.8 ones. I'm working on a big game and starting out using the 42k example, but was getting a lot of random emulator failures (the emu would immediately crash when the game was started; even though I was careful with segment sizes). So, I tried your 40k cart.mac, and it seemed to fix the random emulator crashes. But a couple of days ago, they started up again. I'm hoping newer .asm files will have bug fixes that stop these crashes.... Check your generated .cfg file, and check it doesn't exceed the areas indicated in the 42k example. Most crashes are related to it. Quote Link to comment Share on other sites More sharing options...
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.