Disk access with a Basic Compiler

[fabrice montupet]

The Harry Wilhelm's Basic compiler manual says that it only accepts DISPLAY, VARIABLE for disk files.
But DISPLAY is very slow and space consumer, is there a way to use INTERNAL and FIXED with a Basic Compiler?

[+arcadeshopper]

The Harry Wilhelm's Basic compiler manual says that it only accepts DISPLAY, VARIABLE for disk files.
But DISPLAY is very slow and space consumer, is there a way to use INTERNAL and FIXED with a Basic Compiler?

No

Sent from my LM-V600 using Tapatalk

[fabrice montupet]

Thank you for the answer. This is what I thought but I hoped to be wrong.

I use XB256 for its great new graphic capabilities and the Harry Wilhelm's Basic compiler because it permits to programs be converted to an E/A program. But maybe changing to an other extended basic could be a solution. RXB is a so great extended Basic but I haven't found the way to compile programs and get an E/A program. Is it possible?

[+arcadeshopper]

Thank you for the answer. This is what I thought but I hoped to be wrong.
I use XB256 for its great new graphic capabilities and the Harry Wilhelm's Basic compiler because it permits to programs be converted to an E/A program. But maybe changing to an other extended basic could be a solution. RXB is a so great extended Basic but I haven't found the way to compile programs and get an E/A program. Is it possible?

No

Sent from my LM-V600 using Tapatalk

[fabrice montupet]

Thank you again for the answer. Today wasn't definitely my day ^_^

[fabrice montupet]

I think nevertheless that I will choose RXB, it can't compile programs made to E/A ones but it offers SAMs RAM management that will permit at least to speed up DATA access, more than could do a floppy disk could.  And this is a great feature.

[+arcadeshopper]

I think nevertheless that I will choose RXB, it can't compile programs made to E/A ones but it offers SAMs RAM management that will permit at least to speed up DATA access, more than could do a floppy disk could.  And this is a great feature.

Also it has faster routines and the next version will have even more

Sent from my LM-V600 using Tapatalk

[Tursi]

17 hours ago, fabrice montupet said:

The Harry Wilhelm's Basic compiler manual says that it only accepts DISPLAY, VARIABLE for disk files.
But DISPLAY is very slow and space consumer, is there a way to use INTERNAL and FIXED with a Basic Compiler?

DISPLAY vs INTERNAL is just a flag in the header, it doesn't affect the actual data in any way.

 

VARIABLE takes one more byte per record than FIXED but assumes to make it up by allowing shorter records. However, you're right on the speed, there's not much you can do there.

[+jedimatt42]

31 minutes ago, Tursi said:

DISPLAY vs INTERNAL is just a flag in the header, it doesn't affect the actual data in any way.

 

VARIABLE takes one more byte per record than FIXED but assumes to make it up by allowing shorter records. However, you're right on the speed, there's not much you can do there.

 

In BASIC, I believe in INTERNAL mode items are written as length encoded binary values... a float gets an 0x08 and then the 8 byte encoded float.. strings get a length byte and then the bytes of each character... no separator is used..   In DISPLAY mode, strings are written without the length byte, and items are separated by a comma (? maybe, it was some punctuation) and numbers are written in text form as well.   This is with regard to PRINT #1:A$,B,C and INPUT #1:L$,M,N type access.

 

So, depending on your data, DISPLAY could be more bytes per record, or less... Since, if I recall (or it is still the case), the compiler doesn't support floats, it makes sense it doesn't support a file data format that depends on float encoding. But things that fit in a byte in DISPLAY mode would consume 2 to 4 bytes on disk. Where in INTERNAL mode they would always consume 9 bytes.

 

But to Tursi's point, that isn't a quality of the filesystem, from the disk controller point of view, it is just a flag. Outside of BASIC, it is up to the consuming program to decide what that flag means.

 

 

[RXB]

14 hours ago, jedimatt42 said:

 

