lee@sed170.HAC.COM (John Lee) (11/16/89)
I've decided to purchase a SCSI hard disk controller and have narrowed my
choices to two candidates, the Kronos and Hardframe controllers. The former
is the fastest Diskperf-rated but non-DMA controller, the latter being the
second fastest Diskperf-rate but DMA controller.
Which should I buy? I have heard many good things about the Kronos, but I
am unaware of any reports of its performance when the CPU is heavily loaded.
Similarly, I'm unaware of how the Hardframe performs under heavy DMA.
The prices of the two controllers are close enough for me to ignore the
difference. If you have a recommendation or have experience with either
controller, please drop me a note at either the address above or in my
.signature below. I will post a summary in about a week. Thanks!
--John Lee
-------------------------------------------------------------------------------
Raining CATS and DOGS? Join the RATS: Remote Amiga Teleconferencing System
+--------+ John Lee
| HUGHES |
+--------+ ARPAnet: jhlee@hac2arpa.hac.com
Hughes Aircraft Company
The above opinions are those of the user and not of those of this machine.swarren@eugene.uucp (Steve Warren) (11/22/89)
In article <321@sed170.HAC.COM> lee@sed170.UUCP (John Lee) writes: >I've decided to purchase a SCSI hard disk controller and have narrowed my >choices to two candidates, the Kronos and Hardframe controllers. The former >is the fastest Diskperf-rated but non-DMA controller, the latter being the >second fastest Diskperf-rate but DMA controller. > The reason the Kronos can beat a DMA controller is because it has a 16-bit path to memory. Other controllers only have an 8-bit path to memory. I think that they have a significant performance improvement over other controllers because of the path-width advantage. Their literature is misleading, claiming that DMA controllers are fundamentally inferior when there is chip-ram contention. This is a false claim, and it is also unnecessary if the disk-perf results they published are true. (Their disk-perf results were significantly better than all the others) >Which should I buy? I have heard many good things about the Kronos, but I >am unaware of any reports of its performance when the CPU is heavily loaded. Me neither. --Steve ------------------------------------------------------------------------- {uunet,sun}!convex!swarren; swarren@convex.COM
daveh@cbmvax.UUCP (Dave Haynie) (11/23/89)
in article <3302@convex.UUCP>, swarren@eugene.uucp (Steve Warren) says: > Keywords: Kronos, Hardframe, controller > The reason the Kronos can beat a DMA controller is because it has a 16-bit > path to memory. Other controllers only have an 8-bit path to memory. Pure bunk. All DMA controllers have 16 bit data paths. You'd have to go to a great deal of extra trouble to build a DMA device that supports 8 bit transfers. None of the Commodore controllers even support 8 bit transfers, and I suspect the other don't either -- there's never any reason for that in a DMA controller. Among the non-DMA controllers, you're split. The GVP controller has a 16 bit data path, I believe. So does the C Ltd. Kronos. The low cost TrumpCard from IVS and the old C Ltd. controllers also have 8 bit data paths. > I think that they have a significant performance improvement over other > controllers because of the path-width advantage. The only possible advantage a Kronos card is likely to have over any other 16 bit card is in the software. All the Commodore cards have very tightly written assembly coded device drivers. So does the Hardframe, far as I've heard. The GVP's controller is written in C language and suffers a bit because of it. I'm not sure about the others. > Their literature is misleading... If they've managed to make you think that DMA controllers are doing 8 bit transfers, they're far more misleading than you imagine. > claiming that DMA controllers are fundamentally inferior when there is > chip-ram contention. This is a false claim, and it is also unnecessary > if the disk-perf results they published are true. (Their disk-perf results > were significantly better than all the others) What were their DiskPerf results? Our disk folks are seeing over 1 meg/sec with 2091s through the filesystem, with a good hard disk. The main trouble I've seen with the magazine reviews of HD controllers is that the reviewers don't quite understand or bother to deal with a real, sound, scientifically accurate comparison. For such a test, you've got to benchmark each controller with exactly the same hard disk, and preferably several different ones, under a variety of system load conditions. I haven't designed a hard disk controller myself, but unless there's something really stupid in the design of the 2091 and the Hardframe that I've somehow missed up to this point, there's no way in the world any CPU driven controller should benchmark faster than either of there in a fair test on a stock A2000 or even a stock A2500/30. > --Steve -- Dave Haynie Commodore-Amiga (Systems Engineering) "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy Too much of everything is just enough
swarren@eugene.uucp (Steve Warren) (11/29/89)
In article <8687@cbmvax.UUCP> daveh@cbmvax.UUCP (Dave Haynie) writes: >in article <3302@convex.UUCP>, swarren@eugene.uucp (Steve Warren) says: >> Keywords: Kronos, Hardframe, controller > >> The reason the Kronos can beat a DMA controller is because it has a 16-bit >> path to memory. Other controllers only have an 8-bit path to memory. > >Pure bunk. All DMA controllers have 16 bit data paths. You'd have to go >to a great deal of extra trouble to build a DMA device that supports 8 bit You are right, Dave, I didn't have the data sheet with me, so I came away with this impression even though it didn't really say this in the sheet. So I picked up a copy during lunch today. I will treat you to some of the statements in it. Here is what they said (which I misremembered, until I picked up a copy today - emphasis in original): "C Ltd's KRONOS controllers are the *only* non-DMA controllers utilizing full bus wide 16-bit data transfer. Using a unique dual-buffered psuedo- DMA design, KRONOS systems transfer data into the Amiga at full Amiga bus speed, in fact, KRONOS systems are so fast that the hard drive itself is now the limiting factor." >> Their literature is misleading... > >If they've managed to make you think that DMA controllers are doing 8 bit >transfers, they're far more misleading than you imagine. Well, this was my misunderstanding, C.Ltd did not make this claim. >> claiming that DMA controllers are fundamentally inferior when there is >> chip-ram contention. This is a false claim, and it is also unnecessary >> if the disk-perf results they published are true. (Their disk-perf results >> were significantly better than all the others) > >What were their DiskPerf results? Our disk folks are seeing over 1 meg/sec >with 2091s through the filesystem, with a good hard disk. The main trouble "...For example, when tested with the latest optimized Micropolis high- performance hard drive, the KRONOS controller read in and wrote back out 10 one-megabyte data segments in just under 20 seconds for an astounding 1009K/sec data transfer rate." >I've seen with the magazine reviews of HD controllers is that the reviewers >don't quite understand or bother to deal with a real, sound, scientifically >accurate comparison. For such a test, you've got to benchmark each controller >with exactly the same hard disk, and preferably several different ones, under >a variety of system load conditions. I haven't designed a hard disk >controller myself, but unless there's something really stupid in the design >of the 2091 and the Hardframe that I've somehow missed up to this point, >there's no way in the world any CPU driven controller should benchmark >faster than either of there in a fair test on a stock A2000 or even a >stock A2500/30. >-- >Dave Haynie Commodore-Amiga (Systems Engineering) "The Crew That Never Rests" > {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy > Too much of everything is just enough No, I agree 100%, that was the point I was making, that DMA *is* better. But here are some excerpts from the "marketing release" from C.Ltd re the KRONOS controller: "You can't buy a faster SCSI controller, hardcard or hard drive system for your Amiga at any price. (See the performance test report inside for details.)" Here is an excerpt from the DPerf 2.0 test results, in which C.Ltd says all tests used Quantun 40 Meg harddrives except Supradrive & the Flash!Card (apparently those cards don't support Quantum, so ST138N drives were used instead). These results were for 256K, read is first, then write. CLtd KRONOS/2000 648K 371K non-DMA MicroBotics HardFrame 590K 352K DMA Commodore A-2090A 584K 337K DMA CLtd ECONO/2000 453K 170K non-DMA Xetec FastCard 403K 276K non-DMA Supra Corp SupraDrive 391K 267K DMA IVS Trump Card 292K 230K non-DMA GVP Impact A2000 275K 154K non-DMA Expansion Tech Flash!Card 55K 50K DMA You asked for the disk-perf results; this is part of what they published. But here is some of the misleading stuff: "DMA OR NON-DMA. There are currently two types of SCSI controllers available for the Amiga computers, DMA (Direct Memory Access) and non- DMA. While DMA type systems in the past have been considerably faster than the non-DMA systems, the DMA systems have had problems competing with the Amiga's custom chips which are also DMA and have priority over other DMA devices..." ^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^ (misleading - the custom chips also have priority over the CPU, so this is not an advantage of non-DMA systems over DMA) "...The result of these conflicts has been a substantial reduction in DMA drive performance and possible disruption of video and sound..." ^^^^^^^^^^^^^^^^^^^^^ The problem I think they are referring to did not result from DMA, it was a design flaw that could have been made on any controller. The controller it affected happened to be a DMA drive. Now manufacturers are going around trying to scare people away from DMA. This is silly. "...These problems are seldom catastrophic, but are only destined to get worse as Commodore upgrades the custom chips allowing access to more chip memory and bigger screens thereby requiring more DMA for the custom chips and leaving less for other DMA devices..." ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ This affects the CPU the same way it does DMA. If less time is available for other DMA devices, it is also not available for the CPU, at least with the current bus arbitration scheme. It would be a very complex system where loss of memory bandwidth would significantly reduce the time available to DMA without impacting CPU usage. "...The non-DMA design of the KRONOS controller provides faster data transfer than any available DMA controller while avoiding any conflicts (present or future) with the Amiga's custom chip set." C.Ltd may indeed have developed a nice way of avoiding custom chip conflicts, but whatever it is, it is not because it is non-DMA. The same techniques could be used for a DMA controller. This is what I meant when I said their literature is claiming that non-DMA is fundamentally superior to DMA on the Amiga. And, as I said, there is no reason to misrepresent or mislead this way, if their disk-perf results are accurate. If they really have such a fast controller, why don't just say, "This here wiz-bang controller is so well-designed, it beats the DMA controllers at their own game," or some such nonsense. There *are* some really excellent features claimed in their literature, like support for all kinds of different SCSI devices such as tape drives, removeable media, WORM drives, SCSI laser printers, page scanners, etc. They also claim to be the only controller that is supplied with "...a fully functional AmigaDOS type library that allows users to write and create custom software that can issue SCSI commands directly to SCSI devices." So, with all the features, I wish they didn't feel the need to obfuscate things. With all the dealers and developers on the net, I am suprised no one else has seen this four-page promotion for Kronos. I picked up a photocopy at the local dealer. Cheers, --Steve ------------------------------------------------------------------------- {uunet,sun}!convex!swarren; swarren@convex.COM
daveh@cbmvax.UUCP (Dave Haynie) (11/29/89)
in article <3481@convex.UUCP>, swarren@eugene.uucp (Steve Warren) says: > Keywords: Kronos, Hardframe, controller > "...For example, when tested with the latest optimized Micropolis high- > performance hard drive, the KRONOS controller read in and wrote back out > 10 one-megabyte data segments in just under 20 seconds for an astounding > 1009K/sec data transfer rate." That's certainly possible. If the data's sitting there all ready in a RAM buffer, and they're reading/writing with a decent routine, they can get an effective maximum transfer rate of close to 1/2 the expansion bus speed, about 1.7 megabytes/second. Actually it'll come out less than that with a 68000, because no matter how you optimize your transfer loop, you're going to have to fetch instructions occasionally. Asynchronous SCSI runs at a max of around 1.5 megabytes/second, so they can in theory keep up. I didn't see them claiming this transfer was through the file system up there either. I don't recall the exact numbers, but I think they came in around 1.3-1.4 megs/second with plain device drivers; the 1.1 megs/second or whatever they get with the Wren VI these days is through the filesystem. They tells you two things, though C. Ltd only wants you to hear one of them. They want you to hear that their drive will keep up with DMA devices, and if they haven't made any mistakes, it will come close. What they aren't telling you is that, in order to do that, the Kronos will have to take every available bus cycle during transfers. The DMA device will only need 1/2 the available bus cycles to achieve the same speed. Which means your programs move during disk activity, since the disk transfer is only going at around 1/2 the speed of the Amiga. If it supports synchronous SCSI, the DMA device could possibly run transfers twice as fast, using pretty much all available cycles (synchronous SCSI maxes out at around 4-5 megs/second). It still sounds like the seeking speeds of the drive will be the limiting factor. > You asked for the disk-perf results; this is part of what they published. It's interesting, but our disk folks don't like DiskPerf; they claim it's not granular enough at high speed. For any controller, DMA or non-DMA, once you're at high speeds, the software overhead is going to make a difference. > But here is some of the misleading stuff: So this brochure contains lies, damn lies, AND benchmarks! Sounds like a classic -- I'll have to pick one up if they're at WOC. > The problem I think they are referring to did not result from DMA, it > was a design flaw that could have been made on any controller. The > controller it affected happened to be a DMA drive. Now manufacturers > are going around trying to scare people away from DMA. This is silly. Exactly. The 2090 doesn't properly handle overruns on its FIFO, and the 2090 is a DMA driven controller, therefore all DMA controllers must have the same problem. Sounds like someone either flunked Logic 101 or passed Marketing 101. > C.Ltd may indeed have developed a nice way of avoiding custom chip > conflicts, but whatever it is, it is not because it is non-DMA. The > same techniques could be used for a DMA controller. The ways to avoid custom chip conflicts are well known. You pretty much have your choice of buffering up a whole block from the SCSI device, the way GVP does it, or filling a FIFO and telling SCSI to stop sending before you're filled. They certainly appear to have done things right, but I sincerely doubt they've come up with any new magic. I'll bet if the GVP controller's software were changed from compiled C to carefully hand optimized assembler, it would be roughly as fast as the Kronos. There could be a minor hardware design win in one or the other, but I'm sure C.Ltd's big win here is the software. > If they really have such a fast controller, why don't just say, "This > here wiz-bang controller is so well-designed, it beats the DMA > controllers at their own game," or some such nonsense. Most people don't even come close to understanding the rather simple set of problems a controller has to solve. So hype works real well. > There *are* some really excellent features claimed in their literature ... > So, with all the features, I wish they didn't feel the need to obfuscate > things. Yeah, they did a fair job with their original 8 bit controller. They were playing around with other SCSI devices like their laser printer, scanner, SCSI-net, and a few other things long before most anyone else had built SCSI devices. I agree -- there's no need to mislead folks if you really have something unique to offer. Sure, some may take the bait, but if I read a some promotion that I felt was making an ernest attempt to mislead me, I'd have a bad feeling about the company, regardless of the actual merits of the device they're hawking. I guess the hard disk controller market is getting pretty full these days, though. I wish someone would design something interesting for a change... > Cheers, > --Steve -- Dave Haynie Commodore-Amiga (Systems Engineering) "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy Too much of everything is just enough
don@vax1.acs.udel.EDU (Donald R Lloyd) (11/29/89)
In article <3481@convex.UUCP> swarren@convex.COM (Steve Warren) writes: > >"C Ltd's KRONOS controllers are the *only* non-DMA controllers utilizing ^^^^^^^^^ >full bus wide 16-bit data transfer. Using a unique dual-buffered psuedo- >DMA design, KRONOS systems transfer data into the Amiga at full Amiga bus >speed, in fact, KRONOS systems are so fast that the hard drive itself is >now the limiting factor." Supra is making this same claim for their WordSync controller. I bought it at WOC, mainly because it was cheaper than most of the others the dealers still had left.... I'd like to give it a speed test with my 28ms st157n, but diskperf asks for too much memory. I've heard of, but not seen, something called devspeed, which is supposed to do better on a 1 meg system. Anybody know where I can get it? -- Gibberish .sig for sale or lease. is spoken Contact don@vax1.acs.udel.edu for more information. here. DISCLAIMER: It's all YOUR fault.
maniac@arrakis.nevada.edu (ERIC SCHWERTFEGER) (11/30/89)
In article <5166@udccvax1.acs.udel.EDU> don@vax1.acs.udel.EDU (Donald R Lloyd) writes: >In article <3481@convex.UUCP> swarren@convex.COM (Steve Warren) writes: >> >>"C Ltd's KRONOS controllers are the *only* non-DMA controllers utilizing > ^^^^^^^^^ >>full bus wide 16-bit data transfer. Using a unique dual-buffered psuedo- >>DMA design, KRONOS systems transfer data into the Amiga at full Amiga bus >>speed, in fact, KRONOS systems are so fast that the hard drive itself is >>now the limiting factor." > > Supra is making this same claim for their WordSync controller. > I bought it at WOC, mainly because it was cheaper than most of the >others the dealers still had left.... That's funny. Everyone is ignoring a "little guy" again (just as IBM'ers and Macists ignore Amiga innovations), and that is the PaloMAX project, which has had a 16 bit controller option for over a year. It had diskperfs of about 550-600K/sec too. Naturally, this was done after I built mine, with an 8 bit controller. But 295K/sec isn't bad for an 8 bit non-DMA controller. Eric J. Schwertfeger, UNLV maniac@arrakis.nevada.edu
sullivan@nssg.enet.dec.com (11/30/89)
In article <3481@convex.UUCP>, swarren@eugene.uucp (Steve Warren) writes...
"There *are* some really excellent features claimed in their literature,
"like support for all kinds of different SCSI devices such as
"tape drives, removeable media, WORM drives, SCSI laser printers,
"page scanners, etc. They also claim to be the only controller
"that is supplied with "...a fully functional AmigaDOS type library
"that allows users to write and create custom software that can
"issue SCSI commands directly to SCSI devices."
I follow the C-Ltd BBS regularly and have seen a barely
documented library there for some time. I have used it and it is
usable, though essensially undocumented. When I downloaded it about a
year ago there were incompatibilities in the examples that prevented
them from working and I had to correct the "C" include files. I am
not sure I would call it "fully functional" but it did the little bit
I was trying to do.
With decent documentation and support it could be quite good.
That seems to be the concensus opinion for all C-Ltd Products among
C-Ltd owners I know. They could be *quite* good with better support.
-SESJKT100@PSUVM.BITNET (JKT) (12/01/89)
In article <3481@convex.UUCP>, swarren@eugene.uucp (Steve Warren) says: > >CLtd KRONOS/2000 648K 371K non-DMA >MicroBotics HardFrame 590K 352K DMA >Commodore A-2090A 584K 337K DMA Wait a sec.... Is this claiming that the A-2090A was the 3rd fastest on the market? If so, then with all I've heard about the new 2091, Commodore just might have the fastest HD Controller on the market! Naaaaahh - couldn't happen! ;-) Kurt -- ======================================================================== || Kurt Tappe (814) 862-8630 || Looking for Amigas in all || || 600 E. Pollock Rd., #5705 || the wrong places...... || || State College, PA 16801 -------------------------------------|| || jkt100@psuvm.bitnet or jkt100%psuvm.bitnet@psuvax1 || || or jkt100@psuvm.psu.edu QLink: KurtTappe || ========================================================================
esker@abaa.uucp (Lawrence Esker) (12/01/89)
In article <8750@cbmvax.UUCP> daveh@cbmvax.UUCP (Dave Haynie) writes: > [...] Sure, some may >take the bait, but if I read a some promotion that I felt was making >an ernest attempt to mislead me, I'd have a bad feeling about the >company, regardless of the actual merits of the device they're hawking. This is the impression I have always got from C.Ltd ads, even in the A1000 days. Gut level, I've always mistrusted them strictly from their ads. No evidence. >I guess the hard disk controller market is getting pretty >full these days, though. I wish someone would design something >interesting for a change... Yeah, LIKE A GENERIC TAPE DRIVE AND SOFTWARE THAT WORKS ON ANY SCSI CONTROLLER. Or, at least the A2090A. Common, someone has got to do it soon. As far as C=, are they making us wait until Amix is commercially forsale before they sell the tape drive that is supposed to come with the 2500UX. >Dave Haynie Commodore-Amiga (Systems Engineering) "The Crew That Never Rests" -- ---------- Lawrence W. Esker ---------- Modern Amish: Thou shalt not need any computer that is not IBM compatible. UseNet Path: __!mailrus!sharkey!itivax!abaa!esker == esker@abaa.UUCP
cmcmanis%pepper@Sun.COM (Chuck McManis) (12/05/89)
Dave Haynie wrote : I wish someone would design something interesting for a change... In article <5184@abaa.UUCP> esker@abaa.UUCP (Lawrence Esker) commented: >Yeah, LIKE A GENERIC TAPE DRIVE AND SOFTWARE THAT WORKS ON ANY SCSI CONTROLLER. >Or, at least the A2090A. Common, someone has got to do it soon. First, you need a GENERIC Tape Device. If you have ever written SCSI software then you know that most manufacturers put in whatever the hell they feel like for a command set (although most will at least put CCS in there) and then a lot of the spec is "vendor specific" because it is a damn legislated standard and no one wanted to change the way they reported or delt with bad blocks so you still need to know about every single manufacturers device if you really want to support it. * Standard Chuck "Standards" Flame * SCSI is a piece of shit. It is another example of how American computer companies, and computer companies in general, screw the world by saying "standard, standard, standard, ..." And then in the documentation saying "except, except, except,..." As a computer programmer you would think there is some book which says "To do this you do that, and to do this you do that, and to do this you do that, ..." but there isn't, and the reason there isn't is because if there was, there wouldn't be anything to separate the Seagates from the Quantums of the world (except for stiction problems of course :-)) and they would have to compete on price and performance and quality. The three words that say "Japan, please rape this market." For a graphic example of this look at the IBM PC-Clone market. Here, IBM, rather than some standards body, layed out exactly what was in a PC, including listings of its BIOS, and made a complete map of what was a PC, little or no ambiguity was involved. What little ambiguity there was like, "If there is a BIOS ConOut() call will anyone write directly to the screen memory?" were settled after a few applications didn't run on the clones and they got toasted for it. So we get a completely level playing field and *bam* the Japanese own it. Except for some hold outs like Bell (pushing performance) and Compaq (pushing quality) the best trump card is Japan Inc (pushing cheap). * Flame off * Ideally, there would be a standard tape drive and someone could just sell a package with their SCSI controller and say "Oh, if you buy a tape drive, you can use this to talk to it." Instead, it will probably be something like, "You have to buy brand X tape drive, otherwise the software won't work." And the reason no one will sell tape drives is because if you are a small company and get the 100 unit discount, when it becomes obvious you are going to be successful (like you sell 50 or so drives and people start talking about you) some distributer will buy 1000 and undercut your price leaving you with 50 unsold. --Chuck McManis uucp: {anywhere}!sun!cmcmanis BIX: cmcmanis ARPAnet: cmcmanis@Eng.Sun.COM These opinions are my own and no one elses, but you knew that didn't you. "If it didn't have bones in it, it wouldn't be crunchy now would it?!"
maniac%arrakis.nevada.edu@cunyvm.cuny.edu (12/06/89)
In article <5166@udccvax1.acs.udel.EDU> don@vax1.acs.udel.EDU (Donald R Lloyd) writes: >In article <3481@convex.UUCP> swarren@convex.COM (Steve Warren) writes: >> >>"C Ltd's KRONOS controllers are the *only* non-DMA controllers utilizing > ^^^^^^^^^ >>full bus wide 16-bit data transfer. Using a unique dual-buffered psuedo- >>DMA design, KRONOS systems transfer data into the Amiga at full Amiga bus >>speed, in fact, KRONOS systems are so fast that the hard drive itself is >>now the limiting factor." > > Supra is making this same claim for their WordSync controller. > I bought it at WOC, mainly because it was cheaper than most of the >others the dealers still had left.... That's funny. Everyone is ignoring a "little guy" again (just as IBM'ers and Macists ignore Amiga innovations), and that is the PaloMAX project, which has had a 16 bit controller option for over a year. It had diskperfs of about 550-600K/sec too. Naturally, this was done after I built mine, with an 8 bit controller. But 295K/sec isn't bad for an 8 bit non-DMA controller. Eric J. Schwertfeger, UNLV maniac@arrakis.nevada.edu
sullivan%nssg.enet.dec.com@cunyvm.cuny.edu (12/06/89)
In article <3481@convex.UUCP>, swarren@eugene.uucp (Steve Warren) writes...
"There *are* some really excellent features claimed in their literature,
"like support for all kinds of different SCSI devices such as
"tape drives, removeable media, WORM drives, SCSI laser printers,
"page scanners, etc. They also claim to be the only controller
"that is supplied with "...a fully functional AmigaDOS type library
"that allows users to write and create custom software that can
"issue SCSI commands directly to SCSI devices."
I follow the C-Ltd BBS regularly and have seen a barely
documented library there for some time. I have used it and it is
usable, though essensially undocumented. When I downloaded it about a
year ago there were incompatibilities in the examples that prevented
them from working and I had to correct the "C" include files. I am
not sure I would call it "fully functional" but it did the little bit
I was trying to do.
With decent documentation and support it could be quite good.
That seems to be the concensus opinion for all C-Ltd Products among
C-Ltd owners I know. They could be *quite* good with better support.
-SES