Apple II Pi

[David Schmenk]

This weeks project:

http://youtu.be/Kx_ggKHWaxA

Dave...

[Warren Ernst]

Dave,

Wow! That's pretty cool and impressive. I'm looking forward to future installments.

-Warr

[Michael J. Mahon]

David Schmenk <dsch...@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

[David Schmenk]

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. 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. 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.

Dave...

[Sean Fahey]

On Thursday, May 23, 2013 4:20:26 PM UTC-5, David Schmenk wrote:

> This weeks project:
>
> http://youtu.be/Kx_ggKHWaxA

David - you may remember Applied Engineering had a whimsical run of products with a Star Trek theme - Phasor, Transwarp, PC Transporter... I was thinking, if you are able to mount an RPi on a serial interface like you're planning, you could carry on that tradition and name your project the 'Jean Luc'.

You know... because it's a 'Pi-card'.

[Michael J. Mahon]

David Schmenk <dsch...@gmail.com> wrote:
> On Thursday, 23 May 2013 17:58:45 UTC-7, Michael J. Mahon wrote:
>> David Schmenk <dsch...@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?

[David Schmenk]

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...

[Michael J. Mahon]

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!

[David Schmenk]

On Saturday, 25 May 2013 01:23:56 UTC-7, Michael J. Mahon wrote:
> David Schmenk <dsch...@gmail.com> wrote:
>

SNIP

>
>
>
> 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.

Exactly, and another reason to connect the RPI to the Apple. The Apple II bus is so much easier to play around with. it seems the RPi GPIO pins are really meant to connect with other low-voltage devices that are very power sensitive. It takes a little bit of extra care and hardware to play with any real-world devices without damaging the RPi. The Apple II, on the other hand, is almost bulletproof. That is where I want to use the Apple II as a retro-Arduiono for hardware experimentation, but use code running on the RPi. Time sensitive operations, like reading/writing disk sectors, can be implemented as a downloadable routine to the Apple II and executed locally.

Dave...

[David Schmenk]

Here is an update to Apple II Pi that I thought might be of interest to anyone trying it out. You can always get the code from github.com:/dschmenk/apple2pi

The big addition is the ability to read/write the Apple II memory as well as call a routine. The serial protocol between the Apple II and RPi is able to still handle its input duties for the keyboard and mouse while sending blocks of bytes for reading and writing. The ability to call and arbitrary address is indeed powerful, but fraught with danger. If you hang the Apple II, it can't respond to the keyboard and mouse. But, assuming you haven't overwritten the actual A2PI code, a simple press of RESET will get everything re-synced.

Now, all this is great, but how do you get access to such cool features? Glad you asked. I implemented a socket interface to the a2pid daemon that allows you to send the memory and call requests to the Apple II. To test it, I wrote a very simple monitor program (compatible with the Apple I monitor) that allows you to view, change, and execute memory on the Apple II from a Linux machine. And not just from the RPi; because I used sockets for the interface, you can run the monitor program remotely. Many of us have tried to get our Apple II's on the internet - but usually doing things like web browsing or telnet. This turns it all around. The Apple II is on the net as a programmable device, not unlike Arduino, but with a socket interface. BTW, I use port 6502 for access to the a2pid server ;-) I also added a tool I wrote for Apple 1 development that takes a binary file and spits out an Apple 1 monitor compatible listing (useful to download over a keyboard<->serial interface available for the Apple 1). The reason is: because the Apple II Pi monitor program runs as a console app, you can pipe the output of a binary file through the converter into the monitor program for ease of development and code download.

Next up is to write a FUSE filesystem driver to read and write to physical ProDOS volumes from Linux. Since the Apple II is actually running ProDOS, I just have to download some wedge code to the Apple II, call it remotely, and transfer the data back and forth. The tough part is figuring out how to map the ProDOS metadata to Linux filenames.

Lastly, this isn't really tied to the Raspberry Pi. If you have a modern Linux distro, the only change you would have to make is the #define in a2pid.c that is the name of the serial port to open. I know, it should be a command line argument, I just haven't gotten there yet.

Dave...

[Steve Nickolas]

On Thu, 30 May 2013, David Schmenk wrote:

