page@swan.ulowell.edu (Bob Page) (02/25/88)
Randy Spencer wrote: >The most recent rev of [the CLtd] software .. has software available >that does LAN stuff over the SCSI net. I have a part of that running >on my machines (have 3 amigas and 1 hard disk). Harald Milne responded: >Does anybody know more about this? It's available. The latest rev of the SCSI software is 2.03. If you have 2.01 you can get the new version from the CLtd BBS (send me mail if you want the number). If you have an old version, you have to buy a new PAL for your controller before you can use 2.01 and/or 2.03. If you have 2.01 and don't need the SCSI NET stuff, you don't need 2.03, but if you have a SCSI net you must get 2.03. [bunsen burner on] CLtd's support sucks rocks. If you have a technical question (anything more techincal than "how do I hook it up") they can't answer you. Sure, they'll get one of the technicians to call you. And they love you, and the check is in the mail, and they won't come in your mouth. Foo. Their driver has bugs. Big, hairy ones. Like, the driver goes out for tea sometimes. I wrote a program to bring it back to life. All it does is keep asking for some block until the driver wakes up (with a gawd-awful screech). I called them to tell them (nicely) and they refused to believe it was THEIR problem. "ah, your disk has a bad spot" they say. Foo. The driver also won't load with the Fast File System, unless you allocate something like 5200 bytes of stack for it. It will GURU on you. Wonderful. I call CLtd to tell them this, and they think I'm from Neptune. So, all you CLtd users - take note of this when you get FFS, because CLtd won't tell you. They'll tell you to partition your drive into a 1MB filesystem and a 19MB (or whatever) filesystem, and put the SLOW filesystem on the 1MB partition. They don't support BindDrivers, so there's no need for this. Foo. I asked them when they'd produce a DMA interface. They tell me, "With the Fast File System we are 8 to 9 times faster than the current version," -- they're not -- and "we'll be AS FAST IF NOT FASTER than any DMA controller." And you love me, right? Earlier today I reported that I saw the CBM 2090 doing a cool 500KB/sec, and Steve Beats of CBM (who did FFS) tells me he should be able to top out at over 1MB/sec. I defended CLtd when Perry was dumping on them; I defended CLtd when Fred Fish was dumping on them; I'm not defending CLtd any more. I bought the hard disk when it first came out, with no documentation, and still haven't got any. CLtd mentioned source availability when the driver first came out. Never happened. I don't trust the CLtd driver. CLtd does not support their customers. CLtd doesn't even let their customers support them! [bunsen burner off] Anyone know of a DMA SCSI manufacturer for the A1000? ..Bob -- Bob Page, U of Lowell CS Dept. page@swan.ulowell.edu ulowell!page "I don't know such stuff. I just do eyes." -- from 'Blade Runner'
terry@wsccs.UUCP (terry) (03/04/88)
In article <5074@swan.ulowell.edu>, page@swan.ulowell.edu (Bob Page) writes: > It's available. The latest rev of the SCSI software is 2.03. If you > have 2.01 you can get the new version from the CLtd BBS (send me mail > if you want the number). If you have an old version, you have to buy > a new PAL for your controller before you can use 2.01 and/or 2.03. If > you have 2.01 and don't need the SCSI NET stuff, you don't need 2.03, > but if you have a SCSI net you must get 2.03. Post the number, then we can all get busy signals. Or post the software to here. > CLtd's support sucks rocks. If you have a technical question > (anything more techincal than "how do I hook it up") they can't answer > you. Sure, they'll get one of the technicians to call you. And he will tell you how to correctly tie your socks. I am still waiting for a call on how I am supposed to open a serial port via the "standard" interfaces and then hang (san you say "hibernate"?) until I either get input from the console or the serial port, so as to not have to poll, thereby taking CPU time. I am also waiting for a call back on how you are supposed to have a program boost it's own priority, yet still work with the 68010, et al, and NOT have to resort to supervisor state. This will let me, in combination with the other call, write terminal software that can talk at a decent clip (anybody written an interrupt driven serial.device?) without tripping over other processes. This is apparently what Sonix did to keep it from losing a beat while doing disk I/O. Otherwise, I'll just have to grab the machine... my comm software I'm doing is a port and is over 55,000 lines of C code, and I'll be damned if I'll rewrite it in 68000 for GOD or anybody. It works dandy on a Tandy 6000 (also a 7 or so MGHz box, but running 8 users and Xenix (read system III Unix) and cron and uucp...) at 9600 baud without losing characters. Commodore says they can go MIDI speeds and still multi-task ...this may be true, but the driver's passing stuff to me at about 2400 baud or less, depending on system loading. Maybe my disk has a "bad spot"... (didn't the guy know about the word sector? Some techinical support) > I call CLtd to tell them this, and they think I'm from Neptune. Why not? That's probably the only place you can be from and still have talked to someone who knows something :-(. > I asked them when they'd produce a DMA interface. They tell me, "With > the Fast File System we are 8 to 9 times faster than the current > version," -- they're not -- and "we'll be AS FAST IF NOT FASTER than > any DMA controller." What about a DMA controller using FFS? The truth is, they can't build one either. I only know of one out there, and it's ...well, sorta pretending to do DMA. Can't they even use one of their 26 channels? > Anyone know of a DMA SCSI manufacturer for the A1000? Nope. I don't think it can be done with developement costs low enough that I could afford one anyway. | Terry Lambert UUCP: ...!decvax!utah-cs!century!terry | | @ Century Software or : ...utah-cs!uplherc!sp7040!obie!wsccs!terry | | SLC, Utah | | These opinions are not my companies, but if you find them | | useful, send a $20.00 donation to Brisbane Australia... | | 'There are monkey boys in the facility. Do not be alarmed; you are secure' |
andy@cbmvax.UUCP (Andy Finkel) (03/10/88)
In article <256@wsccs.UUCP> terry@wsccs.UUCP (terry) writes: >> CLtd's support sucks rocks. If you have a technical question >> (anything more techincal than "how do I hook it up") they can't answer >> you. Sure, they'll get one of the technicians to call you. > > And he will tell you how to correctly tie your socks. I am still >waiting for a call on how I am supposed to open a serial port via the I know I'm going to regret asking this: but why do you expect a peripheral manufacturing company to help you write programs ? They make hard disks, and similar things. I mean, the guys at C-Ltd might be nice guys, but what reason do they have to help you write your programs ? Could this explain why they are not much help ? >"standard" interfaces and then hang (san you say "hibernate"?) until I >either get input from the console or the serial port, so as to not have to >poll, thereby taking CPU time. I am also waiting for a call back on how you >are supposed to have a program boost it's own priority, yet still work with >the 68010, et al, and NOT have to resort to supervisor state. This will let Well, you might try looking it up in the manuals, rather than bothering C-Ltd. Most people use Signals to Wait on several events on the Amiga. (See the Exec manual for details) The FindTask() call in combination with the SetTaskPri() call lets you change priorities around. I don't recommend this, unless you know what you are doing. >me, in combination with the other call, write terminal software that can talk >at a decent clip (anybody written an interrupt driven serial.device?) without >tripping over other processes. This is apparently what Sonix did to keep >it from losing a beat while doing disk I/O. Otherwise, I'll just have to grab >the machine... my comm software I'm doing is a port and is over 55,000 lines >of C code, and I'll be damned if I'll rewrite it in 68000 for GOD or anybody. A word of advice...the best programs that run on a machine notice what machine that they run on. For instance, most 68000 programs know to word align data. The worst programs are the quick ports. From what you describe you are doing the port for primarily your own amusement, so whether you rewrite or not is certainly up to you, rather than the supreme being. AmigaTerm, written entirely in C, works at 9200 BAUD *without* flow control (this is faster than a VT101) With flow control it works fine at 19.2KB. The main trick is 1) to get as many characters as the serial device has waiting for you at a time. There's a query command for this purpose. 2) print as many characters as you can at a time. 3) set the buffer on the serial.device based loosely on the baud rate. >losing characters. Commodore says they can go MIDI speeds and still multi-task >...this may be true, but the driver's passing stuff to me at about 2400 baud >or less, depending on system loading. Only if you use it poorly. > What about a DMA controller using FFS? The truth is, they can't >build one either. I only know of one out there, and it's ...well, sorta >pretending to do DMA. Can't they even use one of their 26 channels? You really need to check out the Amiga hardware manual, and the A500/A2000 Technical Manual before you continue about things like this. Really. The A2090 hard disk controller card does use DMA. Its a Zorro-2 card; there are several companies who make cages that let A1000 owners use Zorro-II cards. -- andy finkel {ihnp4|seismo|allegra}!cbmvax!andy Commodore-Amiga, Inc. "Never test for an error condition you don't know how to handle." Any expressed opinions are mine; but feel free to share. I disclaim all responsibilities, all shapes, all sizes, all colors.
dillon@CORY.BERKELEY.EDU (Matt Dillon) (03/10/88)
>AmigaTerm, written entirely in C, works at 9200 BAUD *without* flow control >(this is faster than a VT101) With flow control it works fine at 19.2KB. > .. >loosely on the baud rate. > .. >>losing characters. Commodore says they can go MIDI speeds and still multi-task >>...this may be true, but the driver's passing stuff to me at about 2400 baud >>or less, depending on system loading. > >Only if you use it poorly. Yah, really. Anybody who passes 1 byte read requests to the serial device deserves what he gets! What you *do* get with 1 byte read requests is about 1500 baud on the read. On the otherhand, with MIN(256,SCMD_QUERY) byte requests, you get it at full speed. Every program I know uses the SCMD_QUERY method. Now, assuming C-A fixes (in 1.4?) the problems with Disabling for too long within the kernel, the serial.device shouldn't have any further problems getting overruns reading at high speeds. BTW: BUG in the serial.device ... you cannot have multiple outstanding CMD_WRITE requests. There is a timing window in the serial.device (as far as I can tell) which can cause it to fail to begin a CMD_WRITE and never return the request. That is, you should have only one asynchronous CMD_WRITE active at a time. I found that one working on DNET. -Matt
terry@wsccs.UUCP (terry) (03/15/88)
In article <3449@cbmvax.UUCP>, andy@cbmvax.UUCP (Andy Finkel) writes: > In article <256@wsccs.UUCP> terry@wsccs.UUCP (terry) writes: > > >> CLtd's support sucks rocks. If you have a technical question > >> (anything more techincal than "how do I hook it up") they can't answer > >> you. Sure, they'll get one of the technicians to call you. > > > > And he will tell you how to correctly tie your socks. I am still > >waiting for a call on how I am supposed to open a serial port via the > > I know I'm going to regret asking this: but why do you expect a > peripheral manufacturing company to help you write programs ? They wrote the OS and built the hardware... they damn well better know how to talk to it, don't you think? Or are you leaking something about the OS. > They make hard disks, and similar things. > I mean, the guys at C-Ltd might be nice guys, but what reason > do they have to help you write your programs ? My (again truncated) question "in question" was in reference to how to do something VIA the OS. I _CAN_ do it by thaking over, but everybody tells me "that isn't nice!". If I am supposed to write something that conforms to some CLtd multi-tasking standard, I would appreciate being told how I can conform, given my restraints. > Could this explain why they are not much help ? Hardly. Again, who wrote the OS, elves? Elvis? > > >"standard" interfaces and then hang (can you say "hibernate"?) until I > >either get input from the console or the serial port, so as to not have to > >poll, thereby taking CPU time. I am also waiting for a call back on how you > >are supposed to have a program boost it's own priority, yet still work with > >the 68010, et al, and NOT have to resort to supervisor state. This will let > > Well, you might try looking it up in the manuals, rather than > bothering C-Ltd. Yeah, right. The A1000 ROM Kernal manual does me a lot of good, given that it is written for the '86 or so revision of the OS on a machine no longer being sold. What are the differences I should watch for? How do I maintain compatability with 1.x where x>2? > Most people use Signals to Wait on several events on the Amiga. > (See the Exec manual for details) That would be nice, except you can not then use an alarm in Aztec 3.4 as it conflicts with the timer, giving as colorful results as the same type of event does under VMS. It seems multiple outstanding events of the same type blow up in certain cases... > The FindTask() call in combination with the SetTaskPri() call lets > you change priorities around. I don't recommend this, unless > you know what you are doing. What about "I want this task to have priority x where x is 10 greater than any other user task's priority"? > A word of advice...the best programs that run on a machine notice > what machine that they run on. I should not have to "notice" what machine I'm on to be good. Perhaps it won't be "best", but it _will_ be good. The whole point of an HLL is to *not* notice. > For instance, most 68000 programs > know to word align data. Obviously, I would have pretty severe problems if I were so stupid as to not correctly align my structures/variables. I assume a compiler will do this for me. > The worst programs are the quick ports. I would correct this to "The worst programs are those that can't be ported quickly. The programs which run worst are those that were ported quickly anyway." > AmigaTerm, written entirely in C, works at 9200 BAUD *without* flow control > (this is faster than a VT101) With flow control it works fine at 19.2KB. It's not faster than my VT101.. you must have 50Hz power... what else do you have running at the same time, may I ask? You should be able to do 9600 baud with multiple users and only 20% of the CPU in use. If Tandy can do it with their 68000 box by virtue of Microsoft Xenix, Commodore ought to be able to do it with 50% overhead with a single user. Besides, AmigaTerm cheats: 1) it was written by people with access to current docs 2) you can't run much else 3) it seems that it uses a ANSI 3.64 console driver... that is _NOT_ emulating. > loosely on the baud rate. > > >losing characters. Commodore says they can go MIDI speeds and still multi > >-task ...this may be true, but the driver's passing stuff to me at about > >2400 baud or less, depending on system loading. > > Only if you use it poorly. Oh. You mean by caring about things like "parity" and "wordlength"... you know, communication program-type things. You know, those things Telenet, Tymenet, DataPac, and Western Union use? > > What about a DMA controller using FFS? The truth is, they can't > >build one either. I only know of one out there, and it's ...well, sorta > >pretending to do DMA. Can't they even use one of their 26 channels? > You really need to check out the Amiga hardware manual, and the A500/A2000 > Technical Manual before you continue about things like this. > Really. Make one available. Really. Just because you have one, doesn't mean I can go buy one at my Amiga dealer. > The A2090 hard disk controller card does use DMA. > Its a Zorro-2 card; there are several companies who make cages that > let A1000 owners use Zorro-II cards. Wonderful. Patchwork hardware. But is there an expansion box from CLtd that won't violate the warranty, like Commodore claims the others do? | Terry Lambert UUCP: ...{ decvax, ihnp4 }... | | @ Century Software or : ...utah-cs!uplherc!sp7040!obie!wsccs!terry | | SLC, Utah | | These opinions are not my companies, but if you find them | | useful, send a $20.00 donation to Brisbane Australia... | | 'There are monkey boys in the facility. Do not be alarmed; you are secure' |
jesup@pawl16.pawl.rpi.edu (Randell E. Jesup) (03/20/88)
In article <323@wsccs.UUCP> terry@wsccs.UUCP (terry) writes: >In article <3449@cbmvax.UUCP>, andy@cbmvax.UUCP (Andy Finkel) writes: >> In article <256@wsccs.UUCP> terry@wsccs.UUCP (terry) writes: >> >> CLtd's support sucks rocks. If you have a technical question >> >> (anything more techincal than "how do I hook it up") they can't answer >> >> you. Sure, they'll get one of the technicians to call you. >> > And he will tell you how to correctly tie your socks. I am still >> >waiting for a call on how I am supposed to open a serial port via the >> I know I'm going to regret asking this: but why do you expect a >> peripheral manufacturing company to help you write programs ? > They wrote the OS and built the hardware... they damn well better know >how to talk to it, don't you think? Or are you leaking something about the OS. Commodore is NOT CLtd!!!!!! CLtd is a peripheral company, Commodore makes the Amiga! Are you REALLY calling CLtd?????!!!! I'm quite sure that Andy regrets asking that now. :-) >> They make hard disks, and similar things. >> I mean, the guys at C-Ltd might be nice guys, but what reason >> do they have to help you write your programs ? > My (again truncated) question "in question" was in reference to how >to do something VIA the OS. I _CAN_ do it by thaking over, but everybody >tells me "that isn't nice!". If I am supposed to write something that conforms >to some CLtd multi-tasking standard, I would appreciate being told how I can >conform, given my restraints. Did you think of posting your question here, instead of your flames? (Which were misdirected at CLtd) If you are a REGISTERED developer (it's not expensive), you can get answers to technical questions. In fact, you can get them on Bix in the public amiga.dev conference without being a developer (Bix is where Commodore does technical support, the phone line is mainly for commercial, registered developers). >> Could this explain why they are not much help ? > Hardly. Again, who wrote the OS, elves? Elvis? Actually, most of the OS was written at Commodore/Amiga in Los Gatos, CA. Some was written a Commodore in West Chester, and the DOS was written by Metacompco in England. >> >poll, thereby taking CPU time. I am also waiting for a call back on how you >> >are supposed to have a program boost it's own priority, yet still work with >> >the 68010, et al, and NOT have to resort to supervisor state. This will let >> Well, you might try looking it up in the manuals, rather than >> bothering C-Ltd. > Yeah, right. The A1000 ROM Kernal manual does me a lot of good, given >that it is written for the '86 or so revision of the OS on a machine no longer >being sold. What are the differences I should watch for? How do I maintain >compatability with 1.x where x>2? Why don't you either 1) become a registered developer, 2) buy the 1.2 Autodocs if you don't want to become a developer ($20), or 3) join Bix and ask questions in the amiga and amiga.dev conferences (open to all). Answers usually come fast and furious (often from other developers, as well). >> Most people use Signals to Wait on several events on the Amiga. >> (See the Exec manual for details) > That would be nice, except you can not then use an alarm in Aztec 3.4 >as it conflicts with the timer, giving as colorful results as the same type >of event does under VMS. It seems multiple outstanding events of the same type >blow up in certain cases... Huh? An alarm, you say. As far as I know, there is no such thing on the AMiga. If you mean signals, follow the examples in the RKMs to handle them, you can miss messages at a port if you do it wrong. 'Pure' signals are real tough to foul up, though it can be done. If you're talking events, you must mean messages at a port from intuition. >> The FindTask() call in combination with the SetTaskPri() call lets >> you change priorities around. I don't recommend this, unless >> you know what you are doing. > What about "I want this task to have priority x where x is 10 greater >than any other user task's priority"? Real simple: Forbid(), then walk the task list, find the highest priority user task, and make your's higher (via SetTaskPriority, don't mess with the tasks directly), and Permit(). It makes no difference if your task is 1 higher or 10 higher than another, the task with the highest priority that wants to run gets the CPU (if the same, they time-slice). Note that it is REAL BAD to make your priority higher than any system tasks. I'd advise NEVER using a priority higher than 9, NEVER EVER higher than 14 unless you REALLY know what you're doing. >> AmigaTerm, written entirely in C, works at 9200 BAUD *without* flow control >> (this is faster than a VT101) With flow control it works fine at 19.2KB. > It's not faster than my VT101.. you must have 50Hz power... >what else do you have running at the same time, may I ask? You should be >able to do 9600 baud with multiple users and only 20% of the CPU in use. If >Tandy can do it with their 68000 box by virtue of Microsoft Xenix, Commodore >ought to be able to do it with 50% overhead with a single user. Besides, >AmigaTerm cheats: > 1) it was written by people with access to current docs > 2) you can't run much else > 3) it seems that it uses a ANSI 3.64 console driver... that is _NOT_ > emulating. You seem to be missing the point that speed settings on a terminal doesn't mean the terminal can keep up with continuous data at that speed, complete with scrolling. It {slowly,quickly} falls behind. The Dec VT101 cannot keep up with straight text at 9600 baud (though I think it makes about 7000-8000 effective). Re: the Tandy 6000 - Sure, you can pump out characters fast, we're talking about displaying them on a scrolling screen. Also, I'd bet that the Tandy 6000 would use more than 20% pumping continuous data at 9600 to multiple users. Just cause the line rate is 9600 doesn't mean it's all being used. Re: access to docs - I wrote (for my own interest) a complete vt100 emulator 1.5 years ago (before 1.2), that could also to 9600 on continuous data. It just requires good programming, no 'special docs' needed. Re: Ansi 3.64 - Amiga CLI windows use ANSI 3.64, AmigaTerm is full DEC vt102. There are some programs out there that do just use 3.64 for termeinal programs, but not AMigaTerm. >> >losing characters. Commodore says they can go MIDI speeds and still multi >> >-task ...this may be true, but the driver's passing stuff to me at about >> >2400 baud or less, depending on system loading. >> Only if you use it poorly. > Oh. You mean by caring about things like "parity" and "wordlength"... >you know, communication program-type things. You know, those things Telenet, >Tymenet, DataPac, and Western Union use? Like I said, if you use it right, you can easily do 9600. The real big win is to read as many characters as possible, by using the SCMD_QUERY message to find out how many are waiting (after you wake up from a single character read.) Also, sending characters in large blocks is faster than lots of 1-char sends. Why don't you look at the source code for one of the fast terminal programs (like VT100) on the Fish disks? >> > What about a DMA controller using FFS? The truth is, they can't >> >build one either. I only know of one out there, and it's ...well, sorta >> >pretending to do DMA. Can't they even use one of their 26 channels? >> You really need to check out the Amiga hardware manual, and the A500/A2000 >> Technical Manual before you continue about things like this. >> Really. > Make one available. Really. Just because you have one, doesn't mean >I can go buy one at my Amiga dealer. I think dealers can order them, and I know you can get them from Commodore ($20). I think Andy should be commended for not flaming you when you take potshots at him and Commodore when you don't know what you're talking about (refering to "The truth is, they can't build one either.") >> The A2090 hard disk controller card does use DMA. >> Its a Zorro-2 card; there are several companies who make cages that >> let A1000 owners use Zorro-II cards. > Wonderful. Patchwork hardware. But is there an expansion box from >CLtd that won't violate the warranty, like Commodore claims the others do? For an A1000, expansion boxes mount on the side, and do not violate any warranty. That is what the side connector is for, it is not 'patchwork hardware'. CLtd sells HD controllers that attach directly to the side of an Amiga, COMMODORE doesn't. The only expansions that violate your A1000 warranty are internal ones. (There is no normal internal expansion on the A1000, it's external.) >| Terry Lambert UUCP: ...{ decvax, ihnp4 }... >| These opinions are not my companies, but if you find them | >| useful, send a $20.00 donation to Brisbane Australia... | I seriously doubt I'll be sending that donation... // Randell Jesup Lunge Software Development // Dedicated Amiga Programmer 13 Frear Ave, Troy, NY 12180 \\// beowulf!lunge!jesup@steinmetz.UUCP (518) 272-2942 \/ (uunet!steinmetz!beowulf!lunge!jesup) BIX: rjesup (-: The Few, The Proud, The Architects of the RPM40 40MIPS CMOS Micro :-)
dlarson@blake.acs.washington.edu (Dale Larson) (01/11/90)
<eat me!>
Today I called C Ltd's Customer Support number in an effort to find out
if they are doing anything in regards to tape backup (which they
didn't support as of six months ago). To my suprise, the number was
disconnected. I dialed the number in the SCSIdos 3.0 manual,
316-267-0202.
Does anyone know if C Ltd has moved or gone under or what?
--
A lack of prior planning on the part of any programmer
always constitutes an emergency.
Digital Teddy Bear dlarson@blake.acs.washington.edu