A great business opportunity for someone. Rest assured anything I design will be 100% open source and not need rare or hard to use parts.

I am thinking of doing this too. Don't want my A500 to miss out on all the fun!

Shouldn't be a problem. The bus interface is pretty simple.

Another thing I am thinking of including is ISA bus slots so you can use PC I/O cards. Think of the possibilities - pop in an MDA card and you can finally have Text Mode on your A1000! (only 36 years too late).

You can buy them. Not sure how economical they are today but I've got two here.

https://twinind.com/index.php/produc...typing-boards/
https://www.digikey.com/catalog/en/p...ping-kit/81942

The FPGA on the OxU950 boards were for the controller not PCMCIA glue logic. We were designing the controller.

The hard bit IMO is not the interfacing to an external peripheral of the era. Most interfaces are extremely simple, just wires. The hard bit is writing an AmigaOS driver. But this could be just because I've never done one.

Some people have done AmigaOS PCMCIA drivers

Neil Cafferkey wrote a 3c589 PCMCIA network card SANA2 driver and Prism2 PCMCIA Wifi card SANA2 driver.

Some guy called Bruce Abbott wrote/contributed to the NE2000 PCMCIA network card SANA2 driver.

But are SANA2 drivers easier to write than full AmigaOS drivers? Than say a Poseidon USB host driver?

Thanks for that. The first one looks like what I want. "Call for Price/Avail." could be a problem though in these Covid-infested times, so I will probably just whip up a layout in Eagle and get a few boards made at OSHpark or PCBway. Just have to figure out a safe way to unsolder the connectors from these dismantled PCMCIA cards I have. Should cost a bit less than $200!

:)

They said it couldn't be done because Commodore's implementation of PCMCIA was incomplete so PC PCMCIA cards were fundamentally incompatible. The guy who wrote the ICard driver told me they had to develop a special card for the Amiga for this reason. But I proved them wrong.

Some cards do not work for one reason or another, but a lot do work. And just like with other PC stuff, a lot of the time the problem is not fundamental incompatibility but cards with nonstandard operational requirements or latent bugs that just happen to work OK on a PC because they have to. The biggest problem with PC cards is getting the information required to write a working driver. I examined the Linux PCMCIA network card drivers to get some clues.

Making an Amiga compatible card is not hard. If it is only going to be used on the Amiga and you don't need hotswapping etc. then the design can be very simple. For many applications you don't need a complex controller on the card, and the driver can be simpler too because it knows which card is (or should be) inserted so it doesn't have to parse tuples etc. No need to deal with PC peculiarities, just design the card to be compatible with the Amiga's PCMCIA port and you're done!

Writing a robust SANA II driver was tricky, partly due the complexities of TCP/IP etc., and partly because the reference Amiga driver code was incomplete and Amiga network stacks were still evolving.

I am betting a USB host stack will be easier. If an Arduino can do it then it can't be hard, and we can probably use the same software with minor modifications. I would look at interfacing a cheap Arduino USB host module, or a generic module such as the CH376 (which I used on the Mattel Aquarius). Another option might be an MCU with USB OTG capability.

Another thing we don't have to worry about on the Amiga is making the card thin enough to fit inside the PCMCIA slot. People complain about how the card sticks out the side, but this turns out to be a good thing because we can load the PCB with standard sized parts like DIP ICs, full size USB connectors etc. This can make the card much cheaper and easier to build than having to use special low-profile components.

One annoying problem with the Amiga 600/1200 PCMCIA slot is there is only one of them. I want to expand that to at least 2 slots. Another possibility is to add 'clockport' connectors so we can use cards designed for this.

When the A600 came out people complained about how Commodore had dropped the A500's expansion connector so we wouldn't be able to use all the stuff that was produced for it. But that was mostly only a few hard drive / RAM expansion boxes, and hanging a big box off the side via that huge Zorro I connector would have been very inelegant. The A600 had an internal IDE port so the only real issue was FastRAM (PCMCIA RAM cards were rare and expensive). Then someone came up with the idea of plugging a board directly over the CPU and the FastRAM problem was solved.

The challenge was getting the PCMICA port to work with other devices. Back then we thought bummer, a whole new incompatible bus that is very expensive to design for. But it turned out the only real challenge was mechanical. It didn't take long for Amiga hardware developers to realize that they didn't have to duplicate all the baggage that PC cards needed. The Squirrel SCSI, Surf Squirrel, Archos Overdrive, and Aura sound card all had just enough interface logic to access the port.

