+nanochess Posted January 10, 2019 Share Posted January 10, 2019 (edited) 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. 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 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 9 Quote Link to comment Share on other sites More sharing options...
DZ-Jay Posted January 10, 2019 Share Posted 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. 3 Quote Link to comment Share on other sites More sharing options...
+nanochess Posted January 16, 2019 Author Share Posted 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. 3 Quote Link to comment Share on other sites More sharing options...
DZ-Jay Posted January 17, 2019 Share Posted 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 Quote Link to comment Share on other sites More sharing options...
+nanochess Posted January 17, 2019 Author Share Posted 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. Quote Link to comment Share on other sites More sharing options...
DZ-Jay Posted January 17, 2019 Share Posted 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! Quote Link to comment Share on other sites More sharing options...
artrag Posted February 11, 2019 Share Posted 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 Quote Link to comment Share on other sites More sharing options...
artrag Posted February 11, 2019 Share Posted 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 1 Quote Link to comment Share on other sites More sharing options...
+nanochess Posted February 12, 2019 Author Share Posted 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. 1 Quote Link to comment Share on other sites More sharing options...
First Spear Posted February 16, 2019 Share Posted 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] Quote Link to comment Share on other sites More sharing options...
Kiwi Posted February 16, 2019 Share Posted 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. Quote Link to comment Share on other sites More sharing options...
+Lathe26 Posted February 16, 2019 Share Posted 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? Quote Link to comment Share on other sites More sharing options...
+nanochess Posted February 16, 2019 Author Share Posted 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. Quote Link to comment Share on other sites More sharing options...
DZ-Jay Posted February 17, 2019 Share Posted February 17, 2019 (edited) I hope this clears the matter. 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. Edited February 17, 2019 by DZ-Jay 1 Quote Link to comment Share on other sites More sharing options...
+nanochess Posted February 17, 2019 Author Share Posted 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 1 Quote Link to comment Share on other sites More sharing options...
+Lathe26 Posted February 17, 2019 Share Posted 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. Quote Link to comment Share on other sites More sharing options...
DZ-Jay Posted February 17, 2019 Share Posted 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. Quote Link to comment Share on other sites More sharing options...
First Spear Posted February 18, 2019 Share Posted February 18, 2019 (edited) (redacted) Edited February 19, 2019 by First Spear Quote Link to comment Share on other sites More sharing options...
artrag Posted March 2, 2019 Share Posted March 2, 2019 It seems that MUSIC.PLAYING is broken in v140 I've opened a issue on Github Quote Link to comment Share on other sites More sharing options...
artrag Posted March 2, 2019 Share Posted 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.... Quote Link to comment Share on other sites More sharing options...
artrag Posted March 2, 2019 Share Posted 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 Quote Link to comment Share on other sites More sharing options...
+nanochess Posted March 3, 2019 Author Share Posted 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. Quote Link to comment Share on other sites More sharing options...
artrag Posted March 3, 2019 Share Posted 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 Quote Link to comment Share on other sites More sharing options...
artrag Posted March 3, 2019 Share Posted March 3, 2019 for bosslife=0 to 127 gosub ms_loop gosub boss_explode gosub warp_anim next This is the calling loop... Quote Link to comment Share on other sites More sharing options...
intvnut Posted March 3, 2019 Share Posted March 3, 2019 (edited) 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 2 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.