TD64 or NSD for new storage drivers?

[SpeedGeek]

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.

[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.

[ChaosLord]

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.

[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.

[matthey]

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

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.

[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.

[ChaosLord]

I didn't remember it being in German.

I guess Google autotranslates it into English really well.

Anywayz, lots of juicy information on that site regarding mass storage solutions on the Amiga.

[freqmax]

Found all the filesystem limits!

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

I think this page perhaps gives more insight?
http://thomas-rapp.homepage.t-online.de/4gb_faq.html

[itix]

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.

It is more like Amiga Technologies told Amiga community to f*ck off and ignored it.

To the user neither is better because NSD is TD64 with different command IDs.

[olsen]

I've found a million posts on what the available options are and the drama that it caused, but nothing on what users actually want.

For a new storage device driver, which of the two give the best software compatibility and user experience?

TD64 is supported by Phase 5, DKB and GuruROMs, so being compatible to those is a pretty safe bet.

NSD is the OS3.5 and 3.9 standard.

So which one do you want?

My humble suggestion is to support both. The thing is that the functionality common between the different command sets is so large that it's a small effort to increase your chances of producing software which will work with whatever client software there is.

The political dimension of the TD64/NSD schism was a thing to behold, and mourn, since it obscured the fact that both approaches have weaknesses that could have been resolved (or at least mitigated) in a less caustic atmosphere.

For example, testing whether a driver supports TD64/NSD can produce inconclusive results. Because of shoddy device driver implementation practices in the 1980'ies and 1990'ies you also ran a risk to crash the device driver during the TD64/NSD command testing.

Needless to say, none of these issues were ever resolved. Not just because of the caustic atmosphere created, but also because these were really hard problems to resolve in the first place (which in turn was not helped by the caustic atmosphere: brains were more engaged in hurting the other guy than in chipping away at the problem -- I guess because the one thing is tremendous fun for all ages, and the other is work).

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...

[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.

[olsen]

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

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

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.

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).

[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.

[olsen]

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.

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.

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.

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.

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

[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

[freqmax]

Do there exist any filesystem driver example in C ?