The problem today is that most of the 5v tolerant embedded USB controllers with AmigaOS drivers like the Transdimension UHC124 used on the Subway (and would be practical here) are now EOL (end of life) :(

I don't think there is much point in doing anything above "USB2.0 Full Speed" as I don't think the PCMCIA port has the bandwidth?

ICs with I/Os that are not 5V tolerant may need level shifting buffers. You will see these in many modern designs for the Amiga. However both the A600 and A1200 PCMCIA ports have TTL bus buffers that only pull up weakly above 3.3V, so you could probably get away without level shifters. A 3.3V regulator will be required to power the IC of course, but this is not a big deal.

Well that's a relief, because the PCB layout and devices needed to support USB3 at 5 Gbit/s are very critical. Amiga wins again!

Can I use a USB 3.0 device in a USB 2.0 port?

I was more meaning it's not probably not worth trying to do USB2.0 "High-Speed".

If you could find some Transdimension UHC124s anywhere, the Subway driver I *believe* was open-sourced together with the source code of Poseidon (the Amiga USB stack)

Well Full Speed is only ~1.2MB/s which is well within the capabilities of the Amiga's PCMCIA port, while High Speed is up to ~48MB/s which is well beyond it. But the point is that later devices are still required to support lower speed operation so it's not necessary to support the highest speeds. A High Speed USB 2 controller might require a 30MHz 16 bit bus for maximum continuous throughput, but would still be faster than Full Speed on the Amiga even if it has to slow down to 3.5MHz.

For the zip 250 USBPCM (subject of this thread) full speed should be fast enough because the drive itself can't even manage 1MB/s.

That's good to know. I found a Github repository for the Poseidon driver, then discovered that during the last few days Github has become incompatible with my PC! I wonder if I can download it with IBrowse? If not then I will have to crank up the Linux box...

I am thinking an MCU solution like this might be a better bet. Some PIC24 and PC32 MCUs have a parallel slave port that could be interfaced directly to the PCMICA bus for data transfer and commands, with the MCU taking care of low level USB stuff. Alternatively an STM32 or other MCU with USB host capability could be used with a few latch/buffer interface chips (might want to do this anyway to get 16 bit transfers). Other peripheral ports in the MCU such as SPI, I2C, and GPIO could also be brought out for other purposes. MCU firmware updates could be installed via a separate header and/or through a bootloader controlled by the Amiga.

Advantages of this solution include not being tied to a particular USB host chip that may become obsolete, and reducing CPU load on the Amiga (which only has to send high level commands and transfer data). I have been thinking about producing something like this to replace the CH376, which has a few annoying limitations and (again) may not be available forever.

By not exposing the USB side of things to the Amiga you loose the overhead of a USB stack. But in what format do you try to get the data over to the Amiga? A custom format requires a custom driver? A custom driver for each USB class? Mass Storage, HID, Ethernet, Wifi, Sound etc.

If you forget about hot-plug and you forget about USB hubs. I imagine you could emulate existing single function PCMCIA devices?

e.g. Mass Storage becomes... PCMCIA CF card? Uses CFD driver?

Just an idea.

All drivers are 'custom' drivers, but the bridge between the MCU and Amiga could use a generic protocol that works with many different devices, with lower level USB commands for controlling devices that need it (a bit like SCSI direct in Amiga block devices).

This is how the CH376 does it. Its MCU handles the low level controller stuff but gives the host the access it needs to utilize the device. The host can eg. find out what is plugged into the USB port, mount a block device and read and write sectors on it etc. The CH376 also has a FAT filesystem handler in it so the host can work at an even higher level - get a directory listing, open a file by name and read/write/delete change directory etc. (very useful on low powered machines that don't don't have their own DOS!). Other devices that the CH376 doesn't know about can be used by working with USB packets, with the MCU still doing all the low level USB controller stuff (so the host doesn't need to know how the controller works).

At the higher level most devices should be pretty generic already, so the interface protocol can be similar to existing devices and converting an existing driver would be easy. For other devices you can develop whatever 'bridge' protocol is easiest and most efficient, with the MCU handling the messy details of the actual device protocol.

I am talking about hot-plugging the PCMCIA card. Of course USB devices would be hot-pluggable, but the USB interface card would stay plugged in (not saying it couldn't also be hot-pluggable, but this is more difficult for software to handle and risky for the hardware).

Yes, the idea is that you can have Amiga drivers that are similar to what we already have. USB memory sticks and hard drives would have a block device driver like CFD, USB sound would have an AHI driver, network devices would be SANA-II etc. But the Amiga might just be sending 'generic' commands on to the MCU rather than working at the USB packet level.