Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.sys.apple2.programmer > #5732

Re: New hardware project

Show all headers | View raw

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

Back to comp.sys.apple2.programmer | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

New hardware project Terence Boldt <terence@boldt.ca> - 2020-12-10 20:26 -0800
  Re: New hardware project D Finnigan <dog_cow@macgui.com> - 2020-12-11 17:40 +0000
    Re: New hardware project ol.sc@web.de (Oliver Schmidt) - 2020-12-11 23:03 +0000
  Re: New hardware project ol.sc@web.de (Oliver Schmidt) - 2020-12-11 23:04 +0000
    Re: New hardware project Terence Boldt <terence@boldt.ca> - 2020-12-11 15:49 -0800
      Re: New hardware project ol.sc@web.de (Oliver Schmidt) - 2020-12-12 11:46 +0000
        Re: New hardware project Christian Hausen <chausenbo@googlemail.com> - 2020-12-31 09:33 -0800
          Re: New hardware project Terence Boldt <terence@boldt.ca> - 2020-12-31 10:58 -0800
  Re: New hardware project "ralle@palaveev.org" <ralle@palaveev.org> - 2021-06-05 02:14 -0700

csiph-web