New hardware project

[Terence Boldt]

I have designed a new expansion card for the Apple II that takes a Raspberry Pi Zero W as a daughter board. It's an early stage of the project but I have put all the hardware design and software on GitHub so anyone can follow along with the project. So far, with the driver in RAM, I have successfully got both reads and writes to a 32 MB virtual hard drive image stored on the Raspberry Pi. Next steps are preparing the driver for EPROM. There is a lot of work needed to improve the code including error handling and tests. It's very much a proof of concept at this point but appears to be successful so far.

Planned functionality:
1. Hard drive emulation (mostly working already)
2. Real time clock for ProDOS
3. Terminal access to the Raspberry Pi
4. Web service calls from the Apple II
5. Possibly execute graphical applications on the RPi and render Apple II compatible graphics, sending them to the II for display

https://github.com/tjboldt/Apple2-IO-RPi

Regards,
Terence J. Boldt

[D Finnigan]

Terence Boldt wrote:
>
> Planned functionality:
> 1. Hard drive emulation (mostly working already)
> 2. Real time clock for ProDOS
> 3. Terminal access to the Raspberry Pi
> 4. Web service calls from the Apple II
> 5. Possibly execute graphical applications on the RPi and render Apple II
> compatible graphics, sending them to the II for display
>
> https://github.com/tjboldt/Apple2-IO-RPi
>

I think that an IO board is a really great concept for Apple II! This is
like taking the CFFA or MicroDrive cards for storage, and extending the idea
so that there are more possibilities for IO.

I like the idea of having a multi-access file store that's backed by some
Linux/Mac OS X machine where the modern OS can access the files in its
native format, and the Apple II can also access these files via what appears
to be a ProDOS volume-- all coordinated by your IO card.

On the PC/Mac side, you can drop in a file and it just appears on the ProDOS
volume. Or from the Apple II side, you've saved a file, and you can drag it
out onto your desktop, or just open it in your editor on the PC/Mac.

--
]DF$
The New Apple II User's Guide:
https://macgui.com/newa2guide/

[Oliver Schmidt]

Hi,

>I think that an IO board is a really great concept for Apple II!

Full ACK!

>This is
>like taking the CFFA or MicroDrive cards for storage, and extending the idea
>so that there are more possibilities for IO.

I see in general three use cases:
- Virtual mass storage (ProDOS block driver or Smartport driver)
- Remote login (VT100)
- Virtual printer (Firmware interface + patching Works etc.)

>I like the idea of having a multi-access file store that's backed by some
>Linux/Mac OS X machine where the modern OS can access the files in its
>native format, and the Apple II can also access these files via what appears
>to be a ProDOS volume-- all coordinated by your IO card.

I have the very same(?) idea since quite some time: I'd go about it
like this:

* ProDOS block/Smartport driver
* Backed by image file on the RPi
* ProFUSE with R/W on the RPi on the same image
* SAMBA server on the RPi accessing the ProFUSE directories

ProDOS 8 doesn't cache disk data so it's pretty save to access the
image file both from the A2 via the block/Smartport driver and ProFUSE
without any coorination. However, this approach is not supposed to
work with GS/OS.

Regards,
Oliver

[Oliver Schmidt]

Hi,

>I have designed a new expansion card for the Apple II that takes a Raspberr=

>y Pi Zero W as a daughter board.

I've been toying with that idea ever since the RPi Zero was
introduced.

I certainly don't want to hijack this thread but I think it might make
sense to briefly present the ideas I had so far. Maybe there's
something in them inspires somebody else...

1. I've been thinking about MANY options regarding how to connect the
Rpi to the A2. I started with the idea tht everything that actually
uses the 6502 to transfer data (so no A2 bus snooping, no DMA) means
that the 6502 is for sure the bottleneck. So I was always looking for
some interface allowing the 6502 to read/write many (at least 256)
bytes without having to check for each individual byte if it can be
read/written because such "burst mode" speeds up the transfer
significantly.

1.1 One option is a FTDI USB chip in a parallel FIFO operation mode,
e.g. the FT245R in 'USB to MCU FIFO Interface' mode. These chips have
"large" buffers meaning the 6502 can "assume" to be able to transfer
"lots" of bytes at a time. On the USB side of things RPi OS has great
support for the FTDI chips as virtual serial interfaces.

