GEOS Interrupt Manager - Githubissues

oliverschmidt commented 6 years ago

I don't know if you are aware of the fact that GEOS suffered from the very same issue (no timer source in a stock //e). They solved it by creating a simplistic timer source slot card and including it with the software.

Drop in at 32:07 on http://www.open-apple.net/2015/10/31/show-052-robert-bowdidge-geos-geos-and-more-geos/ to get some details. And look at http://www.open-apple.net/wp-content/uploads/2015/10/IMG_5116.jpeg see the device at the lower left.

Unfortunately I'm not able to find any technical details on that "GEOS Interrupt Manager" card. Nevertheless I thought you might be interested to learn about its existence...

burniouf commented 6 years ago

Yes, i read about this card, quickly googling, i found this: http://mirrors.apple2.org.za/ground.icaen.uiowa.edu/MiscInfo/Hardware/interrupt.card

if only we could find a least one of this board...or good pics of both sides.. ... Another option could be to dissassemble GEOS....searching something like LDA /STA $C70x....as it is supposed to run only from Slot 7......they surely hard coded the address in he sources...

oliverschmidt commented 6 years ago

quickly googling, i found

Ah, I searched for "interrupt manager" without luck, searching for "irq manager" does the trick :-)

oliverschmidt commented 6 years ago

The Hitchhikers Guide to GEOS contains:

The Apple GEOS Interrupt Management Card

The Berkeley Softworks IRQ Management card requires reenabling after every interrupt in order to generate the next interrupt. Part of the Apple Interrupt Level processing reenables the IRQ Generator card to interrupt on the next vblank. Normally this will keep interrupts triggering on a regular basis. However, if the IRQ Managememt card generates an interrupt while the 6502 interrupt disable bit is set, the interrupt service routine will not run, and the IRQ Management card will never be reenabled for the next interrupt.

Apple GEOS attempts to keep interrupts running by reenabling the IRQ Management card during MainLoop and whenever call through the jump table switches banks. Normally applications will do this often enough in their normal operation to reenable the IRQ Management card on a regular basis. It is conceivable, however, that in some very odd cases neither of these circumstances will occur often enough (very odd cases, indeed — if an application is both disabling interrupts and not going back to MainLoop, there is probably something fundamentally wrong with the structure of the program). An application can reenable the IRQ Management card when necessary with the following sequence:

        bit        intSource              ;check the interrupt source
        bvc        5$                     ;ignore if not BSW card IRQ Manager
        sta        IRQ_GEN                ;otherwise, trigger IRQ Manager
5$:

[...]

Apple GEOS draws the mouse cursor (soft sprite #0) at interrupt level so that it can minimize flicker by avoiding the raster beam. However, because different interrupt sources (mouse vs. BSW IRQ Generator) pull the IRQ line low at different times in the Vblank sequence, the sprite is either drawn earlier or later depending on its position on the screen.

[...]

intSource    $02c6    Byte to indicate where interrupts are coming from on the Apple.

Please note that there's no value given for the label IRQ_GEN. However, looking for access to $02c6 I found this code sequence:

        2c c6 02        bit $02c6
        50 03           bvc done
        8d f0 c0        sta $c0f0
done:   60

This is basically exactly what one would have expected for a simple device only working in slot 7. However, I haven't found any information if beside that "reenabling" some initial setup is required.

burniouf commented 6 years ago

We surely could find some other pieces of information here and there.... My fear is that the kernel INIT should be able to detect this hardware.....and playing with I/O in slot7 could be dangerous....ProDOS should have i already identified any block device if present in S7 at this stage... i already met this problem when scanning for NICs with I/O based detection method.....

oliverschmidt commented 6 years ago

i already met this problem when scanning for NICs with I/O based detection method.....

Therefore my NIC drivers strictly stay clear from any general I/O based auto detection! Only after the user has set a "NIC slot" my drivers detect the NIC type...

burniouf commented 6 years ago

btw, with the board description (about 6 pins used) and the few LS used...probably only one IO location is used.....so scanning for STA $C0F0 and LDA $C0F0 in the GEOS kernel...we could find the "detect" method, followed by the INIT method...

burniouf commented 6 years ago

I solved the NIC I/O detection problem with a list of "used slots" in "kernel config block", just to prevent scanning slot 6 while trying to find the LANCEGS.... see : https://github.com/burniouf/A2osX/blob/master/DRV/LANCEGS.DRV.S.txt and : https://github.com/burniouf/A2osX/blob/master/DRV/UTHERNET2.DRV.S.txt works pretty well!

oliverschmidt commented 6 years ago

with the board description (about 6 pins used) and the few LS used...probably only one IO location is used.....

That's why I wrote "expected for a simple device" above. I'm pretty sure there are only STA accesses to $C0F0.

oliverschmidt commented 6 years ago

I solved the NIC I/O detection problem with a list of "used slots" in "kernel config block", just to prevent scanning slot 6 while trying to find the LANCEGS.... [...] works pretty well!

As long as there's no unknown device ;-))