[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Apple II Pi
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...