A2D problems with AppleTalk/interrupts, esp. on LC Apple IIe Card

[mgcaret]

I should have spotted this sooner, but virtually every call to the ProDOS MLI is wrapped by a PHP+SEI and PLA combination. Example:

.proc MLI_RELAY
        sty     call
        stax    params
        php
        sei
        sta     ALTZPOFF
        sta     ROMIN2
        jsr     MLI
call:   .byte   $00
params: .addr   dummy0000
        sta     ALTZPON
        tax
        lda     LCBANK1
        lda     LCBANK1
        plp
        txa
        rts
.endproc

AppleTalk requires interrupts to be enabled, especially during system calls, and it's amazing it works with the WorkStation card at all, but apparently it is a little more forgiving of the IRQ scenario. The main reason that interrupts are required is that the AppleTalk functionality supports asynchronous modes for several calls. All calls can be made synchronously. For the extended interface this is part of the parameter list.

I am convinced that this is the source of hangs on the Apple IIe Card when there is a mounted AppleShare volume. I believe the Apple //e Workstation Card reverts to a polling mode when synchronous calls are used, because the card is effectively a separate computer and there is definitely a polling routine in the firmware. The implementation is totally different on the Apple IIe Card, where the host Mac does the bulk of the processing. I haven't been able to find it yet, but I expect that the AppleTalk firmware issues the command to the host Mac side, and if the call is synchronous, busy-waits for the interrupt or issues the WAI instruction.

ProDOS is generally smart enough to know what devices are non-interruptible and disable interrupts for them when it accesses them. If anything, MLI calls should enable interrupts.

It looks like MGTK properly uses the MLI to configure interrupts, the only sketchy thing I see is in loader.s where it plays with the vector for some reason.

[mgcaret]

Confirmed, if I change the sei to a cli in MLI_RELAY, no more hang and I actually make it all the way to the desktop.

[mgcaret]

On a related note, constructs like this:

        php
        sei
        MLI_CALL <call>, <params>
        plp
        and     #$FF            ; ???

??? = because we just nuked the P reg with plp, the Z flag no longer has the success status of the MLI call. The and #$FF corrects it.

[mgcaret]

I created a branch in my fork at https://github.com/mgcaret/a2d/tree/irqfix that simply removes all of the IRQ-disabling wrappers. Initial testing is highly promising but it will need more than just me to try it out.

[mgcaret]

Reference documentation: http://www.apple2.org.za/gswv/USA2WUG/A2.LOST.N.FOUND.CLASSICS/ACN/FAQS.AND.STUFF/A2.TECH/A2.CLASSIC/APPLETALK002.HTM

"Make sure interrupts are enabled when making ProDOS 8 calls."

"Make sure interrupts are not disabled for long periods of time, nor for a high percentage of time. Whenever interrupts are disabled, there is a chance that an AppleTalk packet will be missed (which could cause AppleShare volumes to be unmounted). The more interrupts are disabled, the more likely that packets will be missed. This risk is inherent for any application that disables interrupts (directly or indirectly), therefore, interrupts should be disabled with discretion and only when absolutely necessary."

[inexorabletash]

Your branch works for me in local testing with Virtual II and GSplus, which is all I have handy at the moment; I think that's fine for now. We can try and wrangle alpha testers with a variety of hardware.

??? = because we just nuked the P reg with plp, the Z flag no longer has the success status of the MLI call. The and #$FF corrects it.

Ah, thanks!

[inexorabletash]

And since I haven't said it enough already: thank you for lending your expertise here! Not only do you know far more about ProDOS and other system details than I do, but you clearly have more experience and knowledge (and 21st Century search tools) than the original authors.

[mgcaret]

Run Basic Here still manages to hang with a mounted AppleShare volume even with my fixes, but I don't yet know why.

Also, thanks for the kind remarks. I wish I had more time to spend actually writing code!

[inexorabletash]

BTW, were you going to submit a PR, or wait until figuring out the Run Basic Here problem?

On that note, I noticed wierdness (see #95) with when PREFIX needed to be set. I wonder if it's an issue with the BI vs. a non-local PREFIX

[mgcaret]

I was going to explore the RBH problem more this weekend. Though it’s not super critical as it should work everywhere else but the IIe Card. We are still in a much better position compatibility-wise than we were before. MG

…

Sent from my iPhone

On Feb 22, 2019, at 12:07 AM, Joshua Bell ***@***.***> wrote: BTW, were you going to submit a PR, or wait until figuring out the Run Basic Here problem? On that note, I noticed wierdness (see #95) with when PREFIX needed to be set. I wonder if it's an issue with the BI vs. a non-local PREFIX — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[mgcaret]

Well, funny enough, in RBH I added some STAs to the graphics and text pages so I could see how far it got before hanging, and I can't replicate my the issue. Weird.