TD64 or NSD for new storage drivers?

[Heiroglyph]

TD64 is probably the easiest to support from a coders point of view (i.e. a simple extension of TD32) but since NSD64 became the official OS 3.5/3.9 standard I think it should always be supported. There is simply no point in continuing the debate about which is better now.
 
Also, support for TD64 is optional since NSDpatch can patch TD64 to emulate NSD64.

I just want to learn the correct way to do it so that no patching is needed.

If I ever sell a product based on this stuff I'd like the user experience to be as hassle free as possible.

The problem was that the only information I could find were rants about how terrible the other option was, nothing technical and nothing about which was best for the user.

I can foresee a website in my future with all the information I've had trouble finding compiled in one place.

[Heiroglyph]

I am sure if you assembled the information that Thomas would happily host it on his awesome Amiga website.  He is really into HD filesystems, drivers, etc.

What site is that?  I'm not familiar with Thomas.

[Heiroglyph]

I believe TCL is referring to Thomas Rapp. His web site is nice (in German but easier to navigate than some bloated English web sites) and it's in his tag line on the 1st page of this thread:

http://thomas-rapp.homepage.t-online.de/

He is a little bit sensitive about copyrights, trademarks, licenses, disclaimers, etc. so he might not put anything on his web site. It probably means he has and makes money so he has to be careful.

If it's in German I probably won't be putting anything there.

It's one more good resource for me though.

[Heiroglyph]

In my own client and driver software, I have always supported both TD64 and NSD. It's reasonably simple to do, and I was just absolutely sick of the TD64 vs NSD matter.

Don't let yourself get drawn into the same old sinkhole. It's dark down there, and very hard to get back to the light...

My frustration wasn't with either "standard", it was with the lack of clear direction and information.

I decided to do both once I found out they weren't mutually exclusive.  Some of the misinformation sounded like the command codes conflicted, but that doesn't seem to be the case.

[Heiroglyph]

I understand; this is one of the side-effects of the discussions, some 15 years ago, which brought forth TD64 and NSD.



The semantics are identical, but of course the command codes are not.

Just in case: it is generally not sufficient to implement the NSCMD_TD and NSCMD_ETD commands (as in NSCMD_TD_READ64, NSCMD_ETD_READ64, NSCMD_TD_WRITE64, NSCMD_ETD_WRITE64, etc.) without also implementing the NSCMD_DEVICEQUERY command.

If you want to support the NSD command set in the most compatible manner, the NSCMD_DEVICEQUERY command must be supported as well. According to the NSD standard, client software is required to try the NSCMD_DEVICEQUERY command before deciding to give any of the other NSD commands a go. Hence, if you omit support for NSCMD_DEVICEQUERY, you might not produce the maximum compatible solution. Some client applications do not bother with the NSCMD_DEVICEQUERY command and just try their luck with NSCMD_TD_READ64, etc., but you cannot rely upon this behaviour to be present.

And one last thing: please make sure that unknown commands are handled safely (reject them with IOERR_NOCMD), and verify that each IORequest which passes through your device is large enough for the respective command to be performed (e.g. IORequest->io_Message.mn_Length should be at least sizeof(struct IOStdReq) for read/write operations).

Thanks, I appreciate the direct, informative tips.

I will at some point be documenting this as fully as possible.  There is a severe lack of examples for modern or even old device drivers and none that I've seen which have the ability to boot.

Basically if I don't get anywhere with this, I want the information to help the next person who wants to attempt it.  If that's the case then it hasn't been a waste of my time.

[Heiroglyph]

I know what you mean. The lack of reference code is an old problem, and it has only grown over the years.

For example, the only reference implementation for a device driver that was ever published by Commodore is written in 68k assembly language, and the only place you can find it is in Appendix B of the "Amiga ROM Kernel Reference Manual, 3rd edition: Devices" (see here: http://wiki.amigaos.net/index.php/Example_Device).

The problems with this implementation are in that hardly anybody can read 68k assembly language code these days and that the code is easily misunderstood as being simplistic and incomplete, while it is in fact a solid example which illustrates how to properly implement a device driver. There is information in this example code which cannot be found anywhere in the other RKM documentation, e.g. proper IOF_QUICK and AbortIO() handling, which is very easy to get wrong.

Yes, I found that example.  I thought it appeared to be well done.  The downsides were asm and the fact it hasn't been updated in years.

I'm also lucky enough to work in one of the few places where I actually have access to source for several published and unpublished Amiga device drivers and the people who wrote them.

Again though, their experience was well before NSD and TD64.

A couple of years ago I rewrote the same code in plain 'C' (it's not up on the developer Wiki yet), which I believe makes it more accessible. If you want to have a look, please contact me.

I would love to get that.  I would like to make sure that you won't be upset if I publish it modified or in full as an example.  You'd be credited of course.

Good luck We badly need robust, instructive device driver code. There just isn't enough to go around which one can learn from.

Thanks, I need all the luck I can get