Jump to content

Photo

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

Intellivision IntyBASIC

247 replies to this topic

#226 carlsson OFFLINE  

carlsson

    River Patroller

  • 4,219 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,790 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,631 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,631 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,342 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,342 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

  • 38 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,631 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,790 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,631 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,790 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,631 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

  • 38 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,790 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

  • 38 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,631 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.





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