Quote:
Originally Posted by RichardP
I was going to use an ESP32-Wroom32 device as a network MAC/Phy.
|
I had a look at the datasheet for ESP32-Wroom32 and it looks like a nice little device. One thing that I noticed is that there are 24 available GPIO pins on the ESP32-Wroom32, which might be a bit on the low side if you want to avoid glue logic.
The Amiga custom chips expects there to be a 256k x 16bit DRAM chip on the other side of the trapdoor expansion. The DRAM bus has 16 data pins, 9 address pins, CASL, CASU, RAS, and WE, so that adds up to 29 pins. Then the trapdoor expansion also has pins to connect a real time clock (RTC), which uses 4 address pins, 4 data pins, CLKRD and CLKWR, so that's another 10 pins; but those you may not be interested in using.
What we do is that we have an Intel MAX 10 FPGA that is connected to the pins on the trapdoor expansion (via 5V to 3.3V voltage level translators) and then the FPGA is connected to the Raspberry Pi via SPI.
Quote:
Originally Posted by RichardP
I think you are correct in your implementation for an offloaded IP stack  |
I think it should fit well with the design we went with.
The design we have is fairly flexible, since both the Amiga custom chips and the Raspberry Pi can read from and write to a shared memory. The video player that can be seen in one of the images I linked to works by the Raspberry writing bitplane data directly into the shared memory that the Amiga chipsets access directly, so playing video is done without any involvement of the Amiga CPU. Other things I have implemented are: RemoteWB (the Amiga Workbench writes its bitplanes to the shared memory, and are then read by the Raspberry, which are converted to a normal image file made available through a WebSocket to be read from a web browser, and any mouse or keyboard events in the web browser are forwarded in the other direction, so that Workbench can be controlled from that web browser somewhere on the Internet; again without any extra load on the Amiga CPU), a filesystem driver that reads and writes files to the sdcard on the Raspberry, and a utility called 'pi' such that from the AmigaDOS command line you can type "pi gcc prg.c -o prg" to run gcc on the Raspberry, and then the resulting binary is immediately available on the Amiga through the filesystem driver.
Quote:
Originally Posted by RichardP
*Although* the SANA driver requires less changes.. it should have an INIT,CLOSE, READ, WRITE, INTERRUPT and STATUS type API.. which is easier to work with.
|
It seems that implementing the SANA-II interface instead could be better suited to your design.