> Next up is to write a FUSE filesystem driver to read and write to
> physical ProDOS volumes from Linux. Since the Apple II is actually
> running ProDOS, I just have to download some wedge code to the Apple II,
> call it remotely, and transfer the data back and forth. The tough part
> is figuring out how to map the ProDOS metadata to Linux filenames.

Could use the CiderPress method of tailing #xxyyyy where xx is the type
and yyyy is the auxtype...

-uso.

[David Schmenk]

If all else fails, that will be the route to go. It least it would be easy to import and export to CiderPress!

Dave...

[mdj]

On Saturday, 25 May 2013 18:23:56 UTC+10, Michael J. Mahon wrote:

> 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!

The Broadcom part has 57 GPIO lines, all of which can overloaded to perform a variety of other functions (SPI, I2C, and the UART Dave is using).

The chip registers are all understandably 32-bit, with the first 32 GPIO's mapped to one register set, and the remainder to another. Read and write are separate registers, and write is separated again into set and clear registers. That's the main annoying part, as that seems completely superfluous to me ?

The rest of the 'problem' is that only 19 of the 57 lines are broken out on the RPi, and the ones chosen make it impossible (even if you configure them all as GPIO) to get 8 consecutive bits in the register, let alone have them fall on a byte boundary :-(

I suppose the designers figured the majority of users will be bit-banging rather than byte-banging. It's relatively straightforward in C to remap a byte-sized quanta appropriately if you wanted to work around it.

I expect though that the majority simply use the virtual-filesystem interface that can be effortlessly exploited in <insert-your-favourite-scripting-language>

Matt

[mdj]

On Saturday, 25 May 2013 02:44:30 UTC+10, Sean Fahey wrote:

> You know... because it's a 'Pi-card'.

<insert raspberry here>

[Daniel Kruszyna]

mdj <mdj...@gmail.com> wrote:
> The chip registers are all understandably 32-bit, with the first 32
> GPIO's mapped to one register set, and the remainder to another. Read
> and write are separate registers, and write is separated again into
> set and clear registers. That's the main annoying part, as that seems
> completely superfluous to me ?

The set and clear registers allow multiple threads of execution to
control different gpio bits without using read-modify-write opertions.
In effect, they allow you to address individual bits.

I'm not familiar with the micro used in the raspberry pi, but all of the
micros I've used that have set and clear registers include them in
addition to a standard write register.

-- Daniel

[David Schmenk]

I think another aspect to the GPIO configuration lies in the fact that most embeddable components today are intelligent, so implementing a serial bus to connect the pieces is cost effective, on a pin by pin basis. The days of parallel busses are apparently over. And I have to say, implementing a protocol over the serial port is pretty easy and fast - on both sides of the Apple II/RPi equation. Linux has a huge library of support routines for serial communication built-in. The 6511 is trivial to program from the 6502, and certainly fast enough for a 1MHz CPU when transferring at 115.2 K baud. As a speed test, I wrote a simple program (dskread.c on github) to image a ProDOS floppy and save it to a file, ala ADT. I can read and transfer the data from floppy disk, send it over the serial port (and out a socket) in just over 70 seconds. I actually had to add a small delay between writing bytes out the serial port because it was losing sync, especially when sending lots of zeros. I'm not sure I would do a whole lot better with a bi-directional parallel port, not to mention the additional programming required on the Linux side.

Since most junior hackers on the RPi just want to read pushbuttons and light up LEDs, I guess I can't fault them too much for the choice of GPIO pins exposed. Anything more sophisticated will probably have an SPI, I2C, or serial interface (RS232 or USB). Again, all the more reason to expose Apple II bus access to the internetz.

Dave...

[Michael Black]

On Fri, 31 May 2013, David Schmenk wrote:


> Since most junior hackers on the RPi just want to read pushbuttons and
> light up LEDs, I guess I can't fault them too much for the choice of
> GPIO pins exposed. Anything more sophisticated will probably have an
> SPI, I2C, or serial interface (RS232 or USB). Again, all the more
> reason to expose Apple II bus access to the internetz.
>

You have to start somewhere. My first computer was a KIM-1, and I spent a
lot of time just trying bits of code, single-stepping it. Having the
parallel port meant I could add switches and LEDs to see how those
worked.

Remember, the PI was intended for learning to program, a really cheap
descendant of the Commodoe 64 or whatever, not an embedded controller.
That there is I/O is just incidental. The fact that many are seeing it as
a cheap controller, well I don't know if that clashes with the original
intent, or just means more get sold to keep the price down.

Michael

[Neo Winston]

Hi Dave,

Where do I find the A2PI.DSK disk image?

Thank you!
Neo Winston

[David Schmenk]

Neo-

I changed the name to A2PI.PO on github. The reason is I switched from using ADTPro to using the dskread tool included in apple2pi. Because it reads and writes ProDOS order files, I changed the extension to match.

The project has also been updated with a Makefile (I'm very makefile challenged, btw) and some better documentation on how to make it work on any Linux distribution, not just Raspberry Pi.

Also, included for your Apple 1 pleasure, I ported my Apple 30th birthday tribute program (the one used to show off the last two Apple 1s that sold for $650K+) over to the Apple II. There is an Apple 1 compatible monitor program (a2mon) that you can use to remotely connect to the Apple II Pi, download and run programs.

Enjoy,

Dave....

URL http://github.com/dschmenk/apple2pi

[Neo Winston]

Thanks a lot for your reply! I do appreciate you pointing out the .PO image that I'll be using shortly :-)

And, BTW, as you wrote your response I was watching your presentation at Kansasfest about your game for the 30th Anniversary of the Apple II.

Thanks again!
Neo Winston

[David Schmenk]

Part 2: Apple IIe Pi

http://youtu.be/BX2VWZQCtkU

Dave...

[BLuRry]

> Part 2: Apple IIe Pi
>
>
>
> http://youtu.be/BX2VWZQCtkU
>
>
>
> Dave...

You are crazy. Crazy awesome! Great work!

-B

[David Schmenk]

Thanks Brendan. Usually I'm called much worse ;-) Next step is to integrate the relevant parts of the Super Serial Card onto the prototype card and eliminate the SSC altogether (along with the associated clutter).

Dave...

[Ralph]

Thanks for posting this. It's fun to see folks hooking their Raspberry Pi systems to the Apple //.

I'm (slowly) working on something similar, except with the Propeller or ATMega/Arduino chips. I think the ATMega would be a better I/O processor for Apple // connections, compared to the Raspberry Pi.

I'm considering a 74LVC244 or 245 chip to use as a bus transceiver, to convert from 3.3V to the 5V used by the 74LS TTL levels used by the Apple //. Finding a cheap source for DIP versions of those chips would be helpful, since I'd prefer not to spend more on logic-level conversion than the micro-controller itself.

[David Schmenk]

On Monday, 3 June 2013 17:59:27 UTC-7, Ralph wrote:
> Thanks for posting this. It's fun to see folks hooking their Raspberry Pi systems to the Apple //.
>
>
>
> I'm (slowly) working on something similar, except with the Propeller or ATMega/Arduino chips. I think the ATMega would be a better I/O processor for Apple // connections, compared to the Raspberry Pi.
>

Actually, I'm using the Apple II as the I/O processor for the Raspberry Pi. I find it's much easier to interface real world devices to the Apple II, either through the game port or through a proto-board/breadboard. I don't find the 3.3V low power I/O of the RPi, or the Aurdino for that matter, as easy or robust as good 'ol 5V TTL. Of course the Broadcom part in the RPi and the ATMega in the Arduino were meant for very low power applications, so it makes sense that they were designed that way. Kind of like the difference between a big block V-8 and a high-strung 4 cylinder.

>
>
> I'm considering a 74LVC244 or 245 chip to use as a bus transceiver, to convert from 3.3V to the 5V used by the 74LS TTL levels used by the Apple //. Finding a cheap source for DIP versions of those chips would be helpful, since I'd prefer not to spend more on logic-level conversion than the micro-controller itself.

I'm going to be experimenting with that myself. I'm going to interface a 3.3V serial port to the 6551. I hope I only need a voltage divider from the 6551's Tx to the BCM's Rx line. Then I hope to power the 6551's crystal input directly from the GPIO GCLK. Fingers crossed.

Dave...

[Riccardo]

Great magic work!

Could be possible to reconfigure server files to use on PC server (linux running), instead to use RPi. I'd like to browse internet by my A//c
:-)

Thanks you

Ric.

[David Schmenk]

Ric-

Apple II Pi will run just fine on a modern Linux PC. You will need a PC with serial port, or USB serial port dongle, and know the device name for it, i.e. /dev/ttyUSB0. Simply pass this device name on to the a2pid daemon. I use my old AMD Athlon PC running Ubuntu and it works great. The README on github.com/dschmenk/apple2pi has all the details.

Let me know if you have any issues,

Dave...

[Riccardo]

> Apple II Pi will run just fine on a modern Linux PC. You will need a PC with serial port, or USB serial port dongle, and know the device name for it, i.e. /dev/ttyUSB0. Simply pass this device name on to the a2pid daemon. I use my old AMD Athlon PC running Ubuntu and it works great. The README on github.com/dschmenk/apple2pi has all the details.

Ok Dave,

I just make c files on /usr/local/bin, my serial is /dev/ttyS0 and work fine with AGS Project.

Now what i should do..

Ric.

[Riccardo]

I change line to /dev/ttyS0 on file a2pid.c after i re make file and run a2pid.
Keyboard and Mouse work, i should only change the mouse parameters.

Ric.

[David Schmenk]

Ric-

follow the README on the GitHub site. No need to modify the source, just add /dev/ttyS0 to the a2pid command. 'make' and 'sudo make install' is all you have to do.

Dave...

[David Schmenk]

For a quick follow up -
I've prototyped a 6551 talking directly to the 3.3V GPIO serial port on the RPi. It took a little longer than I originally thought. The 6551 wants all it's modem control inputs hooked up to something, and it *really* doesn't like the TxD pin driving a voltage divider - even into 2.2K + 3K load. A simple buffer fixed all. Now I just need to program the RPi's GCLK to output a 1.8432 MHz signal so I can ditch the oscillator and it's good to go. A two chip interface between the Apple II and RPi (I blatantly ripped off the SSC). The next step would be looking into any interest in product-izing this card. I don't have any interest in selling a card, so I would have to partner with someone who has experience. But there would have to be sufficient demand.

Dave...

[Charles Richmond]

"David Schmenk" <dsch...@gmail.com> wrote in message
news:5a25fbe9-2a31-472c...@googlegroups.com...

>
>For a quick follow up -
>I've prototyped a 6551 talking directly to the 3.3V GPIO serial port on the
>RPi. It took a little longer than I originally >thought. The 6551 wants
>all it's modem control inputs hooked up to something, and it *really*
>doesn't like the TxD pin >driving a voltage divider - even into 2.2K + 3K
>load. A simple buffer fixed all. Now I just need to program the RPi's
> >GCLK to output a 1.8432 MHz signal so I can ditch the oscillator and it's
>good to go. A two chip interface between the >Apple II and RPi (I
>blatantly ripped off the SSC). The next step would be looking into any
>interest in product-izing this >card. I don't have any interest in selling
>a card, so I would have to partner with someone who has experience. But
>there >would have to be sufficient demand.
>

This is *not* Apple Pi... Apple Pi is here:

http://bob-bishop.awardspace.com/ApplePi/index.html

--

numerist at aquaporin4 dot com

[David Schmenk]

Of course it's *not* Apple Pi. That's why I called it Apple II Pi. Actually, if you search Apple Pi, you will probably hit a bunch of '80s user groups called Apple Pi i.e. Washington Apple Pi, Denver Apple Pi, etc.

Dave..

[David Schmidt]

Bob Bishop is a treasure.

He says his program took 40 hours to calculate 1000 digits of pi. I
compiled his Integer BASIC using the Flash! compiler, throttled AppleWin
all the way up, and it spat out 1000 digits in 1:11.

Mike Willegal has a text version of Bob's program here:
http://www.willegal.net/appleii/Bob-Bishop%27s-PI-Program.htm
It requires a little re-formatting, but it appears to me to be error
free. At least the output matches the article. :-)

