plipbox firmware

How to setup and use the plipbox firmware

After building your device (see plipbox hardware) you need to flash the plipbox device firmware.

This page is obsolete and moved to GitHub: Please see the firmware page there for latest details!

Note: I’ll keep the page open to preserve your comments…

 

13 thoughts on “plipbox firmware

  1. 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!

  2. This is a packet dump of what the amiga is sending me:
    42 02 00 4E 00 00 00 00 08 06 00 01 08 00 01 04 00 01 80 C0 A8 37 01 00 C0 A8 37 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    Doesn’t look good, does it? (I’m pigning 192.168.1.1)

  3. What is your setup? Post the ‘p’ output…

    Did you try: ping from Amiga to PLIP address, ping from ethernet to plipbox ethernet address?

  4. Do you mean this?

    Welcome to plipbox 0.1 20130302
    by lallafa (http://www.lallafa.de/blog)

    nn)et mask: 255.255.255.000
    ng)ateway: 192.168.002.001
    ns)erver 192.168.001.200
    ne)th port: 192.168.002.133
    np)lip port: 192.168.055.002
    na)miga p2p: 192.168.055.001
    nm)ac addr: 74:69:69:2D:30:31
    nd)hcp on: 01
    a1) arp ip: 000.000.000.000
    a2) arp ip: 000.000.000.000
    a3) arp ip: 000.000.000.000

    eth rev: 07
    DHCP: discover
    eth: link up
    DHCP: packet 02 =offer, server mac=00:10:DB:41:5A:92 ip=000.000.000.000 -> request
    DHCP: packet 05 =ack -> got values
    DHCP: my ip=192.168.001.115 mask=255.255.255.000 gw=192.168.001.001
    arp: cache do req #00
    arp: requesting MAC for 192.168.001.001
    arp: reply from 192.168.001.001: MAC=00:10:DB:41:5A:92 -> cache #00
    eth: start net

  5. 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.

  6. 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! 🙂

  7. 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?

  8. Here is as summary of the pins and their usage:

    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

  9. Thanks, it’s a bit clearer now.

    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).

Leave a Reply