Re: 32MB is size???

["Bryan Parkoff" <none@nospam.net>]

"Paul Schlyter" <pausch@saaf.se> wrote in message 
news:e0t3r7$17dl$1@merope.saaf.se...
> In article <HKeYf.44493$_S7.34984@newssvr14.news.prodigy.com>,
> Bryan Parkoff <none@nospam.net> wrote:
>
>> "Paul Schlyter" <pausch@saaf.se> wrote in message
>> news:e0pfuc$2s0u$1@merope.saaf.se...
>>> In article <vTVXf.7800$4L1.2405@newssvr11.news.prodigy.com>,
>>> Bryan Parkoff <none@nospam.net> wrote:
>>>> "Paul Schlyter" <pausch@saaf.se> wrote in message
>>>> news:e0oh20$2h45$1@merope.saaf.se...
>>>>> In article <iAHXf.51135$2O6.5759@newssvr12.news.prodigy.com>,
>>>>> Bryan Parkoff <none@nospam.net> wrote:
>>>>>
>>>>>> Hi, I suggest you to read "Beneath to ProDOS" and "Beneath to DOS 
>>>>>> 3.3"
>>>>>> manual.  DOS 3.3 is designed to read 256 bytes per sector at this 
>>>>>> time.
>>>>>> ProDOS is designed to read 512 bytes per two sectors at this time. 
>>>>>> It
>>>>>> shows that ProDOS is faster than DOS 3.3 for reading and writing
>>>>>> because
>>>>>> double sectors are stored in the RAM.
>>>>>
>>>>> No, that's not the reason ProDos reads so much faster than DOS 3.3.
>>>>>
>>>>> One can fairly easily patch DOS 3.3 so it reads about as fast as
>>>>> ProDos does.  A number of special DOS'es, with these patches, are
>>>>> known by names like Diversi-Dos, Pronto-Dos, etc --- all of them use
>>>>> 256-byte sectors, both at the sector level as well as at the OS level.
>>>>>
>>>>> -- 
>>>>> ----------------------------------------------------------------
>>>>> Paul Schlyter,  Grev Turegatan 40,  SE-114 38 Stockholm,  SWEDEN
>>>>> e-mail:  pausch at stockholm dot bostream dot se
>>>>> WWW:     http://stjarnhimlen.se/
>>>>
>>>> Paul,
>>>>
>>>> Well, unpatched DOS 3.3 executes 6502 instructions by using extra 
>>>> cycles
>>>> because of crossing page boundary.  ProDOS borrowed patched DOS 3.3 to
>>>> reduce cycles by increasing performance so crossing page boundary is
>>>> avoided.
>>>>
>>>> Bryan Parkoff
>>>
>>> I never denied that.  But you claimed that this page boundary stuff was
>>> the reason unpatched DOS 3.3 reads disk so much slower than ProDos.  And
>>> that's what I objected to.
>>>
>>> The reason unpatched DOS 3.3 is so slow is that it pipes all its disk
>>> I/O stuff through a "read one byte" (and, if writing, "write one byte")
>>> subroutine.  And that subroutine saves and restores an environment 45
>>> bytes
>>> large each time it is called.  This means that if you read (or write) a
>>> large
>>> number of bytes, those 45 bytes are needlessly swapped back and forth 
>>> for
>>> each and every byte read.  This slows down unpatched DOS 3.3 enough to
>>> make it miss the next sector when it passes under the disk r/w head,
>>> forcing
>>> DOS 3.3 to wait another disk revolution for the next sector.
>>>
>>> Compared to this "swap 45 bytes back and forth for each and every byte
>>> read",
>>> the delay due to the page boundary stuff you mention is quite
>>> insignificant.
>>>
>>> -- 
>>> ----------------------------------------------------------------
>>> Paul Schlyter,  Grev Turegatan 40,  SE-114 38 Stockholm,  SWEDEN
>>> e-mail:  pausch at stockholm dot bostream dot se
>>> WWW:     http://stjarnhimlen.se/
>> Paul,
>>
>>     Well, I can't remember the article when patched DOS 3.3 and ProDOS 
>> had
>> some ways to reduce approximately 10,000 cycles which it runs faster.
>>
>> Bryan Parkoff
>
> From where do you get the figure 10,000 cycles?  That's about 40
> cycles for each byte of data in a sector....
>
> My code for patching standard DOS 3.3 for faster file load and text
> file I/O can be found here:
>
> http://bobsc5.home.comcast.net/aal/1983/aal8304.html#a1
> http://bobsc5.home.comcast.net/aal/1983/aal8307.html#a3

Paul,

    I apologize when I did not explain clear.  I do not mean to decrease or 
increase performance when 8 bits of data is read from or is written to the 
disk.  The fact is that critical timing is always the same from DOS 3.3 and 
ProDOS.  I suppose that 32 cycles are needed to save 8 bits or 1 byte of 
data into RAM, but 40 cycles are used for sync detection.
    Now, I am saying reading 512 bytes from disk is faster than 256 bytes 
from disk.  After 256 bytes of data is read, one or more routines are 
executed to cost approximately 5,000 to 10,000 cycles.  Some programmers 
have found some ways to read 512 bytes of data at this time before routines 
are executed.  It saves about 10,000 cycles.
    It is not good to reuse routines twice for each sector (256 bytes) that 
costs more cycles.  I stated earlier when I don't remember exactly what I 
read an article.
    Do you know what I explain well?

Bryan Parkoff