[David Schmenk]

The final installment of Apple II Pi - minimal hardware implementation.

http://youtu.be/OpevIc3_H1g

[Riccardo]

Il giorno martedì 25 giugno 2013 05:57:32 UTC+2, David Schmenk ha scritto:
> The final installment of Apple II Pi - minimal hardware implementation.
>
>
>
> http://youtu.be/OpevIc3_H1g

Wow, congratulation!

Please, can you describe the connection GPIO to A2 bus?

P.S: Sorry,I haven't heard any Italian's word in the video. :-)

Ric.

[David Schmenk]

Sure, Ric-

The GPIO of the RPi is fairly limited in the total number of I/O pins available on the header. Many of the pins have alternate functionality other than just reading or writing "0" or "1". By default, two of the pins are set up as a TTL serial port. By connecting the RPi and Apple II together with the serial port, it leaves other GPIO pins available for other uses and simplifies the hardware on the Apple II side. The 6551 ACIA chip is a fully contained serial interface with the exception of an external clock signal needed for the baud rate generator. I used one of the GPIO pins from the RPi to generate the correct clock signal for the 6551 so the crystal oscillator could be deleted. As an aside, this was the original approach taken by Apple with the first Apple //c - generating the 1.8432 MHz clock from one of their custom chips. However, the output wasn't exact and caused issues, especially at lower baud rates. Later //c designs switched back to the 1.8432 MHz crystal oscillator to fix the problem.

