Jump to content

Photo

IntyBASIC compiler v1.4: reloaded with new features


17 replies to this topic

#1 nanochess ONLINE  

nanochess

    Processorus Polyglotus

  • 5,797 posts
  • Coding something good
  • Location:Mexico City

Posted Thu Jan 10, 2019 2:35 PM

Hi guys.

After being slowly updated in the background while I do other things, finally I considered that enough changes have been made to make it worthwhile of another release. :grin:

So I proudly present IntyBASIC compiler v1.4.0 with more optimization in code generation. :)

 

If you're updating your development environment, remember to not only copy the compiler but also the prologue and epilogue files because changes in music format. ;)

 

This release is rather special for me because it marks 5 years since the publishing of the first IntyBASIC compiler :party: and still there are things that I would like to implement!!!

Other changes, enhancements and fixes in v1.4:

  • Tracker allows playing 8 channels of music (using ECS PSG)
  • Now detects failure of flow control when using GOTO to jump wrongly between procedures.
  • Detects wrong flow of control (GOTO to PROCEDURE or GOSUB to non-PROCEDURE)
  • Name mangling for assembler now uses original names, easing assembler interface.
  • Support for local labels (using period character before a label, uses last global label as prefix)
  • Added MUSIC GOSUB, MUSIC RETURN, MUSIC VOLUME and MUSIC SPEED.
  • Added contrib/accel.bas it shows how to move sprites by fractions of pixel (contributed by intvnut)
  • Added samples/rain.bas to show animate rain and moving trees.
  • Added samples/pumpkin_master.bas as another example of a fully working game.
  • VOICE INIT now "shuts up" the Intellivision (contributed by intvnut) and the initialization is done in automatic form at start of program.
  • FLASH INIT SIZE to choose Flash memory size.
  • Allows constants in DATA PACKED.
  • Added ON expr FAST to avoid two instructions.
  • Generates warnings for AND/OR/XOR and small operators non-parenthesized.
  • Now direct CONT1, CONT2, CONT3 and CONT4 generate 8-bit results.
  • Solved bug where IF CONT.B0 THEN wouldn't work, also ABS and SGN.
  • Compatibility with Tutorvision consoles.
  • Solved bug in PLAY SIMPLE (always was processed as NO DRUMS)
  • Added new IntyColor flags to select the block size of GRAM definition per frame, and to process 8x16 bitmaps for sprites.
  • Added ECS.AVAILABLE flag.
  • Allows --cc3 option to change address of RAM memory (for Keyboard Component compatibility)

Enjoy it!

Attached Files



#2 DZ-Jay OFFLINE  

DZ-Jay

    Quadrunner

  • 12,032 posts
  • The P-Machinery AGE is almost here!
  • Location:NC, USA

Posted Thu Jan 10, 2019 2:41 PM

An IntyBASIC SDK release will follow early next week, which will upgrade automatically all necessary files, if you already are using the SDK.

:thumbsup:

#3 nanochess ONLINE  

nanochess

    Processorus Polyglotus

  • Topic Starter
  • 5,797 posts
  • Coding something good
  • Location:Mexico City

Posted Wed Jan 16, 2019 12:59 PM

Just noticed a small bug in local labels when using ON GOTO or ON GOSUB, you should put a space between commas and local label.

Given it's so innocuous I'll save it for next release.

#4 DZ-Jay OFFLINE  

DZ-Jay

    Quadrunner

  • 12,032 posts
  • The P-Machinery AGE is almost here!
  • Location:NC, USA

Posted Thu Jan 17, 2019 4:40 AM

Just noticed a small bug in local labels when using ON GOTO or ON GOSUB, you should put a space between commas and local label.

Given it's so innocuous I'll save it for next release.

 

I'm not clear what you mean.  Is it like this?

ON XYZ GOTO label0 , label1 , label2 , label3


#5 nanochess ONLINE  

nanochess

    Processorus Polyglotus

  • Topic Starter
  • 5,797 posts
  • Coding something good
  • Location:Mexico City

Posted Thu Jan 17, 2019 7:59 AM


 
I'm not clear what you mean.  Is it like this?

ON XYZ GOTO label0 , label1 , label2 , label3

Space after the comma is enough. Thanks for bringing it to my attention.

#6 DZ-Jay OFFLINE  

DZ-Jay

    Quadrunner

  • 12,032 posts
  • The P-Machinery AGE is almost here!
  • Location:NC, USA

Posted Thu Jan 17, 2019 9:52 AM

Space after the comma is enough. Thanks for bringing it to my attention.


I thought so, I just wanted to be sure. Thanks! :)

#7 artrag ONLINE  

artrag

    Stargunner

  • 1,212 posts

Posted Mon Feb 11, 2019 3:15 PM

I'm still trying to make Deep Zone work in v140... Thanks to Joe Zbiciak now I'm able to compile the game again, but still I have problems on sfx and on credits.

Oscar are the following segments of code fully equivalent ?

 

V140

