4 thoughts on “plipbox magplip Setup”

1. Hello Lallafa!

   I’m couple of steps further now. It work but the double nat (generated by the slip interface plus my router) is causing me headache for file transfers. Would you think it would be possible of removing these adresses and directly communicate on the lan?

   As I can see from ifconfig, the magplip device is using flags 0x8e3 (UP,BROADCAST,NOTRAILERS,RUNNING,NOARP). By enabling ARP, the Amiga would be able to manage the MAC layer, thus communicate with other devices directly from its ip stack. This mean modification to the firmware and a way to give the MAC address of the magplip to the Amiga.

   What do you think?

   Reply ↓

2. Hi Nitz76,

   yes the double NAT setup is a bit tricky, but not that uncommon. I have the same setup here with my Fritz!Box router and it works without problems even with passive FTP. I also tested ok with telnet, wget, smbmount, yam, irc, …

   What you describe is an interesting approach: write a SANA II ethernet driver that actually accesses the ethernet chip externally on the plip box HW…
   Then no PLIP is involved and you need the parallel port protocol to exchange ethernet data and state. It would simplify the AVR code as no IP level bridging is necessary anymore but the SANA II driver will likely need a larger rewrite… In plipbox the focus was to use the Amiga driver almost unmodified and establish the missing environment on the AVR side. With your proposal the work load shifts towards the Amiga, but its an interesting approach nevertheless…

   BTW: I am currently investigating another approach: I am trying to write a small replacement bsdsocket.library that actually transports the socket layer already to the external AVR. With this approach the Amiga can do networking almost “TCP/IP stack-less” and I use the power of the external HW to do all the work. Nice thing is also that the new bsdsocket.library is implemented to also works on KS 1.3 – a real benefit for the A500s out there… The external HW could be an AVR with Wiznet chip and its silicon TCP/IP stack or even something more powerful like a Raspberry Pi 🙂 Not decided on this, yet… As I mentioned everything is still very early WIP but you can already peek on the source in my aminisocket GitHub repo.

   Reply ↓

3. Hum… interesting. So our approches are diametrically opposed. You want wish to go to an hardware impementation of the IP stack and I’m looking for a software one.

   The big questions to ask ourselves here are where is the bottleneck and where the payload bandwidth is the smaller;
   Bottle neck is the parallel port, for sure; 8 bits, shared bus with collisions and signalisation.
   In the TCP/IP stack, the payload is getting more and more padded as it goes down the layers; At layer 5, data is formatted but not inserted in the TCP or UDP socket. So, this is where the data is the smaller.

   I think at the very end, your solution would be the best. Most of the layer computations would be offloaded to the hardware. 7Mhz vs 16Mhz, in RISC, choice is easy to make.

   At this point, my suggestion here would be to use an SPI/USART embeded WIFI module like this one: http://www.gainspan.com/docs2/GS1011M-PB.pdf
   Goodbye wiring and complicated MAC/PHY coding. With this one, using an ATMEGA328 to manage the parallel port and pass the requests to the SPI and USART ports, it would be pretty easy to implement. Only thing remaining would be to write a bsdsocket.library talking to that chip. A little software would also be needed to make the WIFI module to associate with a BSID and a passkey. I already own a module like this and it’s very easy to do.

   If you are interested, I would build some usable prototypes so we could work on this together and/or with help of others in the community.

   What’s your word on this?

   Reply ↓

4. Hi Nitz76,

   bulding some nice hardware for this project sounds good to me! For now I’ll stick with the Arduino and the Ethernet Shield (with Wiznet Chip) for the first prototype as I already have the wiring set up here, but it will be great to have more HW supporting the project. I’ll take that into account and make sure the AVR SW has interfaces for different socket adapters. If something test worthy is ready I’ll post it here…

   Currently, I am playing with the parallel byte transfer layer and writing a lib for both Amiga and host side that allows to transfer byte message blocks. That will be a building block for the socket layer on top. Code is currently running on a patched FS-UAE against a virtual parallel port handled by a Python script. Next step will be real HW and an AVR…

   Reply ↓