This approach is probably similar to the fast CP/M cards that ran a 6 MHz Z-80. Because you can't sync the busses together, an asynchronous communication port had to be built to send information back and forth to essentially two separate computers. In the case of Apple II Pi, the interface is serial instead of a parallel port design, but this is transparent to the CPUs. However, there needs to be more software involved as neither side of the communications channel can directly control the other. This also provides the ability for exact timing control of the Apple II side. The RPi is not running a real-time OS, so it couldn't control the Apple II bus with cycle accurate timing if it wanted. This effort has to be done on the 6502, downloading code to execute and sending results back to the RPi.

Hope that clarifies how it is done. Only three wires needed between the RPi and Apple II (plus power and ground).

Dave...

[barrym95838]

On Tuesday, June 25, 2013 3:10:14 PM UTC-7, David Schmenk wrote:
[snip]

> This approach is probably similar to the fast CP/M cards that ran a 6 MHz Z-80. Because you can't sync the busses together, an asynchronous communication port had to be built to send information back and forth to essentially two separate computers. In the case of Apple II Pi, the interface is serial instead of a parallel port design, but this is transparent to the CPUs. However, there needs to be more software involved as neither side of the communications channel can directly control the other. This also provides the ability for exact timing control of the Apple II side. The RPi is not running a real-time OS, so it couldn't control the Apple II bus with cycle accurate timing if it wanted. This effort has to be done on the 6502, downloading code to execute and sending results back to the RPi.

