IntyBASIC compiler v1.4.2: reloaded with new features

+nanochess · January 10, 2019

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

Changes, enhancements and fixes in v1.4.2:

Added escape sequence \\ for inverse bar inside strings.
Limited numeric escape sequences to 3 digits.
Added SCREEN ENABLE/DISABLE for enabling/disabling video.
Generated metavariable jlp wasn't 3 when using FLASH.
Clarifications in manual (maximum number of GRAM that can be defined per video frame).

Changes, enhancements and fixes in v1.4.1:

Added BITMAP NORMAL, BITMAP INVERSE and BITMAP MIRROR_X to ease reusing BITMAP statements in Color Stack mode.
Optimizes POKE to direct address with a single MVO.
Solved bug in local labels preceded with comma, it required a space.
Solved bug compiling nn = (varptr sfx2_v(0)-varptr sfx2_n(0))-sfxstep
Solved bug in MUSIC.PLAYING (relative to new music format)
Solved bug in music player because new _ntsc interpretation.
Solved crash bug in drums for ECS side of music player.

Other changes, enhancements and fixes in v1.4.0:

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!

intybasic_compiler_v1.4.0.zip

intybasic_compiler_v1.4.1.zip

intybasic_compiler_v1.4.2.zip

Edited August 20, 2020 by nanochess

+DZ-Jay · January 10, 2019

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

:thumbsup:

+nanochess · January 16, 2019

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.

+DZ-Jay · January 17, 2019

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

+nanochess · January 17, 2019

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.

+DZ-Jay · January 17, 2019

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

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

artrag · February 11, 2019

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

artrag · February 11, 2019

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

+nanochess · February 12, 2019

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.

First Spear · February 16, 2019

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]

Kiwi · February 16, 2019

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

+Lathe26 · February 16, 2019

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?

+nanochess · February 16, 2019

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.

+DZ-Jay · February 17, 2019

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 February 17, 2019 by DZ-Jay

+nanochess · February 17, 2019

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

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.

-dZ.

That is actually correct. You understood the first time

+Lathe26 · February 17, 2019

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

+DZ-Jay · February 17, 2019

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.

First Spear · February 18, 2019

(redacted)

Edited February 19, 2019 by First Spear

artrag · March 2, 2019

It seems that MUSIC.PLAYING is broken in v140

I've opened a issue on Github

artrag · March 2, 2019

Moreover this segment of code stopped working properly....

boss_explode: procedure
	if (defineflag=0) then
		DEFINE DEF00,6,VARPTR boss_explosion(scale(e_tm)*24+24*8*(bosslife/16))
		defineflag = 1
	elseif (defineflag=1) then
		DEFINE ALTERNATE DEF00,6,VARPTR boss_explosion(scale(e_tm)*24+24*8*(bosslife/16))
	end if
	gosub sfxint4
	SPRITE 4,r+0*8+VISIBLE+HIT-10,c+DOUBLEY, SPR00+0*8 + #color_loop(bosslife and 3)
	SPRITE 5,r+1*8+VISIBLE+HIT-10,c+DOUBLEY, SPR00+2*8 + #color_loop(bosslife and 3)
	SPRITE 6,r+2*8+VISIBLE+HIT-10,c+DOUBLEY, SPR00+4*8 + #color_loop(bosslife and 3)
	end
#color_loop:
	data SPR_ORANGE,SPR_YELLOW,SPR_WHITE,SPR_YELLOW

for higher values of bosslife... I suspect it could be an issue in DEFINE (or in DEFINE + VARPTR).

What I get now for higher values of bosslife is a filled box of FFFFh where before I had the correct frames....

artrag · March 2, 2019

ok, opening the LST files now I think that the problem is in the way the math in VARPTR is expaneded

In V129 the expression scale(e_tm)*24+24*8*(bosslife/16) is translated as:

                                	;[2250] 		DEFINE ALTERNATE DEF00,6,VARPTR boss_explosion(scale(e_tm)*24+24*8*(bosslife/16))
                                	SRCFILE "dzgorf.bas",2250