label_SFX0:	PROC
	BEGIN
	;[18] 	nn = (varptr sfx0_v(0)-varptr sfx0_t#(0))-sfxstep
	SRCFILE "isrsfx.bas",18
	MVII #(label_SFX0_V-label_SFX0_T&) AND $FFFF,R3
	SUB var_SFXSTEP,R0
	MVO R0,var_NN
	;[19] 	sound	2,sfx0_t#(nn),sfx0_v(nn)
	SRCFILE "isrsfx.bas",19
	MVII #label_SFX0_T&,R3
	ADD var_NN,R3
	MVI@ R3,R0
	MVO R0,498
	SWAP R0
	MVO R0,502
	MVII #label_SFX0_V,R3
	ADD var_NN,R3
	MVI@ R3,R0
	MVO R0,509
	;[20] 	sound	4,1,$38
	SRCFILE "isrsfx.bas",20
	MVII #1,R0
	MVO R0,505
	MVII #56,R0
	MVO R0,504
	;[21] 	sfxstep = sfxstep-1
	SRCFILE "isrsfx.bas",21
	MVI var_SFXSTEP,R0
	DECR R0
	MVO R0,var_SFXSTEP
	;[22] 	end
	SRCFILE "isrsfx.bas",22
	RETURN
	ENDP

V129

Q201:	PROC
	BEGIN
	;[18] 	nn = (varptr sfx0_v(0)-varptr sfx0_t#(0))-sfxstep
	SRCFILE "isrsfx.bas",18
	MVII #Q330,R0
	MVII #Q331,R1
	SUBR R1,R0
	SUB V96,R0
	MVO R0,V37
	;[19] 	sound	2,sfx0_t#(nn),sfx0_v(nn)
	SRCFILE "isrsfx.bas",19
	MOVR R1,R3
	ADD V37,R3
	MVI@ R3,R0
	MVO R0,498
	SWAP R0
	MVO R0,502
	MVII #Q330,R3
	ADD V37,R3
	MVI@ R3,R0
	MVO R0,509
	;[20] 	sound	4,1,$38
	SRCFILE "isrsfx.bas",20
	MVII #1,R0
	MVO R0,505
	MVII #56,R0
	MVO R0,504
	;[21] 	sfxstep = sfxstep-1
	SRCFILE "isrsfx.bas",21
	MVI V96,R0
	DECR R0
	MVO R0,V96
	;[22] 	end
	SRCFILE "isrsfx.bas",22
	RETURN
	ENDP



#8 artrag ONLINE  

artrag

    Stargunner

  • 1,212 posts

Posted Mon Feb 11, 2019 3:20 PM

I'm not sure but this seems a bug in the way varptr expressions are evaluated

 

This code 

	;[47] 	nn = (varptr sfx2_v(0)-varptr sfx2_n(0))-sfxstep
	SRCFILE "isrsfx.bas",47
	MVII #(label_SFX2_V-label_SFX2_N) AND $FFFF,R3
	SUB var_SFXSTEP,R0
	MVO R0,var_NN

should be

	;[47] 	nn = (varptr sfx2_v(0)-varptr sfx2_n(0))-sfxstep
	SRCFILE "isrsfx.bas",47
	MVII #(label_SFX2_V-label_SFX2_N) AND $FFFF,R0
	SUB var_SFXSTEP,R0
	MVO R0,var_NN



#9 nanochess ONLINE  

nanochess

    Processorus Polyglotus

  • Topic Starter
  • 5,797 posts
  • Coding something good
  • Location:Mexico City

Posted Tue Feb 12, 2019 2:26 PM

 

I'm not sure but this seems a bug in the way varptr expressions are evaluated

 

 

 

Indeed there was a bug exactly in that specific case. I've updated the Git.



#10 First Spear OFFLINE  

First Spear

    Stargunner

  • 1,369 posts
  • Location:Somewhere in Uptown

Posted Fri Feb 15, 2019 8:39 PM

Can someone show an example that uses the origin_width parameter in SCREEN? I do not understand where it should or should not be used.

 

Thanks.

SCREEN label[,origin_offset,target_offset,cols,rows]
SCREEN label[,origin_offset,target_offset,cols,rows,origin_width]


#11 Kiwi OFFLINE  

Kiwi

    Stargunner

  • 1,658 posts

Posted Sat Feb 16, 2019 2:48 AM

In the sample folder, look in landscape.bas.  It's used for screen data table wider than 20 pixel, usually used with scrolling. 



#12 Lathe26 OFFLINE  

Lathe26

    River Patroller

  • 3,820 posts

Posted Sat Feb 16, 2019 1:17 PM

In the sample folder, look in landscape.bas.  It's used for screen data table wider than 20 pixel, usually used with scrolling. 

 

I don't think that comes across clearly in the manual.  I couldn't figure out what that last parameter did.  Also, does it work if the table is narrower than 20 tiles or does some kind of weird wrap-around of the data occur?



#13 nanochess ONLINE  

nanochess

    Processorus Polyglotus

  • Topic Starter
  • 5,797 posts
  • Coding something good
  • Location:Mexico City

Posted Sat Feb 16, 2019 2:27 PM

 

Can someone show an example that uses the origin_width parameter in SCREEN? I do not understand where it should or should not be used.

 

Thanks.

SCREEN label[,origin_offset,target_offset,cols,rows]
SCREEN label[,origin_offset,target_offset,cols,rows,origin_width]

 

 

In the sample folder, look in landscape.bas.  It's used for screen data table wider than 20 pixel, usually used with scrolling. 

 

 

 

I don't think that comes across clearly in the manual.  I couldn't figure out what that last parameter did.  Also, does it work if the table is narrower than 20 tiles or does some kind of weird wrap-around of the data occur?

 

The SCREEN statement assumes that the origin data is a bidimensional array as well as the target array that is always screen.

 

So, we can copy any rectangular area from the origin data into the screen.

 

We can make a little window in screen where the rectangular area can be copied making us to watch only a little rectangle each time.

 

Notice that this is easier in Background/Foreground mode than Color Stack mode because the bit 13 disrupts the sequence of color stack.

' This works having a standard screen of 160x96 pixels as input.
' Let us draw into a 5 x 8 area located at center (row 4, column 9)
 
FOR y = 0 TO 4
  FOR x = 0 TO 15
    FOR c = 0 TO 10: WAIT: NEXT c
    SCREEN screen_cards, y * 20 + x, 4 * 20 + 9, 5, 8, 20
  NEXT x
NEXT y

Notice I've put the 20 parameter at the end, this means the width of the origin bidimensional array.

 

Change it to 19 or 21 to disrupt the source copy but it still is a nice rectangle in screen. Also notice that the origin offset must be in words, it would me more elegant to put source X,Y but it would need a multiplication, you need to do the multiplication by yourself, so it means y * 20 + x.

 

Now this is excellent for a standard bitmap of screen size, but what happens when the bitmap is smaller or wider?

 

If our input bitmap sizes to 80x80 (for example), then the sixth parameter should be 80 / 8 = 10 and the second parameter now should be y * 10 + x

 

If our input bitmap sizes to 320x80 (for example), then the sixth parameter should be 320 / 8 = 40. This is where the SCREEN statement shines as a mean to show parts of a bigger bitmap in screen or to fill after scrolling with the new part to be shown of image. And of course the second parameter now should be y * 40 + x

 

In a perfect world all sizes should be expressed and the SCREEN statement would clip the rectangles but these are uncommon cases and it leaves to the user to be sure he/she is putting the right arguments.

 

I hope this clears the matter. :)



#14 DZ-Jay OFFLINE  

DZ-Jay

    Quadrunner

  • 12,032 posts
  • The P-Machinery AGE is almost here!
  • Location:NC, USA

Posted Sun Feb 17, 2019 7:55 AM

I hope this clears the matter. :)

 