[snip]
>
> Dave...

Hi Dave,

I never got to see one close up, but your design made me think of this:

http://en.wikipedia.org/wiki/Tube_(BBC_Micro)

Both ideas seem pretty cool, but beyond my present capabilities to compare and contrast.

Mike

[David Schmenk]

Hi Mike-

Definitely the same idea, but the BBC Tube looks much more sophisticated. You could think of the Apple II Pi connection as a single, 1 deep, bi-directional FIFO. In the Apple II Pi case, input is handled by the Apple II, but output is handled by the RPi, as it has much more sophisticated graphics. For a little more in-depth about the communication channel: the Apple II initiates all transactions. It runs the serial chip at 115K without interrupts, so any data transactions have to be dealt with in a tight loop. The way the RPi makes a request for a transaction is it sends the desired transaction command to the Apple II and then responds when the Apple II initiates the actual transaction. Thus, the RPi can only have one outstanding transaction request at a time. This works pretty well in actuality. Input events from the keyboard and mouse can be interleaved with other transactions. Sometimes this can cause problems when a key-up event is delayed during some other transactions (like reading the disk drive). They Linux input system sees this as a long key press and initiates the repeat key logic. So, sometimes you can see a bunch of RETURN key presses (usually the last key pressed to launch a program) if the program immediately starts downloading code to the Apple II.

Dave...

[Riccardo]

