+OLD CS1 Posted January 9, 2019 Share Posted January 9, 2019 Am I to understand that this latest release is producing smaller or faster-running compiled code? Quote Link to comment Share on other sites More sharing options...
LASooner Posted January 9, 2019 Share Posted January 9, 2019 I believe the speed increase he mentioned is the compiler itself not the resulting compiled code 1 Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted January 9, 2019 Author Share Posted January 9, 2019 (edited) I believe the speed increase he mentioned is the compiler itself not the resulting compiled code That is correct. Now, with CPU Overdrive, the faster compiler, a cross assembler such as Asm99, and the assembly language loader, you can make changes to the XB program and test them very quickly. Edited January 9, 2019 by senior_falcon 3 Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted January 11, 2019 Author Share Posted January 11, 2019 Good progress is happening with the CALL SUBPROGRAM in the compiler. The compiler does not produce proper code for this, but I can correct the source code file to the proper syntax. The runtime routines are written for this and, as expected, they work fine. I can call a named subprogram, pass values into the subprogram, change the values and pass them back to the calling program. Amazingly,it almost worked perfectly the first time. I had two INCs that should have been INCT. 2 Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted January 14, 2019 Author Share Posted January 14, 2019 We all know the saying, "The sooner you start to code the longer the job will take." I think the opposite is true as well: "The longer you take to start coding, the less time the job will take." For 25 years I have avoided even trying to add named subprograms to the compiler because it seemed impossibly difficult. It turned out to be fairly straightforward, and It all works just like in XB. I thought having independent variables in the subprograms would be the hardest part but it turned out to need just a couple lines of code. Also there is no need for a second stack; I use the same stack used by GOSUB. Maybe if I had waited a hundred years it could have been done in 5 minutes or even less. There is one step remaining: 10 CALL SUBTEST(A,(B),C) where the parentheses keep B from being updated. I can see a couple of ways to do this and am mulling over the best approach. But even if that doesn't work out, you can get the same result with CALL SUBTEST(A,B+0,C) which works the same compiled and in XB. 8 Quote Link to comment Share on other sites More sharing options...
+OLD CS1 Posted January 14, 2019 Share Posted January 14, 2019 "An object at rest cannot be stopped!" -- The Evil Midnight Bomber What Bombs at Midnight 1 Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted January 16, 2019 Author Share Posted January 16, 2019 Here's a simple question. I think I know the answer, but want to be sure. It involves MOVing at an odd address: MOV @>F001,R1 This moves the word at >F000 into R1. Is this always true? Can it ever move two bytes at >F001 and >F002 into R1 or the word at >F002? Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted January 16, 2019 Share Posted January 16, 2019 Here's a simple question. I think I know the answer, but want to be sure. It involves MOVing at an odd address: MOV @>F001,R1 This moves the word at >F000 into R1. Is this always true? Can it ever move two bytes at >F001 and >F002 into R1 or the word at >F002? I am nearly certain that the MOV instruction insures an even address boundary, likely by ANDing with >FFFE. Edit: Actually, this is probably due to the fact that addressing is performed on a word basis, which, I suppose, could be thought of as the aforementioned ANDing. ...lee Quote Link to comment Share on other sites More sharing options...
+mizapf Posted January 16, 2019 Share Posted January 16, 2019 Here's a simple question. I think I know the answer, but want to be sure. It involves MOVing at an odd address: MOV @>F001,R1 This moves the word at >F000 into R1. Is this always true? Can it ever move two bytes at >F001 and >F002 into R1 or the word at >F002? The 9900 has only 15 address bits (A0-A14), so the TMS9900 can only select even addresses. It is technically impossible for it to reach an odd address. The byte operations work like the word operations, but select the desired byte inside the ALU. Quote Link to comment Share on other sites More sharing options...
+TheBF Posted January 16, 2019 Share Posted January 16, 2019 I am nearly certain that the MOV instruction insures an even address boundary, likely by ANDing with >FFFE. Edit: Actually, this is probably due to the fact that addressing is performed on a word basis, which, I suppose, could be thought of as the aforementioned ANDing. ...lee I am a big fan of asking the machine. How could I do that quickly... hmmm... Forth maybe? In CAMEL99 Forth the store operator is: MOV *R6+,*R4 So we can test this at the console. Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted January 16, 2019 Author Share Posted January 16, 2019 (edited) Excellent! This is handy as a flag when passing values to and from subprogram. Set the address odd if you don't want the variable to be updated when returning from the subprogram. When passing a value to the subprogram you can just ignore that it is odd and it will be passed normally. When passing a value back you can check whether it is odd and if so then don't pass it. I guess the other question is whether any emulators do not behave this way. Edited January 16, 2019 by senior_falcon Quote Link to comment Share on other sites More sharing options...
Opry99er Posted January 16, 2019 Share Posted January 16, 2019 Heh.... that's pretty cool. Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted January 21, 2019 Author Share Posted January 21, 2019 (edited) Here is the latest and probably the final version of the XB Game Developers Package. This version is called "Hondarrabi". (I went directly from GRECHETTOBETA to HONDARRABIBETA) The most important addition is that named subprograms are now fully supported. Now almost everything in XB can be compiled, with the exception of DEF and trig functions. I will leave this in beta for testing for maybe 3 months before making it the final release. Find the bugs now, before I lose interest in this! Once any bugs in this have been found and fixed, I hope to use it as the basis for a similar compiler package based on The Missing Link. (Edit)-You should change line 230 in COMPILER to be a comment - i.e. insert an exclamation point at the beginning. Doing this omits the option to use the original TI BASIC runtime routines. Most people will not want that option and so this will save you one keypress. (Edit)-reuploaded with changed line 230 and revised docs. HONDARRABIBETA.zip Edited January 21, 2019 by senior_falcon 4 Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted January 21, 2019 Author Share Posted January 21, 2019 (edited) I forgot to add something to the manual: When using subprograms, the compiler will shorten the name to the first 6 letters. You can use longer names as long as the first six letters are not duplicates of another subprogram. CALL UPDATEWHITE and CALL UPDATEBLACK would not compile properly (the assembler gives an error for duplicate definition), but CALL UPDATWHITE and CALL UPDATBLACK would be fine. Edited January 21, 2019 by senior_falcon Quote Link to comment Share on other sites More sharing options...
Opry99er Posted January 21, 2019 Share Posted January 21, 2019 Awesome! Quote Link to comment Share on other sites More sharing options...
Tursi Posted January 21, 2019 Share Posted January 21, 2019 Excellent! This is handy as a flag when passing values to and from subprogram. Set the address odd if you don't want the variable to be updated when returning from the subprogram. When passing a value to the subprogram you can just ignore that it is odd and it will be passed normally. When passing a value back you can check whether it is odd and if so then don't pass it. I guess the other question is whether any emulators do not behave this way. I think they are all correct. Classic99 had a bug a few years ago with Bigfoot which loads an odd value into the Program Counter, and it caused issues when it didn't access an even address anyway. I don't know if non-9900 CPUs act that way though... Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted January 22, 2019 Author Share Posted January 22, 2019 (edited) Here is an undocumented feature of the compiler. Normally in XB, when you call a subprogram the variables are updated upon return from the subprogram. You can block this by enclosing them in parentheses like so: CALL SUBTEST(A,(B),C) A and C will be updated but not B. For once the compiler is less finicky than XB. Instead of returning with SUBEND or SUBEXIT you can go back with RETURN. This simply moves on to the next line of code without updating any of the variables. The advantage doing it this way is that there is less overhead, so it it is faster. The disadvantage is that you cannot test it in XB. You'd have to use parentheses and make this change when done programming and testing. In theory this could help with speed, but I doubt it would be very noticeable. Edited January 22, 2019 by senior_falcon Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted January 23, 2019 Author Share Posted January 23, 2019 Even though I said I was done with this, I just found a performance boosting modification. The compiler mimics XB in that if you CALL JOYST and then CALL KEY, both XB and the compiler will do the KSCAN routine twice. The modification is this: CALL KEY will look back to see what the previous instruction was. If it was CALL JOYST then it bypasses the second KSCAN and reports the key values found when JOYST was performed. This should lead to noticeably better keyboard response. JOYST has to be first, immediately followed by KEY and the key unit used by JOYST is what is used for KEY regardless of what value was actually passed. So for instance, if you had: 10 CALL JOYST(1,X,Y)::CALL KEY(5,K,S) the key value reported would actually be for KEY(1,K,S). If this is a problem, just insert an instruction between JOYST and KEY or do KEY first. 2 Quote Link to comment Share on other sites More sharing options...
+OLD CS1 Posted January 23, 2019 Share Posted January 23, 2019 Even though I said I was done with this, I just found a performance boosting modification. The compiler mimics XB in that if you CALL JOYST and then CALL KEY, both XB and the compiler will do the KSCAN routine twice. The modification is this: CALL KEY will look back to see what the previous instruction was. If it was CALL JOYST then it bypasses the second KSCAN and reports the key values found when JOYST was performed. This should lead to noticeably better keyboard response. JOYST has to be first, immediately followed by KEY and the key unit used by JOYST is what is used for KEY regardless of what value was actually passed. So for instance, if you had: 10 CALL JOYST(1,X,Y)::CALL KEY(5,K,S) the key value reported would actually be for KEY(1,K,S). If this is a problem, just insert an instruction between JOYST and KEY or do KEY first. Ooooo... I will look at my reusable input routine to see if I can take advantage of this. Quote Link to comment Share on other sites More sharing options...
+OLD CS1 Posted January 23, 2019 Share Posted January 23, 2019 Does CALL KEY have to immediately follow CALL JOYST? (Expanded further below...) 1 Quote Link to comment Share on other sites More sharing options...
Opry99er Posted January 23, 2019 Share Posted January 23, 2019 Very interesting! Quote Link to comment Share on other sites More sharing options...
RXB Posted January 23, 2019 Share Posted January 23, 2019 (edited) Does CALL KEY have to immediately follow CALL JOYST? GPL IN XB USES A ROUTINE IN GPL called SCAN. In both JOYST and KEY both use SCAN. Thus in RXB 2019 I have a routines CALL JOYLOCATE and CALL JOYMOTION. Just finished manual for RXB 2019: JOYST subprogram PAGE J1 ------------------------------------------------------------- Format CALL JOYST(key-unit,x-return,y-return[,...]) Description See EXTENDED BASIC MANUAL page 108 Except for adding auto repeat there is no changes to JOYST Programs The program on the right will | >100 CALL CLEAR illustrate a use of JOYST | >110 CALL SPRITE(#1,33,5,96,1 subprogram. It creates two | 28,#2,42,2,96,128) sprites and then moves them | >120 CALL JOYST(1,X1,Y1,2,X2, around according to the input | Y2) from the joysticks. | >130 CALL MOTION(#1,-Y1,X1,#2 Two players with the same | -Y2,X2) input speed and motion. | >140 GOTO 120 | JOYLOCATE subprogram PAGE J2 ------------------------------------------------------------- Format CALL JOYLOCATE(key-unit,x-return,y-return, row-index,column-index,#sprite,dot-row, dot-column) CALL JOYLOCATE(key-unit,x-return,y-return, row-index,column-index,#sprite,dot-row, dot-column),key-return-variable) CALL JOYLOCATE(key-unit,x-return,y-return, row-index,column-index,#sprite,dot-row, dot-column),key-return-variable) GOTO line-number Description JOYLOCATE combines commands JOYST, KEY, LOCATE and a built in IF fire-button GOTO line-number. Keyboard key or fire button is in key-return-variable, but only joystick fire or key Q is used for GOTO line-number. As seen above line number option can be left out or furter key-return-variable can be left out too. Programs Clear screen. | >100 CALL CLEAR Set character for use. | >110 CALL CHAR(143,"FFFFFFFFFF | FFFFFF") Set up a sprite to use. | >120 CALL SPRITE(#1,143,2,9,19 | 0) Look for joystick movement | >130 CALL JOYLOCATE(1,X,Y,8,8, and move it or ignore. | #1,R,C,K) GOTO 160 Show variables on screen. | >140 PRINT X;Y;K;R;C Loop forever | >150 GOTO 130 Show variables on screen. | >160 PRINT X;Y;K;R;C;"FIRE" Loop forever | 170 GOTO 130 JOYMOTION subprogram PAGE J3 ------------------------------------------------------------- Format CALL JOYMOTION(key-unit,x-return,y-return, #sprite,row-index,column-index) CALL JOYMOTION(key-unit,x-return,y-return, #sprite,row-index,column-index, key-return-variable) CALL JOYMOTION(key-unit,x-return,y-return, #sprite,row-index,column-index, key-return-variable) GOTO line-number Description JOYMOTION combines commands JOYST, KEY, MOTION and a built in IF fire-button GOTO line-number. Keyboard key or fire button is in key-return-variable, but only joystick fire or key Q is used for GOTO line-number. As seen above line number option can be left out or furter key-return-variable can be left out too. Programs Clear screen. | >100 CALL CLEAR Set character for use. | >110 CALL CHAR(143,"FFFFFFFFFF | FFFFFF") Set up a sprite to use. | >120 CALL SPRITE(#1,143,2,9,19 | 0,20,0) Look for joystick movement | >130 CALL JOYMOTION(1,X,Y,#1,9 and move it or ignore. | ,9,K) GOTO 160 Show variables on screen. | >140 PRINT X;Y;K Loop forever | >150 GOTO 130 Show variables on screen. | >160 PRINT X;Y;K;"FIRE" Loop forever | 170 GOTO 130 KEY subprogram PAGE K1 ------------------------------------------------------------- Format CALL KEY(key-unit,return-variable, status-variable[,...]) CALL KEY(string,key-unit,return-variable, status-variable[,...]) CALL KEY(string-variable,key-unit,return- variable,status-variable[,...]) Description See EXTENDED BASIC MANUAL page 109 RXB has added auto repeat features. Strings or string variables can now be added to KEY to lock out any other keys. The strings can be empty or up to 255 in length. The string function halts program execution unlike a normal key routine similar to ACCEPT or INPUT do. Programs This line scans both joysticks| >100 CALL JOYST(1,X,Y,2,XX,YY) This line scans both of the | >110 CALL KEY(1,F,S,2,FF,SS) fire buttons & split keyboard.| | Try this for fun. | >CALL KEY(CHR$(2),0,K,S) (HINT: FCTN 4) | | Add this line to programs. | >100 CALL KEY("YNyn",0,K,S) | Suspends program until key is| >100 CALL KEY("",0,K,S) pressed. (any key) | | Suspends program until ENTER | >100 CALL KEY(CHR$(13),0,K,S) is pressed. | | Suspends program until the | >100 A$="123" key from string A$ is used. | >110 CALL KEY(A$,0,KV,STATUS) | Suspends program until YES is| >100 CALL KEY("Y",0,K1,S1,"E" typed in. | ,0,K2,S2,"S",0,K3,S3) | Edited January 23, 2019 by RXB Quote Link to comment Share on other sites More sharing options...
+OLD CS1 Posted January 23, 2019 Share Posted January 23, 2019 Below is my user input routine TIdBit code. I ask for two reasons. First, you can see at JoyStick there is an IF/THEN statement between a CALL JOYST and CALL KEY. Second, the CALL KEY scans key unit 3 looking for FCTN keys. I would have to change around the flow of this routine a little, I think. In particular, the routine gives precedent to key presses over joystick movements so that would have to switch around. In non-compiled BASIC/XB this flow gave what felt to be better performance. I could redesign it to meet the compiled performance gains and see how it affects the regular environments. // // USER INPUT // // P = Player number (used as split keyboard scan mode select) // // Needs: K$(0) - Comparison string for split key scan (units 1 and 2) // K$(1) - Comparison string for standard key scan (unit 3) // // Uses: J, X, Y, K, S // // Returns: J = 0 - No key press or joystick // [1-4] - Left, Right, Down, Up // 5 - Fire/SPACE (Select) // [6-8] - AID, REDO, BACK // UserInput: J=0 :: IF P<0 THEN JoyStick CALL KEY(P,K,S) :: IF S THEN UnitKeyPress ELSE JoyStick UnitKeyPress: J=POS(K$(0),CHR$(K),1) :: IF J=0 THEN KeyScan ELSE RETURN JoyStick: CALL JOYST(ABS(P),X,Y) :: IF X+Y THEN JoyPress KeyScan: CALL KEY(3,K,S) :: IF S THEN KeyPress ELSE RETURN KeyPress: J=4+POS(K$(1),CHR$(K),1) DecodeJoySt: J=J*-(J>4) :: RETURN JoyPress: IF SGN(X) AND SGN(Y)THEN DecodeJoySt J=ABS(((SGN(X)+3)/2)*SGN(X))+(ABS(((SGN(Y)+3)/2)*SGN(Y))-2*(Y<>0)) :: RETURN Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted January 23, 2019 Author Share Posted January 23, 2019 (edited) Does CALL KEY have to immediately follow CALL JOYST? Yes. Also the killer for you is that, if the joystick unit is 1 then the key unit is also 1. As far as I know, CALL KEY(3,K,S) and CALL JOYST(1,X,Y) require that KSCAN is called twice. Joystick units of 3 and 4 do not return anything useful, and 0 and 5 gives a "bad value" message. The main advantage here comes when you are using the joystick and looking for the fire button. Edited January 23, 2019 by senior_falcon 1 Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted January 23, 2019 Author Share Posted January 23, 2019 GPL IN XB USES A ROUTINE IN GPL called SCAN. In both JOYST and KEY both use SCAN. Thus in RXB 2019 I have a routines CALL JOYLOCATE and CALL JOYMOTION. Just finished manual for RXB 2019: Nice useful routines, but not compatible with the compiler. Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
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.