Jump to content

Photo

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

Intellivision IntyBASIC

252 replies to this topic

#226 carlsson ONLINE  

carlsson

    River Patroller

  • 4,682 posts
  • Location:Västerås, Sweden

Posted Fri Dec 2, 2016 9:52 AM

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!



#227 DZ-Jay OFFLINE  

DZ-Jay

    Quadrunner

  • 9,838 posts
  • Triple-Stripe Mo' Bro
  • Location:NC, USA

Posted Sun Dec 4, 2016 7:37 AM

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.



#228 GroovyBee OFFLINE  

GroovyBee

    Games Developer

  • 9,736 posts
  • Busy bee!
  • Location:North, England

Posted Thu Dec 15, 2016 1:19 PM

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.



#229 GroovyBee OFFLINE  

GroovyBee

    Games Developer

  • 9,736 posts
  • Busy bee!
  • Location:North, England

Posted Sat Jan 7, 2017 5:37 PM

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 by GroovyBee, Sat Jan 7, 2017 5:55 PM.


#230 nanochess OFFLINE  

nanochess

    River Patroller

  • Topic Starter
  • 4,794 posts
  • Coding something good
  • Location:Mexico, Mexico

Posted Sat Jan 7, 2017 6:55 PM

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.



#231 nanochess OFFLINE  

nanochess

    River Patroller

  • Topic Starter
  • 4,794 posts
  • Coding something good
  • Location:Mexico, Mexico

Posted Fri Jan 20, 2017 11:13 AM

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.

Attached Files



#232 Kiwi OFFLINE  

Kiwi

    Stargunner

  • 1,379 posts

Posted Sun Feb 12, 2017 10:07 PM

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.



#233 GroovyBee OFFLINE  

GroovyBee

    Games Developer

  • 9,736 posts
  • Busy bee!
  • Location:North, England

Posted Mon Feb 13, 2017 4:03 AM

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.

#234 Kiwi OFFLINE  

Kiwi

    Stargunner

  • 1,379 posts

Posted Mon Feb 13, 2017 4:30 AM

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



#235 GroovyBee OFFLINE  

GroovyBee

    Games Developer

  • 9,736 posts
  • Busy bee!
  • Location:North, England

Posted Mon Feb 13, 2017 4:45 AM

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.

#236 mmarrero OFFLINE  

mmarrero

    Space Invader

  • 45 posts

Posted Mon Mar 27, 2017 9:40 PM

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.

 

Spoiler

 

 



#237 GroovyBee OFFLINE  

GroovyBee

    Games Developer

  • 9,736 posts
  • Busy bee!
  • Location:North, England

Posted Tue Mar 28, 2017 2:10 AM

This smaller program shows the problem too :-

#addr=varptr Foo(0)

#x=peek(#addr)
#addr=#addr+1
#y=peek(#addr)

#BACKTAB(0)=((#x+"0")*8)+7    ' Should display "1"
#BACKTAB(2)=((#y+"0")*8)+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.



#238 nanochess OFFLINE  

nanochess

    River Patroller

  • Topic Starter
  • 4,794 posts
  • Coding something good
  • Location:Mexico, Mexico

Posted Tue Mar 28, 2017 9:26 AM

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! :thumbsup:



#239 DZ-Jay OFFLINE  

DZ-Jay

    Quadrunner

  • 9,838 posts
  • Triple-Stripe Mo' Bro
  • Location:NC, USA

Posted Wed Mar 29, 2017 3:29 AM

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! :thumbsup:

 

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

 

   -dZ.



#240 nanochess OFFLINE  

nanochess

    River Patroller

  • Topic Starter
  • 4,794 posts
  • Coding something good
  • Location:Mexico, Mexico

Posted Wed Mar 29, 2017 3:44 PM

 

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

 

   -dZ.

 

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



#241 DZ-Jay OFFLINE  

DZ-Jay

    Quadrunner

  • 9,838 posts
  • Triple-Stripe Mo' Bro
  • Location:NC, USA

Posted Wed Mar 29, 2017 4:09 PM

 
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?

#242 nanochess OFFLINE  

nanochess

    River Patroller

  • Topic Starter
  • 4,794 posts
  • Coding something good
  • Location:Mexico, Mexico

Posted Wed Mar 29, 2017 5:58 PM

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



#243 mmarrero OFFLINE  

mmarrero

    Space Invader

  • 45 posts

Posted Wed Mar 29, 2017 9:47 PM

Nanochess is correct. Dz-Jay's answer is what IntyBasic is doing! icon_smile.gif  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.



#244 GroovyBee OFFLINE  

GroovyBee

    Games Developer

  • 9,736 posts
  • Busy bee!
  • Location:North, England

Posted Thu Mar 30, 2017 2:53 AM

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.



#245 DZ-Jay OFFLINE  

DZ-Jay

    Quadrunner

  • 9,838 posts
  • Triple-Stripe Mo' Bro
  • Location:NC, USA

Posted Thu Mar 30, 2017 6:01 AM

Nanochess is correct. Dz-Jay's answer is what IntyBasic is doing! icon_smile.gif  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

 

:dunce:



#246 mmarrero OFFLINE  

mmarrero

    Space Invader

  • 45 posts

Posted Thu Mar 30, 2017 12:01 PM

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? icon_confused.gif

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



#247 GroovyBee OFFLINE  

GroovyBee

    Games Developer

  • 9,736 posts
  • Busy bee!
  • Location:North, England

Posted Wed May 24, 2017 11:31 AM

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.



#248 nanochess OFFLINE  

nanochess

    River Patroller

  • Topic Starter
  • 4,794 posts
  • Coding something good
  • Location:Mexico, Mexico

Posted Wed May 24, 2017 1:26 PM

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.

#249 dragonHunter OFFLINE  

dragonHunter

    Combat Commando

  • 2 posts

Posted Thu Aug 17, 2017 9:41 AM

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



#250 nanochess OFFLINE  

nanochess

    River Patroller

  • Topic Starter
  • 4,794 posts
  • Coding something good
  • Location:Mexico, Mexico

Posted Mon Aug 21, 2017 12:00 PM

 

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.







Also tagged with one or more of these keywords: Intellivision, IntyBASIC

0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users