Bones-69 Posted February 14, 2017 Share Posted February 14, 2017 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 1 Quote Link to comment Share on other sites More sharing options...
Bones-69 Posted February 14, 2017 Author Share Posted February 14, 2017 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! Quote Link to comment Share on other sites More sharing options...
Opry99er Posted February 14, 2017 Share Posted February 14, 2017 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. Quote Link to comment Share on other sites More sharing options...
Opry99er Posted February 14, 2017 Share Posted February 14, 2017 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... Quote Link to comment Share on other sites More sharing options...
Bones-69 Posted February 14, 2017 Author Share Posted February 14, 2017 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. Quote Link to comment Share on other sites More sharing options...
Opry99er Posted February 14, 2017 Share Posted February 14, 2017 (edited) 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 Quote Link to comment Share on other sites More sharing options...
Bones-69 Posted February 14, 2017 Author Share Posted February 14, 2017 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 Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted February 14, 2017 Share Posted February 14, 2017 There's always Forth! ...lee Quote Link to comment Share on other sites More sharing options...
Opry99er Posted February 14, 2017 Share Posted February 14, 2017 I was just thinking about storing multiple data files instead of one long one. Quote Link to comment Share on other sites More sharing options...
Bones-69 Posted February 14, 2017 Author Share Posted February 14, 2017 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 Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted February 15, 2017 Share Posted February 15, 2017 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 DV1to 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 usedLINPUT 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 errorsError checking only works with peripheral access. It should be set up just like in XB with the followinglimitations:ON ERROR line number transfers control to the desired line numberIf you are not using ON ERROR and encounter a disk error the program will end, but without printingthe disk error message as in XB.RETURN line number – only return to a line number. Do not use RETURN or RETURN NEXTOther peripheral devices should work if they can use DISPLAY VARIABLE format. Quote Link to comment Share on other sites More sharing options...
Bones-69 Posted February 15, 2017 Author Share Posted February 15, 2017 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! Quote Link to comment Share on other sites More sharing options...
Bones-69 Posted February 15, 2017 Author Share Posted February 15, 2017 Actually Owen, was this kind of what you were hinting at? If so, sorry if I misunderstood. Quote Link to comment Share on other sites More sharing options...
Opry99er Posted February 15, 2017 Share Posted February 15, 2017 Yes, precisely what I was saying. Apologies if my wording was confusing. 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.