English Amiga Board


Go Back   English Amiga Board > Coders > Coders. Language > Coders. AMOS

 
 
Thread Tools
Old 01 April 2016, 22:32   #1
volvo_0ne
Registered User

 
Join Date: Mar 2015
Location: Sheffield UK
Posts: 360
Speedup Loading?

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
volvo_0ne is offline  
Old 02 April 2016, 11:35   #2
Samurai_Crow
Total Chaos forever!

Samurai_Crow's Avatar
 
Join Date: Aug 2007
Location: Ft. Collins, CO USA
Age: 45
Posts: 1,306
Send a message via Yahoo to Samurai_Crow
Scanning for a sentinel character is always slow. If you know the length in advance, that's always faster.
Samurai_Crow is offline  
Old 02 April 2016, 18:24   #3
Lonewolf10
AMOS Extensions Developer
Lonewolf10's Avatar
 
Join Date: Jun 2007
Location: near Cambridge, UK
Age: 40
Posts: 1,923
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?
Lonewolf10 is offline  
Old 02 April 2016, 21:28   #4
volvo_0ne
Registered User

 
Join Date: Mar 2015
Location: Sheffield UK
Posts: 360
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
volvo_0ne is offline  
Old 03 April 2016, 06:57   #5
Samurai_Crow
Total Chaos forever!

Samurai_Crow's Avatar
 
Join Date: Aug 2007
Location: Ft. Collins, CO USA
Age: 45
Posts: 1,306
Send a message via Yahoo to 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.
Samurai_Crow is offline  
Old 08 April 2016, 23:39   #6
volvo_0ne
Registered User

 
Join Date: Mar 2015
Location: Sheffield UK
Posts: 360
Quote:
Originally Posted by Samurai_Crow View Post
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.
volvo_0ne is offline  
Old 09 April 2016, 11:38   #7
Samurai_Crow
Total Chaos forever!

Samurai_Crow's Avatar
 
Join Date: Aug 2007
Location: Ft. Collins, CO USA
Age: 45
Posts: 1,306
Send a message via Yahoo to 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.
Samurai_Crow is offline  
Old 09 April 2016, 12:20   #8
Lonewolf10
AMOS Extensions Developer
Lonewolf10's Avatar
 
Join Date: Jun 2007
Location: near Cambridge, UK
Age: 40
Posts: 1,923
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).
Lonewolf10 is offline  
Old 09 April 2016, 13:46   #9
Samurai_Crow
Total Chaos forever!

Samurai_Crow's Avatar
 
Join Date: Aug 2007
Location: Ft. Collins, CO USA
Age: 45
Posts: 1,306
Send a message via Yahoo to Samurai_Crow
The reason I did the input routine for the Apple 2 was a custom cursor that needed refreshing.
Samurai_Crow is offline  
Old 09 April 2016, 18:05   #10
idrougge
Registered User
 
Join Date: Sep 2007
Location: Stockholm
Posts: 3,927
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.
idrougge is offline  
Old 09 April 2016, 23:43   #11
volvo_0ne
Registered User

 
Join Date: Mar 2015
Location: Sheffield UK
Posts: 360
Quote:
Originally Posted by Samurai_Crow View Post
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.



Quote:
Originally Posted by Lonewolf10 View Post
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 is offline  
Old 09 April 2016, 23:50   #12
volvo_0ne
Registered User

 
Join Date: Mar 2015
Location: Sheffield UK
Posts: 360
Quote:
Originally Posted by idrougge View Post
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 is offline  
Old 23 April 2016, 22:08   #13
volvo_0ne
Registered User

 
Join Date: Mar 2015
Location: Sheffield UK
Posts: 360
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
volvo_0ne is offline  
 


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools

Similar Threads
Thread Thread Starter Forum Replies Last Post
A2091ToFast: Even more A2091/A590 speedup possible! SpeedGeek Coders. System 8 24 July 2015 15:47
Is there a way to Speedup Mouse ? Nibbler project.WHDLoad 10 08 February 2015 13:36
SuperBuster Zorro2 Speedup Mod SpeedGeek Hardware mods 12 17 September 2011 04:05
VOB speedup-system adapter Boot_WB support.Hardware 5 18 April 2006 11:53

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 13:59.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2019, vBulletin Solutions Inc.
Page generated in 0.07627 seconds with 15 queries