> The GPIO of the RPi is fairly limited in the total number of I/O pins available on the header. Many of the pins have alternate functionality other than just reading or writing "0" or "1". By default, two of the pins are set up as a TTL serial port. By connecting the RPi and Apple II together with the serial port, it leaves other GPIO pins available for other uses and simplifies the hardware on the Apple II side. The 6551 ACIA chip is a fully contained serial interface with the exception of an external clock signal needed for the baud rate generator. I used one of the GPIO pins from the RPi to generate the correct clock signal for the 6551 so the crystal oscillator could be deleted. As an aside, this was the original approach taken by Apple with the first Apple //c - generating the 1.8432 MHz clock from one of their custom chips. However, the output wasn't exact and caused issues, especially at lower baud rates. Later //c designs switched back to the 1.8432 MHz crystal oscillator to fix the problem.
>

I'm not sure, if i mean right: but, RPi no have any parallel port. Ok, what do you think to use serial to parallel converter IC. Side RPi speed up 115K by sync serial (think also to USB) and side A2 use all 8 bit bus at A2 system frequency. I mean, to interfacing RPi by parallel bus. Obviously, by RPi can handle like serial program (Vserial Drive), by A2 side can handle like a "normal" slot card.

Ric.

[David Schmenk]

Ric.-

That is effectively what the 6551 asynchronous serial chip does.

http://en.wikipedia.org/wiki/MOS_Technology_6551

Dave...

[Riccardo]

Dave

Hmm.. Oh yes, right. You are connected (db0-bd7) to A2 Slot bus(it's the Ic on the board that i seen in Video, sorry). But it up to 125Kbaud. You could use a more up speed version or a converter USB to Parallel. In the RPi side we have more speed to use, i think.

Ric.

[David Schmenk]

It would definitely be nice to have a chip with a deeper buffer and capable of more speed. That would come at the expense of more 6502 interface logic. So, the 6551 was a compromise between ease of interfacing and performance.

[BLuRry]

On Monday, June 24, 2013 10:57:32 PM UTC-5, David Schmenk wrote:
> The final installment of Apple II Pi - minimal hardware implementation.
>
>
>
> http://youtu.be/OpevIc3_H1g

Bravo man... Cool stuff.

I think a pro version would look like this:

1) 26-pin female socket allowing PI to be plugged in without ribbon cable or supporting rubber band. Also having a dummy (non-connected) connector for the other pins (closer to the NTSC connector) can help provide a reliable anchor.

2) Some sort of ram buffer that maps to Cx/C8 memory for the card and is written to directly by the Pi when a specific GPIO pin is set to high, otherwise I/O from the serial goes to the ACIA. This would increase the chip count, but this would also let you use Cx/C8 card memory to hold enough code that you could use the Pi as a block device directly from Prodos. Sort of like a VSDrive on lots of steroids. Even the Cx 256-byte bank alone would be sufficient I think.

-B

[David Schmenk]

On Wednesday, 26 June 2013 07:33:34 UTC-7, BLuRry wrote:
> On Monday, June 24, 2013 10:57:32 PM UTC-5, David Schmenk wrote:
>
> > The final installment of Apple II Pi - minimal hardware implementation.
>
> >
>
> >
>
> >
>
> > http://youtu.be/OpevIc3_H1g
>
>
>
> Bravo man... Cool stuff.
>
>
>
> I think a pro version would look like this:
>
>
>
> 1) 26-pin female socket allowing PI to be plugged in without ribbon cable or supporting rubber band. Also having a dummy (non-connected) connector for the other pins (closer to the NTSC connector) can help provide a reliable anchor.
>

I can't tell you how long it took to find a configuration that worked. That stupid ribbon cable caused me much grief (all the pins were flipped around on the proto board and I kept getting them wrong). Clearance, access to ports and the height of the ports all were problems. If someone can find a better orientation, I'm all for it! But having the RPi face the proto board compenent side as opposed to having the back side face the proto board made it sit pretty far away and be wider than one slot's width.

>
>
> 2) Some sort of ram buffer that maps to Cx/C8 memory for the card and is written to directly by the Pi when a specific GPIO pin is set to high, otherwise I/O from the serial goes to the ACIA. This would increase the chip count, but this would also let you use Cx/C8 card memory to hold enough code that you could use the Pi as a block device directly from Prodos. Sort of like a VSDrive on lots of steroids. Even the Cx 256-byte bank alone would be sufficient I think.
>