1.2 Another at first sight pretty strange option is a WIZnet W5100
combined with a SMSC LAN9512. The Ethernet PHYs of the two chips are
connected back-to-back. On the A2 side the setup emulates an Uthernet
II. On the RPi side the LAN9512 looks to RPi OS just like the builtin
Ethernet port of the older full size RPis.
On the RPi one configures an NAT router for the Ethernet port. This
kills two birds with one stone: I) Existing Uthernet II software gets
an IP address from the RPi DHCP and uses the RPi for wireless network
access. II) New, specific software/firmware uses TCP/IP only to
connect to processes running on the RPi. That means that both the IP
address of the A2 as well as the IP addr of the RPi Ethernet are well
known fixed values. Therefore there's no need for DHCP/DNS on the A2.
and without those it's pretty simple to setup a TCP/IP connection to a
process running on the RPi. This approach has two major benefits: I)
TCP/IP allows for end-to-end flow control which is implicitly handled
by the W5100 - the 6502 just continously reads bytes from the W5100.
It's speed of doing so controls directly the speed the RPi process
write speed. II) The A2 can connect to many different TCP/IP ports on
the RPi and thus directly connect to many different processes on the
RPi, one for a virtual drive, one for a shell, one for <you name it>.
BTW: The two downstream USB ports of the LAN9512 can be connected to
full size USB A sockets on the base PCB allowing for additional
gadgets connected to the RPi.

Both 1.1 and 1.2 have the benefit of only using the RPi USB port - no
GPIO pins. This allows to place the RPi either on the base board or
somewhere else outside of the A2. This might e.g. be necessary to
improve WiFi reception in conjunction with shielded case of the IIgs.
One can even replace the RPi Zero W with a full size RPi (for whatever
reason).

2. One of the things I like about the A2 is how quickly/easily it
reboots. On the other hand the RPi boots pretty slowly. It isn't fun
to have the RPi reboot everytime the A2 is power-cycled. I imagine
that supercapacitors might be a very elegant way to keep the RPi alive
while powercycling the A2.

>1. Hard drive emulation (mostly working already)

I always considered that the primary use case.

>2. Real time clock for ProDOS

Like ADTPro - https://adtpro.com/protocolv1.html#Read3 ;-)

>3. Terminal access to the Raspberry Pi

And from my POV even more interesting connecting from there via SSH to
"everywhere". What are your plans on the A2 software? A PROterm custom
interface driver? In case you're more after a small, fast, bare bones
code base than a feature monster you might consider
https://github.com/cc65/ip65/blob/master/drivers/a2vt100.s an
option...

>4. Web service calls from the Apple II

Yeah, I was thinking about an RPC interface to (a subset of) the cURL
functions.

>5. Possibly execute graphical applications on the RPi and render Apple II c=

>ompatible graphics, sending them to the II for display

Thought about that one a lot. With an interface like I it describe in
1.) and an A2 program moving bytes directly from the interface into
the A2 hires screen RAM even decent frame rates are possible.
Unforunately I'm far from being a Linux hacker but I presume a
'virtual framebuffer' driver would be the suitable approach for the
sending side on the RPi.

6. Printer emulation based on https://github.com/RWAP/PrinterToPDF

>https://github.com/tjboldt/Apple2-IO-RPi

Thanks :-)

Regards,
Oliver

[Terence Boldt]

On Friday, December 11, 2020 at 6:04:04 PM UTC-5, Oliver Schmidt wrote:
> I certainly don't want to hijack this thread but I think it might make
> sense to briefly present the ideas I had so far. Maybe there's
> something in them inspires somebody else...

All constructive feedback is welcome. I made it an open source project to share with the world.

> 1.1 One option is a FTDI USB chip in a parallel FIFO operation mode,
> e.g. the FT245R in 'USB to MCU FIFO Interface' mode. These chips have

> 1.2 Another at first sight pretty strange option is a WIZnet W5100
> combined with a SMSC LAN9512. The Ethernet PHYs of the two chips are

The primary reason for creating this project was for something to do during the winter and COVID-19 lockdown. I had considered ways of making the board much faster (for sure the Apple II is the bottleneck) but also wanted to keep it simple to create as a hobby. The current design is slow but is easy to understand and anyone with moderate soldering skills can put it together themselves.

