Atari disk image with DaynaPort network setup needed

[uweseimet]

I would like to test the DaynaPort emulation with an Atari TT, but I have failed with setting this up. This is why I am interested in a disk image with a working DaynaPort setup. A plain TOS setup without MiNT is preferred, but not required. The disk image should just contain the bare essentials, including software I can test the connection with.

[fdanapfel]

@uweseimet I've put together some information on how I got this working on my ATARI TT030 with STiNG: https://www.atari-forum.com/viewtopic.php?p=438157#p438157

If you can't get the setup to work with this information I can try to upload the disk image with my working setup somewhere sometime next week.

[uweseimet]

@fdanapfel Thank you! I am going to test this most likely tomorrow and will update this ticket with my results.

[uweseimet]

@fdanapfel With your instructions I was quite successful, and piscsi is now receiving SCSI commands for the daynaport when STiNG initializes. The logs look similar to how they look like when a Mac is connected. DHCP does not appear to work yet. The SYSINFO tool says that the TT has IP address 255.255.255.255.
@rdmark https://github.com/PiSCSI/piscsi/wiki/Dayna-Port-SCSI-Link was not fully up to date anymore. I updated the path to the bridge configuration, but there may still be something else that has changed: There was no /etc/dhcpcd.conf file on my Pi running bookworm. Maybe easyinstall would have installed it because one of the packages it installs depends on it. When not using easyinstall you have to manually install dhcpcd. Maybe this should be mentioned on the Wiki.
After installing dhcpd and following the instructions for the wired setup "brctl show" does not list eth0:

bridge name     bridge id               STP enabled     interfaces
piscsi_bridge           8000.6a650450e792       no

After attaching SCDP it says:

bridge name     bridge id               STP enabled     interfaces
piscsi_bridge           8000.6a650450e792       no              piscsi0

Any idea what's still missing?
"ip addr show" says:

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host noprefixroute 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether dc:a6:32:98:c9:d2 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::5fcc:c54f:67f3:bd6a/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever
3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether dc:a6:32:98:c9:d3 brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.103/24 brd 192.168.0.255 scope global dynamic noprefixroute wlan0
       valid_lft 3016sec preferred_lft 3016sec
    inet6 2a02:8071:2284:5340::c4ab/128 scope global dynamic noprefixroute 
       valid_lft 42620sec preferred_lft 42620sec
    inet6 fe80::30cf:c63f:6981:b6c6/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever
    inet6 fe80::653e:8185:a9d7:9ce1/64 scope link 
       valid_lft forever preferred_lft forever
4: piscsi_bridge: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 6a:65:04:50:e7:92 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::dea6:32ff:fe98:c9d2/64 scope link 
       valid_lft forever preferred_lft forever
5: piscsi0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master piscsi_bridge state UNKNOWN group default qlen 1000
    link/ether 6a:65:04:50:e7:92 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::6865:4ff:fe50:e792/64 scope link 
       valid_lft forever preferred_lft forever

[rdmark]

That's an interesting find. I think dhcpcd used to be installed by default in Buster and Bookworm, but isn't anymore in Bookworm. Let me put up a PR to add it to the list of packages to install in easyinstall.sh

[rdmark]

After installing dhcpd and following the instructions for the wired setup "brctl show" does not list eth0:

That's odd. I've never seen this behavior before. Is this on an RPi or Linux PC?

[uweseimet]

On a Pi running bookworm.

[uweseimet]

@rdmark The web tests are failing?

[rdmark]

Is the piscsi_bridge config file in /etc/network/interfaces.d/?

[uweseimet]

Yes, it is.

[rdmark]

@rdmark The web tests are failing?

Yes, but I think it's an issue with the github runners:

2.258 --2023-11-10 09:58:54--  https://github.com/rdmark/hfdisk/archive/refs/tags/2022.11.tar.gz
2.258 Resolving github.com (github.com)... 140.82.113.3
2.260 Connecting to github.com (github.com)|140.82.113.3|:443... connected.
2.362 ERROR: The certificate of 'github.com' is not trusted.
2.362 ERROR: The certificate of 'github.com' doesn't have a known issuer.

I saw this before, a few weeks ago, on one of @nucleogenic 's PRs I think.

[uweseimet]

@rdmark I double-checked everything, but there is not more to do than copying piscsi_bridge and updating dhcpd.conf, isn't it? After a reboot eth0 is not listed by brctl.

[rdmark]

