IntyBASIC compiler v1.2.9: The good things are now better!

[carlsson]

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!

[+DZ-Jay]

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.

[GroovyBee]

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.

[GroovyBee]

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

[+nanochess]

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.

[+nanochess]

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

[Kiwi]

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.

[GroovyBee]

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.

[Kiwi]

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.

[GroovyBee]

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.

[mmarrero]

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

 

 

 

 

[GroovyBee]

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.

[+nanochess]

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!

[+DZ-Jay]

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.

[+nanochess]

 

I think you mean "+ 1" on that last line.

 

-dZ.

 

Nope, I've put the behavior that mmarrero was looking for.

[+DZ-Jay]

 

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?

[+nanochess]

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

[mmarrero]

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.

[GroovyBee]

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.

[+DZ-Jay]

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

 

[mmarrero]

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].

 

[GroovyBee]

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.

[+nanochess]

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.

[dragonHunter]

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....

[+nanochess]

 

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.