Changes to DynaPORT to allow the amiga A590/A2091 and GVP scsi interfaces to use it

[RobSmithDev]

I've written a network driver for the Amiga to use the DynaPORT interface on BlueSCSI.

For anyone that wants to try it, there’s a prebuilt version of this along with the driver and instructions here (https://github.com/RobSmithDev/daynaport-amiga/releases/tag/release)

During my testing I discovered a strange problem with the way the A590 (scsi.device on the Amiga) was handling data received from the DynaPORT read command. I discovered that unless the data received was a multiple of 24 bytes, the trailing end of these bytes didn't get received proerply and never ended up in the buffer received from the driver, even though it claims to have read this amount.

With the GVP SCSI interface (gvpscsi.device) Firstly, issuing the command to request the MAC address caused the driver to throw a GVP invalid status message instantly. The same also happened when calling READ with larger network packets. For example ping replies didnt cause a problem, but downloading files did.

To fix these issues I created an extra two extra SCSI_NETWORK_WIFI_CMD sub commands. One as an alternative method for obtaining the MAC address (which only sends back 6 bytes) and the other as an alternative READ command, which simply redirects it back at the original code but with some flags.

To make sure I dont mess up the existing solution, the new code will only trigger if this special READ command was used. If it was, it has two modes. One will perform the rounding up to 24-bytes, with code to ensure no buffer overrun occurs. The other mode performs a single write including the header, instead of the two (header, delay, data) the original DynaPORT read did.

I've had these on test for a few days and seems stable enough. I'm planning on pushing the driver public on GitHub from Sunday 3rd to coinside with a video on my YouTube channel. If you'd like access to either of these materials beforehand please message me.

[jcs]

If your driver doesn't work with a real DaynaPort device, it should probably use its own interface rather than struggling to conform to an arbitrary interface that DaynaPort created 30 years ago. I would rather see this Amiga code in its own simplified driver that doesn't change the DaynaPort code and (ab)use WiFi commands to tell BlueSCSI it's an Amiga.

The DaynaPort code in BlueSCSI should probably be renamed from a generic "network" driver to something specific to DaynaPort if there are going to be multiple network implementations, and the Wi-Fi DA code extracted out to a separate file as well.

[RobSmithDev]

Thanks for your comments and feedback. The limitations are unfortunatly beyond my control, and I understand what you are saying. Making an entirely new network interface might be more work than required when in reality its only a small change, and the WIFI parts aren't technically part of the original Daynaport either

Your proposal regarding renaming the generic network files etc seems like a good idea, but is way beyond my paygrade as this wasn't my implementation, I have just modified it.

[LinuxJedi]

@jcs as a first step, would it be better if:

• network.c / .h contains generic common code
• daynaport.c / .h is created for daynaport specific things
• amiganet.c / .h is created for amiga specific things

For now it would function similar to this PR, but be better organised and we can remove the hacks from the Amiga driver, using basically just the command set Rob created for the GVP. Then in future the Amiga code here can altered as needed without having to touch the Daynaport code.

If this is acceptable, I'm happy to assist @RobSmithDev with this. Alternatively we can work on something completely unique, but it will take significantly more time.

[jcs]

@LinuxJedi yes that would be great