7a51c13e   
   From: alawther@spammenot.mac.com   
      
   Anthony Ortiz  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.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)