drew@cgofs.dec.com (STEVE DREW 16-Nov-1989 1318) (11/17/89)
-> 2) A pointer to some source in C (manx preferably), that details
-> how to implement the XPR library thing.
->
-> 3) Ideas on what the best route would be in creating an aux: type
-> device with the following things in mind:
->
-> i. Ability to give it decent con: or newcon: compatability
-> ii. Not have it crash when someone calls over the modem to
-> a program running through the aux: device.
-> iii. And especialy have it adjust to any baud that calls.
->
-> Any information on anything here, or related to it (especialy 3.iii !!),
-> please email me.
->
-> I have one aux: type device from a fred fish disk, but while it's better
-> in several ways over the 1.3 aux device (haven't tried with 1.3.2's new
-> serial device). First, it doesn't crash ought-right, but I haven't had
-> any luck in managing to compile the code that came with it to accomodate
-> my needs.
->
Funny you should mention this. I wrote that aux: handler you
mentioned (way back...). It should compile just fine with manx 3.6a.
Lately, I have made a few improvements with it and fixed a couple of bugs.
I also wrote a utility "AZ" that uses the XPRZmodem.library to
allow Zmodem transfers while dailed up through AUX: It works
quite well. I just made the "AZ" utility send AUX: a dos packet
to tell it to sleep while "AZ" shares the serial port.
The only thing I'm strugling over, is that about 1 out of 5 times
while SZ'ding to the amiga the file transfer aborts at the 16K point,
which is when the Amiga writes to disk. It gets a CRC error on the
17K packet that was received while writing to disk. It never happens to RAM:.
And I've even set the serial buffer size upto 4k.
Anybody got any ideas on this one?
Also what would also be usefull when dailed up to the amiga, if the
machine should happen to guru, then to be able to bypass the "RED GURU BOX"
and continue with the reboot, it's easy to disable system requesters but
how does one disable the GURU BOX to forced the machine to reboot?
/Steve
----------------------------------------------------------------------------
Steve Drew at ARPA: drew%cgofs.dec.com@decwrl.dec.com
USENET: {decvax!decwrl}!cgofs.dec.com!drew
---------------------------------------------------------------------------papa@pollux.usc.edu (Marco Papa) (11/17/89)
In article <8911162131.AA06419@decwrl.dec.com> drew@cgofs.dec.com (STEVE DREW 16-Nov-1989 1318) writes: |I also wrote a utility "AZ" that uses the XPRZmodem.library to |allow Zmodem transfers while dailed up through AUX: It works |quite well. I just made the "AZ" utility send AUX: a dos packet |to tell it to sleep while "AZ" shares the serial port. | |The only thing I'm strugling over, is that about 1 out of 5 times |while SZ'ding to the amiga the file transfer aborts at the 16K point, |which is when the Amiga writes to disk. It gets a CRC error on the |17K packet that was received while writing to disk. It never happens to RAM:. |And I've even set the serial buffer size upto 4k. |Anybody got any ideas on this one? You can try to do the things that I do in A-Talk III: 1. Buffer 16K of data and write it all in one chunk out to disk, using the buffered fwrite routine (but you probably do that already). 2. Use an 8K serial input buffer 3. Set up the serial port with RAD_BOOGIE You don't say at what speed you have the problems, but the CRC error is due to the serial input getting an "overrun" error. That results in at least one byte lost, which then produces the CRC error. No. 3 above is definitely required at >= 9,600 bps. I hope this helps. -- Marco Papa 'Doc' -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= uucp:...!pollux!papa BIX:papa ARPAnet:pollux!papa@oberon.usc.edu "There's Alpha, Beta, Gamma, Diga and Caligari!" -- Rick Unland -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
wally@pallas.UUCP (Wally Hartshorn) (11/19/89)
You mentioned that your program sometimes hiccups when it gets to the 16K mark and writes out the data. What I'd like to see is a program that has TWO input buffers. When the one gets full, it then switches to the second one while the first is being written to disk. Presumably this would reduce or eliminate any slowdown caused by writing out the buffer. Wally (uunet!pallas!wally or wally@athenanet.com)