Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.sys.apple2.programmer > #3257 > unrolled thread

Different prerequisites for ProDOS 8 MLI API

Back to article view | Back to comp.sys.apple2.programmer

Contents

  Different prerequisites for ProDOS 8 MLI API Benoit0123 <bgilon@free.fr> - 2017-02-06 13:43 +0000
    Re: Different prerequisites for ProDOS 8 MLI API John Brooks <jbrooks@blueshiftinc.com> - 2017-02-06 08:09 -0800
      Re: Different prerequisites for ProDOS 8 MLI API Benoit0123 <bgilon@free.fr> - 2017-02-12 10:35 +0000
      Re: Different prerequisites for ProDOS 8 MLI API Benoit0123 <bgilon@free.fr> - 2017-02-12 10:52 +0000
      Re: Different prerequisites for ProDOS 8 MLI API Benoit0123 <bgilon@free.fr> - 2017-02-12 14:02 +0000
        Re: Different prerequisites for ProDOS 8 MLI API John Brooks <jbrooks@blueshiftinc.com> - 2017-02-12 13:28 -0800

#3257 — Different prerequisites for ProDOS 8 MLI API

Hi all,
I am in the process of developing a ProDOS 8 utility, and am getting getting
some weird results in some cases.
I got a look at two reference manuals available online, that is:
The ProDOS 8 TRM, and
Beneath Apple ProDOS by Don Worth and Peter Lechner.

The requirement being on the io_buffer address that should be passed to the
OPEN MLI call.
The PRM states that the io_buffer address should point to a non allocated
1024 bytes buffer beginning at a page address ("$XY00" address)
The Beneath Apple ProDOS states that the io_buffer address should point to a
page with the same properties as stated above but in addition that the page
number be *even* (I understand: divisible by 2). One block for the index
data storage, and the other block for the data storage itself.

For the time being the buffer setup start @ address $B900 and ends @ address
$BCFF and I am getting some weird result but not always.
My asking is: do you know from your experience if the requirement that the
page # for specifying the buffer begin be even is a valid requirement or
not.

The buffers setup by BI (BASIC.SYSTEM) start @ adress $9600, $9200, ... so
are always compliant with the stricter constraints quoted above.

Thank your for any information on this,

Anyway tonight I will reorganize my code and give it a try once I am back @
home.

Regards,
Benoît


-- 
Growing old is mandatory..
growing up is optional..
But the other way round is as true.

[toc] | [next] | [standalone]

#3258

On Monday, February 6, 2017 at 5:44:59 AM UTC-8, Benoit0123 wrote:
> Hi all,
> I am in the process of developing a ProDOS 8 utility, and am getting getting
> some weird results in some cases.
> I got a look at two reference manuals available online, that is:
> The ProDOS 8 TRM, and
> Beneath Apple ProDOS by Don Worth and Peter Lechner.
> 
> The requirement being on the io_buffer address that should be passed to the
> OPEN MLI call.
> The PRM states that the io_buffer address should point to a non allocated
> 1024 bytes buffer beginning at a page address ("$XY00" address)
> The Beneath Apple ProDOS states that the io_buffer address should point to a
> page with the same properties as stated above but in addition that the page
> number be *even* (I understand: divisible by 2). One block for the index
> data storage, and the other block for the data storage itself.
> 
> For the time being the buffer setup start @ address $B900 and ends @ address
> $BCFF and I am getting some weird result but not always.
> My asking is: do you know from your experience if the requirement that the
> page # for specifying the buffer begin be even is a valid requirement or
> not.
> 
> The buffers setup by BI (BASIC.SYSTEM) start @ adress $9600, $9200, ... so
> are always compliant with the stricter constraints quoted above.
> 
> Thank your for any information on this,
> 
> Anyway tonight I will reorganize my code and give it a try once I am back @
> home.
> 
> Regards,
> Benoît
> 
> 
> -- 
> Growing old is mandatory..
> growing up is optional..
> But the other way round is as true.

In ProDOS 2.4.1, the 1KB 'open file' buffers only need to be page aligned. Perhaps an earlier version of ProDOS required even page alignment, but I see no such requirement in 2.4.1.

