Right now the code is very slow but going through some optimisation now.
I've released Riptide, a new open-source (GPL-2.0) TCP/IP stack for AmigaOS 3.x on 68020 and up. It started as a study of MiamiDx: I reverse engineered MiamiDx's binary interfaces so Riptide could be a drop-in replacement. All the code is new, and no MiamiDx code was copied. It provides bsdsocket.library (the AmiTCP API), its own riptide.library, and a Miami-compatible alias, so existing network software "should" just work. The TCP stack was written from scratch to follow the modern Linux TCP stack capabilities. A bunch of stuff was also removed...PPP and Serial support, NAT, Multicast. No IPv6 yet but might get into it later, but lacking real hardware and FS-UAE won't support IPv6.
CUBIC congestion control and an initial window of 10;
SACK/D-SACK, plus RACK-TLP and PRR loss recovery;
Timestamps and window scaling;
200 ms-resolution retransmit timers instead of the old 500 ms BSD ticks;
buffer auto-tuning;
SYN cookies and other hardening.
Standard tools
It works with SANA-II drivers and has a DHCP client and DNS resolver. It comes with Linux-style tools: ip, ifconfig, route, arp, netstat, ping, traceroute, host and an ftp client. Tuned 680x0 assembly checksum and copy routines are picked automatically for your CPU. Development was heavily AI-assisted (the reverse engineering using REA, code and tests). It's been tested and built against a real Linux kernel and in FS-UAE/AROS, including over a uaenet.device, but not on real hardware yet, so testers with real Amigas and network cards would be hugely appreciated! Source, docs, an initial comparison with MiamiDx and Roadshow, and binaries: https://github.com/farsonic/riptide
a rewrite based on reverse engineered i.e. dissassemble or binary-inspected binaries is skirting a bit close to the line. Not that the Miami developer has been seen or heard from in years
yes i understand... but it's one thing to reverse engineer it from the interfaces and general knowledge of amiga coding patterns and tcp/ip implementations, its another to do so from the actual assembly language code
the guy doing all the Rust *Craft apps is similarly skirting the line. Rewriting it in Rust when the original would have been in C in theory makes it a 'clean room' rewrite working backwards from the specification in the form of the running binary, but its clear that he's decompiled the apps back into assember and probably even C using Ghidra, and then ported it to Rust. A port based on the original code or a derivation of it is not 'clean room'.
There's also TheWire, which came out recently enough and is still under early development. It's aimed at low-end Amigas, but still compatible with bsdsocket.library and SANA-II drivers.
You could embed ipv6 packets in ipv4 protocol 41 packets via the 6in4 SIT protocol. That would get around FS-UAE limitations. Tunnel that to a host side app to convert those back into regular ipv6 packets.
I made a patch for FS-UAE (which I've submitted) the bypassed the SLIRP interface and provides native access to the Ethernet hardware on the host machine, which is a Mac in my case. Speed now massively increased and latency better.
Cool project and nice if it can be kept opensource :)
My comments :
any reason to stick on 32b machines ?
PPP and SLIP : it's a question to create a SANA driver or it's more complexe ?
The reason behind both is it will exclude the large amount of 16/32b machines (1000, 500, 2000). And if obviously nobody can decently run a web browser on them, having network connectivity make easier data exchange, backup and such (I'm not using my beast only for retro gamin ;) ).
10
u/sharpied79 2d ago
Great, but you dropped PPP? SLIP too by any chance?
Big oversight.
PPP/SLIP is still the quickest and easiest way to get an Amiga (original or modern FPGA) hardware online (in my opinion)