+Lee Stewart Posted March 5, 2017 Share Posted March 5, 2017 ... PRINT LEN(ASC("")) ! BAD ARGUMENT, actually it should factually report BAD VALUE, not BAD ARGUMENT (my change would report o for length and be correct) No. Your change would result in a different error, “STRING-NUMBER MISMATCH”, which would be correct. You have complicated your position with a bad example. Somehow, with this example, you are focused on ASC()’s parameter, not its result. If you insist on ASC("") reporting 0, so be it. Then, the result for LEN(ASC("")) will be the same as for LEN(ASC("ABC")): “STRING-NUMBER MISMATCH”. Whatever you do with ASC("") matters not one whit in how LEN() should handle parameters that are numbers. As @InsaneMultitasker pointed out, taking the LEN() of a number is a misuse of LEN() and should always report an error. Numbers are not strings. Like I said: Bad example. ...lee Quote Link to comment Share on other sites More sharing options...
RXB Posted March 5, 2017 Share Posted March 5, 2017 (edited) Hmm LEN(ASC("")) = is a empty string with 0 length and LEN(ASC("ABC")) = 65 so I have no idea what you are talking about. Look a empty string has zero length, why is so complicated to understand. ASC("") is a BAD VALUE as it is incorrect. Where the hell are you getting this CHARACTER 0? A empty string does not have any characters in it? Look I am not putting a CHR$(0) in that string as it is still empty, and still has a 0 length. I think you guys are hung up on something that does not exist, or you love a certain error for LEN(ASC("")) of Bad Argument which is incorrect for that error. 1. ASC returns a NUMBER not a string. 2. ASC only uses the first character in the string. 3. NOTHING HAS CHANGED, 4. ASC("") should be BAD VALUE, not BAD ARGUMENT as if X$ is a empty string it should say BAD VALUE as for mixing terms like CHR$("") or ASC(65) will be String number mismatch Note: Even XB manual is kind of nuts and says...... BAD ARGUMENT: Bad value given in ASC, ATN, COS, EXP, INT, LOG, SIN, SOUND, SQR, TAN or VAL So is it a BAD VALUE or BAD ARGUMENT? Apparently according to this they are the same?????? Ok so XB manual says..... BAD VALUE: Incorrect value given in ..... This is clearly totally contradictory! Want proof.....ASC("") is incorrect value thus a BAD VALUE! But by all means lets confuse it completely and say both are the same. Edited March 5, 2017 by RXB Quote Link to comment Share on other sites More sharing options...
Asmusr Posted March 5, 2017 Share Posted March 5, 2017 Hmm LEN(ASC("")) = is a empty string with 0 length and LEN(ASC("ABC")) = 65 so I have no idea what you are talking about. 1 Quote Link to comment Share on other sites More sharing options...
RXB Posted March 5, 2017 Share Posted March 5, 2017 (edited) Ok enough about this I will just not do anything to ASC or LEN 1. is deleted. Any issues with the others? Edited March 5, 2017 by RXB Quote Link to comment Share on other sites More sharing options...
+InsaneMultitasker Posted March 5, 2017 Share Posted March 5, 2017 I like the VAL hex value idea. Could have used that one long ago Would removing/replacing EAPGM and EALR cause any problems? What if EAPGM and EALR both just figure out what to do with either file type (that is, make them work the same way, like your proposed EA?). I don't know how often the two names are called, so maybe the new EA is the better approach.. Quote Link to comment Share on other sites More sharing options...
RXB Posted March 6, 2017 Share Posted March 6, 2017 (edited) I like the VAL hex value idea. Could have used that one long ago Would removing/replacing EAPGM and EALR cause any problems? What if EAPGM and EALR both just figure out what to do with either file type (that is, make them work the same way, like your proposed EA?). I don't know how often the two names are called, so maybe the new EA is the better approach.. Yea, the idea was to remove as many commands from RXB as possible. See RXB has more Subprograms then XB so I need to re-arrange them to speed up search in GPL for those names of Subprograms like CALL CLEAR is used the most often than CALL SCSI is used the least. Also reducing the number of RXB Subprograms also speeds up the search as less is better. Thus removing as many commands and combining them into one is more efficient and speeds up the search. CALL EA("DSK#.FILE") is much more efficient if it looks at the file before it picks a loader, it has to do this anyway as how much time does it take in GPL to tell Program Image from DF80? (Not much time.) Note: I can also make this go load a DV80 file for the Editor in Editor Assembler as what else would you need to do with a DV80 file other then view or edit it? Edited March 6, 2017 by RXB Quote Link to comment Share on other sites More sharing options...
Willsy Posted March 6, 2017 Share Posted March 6, 2017 I like the VAL hex value idea. Could have used that one long ago Would removing/replacing EAPGM and EALR cause any problems? What if EAPGM and EALR both just figure out what to do with either file type (that is, make them work the same way, like your proposed EA?). I don't know how often the two names are called, so maybe the new EA is the better approach.. Yes, this is cool. Yea, the idea was to remove as many commands from RXB as possible. See RXB has more Subprograms then XB so I need to re-arrange them to speed up search in GPL for those names of Subprograms like CALL CLEAR is used the most often than CALL SCSI is used the least. Also reducing the number of RXB Subprograms also speeds up the search as less is better. Thus removing as many commands and combining them into one is more efficient and speeds up the search. CALL EA("DSK#.FILE") is much more efficient if it looks at the file before it picks a loader, it has to do this anyway as how much time does it take in GPL to tell Program Image from DF80? (Not much time.) Note: I can also make this go load a DV80 file for the Editor in Editor Assembler as what else would you need to do with a DV80 file other then view or edit it? This sounds like a much better focus for your efforts than LEN/ASC, and will improve the system. Nice. 1 Quote Link to comment Share on other sites More sharing options...
RXB Posted March 6, 2017 Share Posted March 6, 2017 Yes, this is cool. This sounds like a much better focus for your efforts than LEN/ASC, and will improve the system. Nice. Thanks the routine oddly is pretty much already in the ROMs and GPL , but oddly TI never used them for that? Quote Link to comment Share on other sites More sharing options...
RXB Posted March 10, 2017 Share Posted March 10, 2017 After looking into TI Intern for how the XB ROM operate as many of the routines use the ROM 0 to access and work with XB ROMs I have seen oddly how to really speed up BASIC. Example: Fetch space for string: 515C : DADD @>830C,>0004 Length+4 (address and twice length byte) 5160 : DST @>8356,@>831A Start string space 5163 : DSUB @>8356,@>830C Minus length 5166 : DST @>8358,@>836E Value stack pointer 5169 : DADD @>8358,>0040 + 8*8 516D : DCH @>8356,@>8358 Enough space? 5170 : BS GROM@>5187 Yes, jump 5172 : CALL GROM@>51A9 Garbage collection 5175 : DST @>8358,@>836E Compute space once more 5178 : DADD @>8358,>0040 517C : DST @>8356,@>831A 517F : DSUB @>8356,@>830C 5182 : DCH @>8356,@>8358 5185 : BR GROM@>567D No space, memory full 5187 : DSUB @>830C,>0004 Length -4 518B : ST VDP*>831A,@>830D Write length byte in VDP 518F : DSUB @>831A,@>830C Start string space minus length 5192 : DST @>831C,@>831A Temporary pointer on string space 5195 : DSUB @>831A,>0004 -4 5199 : DCLR VDP@>0001(@>831A) Free 519D : ST VDP@>0003(@>831A),@>830D 2nd length byte in VDP 51A2 : RTN Now XB uses the ROMs instead: ********************************** GETSTR XML *********************** * * SYSTEM GET STRING * * @BYTES = LENGTH * @SREF = ADDRESS OF STRING * GETSTR EQU $ LN61A2 LI R6,>736C Load address >736c LN61A6 JMP LN61BE ********************************************************************* * GETSTR LN736C MOV @BYTES,R0 LN7370 MOV R11,R12 * FOR RETURN LN7372 C *R0+,*R0+ LN7374 MOV @STREND,R1 LN7378 S R0,R1 LN737A MOV @VSPTR,R2 * Value Stack Pointer LN737E AI R2,>0040 LN7382 C R1,R2 * STREND = VSPTR? LN7384 JH LN73A2 * Higher jump LN7386 BL @COMPCT * GARBAGE ROUTINE LN738A MOV @VSPTR,R2 * Save VSPTR LN738E AI R2,>0040 * VSPTR+>40 LN7392 MOV @BYTES,R0 * LN7396 C *R0+,*R0+ ???? LN7398 MOV @STREND,R1 * STREND LN739C S R0,R1 * BYTES-STREND LN739E C R1,R2 * STREND = VSPTR? LN73A0 JLE LN7368 * Less or equal to? LN73A2 AI R0,>FFFC LN73AA BL @LN641E * VDP LN73AE C *R10,R12 LN73B0 S R0,@STREND LN73B4 MOV @STREND,@SREF * Save LN73BA DEC @STREND LN73BE BL @LN641E * VDP LN73C2 C *R10,R12 LN73C4 DECT @STREND * STREND-2 LN73C8 CLR R6 LN73CA MOV @STREND,R1 * Save STREND * WRITE ADDRESS, WRITE 2 BYTES to VDP LN73CE BL @>18AE LN73D2 DEC @STREND * STREND-1 LN73D6 B *R12 * RETURN * * COMPCT ROUTINE (GARBAGE COLLECTION) GRBAGE EQU $ LN73D8 MOV R11,R7 LN73DA MOV @FREPTR,R0 * Pointer free space under symbol table LN73DE MOV @STRSP,R5 * End string space (high address) LN73E2 MOV R0,@STRSP * New pointer end string space LN73E6 INC R5 * WTF does this do? LN73E8 DEC R5 * WTF does this do? LN73EA C @STREND,R5 * End of string space? LN73EE JL LN73F6 * No, shift if necessary? LN73F0 MOV R0,@STREND * New pointer start string space, low address LN73F4 B *R7 * LN73F6 MOV R5,R2 * Get string space (high address) LN73F8 MOV R5,R3 * Get string space (high address) * WRITE ADDRESS, READ BYTE LN73FA BL @>1880 LN73FE MOVB R1,R6 LN7400 SRL R6,8 * Swap bytes LN7402 S R6,R5 * LN7404 AI R5,>FFFD * Upper 24K address+R5 LN7408 MOV R5,R3 LN740A BL @LN6C9E LN740E MOV R1,R1 LN7410 JEQ LN73E8 LN7412 C *R6+,*R6+ LN7414 MOV R2,R3 LN7416 MOV R0,R4 * WRITE ADDRESS, READ BYTE LN7418 BL @>1880 LN741C BL @LN6422 LN7420 DEC R3 LN7422 DEC R4 LN7424 DEC R6 LN7426 JGT LN7418 LN7428 ANDI R4,>3FFF LN742C MOV R4,R0 LN742E INC R4 LN7430 MOV R4,R3 LN7432 BL @LN6C9E LN7436 MOV R3,R6 LN7438 AI R6,>0003 * WRITE ADDRESS, WRITE 2 BYTES LN743C BL @>18AE LN7440 JMP LN73E8 So wondering if Basic GPL sections could us the XB ROM routines to speed up BASIC by a considerable speed increase. Will have to put this on back burner but damn would really make Basic fly. Quote Link to comment Share on other sites More sharing options...
RXB Posted April 6, 2017 Share Posted April 6, 2017 Would like some help on this project as I have requested some help before with no takers: PROJECT: Get the XB ROM SOURCE CODE fully commented and explained so we can convert XB ROM to not use VDP for STRINGS and STACK but instead use SAMS memory thus making XB run at least 3 times faster. Really would like some of you Experts in Assembly to give it a look and make some comments in the source code please. Rich XBROM SOURCE 04062017.zip Quote Link to comment Share on other sites More sharing options...
RXB Posted April 10, 2017 Share Posted April 10, 2017 And no one know assembly but me? Can not think of another answer why no one wants to speed up XB but me I guess? Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted April 10, 2017 Share Posted April 10, 2017 And no one know assembly but me? Can not think of another answer why no one wants to speed up XB but me I guess? Trying to get cooperation by insulting us, I see. I am actually interested, but simply do not yet have the time. ...lee 1 Quote Link to comment Share on other sites More sharing options...
+mizapf Posted April 10, 2017 Share Posted April 10, 2017 Currently busy with the Hexbus floppy disassembly; I think I figured it out now. About to start Hexbus implementation in MAME. 3 Quote Link to comment Share on other sites More sharing options...
Omega-TI Posted April 10, 2017 Share Posted April 10, 2017 And no one know assembly but me? Can not think of another answer why no one wants to speed up XB but me I guess? Hi Rich, I one of 'those guys' that does not know a lick of assembly language, and I don't have the time or inclination to try learning it either. It's simply, "not my bag". Now while I have done a few things in Extended BASIC, I like you wish it was faster, but it's not an environment I want to actually RUN my programs in. For me (personally) compiling the completed program is, "where it's at". To that end I'm REALLY, REALLY looking forward to Fest West this year... but I don't want to give anything away. 1 Quote Link to comment Share on other sites More sharing options...
Asmusr Posted April 10, 2017 Share Posted April 10, 2017 I feel kind of responsible for planting this idea of adding seamless SAMS support to RXB. But I didn't know that the ROM code was not part of the RXB code. I thought, perhaps naively, that when you developed a dialect of BASIC you developed both a new GROM and ROM. It an interesting project, but I know very little about BASIC interpreters, and I currently have 3 different games projects I'm working on. 2 Quote Link to comment Share on other sites More sharing options...
Asmusr Posted April 10, 2017 Share Posted April 10, 2017 To that end I'm REALLY, REALLY looking forward to Fest West this year... but I don't want to give anything away. That sounds very interesting. A new XB compiler? Quote Link to comment Share on other sites More sharing options...
Omega-TI Posted April 11, 2017 Share Posted April 11, 2017 That sounds very interesting. A new XB compiler? I'm NOT gonna say! But I will tell you that the Fest West CD has a sub-directory dedicating 129 megabytes to one of the scheduled presentations. With any luck the planned video will inform everyone about a week after Fest West, for those unable to attend. Quote Link to comment Share on other sites More sharing options...
RXB Posted April 11, 2017 Share Posted April 11, 2017 Hi Rich, I one of 'those guys' that does not know a lick of assembly language, and I don't have the time or inclination to try learning it either. It's simply, "not my bag". Now while I have done a few things in Extended BASIC, I like you wish it was faster, but it's not an environment I want to actually RUN my programs in. For me (personally) compiling the completed program is, "where it's at". To that end I'm REALLY, REALLY looking forward to Fest West this year... but I don't want to give anything away. The speed increase would make Compiled XB look like a insane amount of time is needed to speed up a program originally written in XB. The advantage of using RAM over VDP for Strings and RAM STACK vs VDP STACK would be like comparing Basic to XB, the difference would be very very noticeable. In some cases the difference would a 16 time increase in speed especially for RAM STACK memory compared to VDP STACK memory. Example VPUSH and VPOP would be changed to RPUSH and RPOP, these alone would really speed up XB CALL LINK and XB routines in general. Quote Link to comment Share on other sites More sharing options...
RXB Posted April 11, 2017 Share Posted April 11, 2017 That sounds very interesting. A new XB compiler? Compilers are nice, but they have a very very long development time in exchange for a good end product. I much prefer a speed up that gives you the speed of faster development and speed just slightly slower and the added bonus you do not get from a Compiled version....COMPATIBILITY! Every Compiler has the distinct disadvantage of you having to rewrite the XB code to fit the compiler, the worst from my SAMS XB would be adding delay loops to slow it down. Quote Link to comment Share on other sites More sharing options...
RXB Posted April 11, 2017 Share Posted April 11, 2017 I do what to thank everyone for at least responding as this was bothering me that after 28 years the TI99/4A would for the first time have XB ROM source code. I mean that is a long time for something to not be tackled that everyone knew needs to be done! Quote Link to comment Share on other sites More sharing options...
Omega-TI Posted April 11, 2017 Share Posted April 11, 2017 I'll keep an open mind Rich, and see what develops. There have been things over the years I would have liked to have done, but the dog slow nature of TI's BASIC(s) was one of the reasons I didn't. Even eliminating pre-scan, the wait time before program execution is a pain. Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted April 11, 2017 Share Posted April 11, 2017 (edited) The speed increase would make Compiled XB look like a insane amount of time is needed to speed up a program originally written in XB. The advantage of using RAM over VDP for Strings and RAM STACK vs VDP STACK would be like comparing Basic to XB, the difference would be very very noticeable. In some cases the difference would a 16 time increase in speed especially for RAM STACK memory compared to VDP STACK memory. Example VPUSH and VPOP would be changed to RPUSH and RPOP, these alone would really speed up XB CALL LINK and XB routines in general. The idea that there would be a 16x increase in speed is just plain silly. If strings were kept in RAM and all string operations were performed directly on them in ram then of course there would be some speed increase. (nowhere near 16x) But most programs aren't doing a lot of string manipulation. Instead, there are numbers to multiply, HCHAR's to perform, sprites to create, etc. And all those are going to happen at the same slow speed. If you really want to speed up Extended BASIC then ditch GPL and write the whole thing in assembly. I think Myarc XB was all in assembly, so that would be a good starting point and as I recall it was good for about a 3x speed increase. And then you might think about really unlocking the graphics mode by using all 256 characters along with a separate sprite table. You could even have two separate screens that can be toggled, and add some routines for smooth scrolling. But of course, that's just a fantasy... Oh, I forgot - that is available today in XB256, and it runs on original hardware with no need for anything special other than a disk drive, the XB cartridge and 32K.. Edited April 12, 2017 by senior_falcon 2 Quote Link to comment Share on other sites More sharing options...
RXB Posted April 11, 2017 Share Posted April 11, 2017 I'll keep an open mind Rich, and see what develops. There have been things over the years I would have liked to have done, but the dog slow nature of TI's BASIC(s) was one of the reasons I didn't. Even eliminating pre-scan, the wait time before program execution is a pain. This is not TI BASIC, it is XB that is much faster than TI Basic. Quote Link to comment Share on other sites More sharing options...
RXB Posted April 11, 2017 Share Posted April 11, 2017 The idea that there would be a 16x increase in speed is just plain silly. If strings were kept in RAM and all string operations were performed directly on them in ram then of course there would be some speed increase. (nowhere near 16x) But most programs aren't doing a lot of string manipulation. Instead, there are numbers to multiply, HCHAR's to perform, sprites to create, etc. And all those are going to happen at the same slow speed. If you really want to speed up Extended BASIC then ditch GPL and write the whole thing in assembly. I think Myarc XB was all in assembly, so that would be a good starting point and as I recall it was good for about a 3x speed increase. And then you might think about really unlocking the graphics mode by using all 256 characters along a separate sprite table. You could even have two separate screens that can be toggled, and add some routines for smooth scrolling. But of course, that's just a fantasy... Oh, I forgot - that is available today in XB256, and it runs on original hardware with no need for anything special other than a disk drive, the XB cartridge and 32K.. I have used ALL of the XB compilers and not a single one can you convert and compile with any speed, it is even slower than Assembly to do that as all the extra steps. XB is good for what it is designed for which is quickly type in a program and test as you go with the interpreter. Why are you even writing in XB if your goal is Assembly? I mean talk about doing something totally unnecessary to end up someplace else. Why not just write it in Assembly in the first place? Or for that matter C that is 100% designed around that idea in the first place. Also I am a GPL programmer and like it, so am I telling you to abandon what you like to do? You can see how this would rub me the wrong way. Which is why I asked for Assembly Language Programmers to help out. I am not attempting to convert anyone to my thinking, but give me a break for my goals. Am I poo pooing on yours? Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted April 11, 2017 Share Posted April 11, 2017 This is not TI BASIC, it is XB that is much faster than TI Basic. Pay attention, Rich. He referred to all TI Basic languages with “TI's BASIC(s)”. ...lee 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.