Amiga.org
Amiga computer related discussion => Amiga Hardware Issues and discussion => Topic started by: Heiroglyph on February 19, 2013, 04:04:02 PM
-
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?
Edit: I'm doing SCSI Direct regardless in addition to one of these.
-
You are writing ur own drivers?
Then just write your driver twice. Once for NSD and once for TD64. Then you have covered everything, right?
Use the source, Luke :)
-
You are writing ur own drivers?
Then just write your driver twice. Once for NSD and once for TD64. Then you have covered everything, right?
Use the source, Luke :)
Screw that, once plus scsi direct is plenty. It's not my fault that AT had "not invented here" syndrome.
Yes, I'm the first vote for TD64 ;)
-
Which one has the most capabilities?
(I assume they are equal but who knows?)
Which one burns the least CPU power?
Which one requires the least amount of code?
Are they all compatible with any kickstart? Even KS 1.2?
-
I don't think KS1.2 is an option with this hardware, 3.1 or higher would be pretty much expected.
-
So which one do you want?
This question is silly. The handling of both is equal, only the command codes are different. So it's next to no effort to support both.
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.
The users want that their file systems work with the driver, they don't care which technique is used internally. Some file systems use NSD, some use TD64. If you support both you make all users happy.
-
@Heiroglyph
What is your driver called? What hardware is it for?
-
This question is silly. The handling of both is equal, only the command codes are different. So it's next to no effort to support both.
I'm trying to get the developer CD that has the NSD docs on it now, I'm finding it hard to get information.
I thought that NSD had made it so that you couldn't support both. That the codes conflicted or something.
-
@Heiroglyph
What is your driver called? What hardware is it for?
It's called vaporware for now ;)
Just a small project, nothing to get excited about.
-
I'm trying to get the developer CD that has the NSD docs on it now, I'm finding it hard to get information.
I'm sure a torrent for the Dev CD will appear on the pirate bay in a few days. ;)
-
You can get the Native Developer Kit from here:
https://www.google.co.uk/url?q=http://www.haage-partner.de/download/AmigaOS/NDK39.lha&sa=U&ei=hckjUb3RAo-N0wXkooEg&ved=0CCAQFjAB&sig2=kIQt3qYsBWLJQm7Yz4PvBw&usg=AFQjCNHlNFpet5fVGKVAfek33SQ2_oFa0g
-
You can get the Native Developer Kit from here:
https://www.google.co.uk/url?q=http://www.haage-partner.de/download/AmigaOS/NDK39.lha&sa=U&ei=hckjUb3RAo-N0wXkooEg&ved=0CCAQFjAB&sig2=kIQt3qYsBWLJQm7Yz4PvBw&usg=AFQjCNHlNFpet5fVGKVAfek33SQ2_oFa0g
I appreciate the link, but I already had that one.
The developer CD supposedly has more documentation. This doesn't mention NSD at all as far as I can see.
-
I'm trying to get the developer CD that has the NSD docs on it now, I'm finding it hard to get information.
I thought that NSD had made it so that you couldn't support both. That the codes conflicted or something.
If you haven't read Ralf Babel's "Why NSD is broken as designed", you probably should:
http://babel.de/amiga.html#doc
-
I thought that NSD had made it so that you couldn't support both. That the codes conflicted or something.
No idea, but NSDPatch can patch TD64 devices to support NSD.
-
This is another example of how developer hostile AmigaOS has become.
After finding examples of software that does use NSD, I see they all reference devices/newstyle.h which doesn't exist in the 3.9NDK.
Why is it all secret and paid for these days? Assuming I can even buy a developer CD. The RTG lockdown from a 3rd party developer is stupid enough, but a 10+ year old public interface in the OS itself?
I may end up doing TD64 just because I can do it without paying to ship a hard to find CD from Europe or becoming a pirate.
This is why we can't have nice things.
-
Why is it all secret and paid for these days? Assuming I can even buy a developer CD. The RTG lockdown from a 3rd party developer is stupid enough, but a 10+ year old public interface in the OS itself?
I may end up doing TD64 just because I can do it without paying to ship a hard to find CD from Europe or becoming a pirate.
Don't get all upset. There's no money here for the pirate police to make money off of. Maybe a few politically correct immature types will complain but it looks like this material is copyright but freely redistributable. Go figure why the documentation is not in the 3.9 NDK.
http://www.heywheel.com/matthey/Amiga/NSD.lha
-
I have the DEveloper CD V2.1 (made by Schatztruhe for Haage-Partner). In the DEvinfo section there are some docs about NSD device and also Trackdisk64. It is mainly consists of NSDPAtch, NSDQuery tool, Install and Readme.Guide. For TD64 there is just a readme file.
It is pretty much the same as this file on Aminet: disk/misc/NSDPatch43_20.lha.
-
Don't get all upset. There's no money here for the pirate police to make money off of. Maybe a few politically correct immature types will complain but it looks like this material is copyright but freely redistributable. Go figure why the documentation is not in the 3.9 NDK.
http://www.heywheel.com/matthey/Amiga/NSD.lha
Thanks.
It's just frustrating. A platform this old should be well documented and wide open, but I've hit brick walls for the last few years every time I want to work on anything hardware related.
It's like a concerted effort to prevent new hardware from being practical.
If it was my first stumble it wouldn't mean a thing, but it's so far beyond that, that it's a sensitive subject now.
-
Just looking over the docs, I don't see what all the fuss was about and I don't see why a driver can't support both, which seemed to be implied in the arguments I've seen.
Like anything it could be improved, but it doesn't look like the end of the world that it was made out to be.
Yes, it sucks that people had to rewrite drivers after just having added support for TD64, but the standard itself isn't hideous. I do agree that AI should have just gone with the defacto standard that was already available though. That was a waste of everyone's time as far as I can see.
It looks like this poll is a moot point.
Thanks guys!
-
Now I know why I like free open source stuff ;)
Points to consider:
* Reliability - clearly defined API etc (trashed filesystem is bad)
* Compatibility
* Performance (CPU and kB/s)
Probably the documentation CD etc.. was created in a propietary setting. And when the financial trouble started there was the likely hood that a corporate buyout deal might happen etc. When things run out in the sand, everything got stuck in a big mess. Because I suspect that when Commodore was working you would had the info with a bit of cash (+NDA?) without any problems.
This is why systems with documentation in your physical possession is such a good idea.
-
Now I know why I like free open source stuff ;)
Points to consider:
* Reliability - clearly defined API etc (trashed filesystem is bad)
* Compatibility
* Performance (CPU and kB/s)
Probably the documentation CD etc.. was created in a propietary setting. And when the financial trouble started there was the likely hood that a corporate buyout deal might happen etc. When things run out in the sand, everything got stuck in a big mess. Because I suspect that when Commodore was working you would had the info with a bit of cash (+NDA?) without any problems.
This is why systems with documentation in your physical possession is such a good idea.
Amen brother.
-
This is another example of how developer hostile AmigaOS has become.
After finding examples of software that does use NSD, I see they all reference devices/newstyle.h which doesn't exist in the 3.9NDK.
Why is it all secret and paid for these days? Assuming I can even buy a developer CD. The RTG lockdown from a 3rd party developer is stupid enough, but a 10+ year old public interface in the OS itself?
I may end up doing TD64 just because I can do it without paying to ship a hard to find CD from Europe or becoming a pirate.
This is why we can't have nice things.
Those two choices aren't mutually exclusive. I bought my dev CD about 10yrs ago from a well known European Amiga dealer and it is quite obviously a CDR with an inkjet printed label stuck to the disc.
-
If you haven't read Ralf Babel's "Why NSD is broken as designed", you probably should:
http://babel.de/amiga.html#doc
Can you read that without finding him rare out of print books?
-
Can you read that without finding him rare out of print books?
lol, I actually sent him a link to buy one. He already had one in "OK" quality like the one I found.
-
I wonder if that cantankerous old fart has heard of kickstarter now? he could at least cover his publishing cost to be sure.
-
I wonder if he's been asked? I'd definitely pay for a couple of books to get the updated one.
Edit: I just asked him, we'll see. I just hope he doesn't come unglued at the mention of the book.
-
I wonder if he's been asked? I'd definitely pay for a couple of books to get the updated one.
Edit: I just asked him, we'll see. I just hope he doesn't come unglued at the mention of the book.
I have the original print edition of the Guru Book but I'd definitely pay in advance for a copy of the new edition.
-
He's not interested. :(
It's a shame. He put a lot of work into something a lot of us want.
-
He's not interested. :(
It's a shame. He put a lot of work into something a lot of us want.
Perhaps he is full of sh1t......
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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
-
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.
-
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...
-
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.
-
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).
-
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.
-
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.
-
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 ;)
-
Do there exist any filesystem driver example in C ?
-
Do there exist any filesystem driver example in C ?
As far as I know this type of sample code is very rare indeed.
If what you're after is an example of how TD64/NSD commands may be used by client code in general, I may have something to share.
A couple of a years ago I wrote a shell command (in 'C', naturally) for the purpose of making image files from my A3000UX hard disk partitions, and uploading them to a local server via TCP. That shell command (called "SendRawDisk") supports TD64/NSD commands, and also includes portable 64 bit integer arithmetic functions for use with compilers which do not support the 'long long int' type (such as SAS/C). It could serve as an example of how this stuff is done in client code. Mind you, it does a bit more than just reading the data off the disk...
You can download the command (with source code) at http://aminet.net/comm/tcp/SendRawDisk.lha
-
My idea were to provide a filesystem API in one end. And send all requests to a server in the other end.