Page 1 of 1

Any faster way of doing PRINT FRE(0) ?

Posted: Sat Apr 27, 2013 12:50 am
by Brana
Any faster way of doing PRINT FRE(0) ?

In Basic, if you do something like this

10 DIM WRD$(1000)

You will wait at least 20 or 30 seconds until you get the amount of remaining free bytes.

Sometimes my programs need to know the amount of available (remaining) memory, but calling "FREE(0)" function occupies rather large amount of time...

So, is there any address that maybe can be "PEEK-ed" (or something like that), that could be faster than using "PRINT FREE(0)" function?

Re: Any faster way of doing PRINT FRE(0) ?

Posted: Sat Apr 27, 2013 12:55 pm
by Dbug
My BASIC memories are a bit distant, but if I remember correctly the 'FREE(0)' calls happens to be calling the garbage management code.
This code goes through all the variables and strings, and make sure they are consolidated in a way to return as much as free memory as possible.

Since you have a 1000 entries array, I guess what you are paying for is the cost of going through all the strings and check if there are holes between the various variables and move them around in memory.

Imo, the best way would be to have your own memory management for strings, but performance wise that would probably require you to have some C or ASSEMBLER code.

I guess 'TEXT.TAP' is a file that contain stuff you can load and save?

Re: Any faster way of doing PRINT FRE(0) ?

Posted: Wed May 01, 2013 2:19 am
by Brana
The "Test.tap" is only the plain example;

I currently have over 700 TAP (or "data") files that are loaded dynamically: this means when ever a certain type of information is required for processing, it will be found in some of those "data" (tap) files.

But to speed up the searching process, I have one single ("Wmenu.tap") file, that contains the "information reference" for what kind of information to look in which "data" TAP file.

Example, if my Iskra needs to load a money report for current day (expense or earnings), then it will first look at the "Wmenu.tap" to see where (in which data tap file) is that expense information actually stored, and when found, it will then proceed to load some of the "test.tap" files (they re named "data01.tap, data02.tap and so on) to get and display that information.

Or, If I miss someone's phone call at my mobile, I can just enter the caller's number in Iskra, and it will first look at the Wmenu.tap to locate my recorded phone book, and then proceed to load particular data.tap file to display the caller's name...

Whole thing is running incredibly fast: it loads the "Wmenu.tap" (reference) file, finds the required datatape according to the loaded reference, then loads the needed datatape in just one or two seconds, (it's running emulated on Euphoric at 8Mhz Oric CPU), but however - because this "data-storage method" is very dynamical (and it has almost 5 years of my heavy-personal usage!) I now might tend to run in to "Out of memory errors"...

I am thinking to ad an new reference file, which would contain only the "Print FREE(0)" report for each of the data.tap files described above, thus just to enable Iskra to have the "insight" how big the each data.tap file is (before it's being loaded), and this operation Iskra could perform "in the background" while idle, in it's screen saver (and yes, this thing even has an screen saver!) but the problem is that it would require to run on the daily basis, and each day would require at least two hours just to load every data.tap file, calculate the free (remaining) memory, and store it in the new reference tap file...

And there are days when Iskra indeed does have that "free time" for it, but there are also times when I power-on my LapTop just for 20 minutes or so, and in those cases Iskra could never manage to perform such a operation...

Will work on it... I hope :)

Re: Any faster way of doing PRINT FRE(0) ?

Posted: Wed May 01, 2013 7:21 am
by Dbug
Would it not be enough to just have the size of the tape file and not load it at all?

It's possible to call the ROM routines that handle the tape loading to just have them read the header, and from there you have access to the tape name, start and end address, plus the file type and if it's auto-loading or not.

Knowing the end and start you can easily get the size.