sp193
commented
7 years ago The more I think about it, I think I can see a reason for the DEV9 DMA callbacks. If DMA is enabled for both SMAP and ATA simultaneously, the SPEED may be unable to correctly determine where the incoming data is supposed to go. That could explain why my custom HDLDump servers in 2011 had reliability issues with the PlayStation 2 hanging, with the HDD activity indicator left on.
A long time ago, our homebrew SMAP (PS2ETH) and ATAD modules did not have support for the callbacks, and so DMA was enabled/disabled in the device driver modules before the DEV9 DMA function is used. Incoming frames were handled from within the interrupt context of the SMAP driver too, so it would have been possible to interrupt an ongoing transfer from ATA. This situation would fit the triggering conditions for such a problem if it exists...
Right now, I think I'm starting to lean towards the alternative ATAD module (i.e. atad-legacy.irx) for software to optionally use.
rickgaiser
Jay-Jay-OPL
barronwaffles
BatRastard
Some clone/compatible adaptors are no longer compatible with our late designs of ATAD and DEV9. Due to the likelihood of there actually being a multitude of models out there by various manufacturers, the model in question here is a 2015-edition of the GameStar adaptor.
We're in 2017 and the PlayStation 2 is no longer a mainstream console. Since the genuine network adaptor was only released in the US and Japan (and in Europe as only part of the PS2Linux kit), the majority of the world did not see releases. There is possibly a group of users around who may end up with some of the poorly-made adaptors, but may not have the means/do not want to replace them. It is evident that at least GameStar used the (then) sources of ATAD and DEV9 to write the logic for their adaptors, changing how our modules worked has caused such adaptors to become incompatible.
Some of the changes in recent years to ATAD and DEV9 (since 2015) include: -Additional check on the ICRC error state. -Moving the enabling/disabling of DMA (on the ATA interface) into the DEV9 callbacks. -Moving the setting up of DMA direction from before the call to ata_io_start to after the call to ata_io_start. -Correction of the ATA device probing code - our homebrew version worked slightly differently from the original, for one reason or another. For example, devices are assumed to be packet devices unless the ATA LCYL and HCYL are both 0. However, our driver used to assume that the connected device is not a packet device by default. -There was a new check on whether the LCYL and HCYL registers would retain values written. I don't know why this was done, but it may be there to prevent false positives. -There is now an additional operation to disable DMA on the SPEED interface, after the call to ata_io_finish. -As with the newer DEV9 modules, DEV9 now has some code to initialize the SMAP to a known state. -LBA is now set in ata_io_start, causing all operations to always have the LBA bit set to 1.
It appears that the 2015 edition of GameStar expects at least the following: -DMA (ATA) must be enabled with the setting of direction (0x86 must be written). Therefore, the DEV9 DMA callbacks cannot be used. -DMA direction must be set up (ata_set_dir) before the call to ata_io_start. -The "SMAP" cannot be initialized correctly with the initialization code within DEV9.
As for the write to HCYL and LCYL, I haven't really figured out why SCEI added it. Perhaps it's there to detect if the device was incorrectly connected (i.e. floating bus).
As for the DEV9 DMA callbacks, I do not really know why they had to implement them because the SMAP and ATA do not share the same registers for DMA. I guess this means that they want to ensure that DMA will be strictly enabled only before the DEV9 DMA channel is activated, and disabled after the DEV9 DMA channel is deactivated. Right now, the compile-time options that I added to ATAD (see the bottom of this post) will only switch between the two designs for enabling/disabling DMA (pre and post 2015). For the earlier design, there is no code for disabling DMA on the ATA device because the original (earlier design) did not have such a thing... but I cannot tell if I should add it or not.
DEV9 now has some code for initializing the SMAP interface to a known state. Perhaps this is a sign that the SMAP interface can be left in an undesirable state.
That being said, is it worth reaching a compromise? We will be letting go of the changes mentioned above. Personally, I wish to make an accurate copy of the SONY module, but that will prevent owners of clone adaptors from using new software. However, it is worth noting that not all clone adaptors may be made compatible again with such changes. Personally, I own a compatible adaptor, which was already incompatible with our ATAD module in 2013 (before any of my changes were made).
If not, then do we want to make another optional variation of ATAD, for projects like OPL to optionally use? That will allow the effects of the compromise to be confined to only such software, but it also means that owners of such adaptors can only use selected pieces of software, like HDPro users.
The changes can be previewed here, from commit 7faf72a4.