Creating XB Data Lines from HEX data

[sjt]

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

[sometimes99er]

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]

[ti99_forever]

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.

[sjt]

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?

[sometimes99er]

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

[Gazoo]

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

[RXB]

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

[sjt]

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

[sometimes99er]

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.

[Willsy]

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

[senior_falcon]

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

[Willsy]

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 .\DSK1
Ensure WRITE DV80 AS WINDOWS TEXT option is ticked.

Get the speech data file from your QBOX project, and save it into the DSK1
folder of Classic99 as SPDATA.TXT

Now run the program below. You will end up with a file in the DSK1 folder
called DATAOUT.TXT. You can open this in your text editor, copy it, then paste
it 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

[RXB]

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.

[ti99_forever]

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.

[sjt]

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

[sometimes99er]

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

[sometimes99er]

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.

 

 

[senior_falcon]

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

[RXB]

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.

[Willsy]

@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.

[RXB]

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.

[Stuart]

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.

[RXB]

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

[senior_falcon]

@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.

 

[senior_falcon]

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