What kind of 'weird results' are you seeing when the buffer starts on an odd page?

-JB
@JBrooksBSI

[toc] | [prev] | [next] | [standalone]

#3271

John Brooks wrote:
> On Monday, February 6, 2017 at 5:44:59 AM UTC-8, Benoit0123 wrote:
>> Hi all,
>> I am in the process of developing a ProDOS 8 utility, and am getting
>> getting
>> some weird results in some cases.
>> I got a look at two reference manuals available online, that is:
>> The ProDOS 8 TRM, and
>> Beneath Apple ProDOS by Don Worth and Peter Lechner.
>> 
>> The requirement being on the io_buffer address that should be passed to
>> the
>> OPEN MLI call.
>> The PRM states that the io_buffer address should point to a non allocated
>> 1024 bytes buffer beginning at a page address ("$XY00" address)
>> The Beneath Apple ProDOS states that the io_buffer address should point
>> to a
>> page with the same properties as stated above but in addition that the
>> page
>> number be *even* (I understand: divisible by 2). One block for the index
>> data storage, and the other block for the data storage itself.
>> 
>> For the time being the buffer setup start @ address $B900 and ends @
>> address
>> $BCFF and I am getting some weird result but not always.
>> My asking is: do you know from your experience if the requirement that
>> the
>> page # for specifying the buffer begin be even is a valid requirement or
>> not.
>> 
>> The buffers setup by BI (BASIC.SYSTEM) start @ adress $9600, $9200, ...
>> so
>> are always compliant with the stricter constraints quoted above.
>> 
>> Thank your for any information on this,
>> 
>> Anyway tonight I will reorganize my code and give it a try once I am back
>> @
>> home.
>> 
>> Regards,
>> Benoît
>> 
>> 
>> -- 
>> Growing old is mandatory..
>> growing up is optional..
>> But the other way round is as true.
> 
> In ProDOS 2.4.1, the 1KB 'open file' buffers only need to be page aligned.
> Perhaps an earlier version of ProDOS required even page alignment, but I
> see no such requirement in 2.4.1.
> 
> What kind of 'weird results' are you seeing when the buffer starts on an
> odd page?
> 
> -JB
> @JBrooksBSI
>
Thank you for your reply.
It seems that, reading a 283 blocks (tree file storage type 3) file segment
by segment by interleaving SET_MARK MLI calls with READ calls of size 256
bytes will lead to some memory pages (always the same two pages in my
experience) be badly populated (ie. from non correct disk blocks).
My current testing is with the 2.4.1 version of ProDOS.
For the time being I have a query for people like you more knowledgeable on
the subject than I.
In the ProDOS TRM section 3.3.1, it is said that ProDOS MLI uses page zero
locations $40-$4E but restores them before it completes a call. However and
from my own vision, it does not seem to do so. Maybe (and likely) I
misunderstand this sentence but what I did before calling MLI was to save
locations $3A through $3F before calling MLI and restore them after the MLI
call complete (as the paragraph says that Disk drivers might use those
locations but not restore them. Should I do the same for address $40-$4F?
The static organization of the file I am currently trying to read is
described @
http://bgilon.free.fr/apple2/DOPMemMap.ods (Libre Office spreadsheet
format).
But for the time being, I am inclined to think that the culprit is the page
zero management by either ProDOS or my program.
I will be proceeding on my own testing in the days to come.

Thank you for reading,
Benoît


-- 
Growing old is mandatory..
growing up is optional..
But the other way round is as true.

[toc] | [prev] | [next] | [standalone]

#3272

