Creating XB Data Lines from HEX data

[senior_falcon]

Here's how to do it in assembly. There are a few lines to add, but the data stays the same.

Assemble into an object code file, then go to XB. CALL INIT, then CALL LOAD("DSK1.DATA-O"). Then SAVE DSK1.DATA-M,MERGE

 

Can post a video of how do do it if that would be helpful (edit) This technique can be used to create XB DATA lines containing a string that is 250 bytes long. They cannot be merged, so the AORG has to be figured in a different way. Will post details if anyone is interested.

 

*********************************************************

AORG >A800


*Line number table below in numeric order, highest first

LNSTRT DATA 20,L20+1 Line 20,pointer to L20+1
DATA 10,L10+1 Line 10,pointer to L10+1

L20 BYTE E20-L20,>93,>C7,E20-D20 Length byte,DATA,",Length of string
D20 BYTE 1,2,3,4 !your data here
E20 BYTE 0 need 0 at end of line

L10 BYTE E10-L10,>93,>C7,E10-D10 Length byte,DATA,",Length of string
D10 BYTE >11,>22,>33,>44 \
BYTE >55,>66,>77,>88 !your data here-hex,dec or bin OK
BYTE 255,50 /
E10 BYTE 0 need 0 at end of line


AORG >8330
DATA LNSTRT,L20-1

END

Edited August 26, 2014 by senior_falcon

[senior_falcon]

Here's a demo showing an XB line that has a DATA statement that is 250 bytes long. This cannot be done with the XB line editor - it is created with a simple assembly language program.

 

To the A/L gurus out there:

I would like to do this:

AORG >FFE6-XBE+XBS

XBS

(Between XBS and XBE is the XB program containing the line number table and the data statements)

XBE

 

This gives a "BAD FORWARD REFERENCE" error. This would be simpler than what I have done: At the beginning I AORG >A000, then after XBE I have AORG >3000 and DATA >FFE6-XBE+XBS. Then I look at >3000 to get the address, change the AORG >A000 to the new address, save, re-assemble and reload.

[RXB]

So where is this stored as program crunch buffer is only 163 bytes long and the Edit buffer is only 152 bytes long in XB?

 

In RXB I expanded the Edit Buffer to 255 characters but the Crunch Buffer is still only 163 bytes long?

 

If you modifify the program lines to point past the extra data in each line.

 

That would be a good idea for a future RXB that has a 256 character Crunch buffer and a 1024 byte edit buffer, but that would only work if many BASIC programs would no longer work.

 

(Many problems crop up on that.)

[Willsy]

So where is this stored as program crunch buffer is only 163 bytes long and the Edit buffer is only 152 bytes long in XB?

I presume in normal CPU ram, as with any other XB program. Neither the crunch buffer, nor the edit buffer are relevant - the assembly program is "crunching" (more correctly: tokenising) the program, independantly of XB's compiler/tokeniser, and the edit buffer isn't required at all, since there's no need to edit the big DATA statement: If you need to edit it, you change the program that *creates* the big DATA statement. It's just code that writes code. Aint no big thang

Edited August 28, 2014 by Willsy

[RXB]

As a program is run in XB it is moved into the Crunch Buffer depending on type of subprogram used.

You are 100% correct about the Edit Buffer, but the Crunch buffer >0820 has the program line moved there often and interpretation are done both at the CPU address or VDP address at >0820 (Crunch Buffer)

Specifically only a very small number of routines do this when it has to back track the tokens as VDP stack is already in use.

Program line length is not checked often but you could run into this and a error will result.

The problem would be it moves the extra long program long token line into the Crunch Buffer and as the Crunch Buffer is 163 bytes long creates a cascade of other problems.

 

Mostly this works fine but can bite you in the butt if one of those routines is called. Just pointing out a problem that could crop up.

Edited August 28, 2014 by RXB

[Willsy]