You could definitely do a lot with an FPGA, or some such dense logic. That was beyond the scope of my commitment to this project. But if someone else wanted to implement it, I can provide the software.

>
>
> -B

Now, if Jace could just interface directly to the disk drives....

Dave...

[BLuRry]

On Wednesday, June 26, 2013 6:31:16 PM UTC-5, David Schmenk wrote:
>
> Now, if Jace could just interface directly to the disk drives....

That would require Java to work in Real-time which it doesn't. If it did I would be having all kinds of crazy projects cooking. :-)

-B

[David Schmenk]

What if I told you it could with Apple II Pi. I can easily read and write disk data from Linux.

https://github.com/dschmenk/apple2pi/blob/master/src/dskread.c

https://github.com/dschmenk/apple2pi/blob/master/src/dskwrite.c

Dave...

[Michael J. Mahon]

Hmmm...so Linux is cycle-accurate real-time?

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

[barrym95838]

On Friday, June 28, 2013 7:45:36 AM UTC-7, Michael J. Mahon wrote:
>
>
> Hmmm...so Linux is cycle-accurate real-time?
>

I am certainly no expert on the subject, but it appears from his code snippets that David is using the real 6502 processor to run PRODOS, so he doesn't need to worry about Linux' real-time behavior ... a reliable handshake between the two processors is all that he needs. BLuRry doesn't have the luxury of an actual silicon 6502 sitting right there waiting for something to do, so his situation is different. I hope that I got that correct ...

Mike

[David Schmenk]

Mike - you are correct. I'm using the 6502 co-processor, so to speak, to do the dirty work. But, if he wanted, he could implement the same kind of code to read and write the disk from Java, assuming he had an Apple II Pi available (even across the network).

Dave...

[BLuRry]

You're only sort of right. I don't have a 6502. I do, however, have a 65C816 in the //gs that sits on my desk, 65C02s in the //c in my closet and the //e in my garage, and a 6510 in the C64 that is used to hold doors open or prop up wobbly tables as needed. And I can't forget the 6507 in my Atari 2600, modded with composite output.

What I was meaning is that you can't use a non-realtime program (basically anything that runs in any modern multitasking environment) to control things that require realtime accuracy such as bus signals. Now, what David is doing is buffering the bus through the ACIA (6551) on the card. You can talk to an ACIA from a multitasking environment since the serial logic is managed by discreet components and has adequate buffering to avoid under-runs and over-runs of the data stream.

His interface is a brilliant compact solution that replicates things found in other serial-based solutions -- except that he brings some new stuff to the table such as the keyboard/mouse interface part. All to which I must say BRAVO!! :-)

-B

[David Schmenk]

So that means you're going to hook up a Raspberry Pi to one of your 65x02s? Awesome! Actually, given how you've factored out the Media Manager from the rest of the emulator, it might not be that much work to connect to an Apple II Pi and access the floppy drive.

In reviewing the emulators running on the RPi, I didn't see JACE on the list, so I tried it out. The good news is that both the open-jdk6 (the default Java on Raspbian) and the Java 8 preview both ran JACE. Unfortunately, Java isn't too optimized on the ARM and the best it could muster is about 1/4 speed with the Java 8 preview.

All is not lost, though; the Apple II Pi code runs fine on x86 Linux. That may be the next exercise. Thanks for another fine emulator,

Dave...

[Steve Nickolas]

On Tue, 2 Jul 2013, David Schmenk wrote:

> So that means you're going to hook up a Raspberry Pi to one of your
> 65x02s? Awesome! Actually, given how you've factored out the Media
> Manager from the rest of the emulator, it might not be that much work to
> connect to an Apple II Pi and access the floppy drive.
>
> In reviewing the emulators running on the RPi, I didn't see JACE on the
> list, so I tried it out. The good news is that both the open-jdk6 (the
> default Java on Raspbian) and the Java 8 preview both ran JACE.
> Unfortunately, Java isn't too optimized on the ARM and the best it could
> muster is about 1/4 speed with the Java 8 preview.
>
> All is not lost, though; the Apple II Pi code runs fine on x86 Linux.
> That may be the next exercise. Thanks for another fine emulator,
>
> Dave...