John Brooks wrote:
> On Monday, February 6, 2017 at 5:44:59 AM UTC-8, Benoit0123 wrote:
>> Hi all,
>> I am in the process of developing a ProDOS 8 utility, and am getting
>> getting
>> some weird results in some cases.
>> I got a look at two reference manuals available online, that is:
>> The ProDOS 8 TRM, and
>> Beneath Apple ProDOS by Don Worth and Peter Lechner.
>> 
>> The requirement being on the io_buffer address that should be passed to
>> the
>> OPEN MLI call.
>> The PRM states that the io_buffer address should point to a non allocated
>> 1024 bytes buffer beginning at a page address ("$XY00" address)
>> The Beneath Apple ProDOS states that the io_buffer address should point
>> to a
>> page with the same properties as stated above but in addition that the
>> page
>> number be *even* (I understand: divisible by 2). One block for the index
>> data storage, and the other block for the data storage itself.
>> 
>> For the time being the buffer setup start @ address $B900 and ends @
>> address
>> $BCFF and I am getting some weird result but not always.
>> My asking is: do you know from your experience if the requirement that
>> the
>> page # for specifying the buffer begin be even is a valid requirement or
>> not.
>> 
>> The buffers setup by BI (BASIC.SYSTEM) start @ adress $9600, $9200, ...
>> so
>> are always compliant with the stricter constraints quoted above.
>> 
>> Thank your for any information on this,
>> 
>> Anyway tonight I will reorganize my code and give it a try once I am back
>> @
>> home.
>> 
>> Regards,
>> Benoît
>> 
>> 
>> -- 
>> Growing old is mandatory..
>> growing up is optional..
>> But the other way round is as true.
> 
> In ProDOS 2.4.1, the 1KB 'open file' buffers only need to be page aligned.
> Perhaps an earlier version of ProDOS required even page alignment, but I
> see no such requirement in 2.4.1.
> 
> What kind of 'weird results' are you seeing when the buffer starts on an
> odd page?
> 
> -JB
> @JBrooksBSI
OK in my experience, as the time to read disk blocks for faulty pages
(starting at RAM page $AA), instead of accessing absolute disk block $52A9
as it should, it tries to read disk block $5200 (see posted document on my
site as quoted in a previous message). I've set a breakpoint on my device
driver entry point for doing so: emulators are sometimes great tools.. ;-)
Benoît




-- 
Growing old is mandatory..
growing up is optional..
But the other way round is as true.

[toc] | [prev] | [next] | [standalone]

#3273

John Brooks wrote:
> On Monday, February 6, 2017 at 5:44:59 AM UTC-8, Benoit0123 wrote:
>> Hi all,
>> I am in the process of developing a ProDOS 8 utility, and am getting
>> getting
>> some weird results in some cases.
>> I got a look at two reference manuals available online, that is:
>> The ProDOS 8 TRM, and
>> Beneath Apple ProDOS by Don Worth and Peter Lechner.
>> 
>> The requirement being on the io_buffer address that should be passed to
>> the
>> OPEN MLI call.
>> The PRM states that the io_buffer address should point to a non allocated
>> 1024 bytes buffer beginning at a page address ("$XY00" address)
>> The Beneath Apple ProDOS states that the io_buffer address should point
>> to a
>> page with the same properties as stated above but in addition that the
>> page
>> number be *even* (I understand: divisible by 2). One block for the index
>> data storage, and the other block for the data storage itself.
>> 
>> For the time being the buffer setup start @ address $B900 and ends @
>> address
>> $BCFF and I am getting some weird result but not always.
>> My asking is: do you know from your experience if the requirement that
>> the
>> page # for specifying the buffer begin be even is a valid requirement or
>> not.
>> 
>> The buffers setup by BI (BASIC.SYSTEM) start @ adress $9600, $9200, ...
>> so
>> are always compliant with the stricter constraints quoted above.
>> 
>> Thank your for any information on this,
>> 
>> Anyway tonight I will reorganize my code and give it a try once I am back
>> @
>> home.
>> 
>> Regards,
>> Benoît
>> 
>> 
>> -- 
>> Growing old is mandatory..
>> growing up is optional..
>> But the other way round is as true.
> 
> In ProDOS 2.4.1, the 1KB 'open file' buffers only need to be page aligned.
> Perhaps an earlier version of ProDOS required even page alignment, but I
> see no such requirement in 2.4.1.
> 
> What kind of 'weird results' are you seeing when the buffer starts on an
> odd page?
> 
> -JB
> @JBrooksBSI
>
Hereby I can confirm that by embedding the MLI call between two code
segments LDA $49 PHA LDA $48 PHA and PLA STA $48 PLA STA $49, the issue is
solved, that is ProDOS MLI is using page zero locations $48 and $49 (as
quoted in paragraph 3.3.1) and not restoring them once the call is complete.
Just hoping that none of the page zero locations $40-$4E are to be made
persistent between two MLI calls by ProDOS kernel.
Regards,
Benoît