And the correct network interface is defined in /etc/network/interfaces.d/piscsi_bridge, I assume? (The default is eth0 so I would expect so.)

[uweseimet]

auto piscsi_bridge
iface piscsi_bridge inet dhcp
        bridge_ports eth0

[rdmark]

Then there's no additional setup step that I'm aware of that's missing.

@benjamink Are you running the latest Raspberry Pi OS Bookworm, or the older Bullseye, on your RPi?

[uweseimet]

@rdmark He is running bullseye, I think he said so. I can run a test on bullseye later.

[fdanapfel]

@fdanapfel With your instructions I was quite successful, and piscsi is now receiving SCSI commands for the daynaport when STiNG initializes. The logs look similar to how they look like when a Mac is connected. DHCP does not appear to work yet. The SYSINFO tool says that the TT has IP address 255.255.255.255.

Glad those instructions helped! As far As I know STiNG does not support DHCP, so you always need to configure a static IP via the STiNG control panel (which is necessary anyway if the WiFi interface is used on the Pi for the Daynaport).

If you use the STiNG archive I've mentioned in my instructions there is a ping.prg in the TOOLS directory of STiNG that can be used to verify that the network connection is actually working btw.

[rdmark]

@uweseimet I filed #1331 to follow up on the network bridge investigations.

[uweseimet]

@fdanapfel Yes, the ping and traceroute tools are the ones I am currently using for testing. Somewhere it was mentioned that CAB requires a particular overlay. Do you know where to get it from? And one more question: Does STiNG work with MagiC?

[benjamink]

@benjamink Are you running the latest Raspberry Pi OS Bookworm, or the older Bullseye, on your RPi?

Just hopping in to confirm that my PiSCSIs are currently using Bullseye.

[fdanapfel]

@fdanapfel Yes, the ping and traceroute tools are the ones I am currently using for testing. Somewhere it was mentioned that CAB requires a particular overlay. Do you know where to get it from? And one more question: Does STiNG work with MagiC?

For the overlay for CAB, please check https://breakintochat.com/blog/2017/09/05/web-browsing-on-the-atari-st-with-a-cosmosex/ and http://storage.atari-source.org/atari/mirrors/kurobox.serveftp.net/internet/cabovl/

Sorry, haven't used MagiC for decades (I actually only used MagiCMac), therefore I don't know if it works with STiNG. But I think I saw it mentioned somewhere that MagiC has its own network stack (MagicNet).

[uweseimet]

@fdanapfel After switching to bullseye the bridge is now working, and in the piscsi log I can see that the daynaport emulation is constantly being pulled for packets. sysinfo shows that the TT has IP 10.10.20.2, but traceroute and ping (I tried 8.8.8.8, which can be pinged from elsewhere) are not working. Any idea what I may be missing? route.tab looks fine to me.

[fdanapfel]

@uweseimet Does pinging the gateway of that network (10.10.20.1) work?

If not then the issue is most likely with the ROUTE.TAB file as far as I can remember (sorry, it's been a while since I last used the Atari TT with the PiSCSI, since I've now switched to a BlueSCSIv2 which also supports the Daynaport emulation if a Raspberry Pi Pico W is used).

[uweseimet]

