Share this:

Like this:

13 comments to plipbox firmware

Hey!
I managed to compile it and make it work… up to the point I’m trying to ping. I added some debugging information and here is what I get:
plip(rx): not amiga! 001.000.192.168 vs 192.168.055.001
For some reason, the packet get garbled some way and I can’t make it to communicate.
Help!

The sequence C0 A8 37 01 00 C0 A8 37 02 is strange as the two IP should follow without a zero byte.
This leads to the assumption that byte reception via parallel generates “ghost” bytes.
Maybe signalling is too noisy due to long cabling? How long are your parallel wires? Less than 10cm should work ok.

Hum… less than 3cm. The prototype is pretty clean. I suspect the AmiTCP configuration.
I wasn’t able to install it the same way as you did. I installed it as a Norway, then I changed the config to magplip.
Can you provide a .adf of your working test disk?
Thank you! 🙂

Ok, it’s not archived. Name was confusing.
I’ll give that a try.
Any chance about what signal is used for what on the parallel port?
I saw that Strobe is used to signify the magplip that a new byte is available from the Amiga. Ack is used to signify the Amiga that the byte was processed. I assumed two other signals are used to do the opposite (communication from the magplip to the Amiga). The last one is maybe used to tell that the magplip is online?

STROBE: Its automatically triggered by the Amiga whenever a byte is put on the parallel port. We use it on plipbox to detect wether the Amiga wants to start sending a packet. During packet transfer this line is ignored. On AVR its connected to an IRQ capable line, but currently I do polling.

ACK: If plipbox triggers this one then an Amiga IRQ is triggered in the MagPlip driver and then the receive loop is started. This is only used to detect an incoming packet on the Amiga side. In the packet receive/send loops the IRQ is disabled.

SEL: This signal is set by my MagPlip driver patch whenever a packet transfer is ongoing. I use this signal to improve robustness in collision scenarios: This might happen when the Amiga starts to send a packet and also plipbox wants to send one. With this signal the plipbox double checks this signal before starting a send operation.

POUT/BUSY: These are the actual handshaking lines when transferring the bytes of a packet. One is toggle by the Amiga to signal
that a byte is ready and plipbox answers with toggling the other line. If the transfer direction changes then plipbox starts toggling its line to notify about an available byte and the Amiga accepts it by toggling its line. Note that for both directions the lines are always assigned to the same peer. BUSY is out on plipbox and POUT is input.

For more details see the patched MagPLIP driver source and the AVR files plip.c and par_low.c

I’m struggling now with FTP transfers. I tried in both active and passive mode. I think the issue comes from the address in between the amiga and the plipbox. There is a NAT but the nat is not supported by the protocol.

What Internet applications did you where able to run?
Actually, telnet is the only one working properly (TCP plain syn-ack).