Baudbandit.device?
Scotty A Johnson
he is using a baudbandit.device.
I thought that baudbandit was a term prog!
I guess it still could be, but why would people be using
devices from one term prog on another?
Please enlighten me,
--
------------------------------------------------------------------------------
Scotty A. Johnson "The beast with the four foot tail." Igu...@uiuc.edu
------------------------------------------------------------------------------
Robert Lai
The BaudBandit.device is not associated with Baud Bandit, the term
program. It's a replacement for the serial.device that, according
to the docs, makes it possible to transfer at 115200 bps on
a stock 68000. It sounds great, and it does seem to work as
a replacement for the serial.device. I haven't been using it
long enough to say if in fact it does work at such high speeds.
I get errors when I set my term program to 57.6k bps, which is
as much as it allows, so maybe you need 1.3 or 2.0, cause I'm still
using 1.2.
--
This is Robert Lai's "Signature File," and the reader is reminded
that 'tis the season to be Jolly - Falla La La La...la la la la.
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
WGL...@slacvm.slac.stanford.edu
product, and there is a completely unrelated serial.device replacement (?)
called BaudBandit.device by a different author. I believe the two have nothing
to do with one another, and there's a case to be made that baudbandit.device
is in violation of trademark rights, if in fact BaudBandit the terminal
program is trademarked.
By the way, if the author of baudbandit.device reads this and plans to
change the name, please follow Commodore guidelines and make the name all
lower-case.
Willy.
----------
Willy Langeveld - Bitnet: WGLP09 @ SLACVM - BIX: langeveld
Thomas Lydhig
that do wonderful things to your amiga! If you put BaudBandit.device (which is
shareware in opposite to BaudBandit term prog that is commersal) in DEVS: on
you amiga and change serial.device on your term prog you will be able to use
up to 115200 bps on a standard amiga!!! It is superb! I have use it for some
month now an I have no bugs!
You will get it on some ftp-sites, and if I are well informed the latest
version is 1.4. If you can't find it mail me and I will give you a ftp-site!
/ T Lydhig, Sweden
James A Grizzard
>I just read a posting by James Grizzard, and he indicated that
>he is using a baudbandit.device.
>
>I thought that baudbandit was a term prog!
>
>I guess it still could be, but why would people be using
>devices from one term prog on another?
>
>Please enlighten me,
yes, baudbandit IS a term program, but there's also a device called BaudBandit.device.
it's basically a serial device replacement that has a LOT less overhead than serial.
device, and is supposed to be able to handle 115k on a stock 68000. all it removes
is Xon/Xoff, and adds the fact that you have to be at 8N1.
I've definately noticed a lighter strain while multitasking, tho.. it's worth the
trouble to use....
look for it on anonymous ftp at amiga.physik.unizh.ch in amiga/comm/misc/
Paul Kienitz
> BaudBandit term prog that is commersal) in DEVS: on you amiga and
> change serial.device on your term prog you will be able to use up
> to 115200 bps on a standard amiga!!! It is superb! I have use it
> for some month now an I have no bugs!
old serial.device when they encountered problems.
Chris Mojica
Yeah me to I tried using it with JrComm on our serial link-ups in our rooms
and all that happened when I tried to use the BaudBandit.device is that my
whole system locks up. :(
#--------------------------------------------------------------------------#
| /// |
| /// North Carolina State University, USA |
| /// Amiga #1 :) Email: thu...@garfield.catt.ncsu.edu |
| \\\/// pcmo...@eos.ncsu.edu |
| \XX/ |
Thomas Lydhig
: > If you put BaudBandit.device (which is shareware in opposite to
This was a short mail! (Have you heard about "positive waves")!
I have use BaudBandit.device v1.2 it crashed my machine too and I have even
tried other serial.device:s which not have worked. _BUT_ BaudBandit.device v1.4
seems to work. I use Term2.3, WB2.1 and no crashes!
"Try It you like it!!!"
Rankin Eric
I can't even get it to init with Term, JRComm, C-Net, Magicall, NOTHING.
I've tried several versions including 1.0 and 1.4 and nothing...
I'm running ZKicked ROMs and WB 2.1 on an Amiga 3000.
Eric
ANTHONY FRANCIS PRESTON
version I am Beta testing). It did not work however with the Citade3l
er.. Citadel BBS program(I maintain the Amiga Citadel). I don't do
anything unusual and open the port Shared, Xon/Xoff disabled, and
use Serial 7 wire. Other than read and writes to the serial Port,
I do a query. It just kinds locks up when I tried it. It does
seem to be quite a bit faster than the regular serial.device.
Anyone know why it doesn't work?
BarryB
>I can't even get it to init with Term, JRComm, C-Net, Magicall, NOTHING.
>I've tried several versions including 1.0 and 1.4 and nothing...
I have succesfully used both 1.2 and 1.4 of BaudBandit.device.
worked?
-------
VLT no
Term yes
MagiCall yes
I am using all the latest versions of the programs on a 3000 btw.
-BarryB
WGL...@slacvm.slac.stanford.edu
library and device names and BaudBandit.device uses mixed case.
One can patch it to have all lower case everywhere...
Blaise Tarr
(BarryB) says:
>I have succesfully used both 1.2 and 1.4 of BaudBandit.device.
>
> worked?
> -------
>VLT no
>Term yes
>MagiCall yes
I got the BaudBandit.device to work with VLT after reading one of Willy's
posts. The problem is that VLT does not like capital letters in the device
name (C= made that rule). So I took a hex file editor, namely FileMaster,
and changed the capital "B"s in the string "BaudBandit" to a lower case "b".
This occurs at a couple of places in the BaudBandit.device file. After that
I renamed BaudBandit.device to baudbandit.device, and tada, it works :-).
/// Blaise Tarr
///
\\\/// BGT...@psuvm.psu.edu "Typically, the subject being copied
\XX/ ta...@cs.psu.edu is terminated." -CSM 101
Jan Hauge Andersen
>I have succesfully used both 1.2 and 1.4 of BaudBandit.device.
> worked?
> -------
>VLT no
>Term yes
>MagiCall yes
Works with NComm 2.0 as well.
Best Wishes
Jan
Richard Losey
>I can't even get it [BaudBandit.device] to init with Term, JRComm, C-Net,
> Magicall, NOTHING.
>I've tried several versions including 1.0 and 1.4 and nothing...
I was under the impression that it wouldn't work on UNIX boards (at least on
the board I call) that use 7E1 -- it only supports 8N1. Can anybody confirm
this? Otherwise, I think it is OK.
Hans Ridder
I can't, I've never seen this BaudBandit.device. If it's true that it
only supports 8N1, then that would explain the claims that it is faster
than the C= serial.device driver. You don't get something for nothing.
I could very well be other things "missing" from BaudBandit.device to
make it faster.
Since C= rewrote serial.device for 2.0 (and made it quite a bit faster,)
I imagine that it's about as fast as it can be. I'm sure C= could make
it faster by taking some features out!
>Otherwise, I think it is OK.
If you don't need the "extra" features that BaudBandit.device apparently
omits, then I would agree, it is OK. However, C= didn't put those extra
features in the serial.device just to slow it down. Some people
actually need them. For those people BaudBandit.device would not be OK
at all....
-hans
--
Hans-Gabriel Ridder Digital DECwest Engineering
rid...@rust.zso.dec.com Bellevue, Washington, USA
{pacbell,pyramid,uunet}!rust.zso.dec.com!ridder
Russell McOrmond
Mark Welmat down as a 'no'. I have not tested it myself, but
the lack of TermArray support means that baudbandit.device will not
work with Welmat V1. I have no idea if it will work with Welmat V0.44
or V.47.
--
Opinions expressed in this message are my Own. I represent nobody else.
Russell McOrmond r...@Atronx.OCUnix.On.Ca Net Support:(613) 230-2282(V.32Bis)
FidoNet 1:163/109 Welmat Help 1:1/139 Current WELMAT 'keeper of sources'.
Thomas Lydhig
Hans-Gabriel Ridder wrotes:
: I can't, I've never seen this BaudBandit.device. If it's true that it
: only supports 8N1, then that would explain the claims that it is faster
: than the C= serial.device driver. You don't get something for nothing.
: I could very well be other things "missing" from BaudBandit.device to
: make it faster.
:
: Since C= rewrote serial.device for 2.0 (and made it quite a bit faster,)
: I imagine that it's about as fast as it can be. I'm sure C= could make
: it faster by taking some features out!
:
: >Otherwise, I think it is OK.
:
: If you don't need the "extra" features that BaudBandit.device apparently
: omits, then I would agree, it is OK. However, C= didn't put those extra
: features in the serial.device just to slow it down. Some people
: actually need them. For those people BaudBandit.device would not be OK
: at all....
I supose you try it before have to many opinions about it. Of cause you lose
something, but for modem users it has exactly what you need. Who wants to have
parity and a lot of stop bit that makes communication slower, it's better to
have a good communication protocoll like Zmodem! The serial.device is for many
different uses. C= have to do it general so the user can connect any device to
the Amiga. But the you use highspeed modem BaudBandit.device it's better
because it do exactly what it have to do and not more!
David Walthour
>j...@holger.icl.dk (Jan Hauge Andersen) writes:
>>n884...@henson.cc.wwu.edu (BarryB) writes:
>
>
>>>I have succesfully used both 1.2 and 1.4 of BaudBandit.device.
>
>>> worked?
>>> -------
>>>VLT no
Using the QuickFix program which comes with BaudBandit 1.4, I have been
successfully using it with VLT, but I couldn't get it to work by having
VLT open the BaudBandit.device.
>>>Term yes
>>>MagiCall yes
>
>>Works with NComm 2.0 as well.
>
> Mark Welmat down as a 'no'. I have not tested it myself, but
>the lack of TermArray support means that baudbandit.device will not
>work with Welmat V1. I have no idea if it will work with Welmat V0.44
>or V.47.
>
>--
> Opinions expressed in this message are my Own. I represent nobody else.
> Russell McOrmond r...@Atronx.OCUnix.On.Ca Net Support:(613) 230-2282(V.32Bis)
> FidoNet 1:163/109 Welmat Help 1:1/139 Current WELMAT 'keeper of sources'.
David Walthour
walt...@dartmouth.edu
John Bickers
> Since C= rewrote serial.device for 2.0 (and made it quite a bit faster,)
CBM is a little wierd with the serial.device. Did they put in a
"drop DTR" command with 2.0?
I think it's fair to say that most comms people do with a micro
nowadays is 8N1 with hardware handshaking. Anything else is either
obsolete or getting that way.
For example, all BBSing here is 8N1, and the only thing I've got
that needs 7E1 is logging into a stupid Unix box.
> I imagine that it's about as fast as it can be. I'm sure C= could make
> it faster by taking some features out!
The documented performance of serial.device that I've got does not
match the speed that the comms port can be driven at by some
pieces of software. I don't think the serial.device is written
with "ultimate" speed in mind, it's more of a general purpose
thing.
> -hans
--
*** John Bickers, TAP. jbic...@templar.actrix.gen.nz ***
*** "Radioactivity - It's in the air, for you and me" - Kraftwerk ***
Ernst Jan Plugge
>> least on the board I call) that use 7E1 -- it only supports 8N1. Can
>> anybody confirm this?
HR> I can't, I've never seen this BaudBandit.device. If it's true that it
HR> only supports 8N1, then that would explain the claims that it is
HR> faster than the C= serial.device driver. You don't get something for
HR> nothing. I could very well be other things "missing" from
HR> BaudBandit.device to make it faster.
Yes, that was the idea behind BaudBandit.device! For normal use, calling BBS'es and stuff (I heard it's good with serial cables connecting computers directly too (damn, I don't know the English word for it...)). Fancy stuff that isn't needed for normal BBS'ing (like 7E1, because all BBS'es I know use 8N1) is left out, to allow greater speed.
HR> Since C= rewrote serial.device for 2.0 (and made it quite a bit
HR> faster,) I imagine that it's about as fast as it can be. I'm sure C=
HR> could make it faster by taking some features out!
Well, I manage very well with the serial.device in 2.04, but then again, I hardly ever need more than 2400 bps :)
Next time I need to do some transfers over serial cable, I'll take a look at BaudBandit.
Greetz,
Ernst
Fido: 2:512/17.31 NLA: 14:103/100.5 AMY: 39:155/101.5 Usenet:ernst.ja...@waterland.wlink.nl
Owen Mckeith
didn't notice any problems, but a number of high speed users state that
they were getting SLOWER transfer rates than they did when I used C='s
Serial.device, therefore I switched back, and we were getting back up
towards 1600 - 1800 cps on compressed files.
-- Via DLG Pro v0.992
__ |
/// Owen McKeith. | Sysop: SASKATOON AMIGA USERS' GROUP BBS
/// | 14400 V.32bis/V.42bis
__ /// Amiga 2000 | Phone: (306) 244-6936
\\\/// 50Mhz G-Force | Fido: 1:140/58.0
\XX/ 9Mb RAM | UUCP: Telepro!SAUG!Owen_M...@access.usask.ca
|
Hans
>I supose you try it before have to many opinions about it.
If you reread what I said, you'll see that I didn't post my opinions
about it.
>Of cause you lose something, but for modem users it has exactly what
>you need. Who wants to have parity and a lot of stop bit that makes
>communication slower, it's better to have a good communication
>protocoll like Zmodem!
There are modem users who don't have the choice of *not* using parity.
So for them, it is *not* exactly what they need. Better is a matter of
opinion and a matter of need.
>The serial.device is for many different uses. C= have to do it general
>so the user can connect any device to the Amiga.
You're repeating what I said!
>But the you use highspeed modem BaudBandit.device it's better because
>it do exactly what it have to do and not more!
Right, but like I said before, *only* if you don't need more than what
it provides, and some people do need more.
Hans Ridder
>Quoted from <1992Oct12....@ninja.zso.dec.com> by Hans Ridder <rid...@zso.dec.com>:
>> Since C= rewrote serial.device for 2.0 (and made it quite a bit faster,)
>
> CBM is a little wierd with the serial.device. Did they put in a
> "drop DTR" command with 2.0?
No, so what's your point? What does that have to do with its speed, or
whether they rewrote it? Does BaudBandit.device have a "drop DTR"
command? I don't want to put myself in the postion of defending C=,
I'll leave that to them, I was just stating a fact, which you took out
of context.
> I think it's fair to say that most comms people do with a micro
> nowadays is 8N1 with hardware handshaking. Anything else is either
> obsolete or getting that way.
>
> For example, all BBSing here is 8N1, and the only thing I've got
> that needs 7E1 is logging into a stupid Unix box.
So far you've shown two examples. BBSing and "a stupid Unix box." And
the results are 50/50 for your 8N1 claim. What else comes under your
heading of "most comms people do?" *I* think it's fair to say that not
all the world is a BBS. Some people *must* use XON/XOFF, parity, etc.,
no matter what you think of it. It's not a matter of choice.
The stupidity of Unix is of course a matter of opinion. If you think
it's stupid or obsolete because it uses 7E1, then don't log in to it.
The point is, just saying it's "stupid" doesn't make it go away, or make
anyone's need to communicate with it vanish. Unix is there, people use
it, and it frequently requires 7E1.
>> I imagine that it's about as fast as it can be. I'm sure C= could make
>> it faster by taking some features out!
>
> The documented performance of serial.device that I've got does not
> match the speed that the comms port can be driven at by some
> pieces of software.
OK, let's see your documentation.
I too can write software which will drive the serial port faster than
the serial.device but that's not the point. The point was that
BaudBandit.device makes gains over serial.device by sacrificing
features. Some people don't need those features, some do. It's not for
everyone.
> I don't think the serial.device is written with "ultimate" speed in
> mind, it's more of a general purpose thing.
Isn't that just rephrasing what I said? (Look up above.) I say it's
probably as fast as it can be given the requirements. Take some
requirements away, and you can probably make it faster. Pretty basic
engineering.
>*** John Bickers, TAP. jbic...@templar.actrix.gen.nz ***
-hans
Paul Kienitz
> by sacrificing features. Some people don't need those features,
> some do. It's not for everyone.
For too many of us, there are times that come up when
baudbandit.device just doesn't quite behave in a reliable way, which
the C= driver always does.
John Bickers
> > CBM is a little wierd with the serial.device. Did they put in a
> > "drop DTR" command with 2.0?
>
> No, so what's your point? What does that have to do with its speed, or
Somewhere the article I was replying to said how the serial.device
sacrificed speed for features. I was trying to point out how bogus
this claim would be if it STILL didn't support dropping DTR.
> whether they rewrote it? Does BaudBandit.device have a "drop DTR"
> command? I don't want to put myself in the postion of defending C=,
No, but then BaudBandit.device doesn't have people going about
claiming how wonderful its features are.
> So far you've shown two examples. BBSing and "a stupid Unix box." And
> the results are 50/50 for your 8N1 claim. What else comes under your
> heading of "most comms people do?" *I* think it's fair to say that not
It's not the quantity of the examples, it's the quality. Hands up
everyone whose only comms is BBSing. Hands up everyone who has
more than 50% of the comms time spent BBSing. Around people I
know, virtually everyone would have raised their hand.
It turns out VLT supports the Unix box simply by stripping the
8th bit, and not relying on the serial.device to do the job. So
one doesn't even need 7E1 for that...
> The stupidity of Unix is of course a matter of opinion. If you think
> it's stupid or obsolete because it uses 7E1, then don't log in to it.
It's a living. And of course it can be switched to 8N1. It's
just inconvenient to deviate from the norm when one is a support
guy.
And logging into a Unix box like a terminal IS getting obsolete.
It's not there yet, but it's getting there.
> probably as fast as it can be given the requirements. Take some
> requirements away, and you can probably make it faster. Pretty basic
Frankly no, I don't think this is the case. Writing a fast
general purpose piece of code is just a matter of writing more
specialized chunks, which would increase the size of the thing
but not slow it down.
For example, suppose you wanted to copy a rectangle into a
picture, and wanted to handle both a chunky-pixel and a planar
destination. You COULD have a common rectangle copy that used
a general write pixel routine, but it wouldn't be as fast as
two rectangle copy routines, each optimized for a particular kind
of destination.
I do agree that BaudBandit.device is not for everyone, though. It
has crashed my machine, which got it ditched pretty quick. :)
> -hans
--
*** John Bickers, TAP. jbic...@templar.actrix.gen.nz ***
Jesper Kehlet
> In article <1992Oct9.2...@henson.cc.wwu.edu>, n884...@henson.cc.wwu.edu
> (BarryB) says:
> >I have succesfully used both 1.2 and 1.4 of BaudBandit.device.
> >
> > worked?
> > -------
> >VLT no
> >Term yes
> >MagiCall yes
>
> I got the BaudBandit.device to work with VLT after reading one of Willy's
> posts. The problem is that VLT does not like capital letters in the device
> name (C= made that rule). So I took a hex file editor, namely FileMaster,
> and changed the capital "B"s in the string "BaudBandit" to a lower case "b".
> This occurs at a couple of places in the BaudBandit.device file. After that
> I renamed BaudBandit.device to baudbandit.device, and tada, it works :-).
Or one could use QuickFix, supplied with the BB archive.
>
> /// Blaise Tarr
> ///
> \\\/// BGT...@psuvm.psu.edu "Typically, the subject being copied
> \XX/ ta...@cs.psu.edu is terminated." -CSM 101
--
Jesper Kehlet, Compos Mentis Software Systems -- A Kind Of Magic
(uunet|pyramid|rutgers)!cbmvax!cbmehq!cbmden!kehlet!kehlet
keh...@kehlet.adsp.sub.org
'The lunatic is in my mind' -- Pink Floyd, Dark Side
Hans Ridder
> Somewhere the article I was replying to said how the serial.device
> sacrificed speed for features. I was trying to point out how bogus
> this claim would be if it STILL didn't support dropping DTR.
I don't believe I said it that way. I believe I said that
BaudBandit.device left out some features (of the serial.device) to get
it's speed. I never said that serial.device has everything you'd ever
want and thus has a good excuse to be slow.
I too would like better control of the modem signals, but if we had
them, people would do *all sorts* of ugly things things with them. At
least this way there is *some* reasonable modem signal behavior from the
serial.device.
I'd like to point out that C= is well within the spirit of the EIA232
standard to only support lowering of DTR by closing the device.
> No, but then BaudBandit.device doesn't have people going about
> claiming how wonderful its features are.
Well I *certainly* wasn't claiming that the serial.device features were
"wonderful," as you say. Again, I merely stated the fact that
BaudBandit.device achieved its increase in speed by leaving out some
features that serial.device has. Then everyone starts telling me that
those missing features aren't needed. I took that as being a rather
silly assertion, since some segment of the user population needs those
features. I don't think you or I can make any good estimate of that
population's size.
> It's not the quantity of the examples, it's the quality. Hands up
> everyone whose only comms is BBSing. Hands up everyone who has
> more than 50% of the comms time spent BBSing. Around people I
> know, virtually everyone would have raised their hand.
I didn't raise my hand for either question, honest, although I'm only
one person. You and I obviously know different sorts of people because
in my circles, I'm not the only one who would have had my hand down.
This just makes the point that the world is a big place, and we (you and
me) can't make the assumption that our experience is "typical."
> It turns out VLT supports the Unix box simply by stripping the
> 8th bit, and not relying on the serial.device to do the job. So
> one doesn't even need 7E1 for that...
That's true. There are other systems which *check* parity, and they
wouldn't work with that solution. I think parity is silly, and
apparently you do too. Unfortuatly, some people in the world forgot to
ask either of us if they should be using it. ;-)
> Frankly no, I don't think this is the case. Writing a fast
> general purpose piece of code is just a matter of writing more
> specialized chunks, which would increase the size of the thing
> but not slow it down.
In the case of the serial.device, things like parity, break detection,
overrun detection, XON/XOFF, etc. are all in the critical path. They
don't just add to the size of the code, they add to the number of
instructions which *must* be executed for every character received.
That slows it down. You can't just take your "specialized chunk" out
without a conditional test, and that's part of what slows it down.
The only solution for the serial.device would be to have separate
interrupt routines for every possible combination of desired "features,"
or to have a separate driver altogether (hence BaudBandit.device.) C=
at partially addressed the problem with RADBOOGIE, but that of course
adds another conditional in the critical path....
>*** John Bickers, TAP. jbic...@templar.actrix.gen.nz ***
-hans
Michael B. Smith
> In the case of the serial.device, things like parity, break detection,
> overrun detection, XON/XOFF, etc. are all in the critical path. They
> don't just add to the size of the code, they add to the number of
> instructions which *must* be executed for every character received.
> That slows it down. You can't just take your "specialized chunk" out
> without a conditional test, and that's part of what slows it down.
>
> The only solution for the serial.device would be to have separate
> interrupt routines for every possible combination of desired "features,"
> or to have a separate driver altogether (hence BaudBandit.device.) C=
> at partially addressed the problem with RADBOOGIE, but that of course
> adds another conditional in the critical path....
NO!
That's what function pointers are for. You create specialize procedures to
address individual and combinatorial features and just call the appropriate
function. The ONLY routine that needs special code for that is OpenDevice()
and who cares if it is slow?
--
// Michael B. Smith
\X/ m...@adastra.cvl.va.us -or- uunet.uu.net!virginia.edu!adastra!mbs
Tony Poole
>So far you've shown two examples. BBSing and "a stupid Unix box." And
>the results are 50/50 for your 8N1 claim. What else comes under your
>heading of "most comms people do?" *I* think it's fair to say that not
>all the world is a BBS. Some people *must* use XON/XOFF, parity, etc.,
>no matter what you think of it. It's not a matter of choice.
That's right. An awful lot of people who connect to hosts in Michigan via a
statewide network known as "MichNet" fall into this group, myself included.
MichNet dialins are not wired for hardwire handshaking, we must use
XON/XOFF. Anyone that thinks nobody uses software flow control is not too
informed.
--
----------------------------------------------------------------------------
Tony Poole to...@umcc.ais.org * to...@irie.ais.org
Traverse City, MI USA to...@cherry1.trv.mi.us * to...@cherry1.UUCP
Adrian Tritschler
1) Is the crashing that people report due to baudbandit.device or due to
comms programs requesting a setting that is unavailable, then not
checking return codes?
2) Has anyone used baudbandit.device with AmigaNOS and got any hard numbers
as too performance improvement/degradation?
Adrian (soon to be connecting amiga to slip network)
--
// Adrian Tritschler // ajft@ajft_sun.cs.adfa.oz.au //
||\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\|| (06) 268 8166/\/\/\/\/\/\/\/\/\/\||
|| UAE: Uncontrollable African Elephants || Comp Sci Dept, ADFA ||
\\ Chewing Segments, run for cover \\ Canberra, ACT, Australia \\
ANTHONY FRANCIS PRESTON
messages on the console for any serial port errors. BaudBandit.device
does not give control back to Citadel. Citadel 68K is rather large
as a debug image so it is rather difficult to run a debug session
and attempt to track exactly where it is hanging. I do know that
Citadel opens the serial.device three times, once each for read, write,
and status. It issues read and write requests asyncronously and does
status(like change the baud rate) commands. It also does queries on
the serial port. Any Error returned gives a message like:
IO ERROR [nn]
Where nn is the error code returned. BaudBandit.device never causes
Citadel to give this, it just locks up.
Malcolm Caldwell
The only solution for the serial.device would be to have separate
interrupt routines for every possible combination of desired "features,"
or to have a separate driver altogether (hence BaudBandit.device.) C=
You could have a serial.device that 'compiled' a serial.device with your
desired features. :-)
(You also might be able to use multiple entry points to skip stuff that was not
needed in the go-fast no feature case)
at partially addressed the problem with RADBOOGIE, but that of course
adds another conditional in the critical path....
What is RADBOOGIE?
--
Malcolm Caldwell Email: mal...@pandanus.ntu.edu.au
Technical Officer Ph: +61 89 466546
Computer Science Fax: +61 89 270612
Northern Territory University, Darwin Australia
jerry cullingford
>2) Has anyone used baudbandit.device with AmigaNOS and got any hard numbers
> as too performance improvement/degradation?
Well, I tried it and it didn't work at all :-( with amiganos, although it
worked fine with my terminal program.. But it _might_ just be the mixed case
device name problem.
--
+------------------------------------------------------------------+ |
| Jerry Cullingford #include <std.disclaimer> +44 442 230000 x3868| ,-|--
| j...@crosfield.co.uk (j...@cel.uucp) or j...@selune.demon.co.uk | \_|__
+-----(Work)---------------------------------(home)----------------+ \___/
Hans Ridder
>What is RADBOOGIE?
It's a serial.device parameter which is supposed to make the character
processing faster. It's documented in the RKM:Devices.
>Malcolm Caldwell Email: mal...@pandanus.ntu.edu.au
-hans
--
Hans-Gabriel Ridder <rid...@rust.zso.dec.com>
DECwest Engineering, Bellevue, Washington, USA
"I'd rather be writing MACRO-20!"