-- 
Growing old is mandatory..
growing up is optional..
But the other way round is as true.

[toc] | [prev] | [next] | [standalone]

#3275

On Sunday, February 12, 2017 at 6:04:47 AM UTC-8, Benoit0123 wrote:
> John Brooks wrote:
> > On Monday, February 6, 2017 at 5:44:59 AM UTC-8, Benoit0123 wrote:
> >> Hi all,
> >> I am in the process of developing a ProDOS 8 utility, and am getting
> >> getting
> >> some weird results in some cases.
> >> I got a look at two reference manuals available online, that is:
> >> The ProDOS 8 TRM, and
> >> Beneath Apple ProDOS by Don Worth and Peter Lechner.
> >> 
> >> The requirement being on the io_buffer address that should be passed to
> >> the
> >> OPEN MLI call.
> >> The PRM states that the io_buffer address should point to a non allocated
> >> 1024 bytes buffer beginning at a page address ("$XY00" address)
> >> The Beneath Apple ProDOS states that the io_buffer address should point
> >> to a
> >> page with the same properties as stated above but in addition that the
> >> page
> >> number be *even* (I understand: divisible by 2). One block for the index
> >> data storage, and the other block for the data storage itself.
> >> 
> >> For the time being the buffer setup start @ address $B900 and ends @
> >> address
> >> $BCFF and I am getting some weird result but not always.
> >> My asking is: do you know from your experience if the requirement that
> >> the
> >> page # for specifying the buffer begin be even is a valid requirement or
> >> not.
> >> 
> >> The buffers setup by BI (BASIC.SYSTEM) start @ adress $9600, $9200, ...
> >> so
> >> are always compliant with the stricter constraints quoted above.
> >> 
> >> Thank your for any information on this,
> >> 
> >> Anyway tonight I will reorganize my code and give it a try once I am back
> >> @
> >> home.
> >> 
> >> Regards,
> >> Benoît
> >> 
> >> 
> >> -- 
> >> Growing old is mandatory..
> >> growing up is optional..
> >> But the other way round is as true.
> > 
> > In ProDOS 2.4.1, the 1KB 'open file' buffers only need to be page aligned.
> > Perhaps an earlier version of ProDOS required even page alignment, but I
> > see no such requirement in 2.4.1.
> > 
> > What kind of 'weird results' are you seeing when the buffer starts on an
> > odd page?
> > 
> > -JB
> > @JBrooksBSI
> >
> Hereby I can confirm that by embedding the MLI call between two code
> segments LDA $49 PHA LDA $48 PHA and PLA STA $48 PLA STA $49, the issue is
> solved, that is ProDOS MLI is using page zero locations $48 and $49 (as
> quoted in paragraph 3.3.1) and not restoring them once the call is complete.
> Just hoping that none of the page zero locations $40-$4E are to be made
> persistent between two MLI calls by ProDOS kernel.
> Regards,
> Benoît
> 
> 
> 
> -- 
> Growing old is mandatory..
> growing up is optional..
> But the other way round is as true.

Nice work tracking that down.

I can confirm that ProDOS 2.0.3 through ProDOS 2.4.1 use Zero Page locations $40-$4F as temp working memory. These 16 bytes are not saved/restored across MLI calls, and they are not expected to contain any particular values at entry to the MLI.

Unfortunately, the ProDOS documentation is not up-to-date, and I'm afraid you got bitten by one of these discrepancies.

One technique I find helpful while using & modifying ProDOS is to run the ProDOS exerciser application to independently test any odd behavior. If a ProDOS operation works in the exerciser, but fails in my application, I assume I have a corrupt memory bug or error in my MLI parameters.

Hope that helps.
-JB
@JBrooksBSI

[toc] | [prev] | [standalone]

Back to top | Article view | comp.sys.apple2.programmer

csiph-web