sjt Posted August 19, 2014 Share Posted August 19, 2014 (edited) XB programmers Is there an easy way to convert data that is in hex format to DATA statements in XBASIC. Is there a program that can convert hex data to tokenized data statements? If I have a block of data that is in hex format but want to have it read by xbasic, Not as a separate file, but part of the extended basic program. it can be in data statements, correct? It will not make much sense looking at it since some codes will not be valid text characters but xbasic can read the data in that format. EX. BYTE >FF,12,01,FE,02 ETC ETC TO...... DATA "........" One more thing is there an easy way to delete blocks of XB lines from a program Edited August 19, 2014 by sjt Quote Link to comment Share on other sites More sharing options...
sometimes99er Posted August 19, 2014 Share Posted August 19, 2014 it can be in data statements, correct? Yes. I did export data to an "xb merge format" (handcrafted within Magellan) and it accepts full byte range (0-255) per character. [media=600,480]http://sometimes.planet-99.net/pic/merge.swf[/media] Quote Link to comment Share on other sites More sharing options...
ti99_forever Posted August 19, 2014 Share Posted August 19, 2014 TI released like 3 programming aid disks. #2 or 3 had ability to delete a range of lines. Also, Super Extended Basic or RXB have that capability. You can use Classic99 to run an emulator. Quote Link to comment Share on other sites More sharing options...
sjt Posted August 19, 2014 Author Share Posted August 19, 2014 Sometimes99er, That's pretty much exactly what I need to do, however the hex data will be created outside of magellan. Though it would require a lot of typing, can hex data be entered by hand and then used to create a merge xb file? The data would not be graphics. I've seen some older programs where data lines were in XB programs in this format. I assumed there was some utility out there? I think sometimes there were separate data files that accompanied the main program and this method was employed to put the data inside the xb program so they data would not be separated from the program as it was shared with others Does this make sense? Quote Link to comment Share on other sites More sharing options...
sometimes99er Posted August 19, 2014 Share Posted August 19, 2014 (edited) Sometimes99er, That's pretty much exactly what I need to do, however the hex data will be created outside of magellan. Though it would require a lot of typing, can hex data be entered by hand and then used to create a merge xb file? The data would not be graphics. I've seen some older programs where data lines were in XB programs in this format. I assumed there was some utility out there? I think sometimes there were separate data files that accompanied the main program and this method was employed to put the data inside the xb program so they data would not be separated from the program as it was shared with others Does this make sense? My reason for doing the screen-to-data-statement converter was to utilize the speed of DISPLAY AT. Thinking about it now, it could indeed have been done with data file(s) instead of the (inline) DATA statements. Creating a data file, even from XB, shouldn't be too hard. And I think it's on par concerning final execution speed. Also random access to a file is easier than managing data statements (you can't RESTORE with anything but a constant (not a variable)). Doing it just to keep it one file instead of two could of course be something one could consider. I would be fine with two files though. You have to consider the source of the hex data you're talking about to maybe avoid going over formats not necessary. Reading data from hex strings shouldn't give all that much of an overhead (compared with raw bytes), but again, it's all relative and depends. Edited August 19, 2014 by sometimes99er Quote Link to comment Share on other sites More sharing options...
Gazoo Posted August 19, 2014 Share Posted August 19, 2014 Are you looking to create a screen and display it? If so I recommend tracking down MENGEN by Greg Wonderly. Havent used it in years as I'll just code something in assembly like it to display a screen in XB, but it works great for that purpose. Gazoo Quote Link to comment Share on other sites More sharing options...
RXB Posted August 19, 2014 Share Posted August 19, 2014 (edited) OPCODE for RXB, GKXB and XB are mostly the same. Here is a listing of the Hex Opcodes that GKXB and RXB use, the only real difference is that normal XB does not include commands: COPY start line-end line,new start line,increment EXAMPLE: 120-150,9000,100 DEL start line-end line EXAMPLE: 180-265 MOVE start line-end line,new start line,increment EXAMPLE: 110-180,1100,5 One of the reasons the REDO buffer was removed from RXB was for CALL USER to load TEXT directly like you keyed it in. Anyway here are the HEX OPCODES: *********************************************************** * BASIC TOKEN TABLE * EQU >80 spare token ELSEZ EQU >81 ELSE SSEPZ EQU >82 :: TREMZ EQU >83 $ IFZ EQU >84 IF GOZ EQU >85 GO GOTOZ EQU >86 GOTO GOSUBZ EQU >87 GOSUB RETURZ EQU >88 RETURN DEFZ EQU >89 DEF DIMZ EQU >8A DIM ENDZ EQU >8B END FORZ EQU >8C FOR LETZ EQU >8D LET BREAKZ EQU >8E BREAK UNBREZ EQU >8F UNBREAK TRACEZ EQU >90 TRACE UNTRAZ EQU >91 UNTRACE INPUTZ EQU >92 INPUT DATAZ EQU >93 DATA RESTOZ EQU >94 RESTORE RANDOZ EQU >95 RANDOMIZE NEXTZ EQU >96 NEXT READZ EQU >97 READ STOPZ EQU >98 STOP DELETZ EQU >99 DELETE REMZ EQU >9A REM ONZ EQU >9B ON PRINTZ EQU >9C PRINT CALLZ EQU >9D CALL OPTIOZ EQU >9E OPTION OPENZ EQU >9F OPEN CLOSEZ EQU >A0 CLOSE SUBZ EQU >A1 SUB DISPLZ EQU >A2 DISPLAY IMAGEZ EQU >A3 IMAGE ACCEPZ EQU >A4 ACCEPT ERRORZ EQU >A5 ERROR WARNZ EQU >A6 WARNING SUBXTZ EQU >A7 SUBEXIT SUBNDZ EQU >A8 SUBEND RUNZ EQU >A9 RUN LINPUZ EQU >AA LINPUT * EQU >AB Zpare token (LIBRARY) * EQU >AC Zpare token (REAL) * EQU >AD Zpare token (INTEGER) * EQU >AE Zpare token (SCRATCH) * EQU >AF Zpare token THENZ EQU >B0 THEN TOZ EQU >B1 TO STEPZ EQU >B2 STEP COMMAZ EQU >B3 , SEMICZ EQU >B4 ; COLONZ EQU >B5 : RPARZ EQU >B6 ) LPARZ EQU >B7 ( CONCZ EQU >B8 & (CONCATENATE) * EQU >B9 spare token ORZ EQU >BA OR ANDZ EQU >BB AND XORZ EQU >BC XOR NOTZ EQU >BD NOT EQUALZ EQU >BE = LESSZ EQU >BF < GREATZ EQU >C0 > PLUSZ EQU >C1 + MINUSZ EQU >C2 - MULTZ EQU >C3 * DIVIZ EQU >C4 / CIRCUZ EQU >C5 ^ * EQU >C6 spare token STRINZ EQU >C7 QUOTED STRING UNQSTZ EQU >C8 UNQUOTED STRING NUMZ EQU >C8 ALSO NUMERICAL STRING NUMCOZ EQU >C8 ALSO UNQUOTED STRING LNZ EQU >C9 LINE NUMBER CONSTANT * EQU >CA spare token ABSZ EQU >CB ABS ATNZ EQU >CC ATN COSZ EQU >CD COS EXPZZ EQU >CE EXP INTZ EQU >CF INT LOGZ EQU >D0 LOG SGNZZ EQU >D1 SGN SINZ EQU >D2 SIN SQRZ EQU >D3 SQR TANZ EQU >D4 TAN LENZ EQU >D5 LEN CHRZZ EQU >D6 CHR$ RNDZ EQU >D7 RND SEGZZ EQU >D8 SEG$ POSZ EQU >D9 POS VAL EQU >DA VAL STRZZ EQU >DB STR$ ASCZ EQU >DC ASC PIZ EQU >DD PI RECZ EQU >DE REC MAXZ EQU >DF MAX MINZ EQU >E0 MIN RPTZZ EQU >E1 RPT$ * EQU >E2 unused * EQU >E2 unused * EQU >E3 unused * EQU >E4 unused * EQU >E5 unused * EQU >E6 unused * EQU >E7 unused NUMERZ EQU >E8 NUMERIC DIGITZ EQU >E9 DIGIT UALPHZ EQU >EA UALPHA SIZEZ EQU >EB SIZE ALLZ EQU >EC ALL USINGZ EQU >ED USING BEEPZ EQU >EE BEEP ERASEZ EQU >EF ERASE ATZ EQU >F0 AT BASEZ EQU >F1 BASE * EQU >F2 spare token (TEMPORARY) * EQU >F3 spare token (VARIABLE) * EQU >F4 spare token (RELATIVE) * EQU >F5 spare token (INTERNAL) SEQUEZ EQU >F6 SEQUENTIAL OUTPUZ EQU >F7 OUTPUT UPDATZ EQU >F8 UPDATE APPENZ EQU >F9 APPEND FIXEDZ EQU >FA FIXED PERMAZ EQU >FB PERMANENT TABZ EQU >FC TAB NUMBEZ EQU >FD # VALIDZ EQU >FE VALIDATE * EQU >FF ILLEGAL VALUE *********************************************************** As you can see more then a few are unused as of yet. Edited August 19, 2014 by RXB Quote Link to comment Share on other sites More sharing options...
sjt Posted August 20, 2014 Author Share Posted August 20, 2014 In this case I was looking to incorporate raw speech data in XB . Which can be substantial in size.. Though there may be a limitation of the max data that can be sent to the synthesizer at one time using XB , maybe 256 bytes? Steve Quote Link to comment Share on other sites More sharing options...
sometimes99er Posted August 20, 2014 Share Posted August 20, 2014 In this case I was looking to incorporate raw speech data in XB . Which can be substantial in size.. Though there may be a limitation of the max data that can be sent to the synthesizer at one time using XB , maybe 256 bytes? Yes. With XB only (no CALL LINK etc.), you're pretty much limited to one word speech at a time with this string max. size of 255 bytes. Quote Link to comment Share on other sites More sharing options...
Willsy Posted August 20, 2014 Share Posted August 20, 2014 (edited) The speech synth buffer is 16 bytes (IIRC). If you want the XB program to run while it speaks then you'll have to hook into the VDP ISR and drip-feed bytes to the speech synth. In XB this is going to be tricky: It's necessary to read the speech synth's buffer status to see if the buffer needs to be re-filled or not, and that has to be done from PAD memory; it can't be done from the 8-bit 32K memory. The trouble is, the PAD ram in TIB/XB is very heavily utilised. You might struggle to find a free area of PAD in which to insert the machine code required to read the speech synth status. This is probably the reason why speech in XB "hangs" the program until it is done with talking rather than run on the ISR ala sprites; no room in PAD to implement the required routines. Edited August 20, 2014 by Willsy 1 Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted August 22, 2014 Share Posted August 22, 2014 (edited) XB programmers Is there an easy way to convert data that is in hex format to DATA statements in XBASIC. Is there a program that can convert hex data to tokenized data statements? If I have a block of data that is in hex format but want to have it read by xbasic, Not as a separate file, but part of the extended basic program. it can be in data statements, correct? It will not make much sense looking at it since some codes will not be valid text characters but xbasic can read the data in that format. Willsy's answer above probably puts the kibosh on what you intended to do, but here is how it can be done if it helps you or someone else: Merge format files are in DISPLAY,VARIABLE 163 format. You can write the following line: 30000 DATA "ABCD" and save it in merge format. Then write a short program to open the file: 10 OPEN #1:"DSK1.TESTABCD",DISPLAY,VARIABLE 163,INPUT 20 LINPUT A$ 30 FOR I=1 TO LEN(A$)::PRINT ASC(SEG$(A$,I,1));::NEXT I 40GOTO 20 And you will see that line 30000 is: 117,48,147,199,4,65,66,67,68,0 117 and 48 is the line number (117*256+48)=30000 147 and 199 are the tokens for DATA and quotation mark 4,65,66,67,68 is the length and the characters ABCD 0 must be at the end of the line With the information above you should be able to write a short program to create your own merge format DATA statements containing any characters. Hex numbers must be converted to decimal because that is all XB understands. Also, you can list but cannot edit a line that contains weird characters that can't be entered via the keyboard. After the last DATA statement write the two byte string CHR$(255)&CHR$(255) to mark the end of the file. (edit) I think I misunderstood your question. and it looks like Willsy's program below is better at doing what you want. What my program does is make a string with each value represented by a single byte making it very compact. Here's the difference: In my program you have DATA "ABCD" where the string can be any length up to around 156 (I forget the exact number) and the bytes in the string are any number from 0 to 255. Willsy's program would have that as DATA 65,66,67,68 which makes it easy to read individual bytes of data. Edited August 22, 2014 by senior_falcon 2 Quote Link to comment Share on other sites More sharing options...
Willsy Posted August 22, 2014 Share Posted August 22, 2014 (edited) Here you go. This should work.To use this program, work in Classic99.Make sure that the following options for DSK1 are set:In the menu bar in Classic99 click Disk, then click .\DSK1Ensure WRITE DV80 AS WINDOWS TEXT option is ticked.Get the speech data file from your QBOX project, and save it into the DSK1folder of Classic99 as SPDATA.TXTNow run the program below. You will end up with a file in the DSK1 foldercalled DATAOUT.TXT. You can open this in your text editor, copy it, then pasteit into the classic99 window.The following data: * * 10 Voiced 4 Unvoiced 8 kHz 5220 * PHR00001 *; addr [0000] *; *;[no name] *; *; [LPC] BYTE >04,>A8,>D1,>85,>00,>D5,>9B,>10,>A0,>06,>13,>02,>D4,>10 BYTE >4A,>80,>1A,>5C,>18,>D0,>42,>08,>03,>5A,>70,>65,>40,>8B BYTE >AE,>0C,>68,>DE,>94,>00,>CD,>9B,>32,>A0,>79,>17,>02,>14 BYTE >A7,>46,>80,>6A,>CD,>08,>50,>B4,>29,>01,>92,>51,>25,>00 BYTE >30,>6A,>00,>C0,>00,>90,>2B,>4F,>EA,>AD,>65,>F4,>4A,>3C BYTE >AB,>3C *; *; nb bytes: [4762] *; ...produces this in the output text file (DATAOUT.TXT)10000 DATA 4,168,209,133,0,213,155,16,160,6,19,2,212,16 10001 DATA 74,128,26,92,24,208,66,8,3,90,112,101,64,139 10002 DATA 174,12,104,222,148,0,205,155,50,160,121,23,2,20 10003 DATA 167,70,128,106,205,8,80,180,41,1,146,81,37,0 10004 DATA 48,106,0,192,0,144,43,79,234,173,101,244,74,60 10005 DATA 171,60 Hope this helps. It's a bit slow. I'll see if I can produce a faster version.This will get you going though. Use CPU Overdrive :-)10 OPTION BASE 0 20 DIM N(14):: LN=10000 30 HEX$="0123456789ABCDEF" 40 OPEN #1:"DSK1.SPDATA.TXT",DISPLAY ,VARIABLE 80,INPUT 50 OPEN #2:"DSK1.DATAOUT.TXT",DISPLAY ,VARIABLE 80,OUTPUT 60 P=0 :: CALL PARSE_LINE(HEX$,N(),LN,P) 70 IF P>0 THEN CALL WRITE_DATA(P,LN,N()):: LN=LN+1 80 IF EOF(1)=0 THEN 60 90 CLOSE #1 100 CLOSE #2 110 END 120 SUB PARSE_LINE(HEX$,N(),LN,P) 130 LINPUT #1:IN$ 140 IF LEN(IN$)=0 THEN SUBEXIT 150 X=POS(IN$,"BYTE >",1):: IF X=0 THEN SUBEXIT 160 FOR I=X+6 TO LEN(IN$)STEP 4 170 CALL TO_DEC(SEG$(IN$,I,2),N(),HEX$,DEC) 180 N(P)=DEC :: P=P+1 190 NEXT I 200 SUBEND 210 SUB TO_DEC(HEXVAL$,N(),HEX$,DEC) 220 DEC=((POS(HEX$,SEG$(HEXVAL$,1,1),1)-1)*16)+(POS(HEX$,SEG$(HEXVAL$,2,1),1)-1) 230 SUBEND 240 SUB WRITE_DATA(P,LN,N()) 250 A$=STR$(LN)&" DATA " 260 FOR I=0 TO P-2 270 A$=A$&STR$(N(I))&"," 280 NEXT I 290 A$=A$&STR$(N(P-1)) 300 PRINT #2:A$ 310 SUBEND Edited August 22, 2014 by Willsy Quote Link to comment Share on other sites More sharing options...
RXB Posted August 23, 2014 Share Posted August 23, 2014 Would using DEF statements like DEF DDEC(DEC)=((POS(HEX$,SEG$(HEXVAL$,1,1),1)-1)*16)+(POS(HEX$,SEG$(HEXVAL$,2,1),1)-1) work any better then SUB as DEF statements often execute very fast according to testing of speed. The reason why is the DEF uses more ROM assembly then SUB does to execute the values. Quote Link to comment Share on other sites More sharing options...
ti99_forever Posted August 23, 2014 Share Posted August 23, 2014 Restore with a variable ain't possible? ON I GOSUB 200,300,400 200 RESTORE 10::RETURN 300 RESTORE 20::RETURN etc. a lookup table is likely to be required. Quote Link to comment Share on other sites More sharing options...
sjt Posted August 23, 2014 Author Share Posted August 23, 2014 (edited) The program Willy suggested would work to create the data. (I've used it with slight modification) But it is a slow process, and then reading it into strings to use the data will be very slow. I think the faster way to handle the data is to use tokens and create a dv163 merge file. The data would be in the form of a single string Read as text. DATA " (ascii representing hex values) " A string converted and written in dv163 format would look something like this: disregard the\ lines \0001\93c8\string length?\hex for data in string format"chr$(2)etc &chr$(255)" line# data Writing 255 stored as FF not stored as 32 35 35 Is it possible to do this inside the xb environment Does this make sense? Steve Edited August 24, 2014 by sjt Quote Link to comment Share on other sites More sharing options...
sometimes99er Posted August 24, 2014 Share Posted August 24, 2014 (edited) Restore with a variable ain't possible? ON I GOSUB 200,300,400 200 RESTORE 10::RETURN 300 RESTORE 20::RETURN etc. Yes, as I said. RESTORE 10 and RESTORE 20 still does not make RESTORE <VARIABLE>. I've used the exact same and nice workaround, but then there are other ways to Rome - it all depends. Edited August 27, 2014 by sometimes99er Quote Link to comment Share on other sites More sharing options...
sometimes99er Posted August 24, 2014 Share Posted August 24, 2014 The program Willy suggested would work to create the data. (I've used it with slight modification) But it is a slow process, and then reading it into strings to use the data will be very slow. I think the faster way to handle the data is to use tokens and create a dv163 merge file. The data would be in the form of a single string Read as text. DATA " (ascii representing hex values) " A string converted and written in dv163 format would look something like this: disregard the\ lines \0001\93c8\string length?\hex for data in string format"chr$(2)etc &chr$(255)" line# data Writing 255 stored as FF not stored as 32 35 35 Is it possible to do this inside the xb environment Yes, I think it's possible to create almost any file (you know within reason) from the XB environment. Since you've already cross-platform with the Qboxpro, then a little PC (or Web) application to read the data file and output an XB merge file (almost instantly) could be the way to go. Of course the usual string maximum size of 255 characters still applies. Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted August 24, 2014 Share Posted August 24, 2014 (edited) Post 11 above gives most of what you need to write your own program. To give you a little nudge in the right direction, lets say you want to have line 30000 (which in two bytes gives a line number of 117,48) contain a 4 byte long string containing the bytes 10,223,14,188 10 OPEN #1:"DSK1.TEST-M",DISPLAY,VARIABLE 163,OUTPUT 20 A$=CHR$(117)&CHR$(48)&CHR$(147)&CHR$(199)&CHR$(4)&CH$(10)&CHR$(223)&CHR$(14)&CHR$(188)&CHR$(0) 30 PRINT #1:A$ !you can print as many lines as desired 40 PRINT #1:CHR$(255)&CHR$(255) !end of file 50 CLOSE #1 When you merge DSK1.TEST-M it will add line 30000 to your program with that 4 byte string. One point about Sometimes99's comment above: While strings can have a maximum size of 255 bytes, program lines must be shorter and the maximum string length possible in a DATA statement is 155 bytes. (edit) Of course, you can concatenate strings up to 255 bytes long. Edited August 24, 2014 by senior_falcon 1 Quote Link to comment Share on other sites More sharing options...
RXB Posted August 24, 2014 Share Posted August 24, 2014 Post 11 above gives most of what you need to write your own program. To give you a little nudge in the right direction, lets say you want to have line 30000 (which in two bytes gives a line number of 117,48) contain a 4 byte long string containing the bytes 10,223,14,188 10 OPEN #1:"DSK1.TEST-M",DISPLAY,VARIABLE 163,OUTPUT 20 A$=CHR$(117)&CHR$(48)&CHR$(147)&CHR$(199)&CHR$(4)&CH$(10)&CHR$(223)&CHR$(14)&CHR$(188)&CHR$(0) 30 PRINT #1:A$ !you can print as many lines as desired 40 PRINT #1:CHR$(255)&CHR$(255) !end of file 50 CLOSE #1 When you merge DSK1.TEST-M it will add line 30000 to your program with that 4 byte string. One point about Sometimes99's comment above: While strings can have a maximum size of 255 bytes, program lines must be shorter and the maximum string length possible in a DATA statement is 155 bytes. (edit) Of course, you can concatenate strings up to 255 bytes long. Have you tried using RXB feature CALL USER ? You can write a DV80 file for XB that can do almost anything you could type in and create files that create files that create programs. Besides it will allow you to run multiple XB programs that can merge or save or rewrite XB programs or files while running that DV80 Text file at same time. Quote Link to comment Share on other sites More sharing options...
Willsy Posted August 25, 2014 Share Posted August 25, 2014 @Senior_falcon I think the best way to go about this would be to have a program that read the data in from disk, and poked that data *after* itself, in CPU memory (so that in CPU memory we have the XB program and the data immediately following it). Then, somehow, we change the data pointers in XB such that when the program is saved to disk, the TI saves the program, *and* the data that was poked into memory. I don't know how to do this in XB, but I think it's possible, as I've seen programs that load themeselves, and their data as one big file. Quote Link to comment Share on other sites More sharing options...
RXB Posted August 25, 2014 Share Posted August 25, 2014 The speech synth buffer is 16 bytes (IIRC). If you want the XB program to run while it speaks then you'll have to hook into the VDP ISR and drip-feed bytes to the speech synth. In XB this is going to be tricky: It's necessary to read the speech synth's buffer status to see if the buffer needs to be re-filled or not, and that has to be done from PAD memory; it can't be done from the 8-bit 32K memory. The trouble is, the PAD ram in TIB/XB is very heavily utilised. You might struggle to find a free area of PAD in which to insert the machine code required to read the speech synth status. This is probably the reason why speech in XB "hangs" the program until it is done with talking rather than run on the ISR ala sprites; no room in PAD to implement the required routines. Found this as a consideration of the problem you may have and taken from the Hardware-manual-for-the-texas-instruments-994a 4.5 SPEECH SYNTHESIZER CONSIDERATIONS Direct communication with the Speech Synthesizer from code in a Memory Expansion Unit will cause some interesting problems during a READ operation. The synthesizer chip is much like a TMS1000 uC. It must remove itself from the TI-99/4 system Data Bus with its own software even though the Console address decoding logic has deselected the chip. It will take at least 20 us for the chip to disable its data bus drivers; so, it will still be driving the Data Bus when the next instruction is fetched from the Memory Expansion. Therefore, this chip may not be generally accessed by code in the external Memory Expansion unit since both use the same data bus to the console. This is true of either the old "side car" peripheral or the Peripheral Expansion Box. You must transfer code from the Memory Expansion Unit into the console, and execute the code in the console. If the Console SRAM is to be used, an area must be saved to be restored later. No system level software may be used until SRAM is restored. In any case be sure that at least 20 us have elapsed from the READ access until control is returned to the code in the Memory Expansion. Experience has shown that strange things will happen if you do not! This is also a condition that some systems will tolerate, but others will not. The problem was discovered on systems that would not function correctly. Quote Link to comment Share on other sites More sharing options...
Stuart Posted August 25, 2014 Share Posted August 25, 2014 I think the best way to go about this would be to have a program that read the data in from disk, and poked that data *after* itself, in CPU memory (so that in CPU memory we have the XB program and the data immediately following it). Then, somehow, we change the data pointers in XB such that when the program is saved to disk, the TI saves the program, *and* the data that was poked into memory. I don't know how to do this in XB, but I think it's possible, as I've seen programs that load themeselves, and their data as one big file. Systex, by Barry Boone, is a program that can do this. Quote Link to comment Share on other sites More sharing options...
RXB Posted August 25, 2014 Share Posted August 25, 2014 (edited) RXB has CALL USER("pathnam.dv80file") You can run USER then open a Merge format and extract tokens or a DV80 listing and extract the DATA statements or use CALL USER to run like a DOS environment to extract sectors off disk. If you can type it then CALL USER can do it. The VIDEOS of CALL USER is many Video of the same USER program doing all this stuff. ALL A SINGLE CALL USER DEMO: RXBDEMO1: RXBDEMO2: RXBDEMO3: RXBDEMO4 A LOAD PROGRAM THAT WRITES A XB LOAD PROGRAM THEN SAVES AND DELETES THAT FILE AND CREATES DATA STATEMENTS! The RXBDEMO4 does along with the previous demo can do exactly what is being asked for from a DV80 TI Writer file format. Just take a look at RXB CALL USER in the RXB manual please. Edited August 25, 2014 by RXB Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted August 25, 2014 Share Posted August 25, 2014 @Senior_falcon I think the best way to go about this would be to have a program that read the data in from disk, and poked that data *after* itself, in CPU memory (so that in CPU memory we have the XB program and the data immediately following it). Then, somehow, we change the data pointers in XB such that when the program is saved to disk, the TI saves the program, *and* the data that was poked into memory. I don't know how to do this in XB, but I think it's possible, as I've seen programs that load themeselves, and their data as one big file. It seems that what Steve wants to do is pretty simple: read a string from a DATA statement and then access the speech synthesizer with CALL SAY(A$). (@Steve - if this is wrong then you need to provide more info on exactly what you want to do.) What you propose might work, but how would you get the string out of the memory? You could CALL PEEK 100 times or more and concatenate a string, but that would take an eternity compared to READ A$. Of course, a clever A/L programmer (which you are) could write a subroutine that moves an XB program around and merges a line containing a DATA statement, but that capability is already built into XB using MERGE. Why reinvent the wheel? I suppose if you knew how long the DATA statements were you could put in dummy DATA statements the right length and then poke in the desired values. Try out the short program in post #18 and you will see that it does what it is supposed to - creates a merge format file with 30000 DATA "xxxx" where the 4 byte string contains the characters 10,223,14,188. This just needs to be expanded to do what Steve wants. @Rich - your comment "If you can type it then CALL USER can do it" pretty much says it all. What key do you press to get a 10 or a 223 or a 14 or a 188 and how do you get the XB line editor to accept it? It could be I misread the manual and if so please post details on how to do this. Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted August 25, 2014 Share Posted August 25, 2014 (edited) Another way that might work well would be to take Steve's hex values and treat them as an assembly program. You would need to add some stuff to keep the XB interpreter happy. You need a line number table with pointers to where the data statements start. (2 bytes per line number and 2 bytes for the pointer.) This table should be followed by the hex values preceded by 147 and 199 for the XB tokens, then a length byte, then the hex data followed by BYTE 0. All this needs to be AORG'd into the proper place in high memory and the XB pointers in the scratchpad set accordingly. (One thing to remember is that assembly is word oriented, while BASIC is byte oriented. If you use something like: DATA 30000 DATA L30000 for the line number table, you must be sure that it is at an even address.) Then you could either save the resulting XB program in merge format for future use, or simply start adding program lines to it via the XB editor. Edited August 25, 2014 by senior_falcon 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.