Re: Apple II Pi

[Michael J. Mahon <mjmahon@aol.com>]

David Schmenk <dschmenk@gmail.com> wrote:
> On Friday, 24 May 2013 11:30:14 UTC-7, Michael J. Mahon  wrote:
>> David Schmenk <dschmenk@gmail.com> wrote:
>> 
>>> On Thursday, 23 May 2013 17:58:45 UTC-7, Michael J. Mahon  wrote:
>> 
>>>> David Schmenk <dschmenk@gmail.com> wrote:
>> 
>>>> 
>> 
>>>>> This weeks project:
>> 
>>>> 
>> 
>>>>> 
>> 
>>>> 
>> 
>>>>> http://youtu.be/Kx_ggKHWaxA
>> 
>>>> 
>> 
>>>> 
>> 
>>>> 
>> 
>>>> Dave,
>> 
>>>> 
>> 
>>>> 
>> 
>>>> 
>> 
>>>> You can probably use the RPi GPIO pins to eliminate the need for a serial
>> 
>>>> 
>> 
>>>> link...  It shouldn't take more than an octal transceiver connected between
>> 
>>>> 
>> 
>>>> the RPi and the Apple bus--controlled by the Apple bus. 
>> 
>>>> 
>> 
>>>> 
>> 
>>>> 
>> 
>>>> -michael - NadaNet 3.1 and AppleCrate II: http://home.comcast.net/~mjmahon
>> 
>>> 
>> 
>>> 
>> 
>>> The RPi GPIO pins really aren't as powerful as you might think.  The
>> 
>>> choice by the Raspberry Pi foundation as to which pins to bring out to
>> 
>>> the header, was, um, a little odd.  
>> 
>> 
>> 
>> That's too bad--I find it hard to imagine that there wouldn't be at least
>> 
>> an 8-bit port there, plus a couple of lines for handshaking/interrupts. 
>> 
>> 
>> 
>> I wonder what part of GPIO they misunderstood?  Or maybe it's a limitation
>> 
>> of the Broadcom part...
>> 
>> 
>> 
>>> Once I gave in to using the serial interface as the communication channel
>> 
>>> and using the 6502 to do the dirty work, it actually made things much
>> 
>>> easier.  For one, it's pretty hard to service interrupts for the Apple
>> 
>>> Mouse remotely.  As I'm running the serial link at 115K and the
>> 
>>> communication traffic is pretty light, performance isn't much of an
>> 
>>> issue.  I would like to add the ability to read and write Apple II memory
>> 
>>> from the RPi, as well as call code on the Apple II - kind of like a retro Arduino.  
>> 
>> 
>> 
>> The first three commands/transactions I implemented for NadaNet, back in
>> 
>> the beginning, were peek, poke, and call. ;-). I figured if necessary I
>> 
>> could build anything else out of those!
>> 
>> 
>> 
>>> My thoughts on the IIe expansion card are to use a 6551 (same as the
>> 
>>> SuperSerial Card) but derive it's baud rate clock from the RPi's GPIO
>> 
>>> general purpose clock pin (thus saving a crystal).  Also connecting one
>> 
>>> of the GPIO pins to the 6502 RESET line would allow the RPI to reboot the
>> 
>>> Apple II if it hung.  Then we could play with the Apple II's I/O bus from Linux.
>> 
>> 
>> 
>> Just out of curiosity, if GPIO can't control a transceiver, how do you
>> 
>> manage to interact with the Apple bus?
>> 
>> 
>> 
>> -michael - NadaNet 3.1 and AppleCrate II: http://home.comcast.net/~mjmahon
> 
> Michael-
> 
> It's not that the GPIO's couldn't interact with an octal latch, it's just
> that they're kind of spread all over.  Some pins are assigned to certain
> function that can be re-assigned, but not neatly.  At least as far as I
> could detect.  Aside from some common block functions like serial ports,
> I2C, SPI, PWM, and CLKS, you get control of one bit per address.  So by
> using the serial port functionality that is burned into the default Linux
> distribution, I don't have to do much work for things like blocking I/O. 
> I can also write the code in user space without resorting to kernel
> drivers.  I figure simple operations like general clocks and reset lines
> would be appropriate for some other GPIO pins that are available.
> 
> All the R/W interaction with the Apple bus will be through client/server
> protocol between the ARM and 6502. It involves much hand waving and
> speculation, at the moment.  But the basic proof-of-concept seems to bear
> out the feasibility of this approach.  It does end up looking quite a bit
> like a network protocol.  Since the 6502 is the slowest part of the
> communications channel, I make it the initiator of the transactions.  I
> also don't use interrupts on the 6551 so as to not interfere with the mouse interrupts.
> 
> In the end, it kind of kind of blurs the line between emulation and
> enhancement.  Does running some code on the Apple qualify the RPi as an
> Apple II accelerator?
> 
> Dave...

Thanks, I see now what you mean. 

I'm still amazed that the RPi chip (apparently) is so unlike a
general-purpose microcontroller that it doesn't have a single-address 8-bit
port. ;-( I suppose that's what happens when you re-purpose a phone
processor!

-michael - NadaNet 3.1 and AppleCrate II: http://home.comcast.net/~mjmahon