Speedup Loading?

[volvo_0ne]

Any of you AMOS brainboxes any ideas how to speed this up please?
I tried using

Line Input#1,AM$(INDEX)

However there is a 1000 character limit for that command and some of my elements can be way larger.

CODE:-

Open In 1,FILE$
Rem *** Read in tilemap ***
For I=0 To 239
A$=(Input$(1,1))
Poke Start(8)+I,Asc(A$)
Next I
Rem *** Null all elements of AM$ (not really needed) ***
For I=0 To 16
AM$(I)=""
Next I
Rem *** NEED to speed up this bit cos it's slooooow! ***
INDEX=0
Do
A$=Input$(1,1)
If A$=Chr$(13)
A$=Input$(1,1)
Inc INDEX
If INDEX=17 : Goto OUT : End If
AM$(INDEX)=""
Else
AM$(INDEX)=AM$(INDEX)+A$
End If
Loop
OUT:
Close 1


TIA V1

[Samurai_Crow]

Scanning for a sentinel character is always slow. If you know the length in advance, that's always faster.

[Lonewolf10]

I agree with Samurai Crow. If the lengths of the fields are known, you could add a byte (or word) value prior to each text field in the file specifying the length of the following string, thus speeding things up immensely as you can use this to jump to the next string length value in the file.

To avoid the Line Input# issue, why not load the file in as an AMOS data bank?

[volvo_0ne]

Unfortunately the length of each element is wildly variable from 0 to 1500+characters.

that is why I didn't go down the BLOAD route because the bank would have to be quite large "just in case" or re allocating could cause memory frag problems, but I'll look into it anyway.

Thanks guys

[Samurai_Crow]

Don't forget you can check the length of a file with the Lof function and allocate the exact bank size needed even if you keep your existing file format.

[volvo_0ne]

Originally Posted by Samurai_Crow

Don't forget you can check the length of a file with the Lof function and allocate the exact bank size needed even if you keep your existing file format.

Yes, but I'm storing a tilemap and an array of 17 (0-16) elements, all of which can vary enormously in size in one file, so Lof wouldn't help much in this case.

Anyway, I've (kinda) worked around it with a "Loading" screen which I may add DOESN'T say "Please Wait" (I hate that LOL).

So thanks for your ideas guys

Next Question :-

Is it possible to FORCE uppercase or lowercase in Amos inputs?

Obviously you can use upper$ etc, but that doesn't solve the problem of how your input is echoed to the screen on input.

[Samurai_Crow]

You'll have to write a custom input routine to do that. I wrote one for 8 bit Apple back in high school. It is easy using the Inkey$ function in AmosPro.

[Lonewolf10]

An alternative to using Inkey$ would be Input$(1). Unlike with Inkey$, AMOS won't continue through the code until a key has been pressed to satisfy the Input$(1).

[Samurai_Crow]

The reason I did the input routine for the Apple 2 was a custom cursor that needed refreshing.

[idrougge]

Why don't you implement your format like the IFF format, where each segment to be loaded is preceded by its size? That way you can set up your loading loop to work really fast.

[volvo_0ne]

Originally Posted by Samurai_Crow

You'll have to write a custom input routine to do that. I wrote one for 8 bit Apple back in high school. It is easy using the Inkey$ function in AmosPro.

I guess I'm just Lazy, altho a "poke" a'la the Spectrum would have been handy.

Originally Posted by Lonewolf10

An alternative to using Inkey$ would be Input$(1). Unlike with Inkey$, AMOS won't continue through the code until a key has been pressed to satisfy the Input$(1).

Yeah that would do it, I kinda knew a custom routine was required, just wondered wether there was a (lazy & code saving) alternative.

I'm a bit of a space saver if possible, and I don't think it REALLY matters in the age of mass storage, however the simplest routines are usually the most efficiant.

Thanks guys

[volvo_0ne]

Originally Posted by idrougge

Why don't you implement your format like the IFF format, where each segment to be loaded is preceded by its size? That way you can set up your loading loop to work really fast.

This has been suggested earlier in the thread.

Lazyness (again) on my part I guess, but it means re-writing 2 save & load routines in this particular case.

I could have just loaded into banks & peek'd it out again, but I hate wasting space either in mem or on disk.

[volvo_0ne]

OK
Finally got around to a small re-write, and the results of just peeking out the 2 byte length of each string element is astounding, cutting loading time by about 3/4 .

Thanks for the help guys