> 2. One of the things I like about the A2 is how quickly/easily it
> reboots. On the other hand the RPi boots pretty slowly. It isn't fun
> to have the RPi reboot everytime the A2 is power-cycled. I imagine
> that supercapacitors might be a very elegant way to keep the RPi alive
> while powercycling the A2.

The RPi does not seem to reboot when I restart the Apple II. It only pulls the reset line low, not disconnect power. So really only the initial boot on power-up is slow. I get around this by using one of my previous projects. It boots quickly on power-up (ProDOS boot + BASIC.SYSTEM in 1.5 seconds). It's not ideal but helps take away some of the slow initial boot frustration. Someday I might combine the two designs... Boot out of ROM and then present a second drive from the RPi.

https://github.com/tjboldt/ProDOS-ROM-Drive

> Like ADTPro - https://adtpro.com/protocolv1.html#Read3 ;-)

I was reading through this to add a clock driver routine to ProDOS: https://prodos8.com/docs/techref/adding-routines-to-prodos/

> >3. Terminal access to the Raspberry Pi
> And from my POV even more interesting connecting from there via SSH to
> "everywhere". What are your plans on the A2 software? A PROterm custom
> interface driver? In case you're more after a small, fast, bare bones
> code base than a feature monster you might consider
> https://github.com/cc65/ip65/blob/master/drivers/a2vt100.s an
> option...

I haven't thought this through in detail yet. I was focused on the drive emulation first which is now working. I am finalizing the firmware so I can burn it to an EPROM and make it bootable. The firmware will be similar to what I had done for my previous project so I think I can get that done this weekend. One thing I was considering was making the RPi do all the work and just send HTAB/VTAB locations and the character for a simple bit of code to render on the Apple II side of things. It's easier to code the magic in Go or Node.js or whatever on the RPi than to make it all work in 6502 assembler. The VT100 emulation you linked though is cool.

> >4. Web service calls from the Apple II
> Yeah, I was thinking about an RPC interface to (a subset of) the cURL
> functions.

I need to think of some use cases for this. It seems like something useful in general but having the II have to fill out and parse JSON seems a bit much. Again, once I think of what and how the II might wish to consume the web service, I would likely have the RPi handle the magic and parse it down to something simpler to access in assembler.

>
> >5. Possibly execute graphical applications on the RPi and render Apple II c=
> >ompatible graphics, sending them to the II for display
> Thought about that one a lot. With an interface like I it describe in
> 1.) and an A2 program moving bytes directly from the interface into
> the A2 hires screen RAM even decent frame rates are possible.
> Unforunately I'm far from being a Linux hacker but I presume a
> 'virtual framebuffer' driver would be the suitable approach for the
> sending side on the RPi.

Once again, it's just a rough idea in my head. Perhaps something similar to a VNC protocol, sending changed chunks of graphics instead of rendering the entire page. Maybe even leverage the open source VNC and customize it to work with the card. That could potentially allow connections to other machines, not just the RPi. The RPi would act as a bridge between a machine serving VNC and the Apple II. This might be easier than hacking into graphics locally.

> 6. Printer emulation based on https://github.com/RWAP/PrinterToPDF
>

This also looks interesting. I hadn't thought of adding printer support but this is why I made my ideas and design public so that others can contribute.

I assume you are the same Oliver Schmidt I have to thank for your work on cc65 that I use to write my 6502 assembler with.

Thanks,
Terence

[Oliver Schmidt]

Hi Terence,

>> 1.1 One option is a FTDI USB chip in a parallel FIFO operation mode,=20
>> e.g. the FT245R in 'USB to MCU FIFO Interface' mode. These chips have=20
>
>> 1.2 Another at first sight pretty strange option is a WIZnet W5100=20
>> combined with a SMSC LAN9512. The Ethernet PHYs of the two chips are=20
>
>The primary reason for creating this project was for something to do during=
> the winter and COVID-19 lockdown. I had considered ways of making the boar=
>d much faster (for sure the Apple II is the bottleneck) but also wanted to =
>keep it simple to create as a hobby. The current design is slow but is easy=
> to understand and anyone with moderate soldering skills can put it togethe=
>r themselves.

