Hello world!

I'd like to gradually expose quite a bit of functionality on my card so I expect the API is going to be pretty big, so I'd appreciate some advice on how best to structure the API interface to make it really easy to program with. The card has a Raspberry Pi on it and I use bit-banging to create a bus between the Apple II address/data bus and the Pi's GPIO pins, and the GPIO seems more than capable of working at 1mhz speeds so it can 'keep up' with the Apple II. What I'd like to do is gradually add API support for things the Pi can provide, such as HDMI monitor and all the resolutions a PI supports, 8gb of RAM, TCP/IP over wired/WIFI, USB storage/audio/printer, 1.5ghz co-processor capabilities, etc...

Any thoughts on how best to expose this type of API for easy consumption?

On Wednesday, August 10, 2022 at 10:48:43 AM UTC-7, anthon...@gmail.com wrote:
> Any thoughts on how best to expose this type of API for easy consumption?

Something like SmartPort? Single entry point with parameters on the stack?

Anthony Ortiz <anthonypaulo@gmail.com> wrote:
> Hello world!
>
> I'd like to gradually expose quite a bit of functionality on my card so I
> expect the API is going to be pretty big, so I'd appreciate some advice
> on how best to structure the API interface to make it really easy to
> program with. The card has a Raspberry Pi on it and I use bit-banging to
> create a bus between the Apple II address/data bus and the Pi's GPIO
> pins, and the GPIO seems more than capable of working at 1mhz speeds so
> it can 'keep up' with the Apple II. What I'd like to do is gradually add
> API support for things the Pi can provide, such as HDMI monitor and all
> the resolutions a PI supports, 8gb of RAM, TCP/IP over wired/WIFI, USB
> storage/audio/printer, 1.5ghz co-processor capabilities, etc...
>
> Any thoughts on how best to expose this type of API for easy consumption?
>

If the Pi is snooping every phase of every bus cycle you could copy the
interfaces of standard peripheral cards (Uthernet II for IP, SSC for
printers, video phase of the data bus for native video) and then maybe
Smartport for storage and any new facilities you want to add. By allowing
the one card to logically appear in multiple slots (user programmed e.g.
Uthernet II in Slot 1, SSC in Slot 2, Mouse card in Slot 4, Smartport in
Slot 5, Disk ][ in Slot 6) backed by emulated peripherals on the Pi you
could tap into much of the existing software base and only need to create
new Apple software to take advantage of the new features.

With the user programming of functions to slots, you could even have a
helper program in the Apple interrogate the slots for physical cards and
disallow use of occupied slots to avoid bus contention. If you want to get
really adventurous you could require your card be placed in Slot 7 and have
it subvert the boot process by appearing as a boot device, pushing the
helper program to system RAM as a boot block, interrogating the slots to
identify physical cards, allow the user to decide how to manage any
conflicts detected, and then continue the boot process as normal. That
would slow down every boot, so it might be something you’d want to be able
to disable or only perform when a certain key combination is detected.

On Tuesday, August 16, 2022 at 7:48:21 PM UTC-4, Anthony Lawther wrote:
> If the Pi is snooping every phase of every bus cycle you could copy the
> interfaces of standard peripheral cards (Uthernet II for IP, SSC for
> printers, video phase of the data bus for native video) and then maybe
> Smartport for storage and any new facilities you want to add. By allowing
> the one card to logically appear in multiple slots (user programmed e.g.
> Uthernet II in Slot 1, SSC in Slot 2, Mouse card in Slot 4, Smartport in
> Slot 5, Disk ][ in Slot 6) backed by emulated peripherals on the Pi you
> could tap into much of the existing software base and only need to create
> new Apple software to take advantage of the new features.
>
> With the user programming of functions to slots, you could even have a
> helper program in the Apple interrogate the slots for physical cards and
> disallow use of occupied slots to avoid bus contention. If you want to get
> really adventurous you could require your card be placed in Slot 7 and have
> it subvert the boot process by appearing as a boot device, pushing the
> helper program to system RAM as a boot block, interrogating the slots to
> identify physical cards, allow the user to decide how to manage any
> conflicts detected, and then continue the boot process as normal. That
> would slow down every boot, so it might be something you’d want to be able
> to disable or only perform when a certain key combination is detected.

Wow, these are some great ideas! I really like making it logically appearing in multiple slots and leveraging existing code, and I had no idea slot 7 could be used that way... You've given me a lot to think about, thank you!

Anthony Ortiz <anthonypaulo@gmail.com> wrote:
> On Tuesday, August 16, 2022 at 7:48:21 PM UTC-4, Anthony Lawther wrote:
>> If the Pi is snooping every phase of every bus cycle you could copy the
>> interfaces of standard peripheral cards (Uthernet II for IP, SSC for
>> printers, video phase of the data bus for native video) and then maybe
>> Smartport for storage and any new facilities you want to add. By allowing
>> the one card to logically appear in multiple slots (user programmed e.g.
>> Uthernet II in Slot 1, SSC in Slot 2, Mouse card in Slot 4, Smartport in
>> Slot 5, Disk ][ in Slot 6) backed by emulated peripherals on the Pi you
>> could tap into much of the existing software base and only need to create
>> new Apple software to take advantage of the new features.
>>
>> With the user programming of functions to slots, you could even have a
>> helper program in the Apple interrogate the slots for physical cards and
>> disallow use of occupied slots to avoid bus contention. If you want to get
>> really adventurous you could require your card be placed in Slot 7 and have
>> it subvert the boot process by appearing as a boot device, pushing the
>> helper program to system RAM as a boot block, interrogating the slots to
>> identify physical cards, allow the user to decide how to manage any
>> conflicts detected, and then continue the boot process as normal. That
>> would slow down every boot, so it might be something you’d want to be able
>> to disable or only perform when a certain key combination is detected.
>
> Wow, these are some great ideas! I really like making it logically
> appearing in multiple slots and leveraging existing code, and I had no
> idea slot 7 could be used that way... You've given me a lot to think about, thank you!
>

I suggest Slot 7 because it is polled first in the boot sequence. There are
some signals that are only connected to Slot 7, but every slot has the full
buffered address bus, data bus, R/W’, and clocks. The capability needs to
come from the Pi watching the buses and managing the interactions with the
Apple.
If people had a card sitting in Slot 7 that made use of the extra signals
(mostly relevant to video) then that card would most likely not have the
ROM signature of a boot device and with your card in Slot 6 the same boot
subversion approach could work.
Another thing to note is that Slot 7 is last in the DMA and interrupt
priority chains. If you haven’t looked at Jim Sather’s ‘Understanding the
Apple IIe’ then I highly recommend it. Chapter 7 gives a thorough look at
the card slots.