XB compiler - Disc Access

[Bones-69]

Wondering if somebody might steer me in the right direction here... For testing purposes I wrote the following program to create a small Disc file (DSK3.TESTF) which created 10 sequential records.

 

 

100 ! GOTO 180
110 OPEN #1:"DSK3.TESTF",RELATIVE,DISPLAY ,OUTPUT
120 PRINT #1,REC 0:"FIRST FILE"
130 FOR I=1 TO 10 :: PRINT I;" ";
140 INPUT A$ :: PRINT #1,REC I:A$
150 NEXT I
160 CLOSE #1
170 END
180 OPEN #1:"DSK3.TESTF",RELATIVE,DISPLAY ,INPUT
190 INPUT A
200 INPUT #1,REC A:A$ :: PRINT A$
210 GOTO 190

[Bones-69]

After creating the 10 records (lines 110 to 170), I then tested it in XB by running lines 180-210. I was able to confirm all records were correct as they were saved, and that I could recall the records in any order I requested.

After I ran the compiled version the records were not being fetched correctly. The compiled version seemed to only pick-up the records sequentially (ignored the REC function) and it also skipped every 2nd record.

No doubt this is the result of me not correctly understanding the TI file system, or not understanding the correct application for using files with the XB compiler. I have read the compiler documentation and if I understand correctly, a VARIABLE file structure can only be read sequentially. Is this where it has all gone wrong for me?

Basically, I am playing with the idea of an adventure game and aiming to recall text records randomly (if this is possible).

Thanks!

[Opry99er]

You should be able to read the records into your XB program and then randomize them there... If you read sequential records into variables, you should be able to randomize which records you use with your program code. I do not have any test code for you, but conceptually, it should not be too difficult to execute.

[Opry99er]

Of course this partially defeats the purpose of calling random stuff from disk and would require you to put more info into memory (for a larger pool of variables to simulate randomness) but you could achieve the desired result by loading blocks of data that are pseudo-random if you carefully structure the files... The end user would never know the difference.

 

A seed concept, if you will...

[Bones-69]

To be more specific, as the player moved into a new environment (ie - a map location), I want to be able to temporarily load the details for that location. So for the sake of clarity, lets assume the map grid was 10 x 10. If the player was in location 10, and they went South, the location might become location 20. It would be beneficial to be able to instantly read record 20 without having to first read the next 10 records to then arrive at the required file (perhaps the player moves from location 10 to 50, in which case 40 files would first need to be read/dismissed to arrive at the correct record).

 

By Random I refer to being able to retrieve the disc records Randomly (eg. REC 10, REC 50, REC 5 etc), rather than Sequential. So I am not actually looking to randomize any data, just not be forced to retrieve the data records Sequentially. The amount of information I am considering would quickly erode the TI stack so I need to be able to load the info that I want, process it, and forget it. I can see myself using the 255 bytes per record so a fair amount of data is being considered. ie- Too much for Stack or Data statements.

 

As I understand it, to be able to do Random files requires that the Open statement specify FIXED file type & I don't *think* the compiler likes this. I think it wants file types to only be Variable. Just looking for confirmation my understanding here is correct. ie- Variable file types can not be read/written randomly.

[Opry99er]

Understood. In that instance, a 2D array stored in memory would be the way you're tracking position?.

 

Could you store each position's attributes into separate files on disk, then access them as needed, based on the array position?

Edited February 14, 2017 by Opry99er

[Bones-69]

I think there is some confusion. The problem is having to access the disc records Sequentially to arrive at the required record (the record is already known). So assume you need to read Record 125, usually you could;

 

INPUT #1, REC 125:A$

-Process A$ as required

 

 

But without Random file access you would have to;

 

FOR I=1 TO 125 :: INPUT #1:A$ :: NEXT I

-Process A$ as required

[+Lee Stewart]

There's always Forth!

 

...lee

[Opry99er]

I was just thinking about storing multiple data files instead of one long one.

[Bones-69]

Consider that each Disc Record might contain a string up to 255 character long containing the text location, location description & any other information/variables required. If there are 100 locations in the game, that’s 25K of my stack instantly gone if I attempt to load any of it into RAM. If I can fetch this data as required, process it, then write any changes to the same Disc Record, I go from using 25K stack to only using what I require at that specific time for that specific location.

 

That’s the whole thought process anyway.

 

In regards to Forth…. I think this old dog is too old to learn new tricks. J

[senior_falcon]

As I understand it, to be able to do Random files requires that the Open statement specify FIXED file type & I don't *think* the compiler likes this. I think it wants file types to only be Variable. Just looking for confirmation my understanding here is correct. ie- Variable file types can not be read/written randomly.

 

Relative is not supported in the compiler, though the docs are a bit fuzzy. I actually don't remember whether "update" and" append" are supported. I am not sure whether there is an easy solution to your problem but I will give it some thought.

 

From the manual:

Disc Access

Disk and other peripheral access is now supported with some limitations:
DISPLAY, VARIABLE is the only file type recognized, but you can use any length desired from DV1
to DV254.

Up to three files can be open at a time. You must use #1, #2, or #3 – do not use other file numbers.
You can only use colons in a print statement. Commas and semicolons will not save as in XB.
10 PRINT #1:”Now, is, the, time “ will print the entire string contained in the quotes.
20 PRINT #2:”Hello”:”World” or 20 PRINT #2:”Hello”::PRINT #2:”World” are equivalent.
Use LINPUT for reading strings – INPUT will be treated as LINPUT if used
LINPUT will read the entire entry including any ASCII characters (like in XB)
Use INPUT for reading numbers (like in XB)
Specify INPUT or OUTPUT when opening a peripheral for reading or writing files.
Checking for errors
Error checking only works with peripheral access. It should be set up just like in XB with the following
limitations:
ON ERROR line number transfers control to the desired line number
If you are not using ON ERROR and encounter a disk error the program will end, but without printing
the disk error message as in XB.
RETURN line number – only return to a line number. Do not use RETURN or RETURN NEXT
Other peripheral devices should work if they can use DISPLAY VARIABLE format.

[Bones-69]

Thanks for confirming Harry. I have also been thinking about the problem.

 

Maybe a possible work around might be instead of having 1 file with 100 records, perhaps having 10 files each with 10 records might be an option. In this instance you could pre-drill down to the individual disc file and then only have to process a modest number of sequential records before arriving at the highest numbered record. Actually, the more I think about this, the more I think this might be a workable option. No doubt it would never execute as fast being able to directly read the required record straight up, but I don't see why it wouldn't work.

 

Although without being able to Update... Might have to go back to the drawing board!

[Bones-69]

Actually Owen, was this kind of what you were hinting at? If so, sorry if I misunderstood.

[Opry99er]

Yes, precisely what I was saying.

 

Apologies if my wording was confusing.