In BASIC, I believe in INTERNAL mode items are written as length encoded binary values... a float gets an 0x08 and then the 8 byte encoded float.. strings get a length byte and then the bytes of each character... no separator is used..   In DISPLAY mode, strings are written without the length byte, and items are separated by a comma (? maybe, it was some punctuation) and numbers are written in text form as well.   This is with regard to PRINT #1:A$,B,C and INPUT #1:L$,M,N type access.

 

So, depending on your data, DISPLAY could be more bytes per record, or less... Since, if I recall (or it is still the case), the compiler doesn't support floats, it makes sense it doesn't support a file data format that depends on float encoding. But things that fit in a byte in DISPLAY mode would consume 2 to 4 bytes on disk. Where in INTERNAL mode they would always consume 9 bytes.

 

But to Tursi's point, that isn't a quality of the filesystem, from the disk controller point of view, it is just a flag. Outside of BASIC, it is up to the consuming program to decide what that flag means.

 

 

Neither XB or Basic save files in Binary ever. They are always HEX and use the standard >0000 to>FFFF values for the file system.

Now you can use a Floating Point value for things like OPEN #X:"DSK1.FILENAME",OUTPUT where the X is a floating point number.

But that never ends up in the file it is converted to HEX and used in that fashion >01 as up to >FF  or 1 to 255 in Decimal.

[Tursi]

18 hours ago, jedimatt42 said:

 

In BASIC, I believe in INTERNAL mode items are written as length encoded binary values... a float gets an 0x08 and then the 8 byte encoded float.. strings get a length byte and then the bytes of each character... no separator is used..   In DISPLAY mode, strings are written without the length byte, and items are separated by a comma (? maybe, it was some punctuation) and numbers are written in text form as well.   This is with regard to PRINT #1:A$,B,C and INPUT #1:L$,M,N type access.

I don't believe in belief, when testing is so easy.

10 OPEN #1:"DSK0.TESTINT",OUTPUT,INTERNAL,FIXED 80
20 PRINT #1:"TEXT LINE"
30 PRINT #1:1,2,3
40 CLOSE #1
50 OPEN #1:"DSK0.TESTDIS",OUTPUT,DISPLAY ,FIXED 80
60 PRINT #1:"TEXT LINE"
70 PRINT #1:1,2,3
80 CLOSE #1

And you are correct, there ARE differences! Even on the text line, the fixed length padding is different. I am surprised to see the numbers stored as ASCII in the Display version.

I love that 40 years in, I'm still learning things.

 

[+TheBF]

7 hours ago, RXB said:

Neither XB or Basic save files in Binary ever. They are always HEX and use the standard >0000 to>FFFF 

<wordnerdalert>

I think this sentence is bit confusing in terms of are we referring to the the display format of a number or the internal representation of a number.

Since what goes on the disk is always bits it could be said to be binary information even though a program chooses to display the bits as text.

 

The bits that we interpret as unsigned integers from 0000  to FFFF can also be displayed as  -8000 to 7FFF .  HEX does not say if we are going to print numbers in signed or unsigned representation or if we are using 2's complement arithmetic (although I don't know of machine that doesn't do that these days).

 

To some degree I guess it's an English language problem.  Binary can mean radix 2 number output or it can describe a bunch of bits. 

I will stop now.

</wordnerdalert>

 

Same bits different presentation

 

[Tursi]

4 hours ago, Tursi said:

And you are correct, there ARE differences! Even on the text line, the fixed length padding is different. I am surprised to see the numbers stored as ASCII in the Display version.

That said, in looking at the differences, there is no difference is space used because I wrote as FIXED length. So here's the same thing in VARIABLE:

 

 

It would seem in this simple example, the same number of bytes is STILL consumed... is there a test I could try that we might expect to see a difference, @fabrice montupet?

 

[fabrice montupet]

Thank you for all of these information.

I had made no test, I had just read information delivered by the TI Extended manual:

Quote

File-type may be either DISPLAY or INTERNAL. Files can be written either in human-readable form, called ASCII (DISPLAY), or in machine-readable form, called binary (INTERNAL). Binary records may take up less space and are processed more quickly by the computer.

 

Edited August 18, 2021 by fabrice montupet