@fdanapfel Pinging the gateway does not work, but I think I know now why. (I'm not a networking expert.) The 10.10.20.0 network only exists when the bridge is set up for wlan0. In my case it's currently eth0, and the Atari most likely gets its IP in the regular local network, in my case 192.168.0.0. I guess I will have to configure a static IP to be asigned to the MAC STiNG uses. Not sure though, how the PI's dhcpcd DHCP and the DHCP of my regular router can both provide IPs for the 192.168.0.0 network. The PI's DHCP configuration does not say anything about 10.10.20.0.

[uweseimet]

I will keep this ticket open until I have also managed to get everything running with wlan0 instead of eth0.

[uweseimet]

@fdanapfel Can you recommend an ftp client?

[fdanapfel]

@uweseimet Take a look at https://www.atari-forum.com/viewtopic.php?t=34155 or https://www.janatari.de/atari-firebee/anwender-software/litchi-ftp-client/

[uweseimet]

@fdanapfel Thank you, I will. I also found pftp, and was able to successfully connect to an ftp server.

[uweseimet]

With wlan0 I was also succesful. @fdanapfel Once again thank you for your help. Using my Atari with the daynaport is a great help when testing changes. Now that I know how to configure STiNG for the daynaport I will try again to also get it working with my Riebl card. Till now I could only use it with Linux-68k and Atari's SVR4. The last time I tried to use it with STiNG I had no success.

[fdanapfel]

@uweseimet Glad to hear that it is working and happy that I could help.

Good luck with the Riebl card. Would love to have one of those, but its next to impossible to find them nowadays. I‘ve managed to get a Pams Net card a while ago, but could not get it to work with either STiNG, MiNT or Atari SVR4 ☹️

[uweseimet]

@fdanapfel As far as I know there is no ASV driver for the Pams Net card.
I have tried to set up the RIebl card with STING, but the CPX crashes with a bus error when doing that. This is what I also observed when I tried it the first time long ago. There might just be a bug in the CPX, but it could also be a bug in ETHER.STX, for instance. It should be possible to manually set up STING.PRT, but I do not know how it would have to look like regarding the card type/jumperr settings (VME TT/MegaSTE etc.). I expect information on this in STING.PRT.

[fdanapfel]

@uweseimet Yepp, the only supported network card for ASV unfortunately seems to be the Riebl cards 😩

Not sure if you are aware of this, but the source code for STiNG is available at https://github.com/th-otto/STinG
Maybe this is useful for you to figure out how to get it working with your Riebl card.

[uweseimet]

@fdanapfel I was not aware of that, indeed. Thank you. It's even for Pure C, which is fine for me. For Atari software I would not want to work with GCC, neither native nor as a cross compiler.
The sources of Roger's DaynaPort driver might be interesting, especially in the context of PiSCSI. But somehow I have the impression that he does not have the sources anymore.

[fdanapfel]

@uweseimet The sources of the DaynaPort driver for MiNT are available as part of FreeMiNT: https://github.com/freemint/freemint/tree/master/sys/sockets/xif/daynaport

Looks like they are from the same person who created the driver for STiNG, so maybe they are useful even if the Source of the STiNG driver isn't available anymore.

[uweseimet]

@fdanapfel :) Yet another interesting link, thank you.

[uweseimet]

@fdanapfel With a patch HDDRIVER can map SCSI IDs to LUNs of ID 0. On my TT the DaynaPort driver now also works when the emulation is assigned a LUN > 0. This is probably interresting when using the internal host adapter of the MegaSTE, which only supports a single SCSI ID. I do not have a good setup for testing this with a MegaSTE, though.
Do you know a tool for the Atari that can patch binaries and apply binary patches?

[fdanapfel]

@uweseimet Sorry, no I don't know of any such tool.

Over on https://www.atari-forum.com/viewtopic.php?t=43204 somebody was trying to get the DaynaPort emulation that is now also available on the BlueSCSIv2 to work with a MegaSTE, with the BlueSCSIv2 attached to the internal ACSI to SCSI adapter. But the problem seems to be that at least the DaynaPort driver for STing only is able to use LUN0, and even with the MapLunsToIDs of the BlueSCSIv2 it is not possible to get the DaynaPort driver to recognize the emulated DaynaPort adaper when the internal ACSI to SCSI adapter of the MegaSTE is used: https://www.atari-forum.com/viewtopic.php?p=453610#p453610

[uweseimet]

@fdanapfel Yes, the problem with BlueSCSI is identical with what you observe with PiSCSI. This is something that must be resolved on the Atari side. BlueSCSI/PiSCSI cannot do anything about it.

[uweseimet]

@fdanapfel There is a performance issue I noticed with the MegaSTE (but ACSI i general is affected) where a patch to BlueSCSI or PiSCSI would help: ACSI/DMA can only transfer multiples of 16 bytes. Any excess bytes are stuck in a FIFO. For hard drive sectors this is not an issue. But with commands where the number of bytes returned is not a multiple of 16 an additional SCSI command has to be sent in order to flush the buffer..
With the DaynaPort this is quite an issue, because the drivers (both Mac and Atari) poll for network data several times per second. Usually the amount of data returned is not a multiple of 16. With ACSI this effectively doubles to number of SCSI commands sent per second. In the piscsi logs I can see that for ACSI almost always two commands are needed for each polling cycle. Sending just one kind of command several times per second will definitely not make the MegaSTE faster. Doubling the amount of commands makes things even worse.
If PiSCSI or BlueSCSI were ensuring that always multiples of 16 bytes are returned this would help. As far as I can tell the network packets sent back are often padded anyway, so padding as such appears not to cause an issue for the drivers.

[uweseimet]

@fdanapfel Instead of a patched HDDRIVER there is a tool for the AUTO folder now. No patching required anymore.