If I had a RPi to test on, I'd prolly try to see if I could roll an
emulator specifically for the combination of the ][ and the Pi.

-uso.

[David Schmenk]

Funny you should bring that up. I actually considered porting my Appalm emulator over. It is an adequate emulator, but the constraints of the Palm OS meant that it would be severely lacking in functionality to the myriad of emulators available today. And the thought of rewriting all the 68000 code in ARM assembly, although a cool challenge, had me a little put off. Instead, taking something like gsport, the best Linux GS emulator in my opinion, and add some functionality there. I would still like it to run full screen for that fully immersive feeling - I just need to understand the architecture better. Damn the real world for interfering with my play time.

Dave...

[BLuRry]

If anything, I can use the guts of Jace sans video emulation, essentially what I did in the minecraft plugin. Java is in a weird awkward transitional state. JavaFX is due to replace Swing - and it is savy enough to use GPU acceleration. It has an entirely different programming model, and all in all is more flexible.

What this means in the short term though is that until every platform that wants to support JavaFX has to implement it. Right now the official Oracle Java had JavaFX support in JRE 7. It is freely available, but OpenJDK has not yet caught up.

For now, I'm fence-sitting. I'm using JavaFX for personal stuff that is not being widely distributed (it is Apple related but I ain't talking about it yet, pardner.) I hope to revamp Jace's GUI with the overhaul I've always wanted but couldn't pull off in Swing.

What this means for the Pi: Well, Schmenk took it pretty far. :-) Jace uses integer code for most things so it shouldn't be horribly slow. But Jace relies on Swing to pump pixels out to the screen and the Java supplied on Pi is headless.

So I can take it one of two ways: 1) I could wait for JavaFX to change the world. This has the advantage of greater portability if by chance other handheld platforms such as Android support JavaFX-based displays or 2) I could employ LWGJL the same way in which Minecraft does (and Minecraft was ported successfully to the Pi for anyone following that sort of thing.) LWGJL is capable of hardware-accelerated display and might be a good interim solution.

LWGJL might be acceptable, but it's something I haven't had time to fuss with. Still, it might be worth trying in the future once I finish other things on my plate. I think a good solid release of Jace with the current planned features is the next step. Never enough time to do the things I want to do. :-/

-B

[David Schmenk]

For anyone interested, I updated my blog with the details of Apple II Pi - including my first ever schematic capture (be kind): http://schmenk.is-a-geek.com/wordpress/?p=88

[Riccardo]

Il giorno giovedì 4 luglio 2013 02:35:09 UTC+2, David Schmenk ha scritto:
> For anyone interested, I updated my blog with the details of Apple II Pi - including my first ever schematic capture (be kind): http://schmenk.is-a-geek.com/wordpress/?p=88

David,

Do you never seen this project?

http://www.calormen.com/vnIIc/

I think, yes :-)

-Ric.

[David Schmenk]

Ric -

I have seen the video before but never knew vnIIc was updated to input keyboard and mouse events into Windows. Pretty cool. Thanks for the heads-up,

Dave...

[Cyril Thibout]

Hi

the Apple II Pi PDF manual at http://schmenk.is-a-geek.com/tarfiles/UserManual.pdf only explains how to install the Apple II Pi with with adaptor that can't be purchased now.

On https://ultimateapple2.com/ we can read a new version of the APple II pi adaptor will be released but without any details nor any date.

Can we please know a bit more about the new card please ?
And is there another installation guide without the adaptor but directly thriugh the serial port ?

thanks

cyril

[David Schmenk]

Hi Cyril-

Sorry for the lack of clarity into the forthcoming Apple II Pi card. It's a labor of love, not a full time job so the development isn't as timely as it probably should be. But, there are still options to get the full experience using off-the-shelf parts. All you need is a SuperSerial card, a USB->serial dongle, and the proper cable to connect them. Ivan's RASPPLEII page: http://appleii.ivanx.com/rasppleii/ has some great information on getting the SD card image and connection going between the Apple II and RPi.

Once you have all that connected, a simple edit to the /etc/default/a2pi file to change the DAEMON_OPTS setting to point to the USB->serial dongle. There is a default value commented out in that file which should work for most dongles.

The rest of the Apple II Pi manual is applicable to this setup: https://www.ultimateapple2.com/forum/viewtopic.php?f=3&t=3

Hope that gets you going,

Dave...