Many thanks Canie,

I do not know if I have answered this yet but me thinks not.

I will have to experiment myself from this point on
to learn more since no one has exact answers I
was looking for. There should be one fastest way of all
to transfer data from an array to a hard disk file
and no one seems to know what it is.
If I could see how BASIC BSAVE command is working I may have
my answer because it by far is the lightning fast
quickness I wish to have. But when I tried the BSAVE command
none of the data was in the correct order and saved were
more bytes then I wanted to save. For me to unassemble
the BSAVE routine would be a violation of the
reverse engineering agreement in any licenses so that
is out of the question for myself.

I am using a Virtual Array ( Located In EMS Memory )
and not REAL MODE memory ( First 1MB ) and there is a
possibility BSAVE may only function well in the REAL MODE
instead of PROTECTED MODE ( EVERYTHING ABOVE 1MB ) .
If I try to limit my entire program to REAL MODE
then things may be faster too.
The Originators of the IBM PC were more oriented
to Business Administration then to science so
security of design was way overboard and terribly
subtracts from IBM PC performance.
What is needed is the entire machine be REAL MODE
without the stupid form of Paginated RAM and
Interrupt ( TIME Sharing ) based design.
They have tried to do too much with a serial
CPU device which for best speed should only
run one program at a time.

Best Regards;
geoff






----- Original Message ----- 
From: "Canie" 
To: 
Sent: Monday, May 05, 2008 3:12 PM
Subject: Re: Basic Programming Help desired?


> Yes - size of the data record can have such an effect..  all these 
> little things that you'de wish the Microsoft engineers would know..
> 
> We always tried to do record sizes (of file definition sizes) of 64, 
> 256, 512, 1024 bytes..for that reason - the disk writes would be faster..
> 
> And for some reason division is slower that multiplication..  so for 
> certain things, rather than divide, we'de figure out how to 
> multiply..  also these things can be compiler dependant I assume..
> 
> Canie
> 
> At 12:09 PM 5/5/2008, you wrote:
>>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
> 
> __________________________________________________________
> 
> 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)