Roger Wilco Canie;

I have found when dealing with the disk
it matters how many bytes you can deal with
in a single instruction/operation and that those bytes
match the sector sizes on the disk itself.
I think that one sector can be entirely
written in a single write operation
but if you use odd sizes it slows things down.
Possibly the way the compiler does things
is also important like DMA or Interrupt
type programming. DMA between ram and disk
is most probably the best way to go for a
stable machine. But this would require
assembly programming of a custom nature
and Id have to go back to school to
be able to do this.
The sector sizes vary according to
where you are on the disk and what the
format type happens to be.
It seems to me that powers of two relating to
512 bytes is possible the right thing to do.
Someone has all the answers but finding
a willing person to share such knowledge
is very difficult for myself. Such expert people are
typically too sensitive about sharing knowledge.
They are capitalists with eyes that see only money
and not true amateurs seeking and sharing knowledge.
Thanks for your input.
DMA = Direct memory access where you wind up the hard
drive ( or whatever ) and it goes and gets its own data from ram
by itself using the transfer times between machine (CPU) cycles.
regards;
geoff



----- Original Message ----- 
From: "Canie" 
To: 
Sent: Monday, May 05, 2008 9:52 AM
Subject: Re: Basic Programming Help desired?


> I've worked with basic programming for about 30 years..  no ms basic, 
> but a flavor of basic..  and whenever we were trying to speed such 
> things up, it was known that for-next loops were rather slow...
> 
> You might play around with a while-wend statements to see if that 
> executes and faster, or just use a counter and gotos...  interesting 
> test for timing of things..
> 
> Canie
> 
> At 09:15 AM 5/5/2008, you wrote:
>>THANK you but this is not the problem I am addressing.
>>A/D is not the concern at this time.
>>ALL data is saved to an array that resides somewhere
>>in MSDOS EMS RAM. What I am trying to do is
>>save that array as fast as possible FROM RAM to a file
>>residing on hard disk. This lets me turn off the
>>disk while the recorder is running and turn on the drive
>>only for file operations ( permanent storage ).
>>I have always had troubles quickly dealing with
>>file formation and lots of bytes.
>>If you play with BSAVE command you will
>>find it is almost instant unlike my own programs.
>>If only I could make a program as fast as BSAVE
>>BASIC command then I could do anything I need to
>>in this regard very quickly and miss few samples
>>inbetween recordings.
>>
>>Immediately below is the routine which does this
>>operation as fast as I have ever done it.
>>Comments are welcome.
>>
>>Regards;
>>geoff
>>
>>*************************
>>$LIB COM        ON
>>$LIB FULLFLOAT  ON
>>$LIB VGA        ON
>>$ERROR BOUNDS   ON
>>$ERROR NUMERIC  ON
>>$ERROR OVERFLOW ON
>>$ERROR STACK    ON
>>$CPU 80386
>>$COM    1024
>>$STRING 32
>>$STACK  2048
>>$SOUND  256
>>$DYNAMIC
>>$COMPILE EXE "TEST.EXE"
>>$FLOAT NPX
>>$OPTIMIZE SPEED
>>$EVENT
>>$OPTION CNTLBREAK ON
>>
>>DIM VIRTUAL DATA_1?(0:32780)
>>
>>' Create a test set of data
>>FOR a = 0 to 32780 : DATA_1?(a) = ( 65 + a MOD 58 ) : NEXT a
>>' Create the path and filename
>>FILE1$ = "c:\data\test.dat"
>>' Write The Array in EMS RAM To The File on HARD Drive
>>CLS
>>PRINT "NOW SAVING DATA TO FILE c:\data\test.dat "
>>OPEN FILE1$ FOR BINARY AS #1
>>FOR ka = 0 to 7
>>  tmpz1$ = ""
>>  For kb = 0 to 4095
>>    kc = (( ka * 4096 ) + kb )
>>    tmpz1$ = tmpz1$ + chr$(DATA_1?(kc))
>>  NEXT kb
>>  kd = ( ka * 4096 )
>>  SEEK #1,kd : PUT$ #1,tmpz1$
>>NEXT ka
>>tmpz1$ = ""
>>FOR ka = 32256 to 32769
>>  tmpz1$ = tmpz1$ + chr$(DATA_1?(ka))
>>NEXT ka
>>SEEK #1,32256 : PUT$ #1,tmpz1$
>>CLOSE #1
>>tmpz1$ = ""
>>END
>>*********
> 
> __________________________________________________________
> 
> Public Seismic Network Mailing List (PSN-L)
> 
> To leave this list email PSN-L-REQUEST@.............. with 
> the body of the message (first line only): unsubscribe
> See http://www.seismicnet.com/maillist.html for more information.
__________________________________________________________

Public Seismic Network Mailing List (PSN-L)