Ah! I see. Thanks Rich. This cool information. I wasn't aware of that. Its cool to have a GPL/interpreter guru on this board!

[senior_falcon]

You will not have any problem with overflowing the crunch buffer when reading a long DATA string, because it is not used when reading strings. (You can check this using the Classic99 debugger.) In my experience, the crunch buffer doesn't do a whole lot when an XB program is running. The reason I know this is from writing and testing The Missing Link. TML had to deal with some VDP memory usage by XB that were in inconvenient locations. The XB system area starting at >0370 is one and the crunch buffer at >0820 is the other. Both these fall in the middle of the color table and cannot be changed without crashing XB. By putting a blank character at the edges of the screen I was able to "hide" the XB system area and the first 8 bytes of the crunch buffer. Any line in XB that used more than 8 bytes of the crunch buffer would make unwanted junk appear on the screen. My testing only showed this happening with user defined subprograms having names more than 8 bytes long, and when reading display format disk files. (And maybe when you RUN an XB program from another one-can't remember that) If you want to see this load up TML and write this program:

10 CALL ILOVEMYTI99

20 GOTO 20

100 SUB ILOVEMYTI99

110 SUBEND

There were some pretty complex program written for TML and as far as I know none of them had this problem with unwanted colors, which says that those programs used no more than 8 bytes of the crunch buffer. Of course, I have not tested every possible combination in XB, and would be interested in seeing if you can come up with an XB line that makes heavy use of the crunch buffer.

Edited August 29, 2014 by senior_falcon

[RXB]

Well I do know that the USER DEFINED FUNCTION does do a Crunch buffer back track and the File system you mentioned will also create a issue.

I do not think XB would have a issue.

But RXB has CALL USER and I do know that it is not compatible with TML as it takes over the keyscan of XB and allows DV80 files to be batch processed not unlike a TI version of DOS.

 

RXB does make use of everything I can unlike normal XB.

XB did after all never push any limits on the TI and I think they assumed Pascal would be the next big thing over BASIC, but of course TI was wrong again.

[sjt]

Thanks for everyone's help. I decided the easiest way to do this was take the hex data, put it in merge format to be placed at the end of A XB program I wrote. It recodes it and writes out a new merge file using tokens. (Sounds more complicated than it is)

 

 

I take the raw hex data in lines of text- Byte format, ex. Byte >FF,>FE,>00 etc change the line begining for each to example -9000 DATA FF,FE,00 etc 9010 etc etc

Simple search and replace.

 

 

I then save that in merge format. (using classic99) That file gets merged with the XB program I wrote and outputs a new merge file with the data now in a couple of complete strings and a small header to speak the data, and display it.

As it stands I have it limited to 240 bytes, in a max of 120 byte chunks. Just made it easier to break up phrases. While I'm playing with it.

Eventually it could write out 252bytes of data + string header to conserve space, and read instructions etc

 

The attached file shows the result.

This will only work reliably on an actual TI computer with speech of course. On win994a it will try to work but will have trouble most often and not be able to speak it twice

 

I removed the tokenized header that is created by my conversion pgm and added a few lines to allow it to be spoken using both methods.

Sounds pretty much the same.

 

 

 

 

 

 

 

SHALLWEPLAY.zip

[senior_falcon]

I'm pretty sure the longest DATA line you can MERGE is 155 bytes long. If you can save it in program format as described above it could be longer. Also, you can concatenate strings to make one that is 255 bytes long.

[sjt]

Yes, senior falcon your right. The max of an individual data line is limited to 155 but 2 data lines can be added together to achieve larger data strings.

The program I wrote takes this in account now, if the 2 strings generated can fit in the boundary of one data line they are combined. Otherwise the data is split into 2 data lines. Simply read as A$,B$ C$=A$&B$ Call say(,C$)

I learned this the hard way, if the data line exceeds that limit it trashes the merge file

 

Steve

Edited September 17, 2014 by sjt