EBDB:F 01C0                     	CLRR R0
EBDC:F 0240 0107                	MVO R0,_gram2_target
EBDE:F 02B8 0006                	MVII #6,R0
EBE0:F 0240 0108                	MVO R0,_gram2_total
EBE2:F 02BB A5CB                	MVII #Q133,R3
EBE4:F 02C3 014E                	ADD V49,R3
EBE6:F 0298                     	MVI@ R3,R0
EBE7:F 02BC 0018                	MVII #24,R4
EBE9:F 0240 9F86                	MVO R0,40838
EBEB:F 0244 9F87                	MVO R4,40839
EBED:F 0280 9F8E                	MVI 40846,R0
EBEF:F 0281 012F                	MVI V51,R1
EBF1:F 03F9 0080                	XORI #128,R1
EBF3:F 0339 0080                	SUBI #128,R1
EBF5:F 0065                     	SLR R1,2
EBF6:F 0065                     	SLR R1,2
EBF7:F 02BC 00C0                	MVII #192,R4
EBF9:F 0241 9F86                	MVO R1,40838
EBFB:F 0244 9F87                	MVO R4,40839
EBFD:F 0281 9F8E                	MVI 40846,R1
EBFF:F 00C8                     	ADDR R1,R0
EC00:F 02B9 EF31                	MVII #Q483,R1
EC02:F 00C8                     	ADDR R1,R0
EC03:F 0240 033D                	MVO R0,_gram2_bitmap

Instead in v140 it gives:

                                	;[2250] 		DEFINE ALTERNATE DEF00,6,VARPTR boss_explosion(scale(e_tm)*24+24*8*(bosslife/16))
                                	SRCFILE "dzgorf.bas",2250
EB6D:F 01C0                     	CLRR R0
EB6E:F 0240 0107                	MVO R0,_gram2_target
EB70:F 02B8 0006                	MVII #6,R0
EB72:F 0240 0108                	MVO R0,_gram2_total
EB74:F 02BB A5C9                	MVII #label_SCALE,R3
EB76:F 02C3 0150                	ADD var_E_TM,R3
EB78:F 0298                     	MVI@ R3,R0
                                ;	MULT R0,R4,24
                                	;
EB79:F 004C                                     SLL     R0,  2
EB7A:F 0048                                     SLL     R0,  1
EB7B:F 0084                                     MOVR    R0,  R4
EB7C:F 0048                                     SLL     R0,  1
EB7D:F 00E0                                     ADDR    R4,  R0
EB7E:F 0281 0131                	MVI var_BOSSLIFE,R1
EB80:F 03F9 0080                	XORI #128,R1
EB82:F 0339 0080                	SUBI #128,R1
EB84:F 0065                     	SLR R1,2
EB85:F 0065                     	SLR R1,2
EB86:F 02BC 00C0                	MVII #192,R4
EB88:F 0241 9F86                	MVO R1,40838
EB8A:F 0244 9F87                	MVO R4,40839
EB8C:F 0281 9F8E                	MVI 40846,R1
EB8E:F 00C8                     	ADDR R1,R0
EB8F:F 02B9 EEB0                	MVII #label_BOSS_EXPLOSION,R1
EB91:F 00C8                     	ADDR R1,R0
EB92:F 0240 033D                	MVO R0,_gram2_bitmap

So the problem could be probably in the way MULT R0,R4,24 is expanded

+nanochess · March 3, 2019

Both snippets of code should behave the same way.

Are you sure your bosslife variable doesn't exceed the value 127? because it's being read as a signed 8-bits variable.

artrag · March 3, 2019

I have pasted also the calling loop in github.com and the for on boss life ends to 127

Anyway, why in v140 you do not use hw multiplications? I've used --jlp for both

artrag · March 3, 2019

for bosslife=0 to 127

gosub ms_loop

gosub boss_explode

gosub warp_anim

intvnut · March 3, 2019

I have pasted also the calling loop in github.com and the for on boss life ends to 127

Anyway, why in v140 you do not use hw multiplications? I've used --jlp for both

The hardware multiply isn't always faster or smaller than a sequence of shift/adds, particularly for constant values. Compare these two sequences, annotated with cycle costs:

.


MVII #24,R4    ;  8
MVO R0,40838   ; 11
MVO R4,40839   ; 11
MVI 40846,R0   ; 10
               ;---
               ; 40

.

versus

.

SLL     R0,  2    ;  8
SLL     R0,  1    ;  6
MOVR    R0,  R4   ;  6
SLL     R0,  1    ;  6
ADDR    R4,  R0   ;  6
                  ;---
                  ; 32

.

The second one is 20% faster and 37.5% smaller (5 words rather than 8 ). I suspect most, if not all, of the multiply-by-constant macros are faster and smaller than using JLP's accelerator. Those MVOs are expensive. JLP helps more when doing larger multiplications, or multiplies where both multiplicands aren't known at compile time.

Edited March 3, 2019 by intvnut

IntyBASIC compiler v1.4.2: reloaded with new features

Recommended Posts

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Join the conversation

Recently Browsing 0 members