Sorry, but I think I am even more confused than before! :dunce:

 

What I think I understand is that, the matrix to copy is by default expected to be the same size as the screen (20x12), but if you want to just copy from a smaller or larger matrix, you use the sixth parameter to indicate the adjusted width.

 

If that is actually correct, then I think the explanation in the manual was clear, because that's what I understood.  Your explanation above just threw me off completely.  :?

 

I'm really not the target audience for this, so if others got it, then I guess your explanation is sufficient. :thumbsup:

 

    -dZ.


Edited by DZ-Jay, Sun Feb 17, 2019 8:00 AM.


#15 nanochess ONLINE  

nanochess

    Processorus Polyglotus

  • Topic Starter
  • 5,797 posts
  • Coding something good
  • Location:Mexico City

Posted Sun Feb 17, 2019 1:05 PM

 

Sorry, but I think I am even more confused than before! :dunce:

 

What I think I understand is that, the matrix to copy is by default expected to be the same size as the screen (20x12), but if you want to just copy from a smaller or larger matrix, you use the sixth parameter to indicate the adjusted width.

 

If that is actually correct, then I think the explanation in the manual was clear, because that's what I understood.  Your explanation above just threw me off completely.  :?

 

I'm really not the target audience for this, so if others got it, then I guess your explanation is sufficient. :thumbsup:

 

    -dZ.

 

That is actually correct. You understood the first time :)



#16 Lathe26 OFFLINE  

Lathe26

    River Patroller

  • 3,820 posts

Posted Sun Feb 17, 2019 2:33 PM

I think I follow at well. It would be good to add an ASCII art diagram to the manual to be extra clear.

#17 DZ-Jay OFFLINE  

DZ-Jay

    Quadrunner

  • 12,032 posts
  • The P-Machinery AGE is almost here!
  • Location:NC, USA

Posted Sun Feb 17, 2019 4:11 PM

 

That is actually correct. You understood the first time :)

 

Cool! :)

 

 

I think I follow at well. It would be good to add an ASCII art diagram to the manual to be extra clear.

 

Yes, that might help.  Something like what the STIC.TXT uses to show the difference between the "object area" and "screen area."

 

  -dZ.



#18 First Spear OFFLINE  

First Spear

    Stargunner

  • 1,369 posts
  • Location:Somewhere in Uptown

Posted Mon Feb 18, 2019 4:56 PM

(redacted)


Edited by First Spear, Tue Feb 19, 2019 8:32 AM.





0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users