And the fact that your design already works while none of my designs
was realized in 5 years shows how right you are!

>> 2. One of the things I like about the A2 is how quickly/easily it=20
>> reboots. On the other hand the RPi boots pretty slowly. It isn't fun=20
>> to have the RPi reboot everytime the A2 is power-cycled. I imagine=20
>> that supercapacitors might be a very elegant way to keep the RPi alive=20
>> while powercycling the A2.
>
>The RPi does not seem to reboot when I restart the Apple II. It only pulls =

>the reset line low, not disconnect power.

Maybe a misunderstanding. With 'reboot' I was refering to powering the
A2 off, waiting for the RAM to loose content in order to have the A2
"power up byte" become void and then powering on again. I presume that
this procedure makes the RPi reboot, doesn't it?

BTW: That's one of the things I like about the IIgs - the keyboard
driven reboot feature.

>So really only the initial boot o=
>n power-up is slow. I get around this by using one of my previous projects.=
> It boots quickly on power-up (ProDOS boot + BASIC.SYSTEM in 1.5 seconds). =
>It's not ideal but helps take away some of the slow initial boot frustratio=
>n. Someday I might combine the two designs... Boot out of ROM and then pres=

>ent a second drive from the RPi.

I've been thinking about such an approach too (a lot). At least to me
it doesn't seem woth the effort. I'd rather use opto-couplers to
electrically separate the RPi from the A2 and have the RPi powered in
the usual way via USB. Then I'd turn on the RPi together with my
monitor before actually booting the A2.

>> >4. Web service calls from the Apple II

>> Yeah, I was thinking about an RPC interface to (a subset of) the cURL=20
>> functions.=20

>
>I need to think of some use cases for this.

I think I know of a true use case. I wanted to generate and display QR
codes on the A2. I was totally surprised how complex the algorithm to
do so is. I got it generally working but it would take like an hour to
generate one. So the A2 could call http://goqr.me/api/ and display the
result.

>It seems like something useful =
>in general but having the II have to fill out and parse JSON seems a bit mu=
>ch.

I wasn't thinking of JSON. Rather of some proprietary binary format.

>Once again, it's just a rough idea in my head. Perhaps something similar to=
> a VNC protocol, sending changed chunks of graphics instead of rendering th=
>e entire page. Maybe even leverage the open source VNC and customize it to =
>work with the card. That could potentially allow connections to other machi=
>nes, not just the RPi. The RPi would act as a bridge between a machine serv=
>ing VNC and the Apple II. This might be easier than hacking into graphics l=
>ocally.

Again, I've been thinking about this a lot - and looked into VNC in
quite some detail. I consider it technically feasible, the issue is
rather that about every exsisting "content" requires a much higher
screen resolution.

The best I came up with is to customize an open source J2ME (Java 2
Micro Edition) CLDC/MIDP emulator to use the A2 for input/output and
run it on the RPi. That allows to run the loads of exsisting MIDlets.

In the MIDlet world a 280x192 monochrome screen is at least somewhat
reasonable.

>I assume you are the same Oliver Schmidt I have to thank for your work on c=

>c65 that I use to write my 6502 assembler with.

Yes - and you're welcome :-)

Regards,
Oliver

[Christian Hausen]

Hi Oliver, hi Terence,

I really love the ideas you are discussing. And I am not a hardware guy. But wouldn't be the compute module be an better option as basis for your project instead of the Zero?
https://www.raspberrypi.org/products/compute-module-4/?variant=raspberry-pi-cm4001000

Regards,
Christian

[Terence Boldt]

Hi Christian,

Thanks for showing an interest in the project. The Compute Module 4 was not chosen for the following reasons:

1. The connector is too difficult to solder by hand for a hobby project
2. The module draws too much current to be powered by the Apple II expansion bus
3. It costs more

I have a new revision of the hardware in the works that should significantly increase the communications speed. The current revision is transferring nibbles instead of bytes so the 6502 is really busy bit shifting. The new version is full byte read/write.

Terence

[ra...@palaveev.org]

Hi, I did a project in 1995 similar to the card you did, so I can share (apologies if not the correct thread) :) www.clintech.net/romcard/