Synchronet v3.19b-Win32 (install) has been released (Jan-2022).

You can donate to the Synchronet project using PayPal.

This is an old revision of the document!


Discussions of Synchronet Development (1991)

Steve Deppe archived his emails (to 5.25“ floppy disks!) back in 1991 and he saved the following exchanges with Rob discussing some of the earliest development of “The BBS” (which you can see here had been assigned the name “synchro_net” by April of 1991). These message exchanges took place on Vertrauen which was still running WWIV v4 BBS software at that time.

27/27: It backspaces...it wraps...it scrolls...it rings...
Name: Ille Homine Albe #4 @2
Date: Tue Mar 12 20:42:30 1991

    New from rAdWaReZ... putlc(int)!  And if you act now, we'll throw in a
link map and a batch utility!  Free!  (.exe not included)
 
    It always returns zero.  It could return something, like the current video
mode(?)  The argument (16-bit int) can be:
 
        1) 0000-00FFh     Output character
        2) 01xx-FExxh     Set Current Attribute
        3) FFC0-FFFFh     Set Screen Length (Initialize)
 
    1) Outputs all characters except 7, 8, 10, and 13, which perform their
assigned functions.
    2) Any attribute combination can be set except 00 (black/black) and FF
(white/white, high, blinking).  If the low byte is zero, no other action is
taken; if non-zero, it is output as a character.
    3) The screen length is the number of lines minus one, negative, so the
minumum number of lines is two (-1, FFFFh).  A regular 25-line screen would
be set with "putlc(-24);"
    The best idea is to initialize it before you use it, that way it gets the
current cursor position, display page, and screen width from the BIOS.  Else,
you end up with set defaults.
-----------------------------------------------------------------------------
(1/2): RE:putlc
Name: Digital Man #1 @2
Date: Wed Mar 13 00:09:12 1991

Thanks.. It's late (just got home from band practice) and I must sleep now. I 
will certainly check it out tommorow. Thanks again.

(2/2): Putlc...
Name: Digital Man #1 @2
Date: Wed Mar 13 00:37:11 1991

I take that back.. I decided it was no big deal to replace the putch calls 
with putlc (assuming they worked the same) and tried it out.... Well, it 
didn't exactly work. Have you tried it? I just added putlc.obj to the end of 
the bbs.prj file... it linked it in and all... strange... It's pretty fucked 
up - none of the extended ascii chars or and color came out and the cursor 
position was quite odd. Have you tried it in the bbs yet?... well, I've got to 
hit the hay. I'm sure you'll figure it out. See ya! - Oh, and you need to 
knock off that attitude of yours in Gwar...
-----------------------------------------------------------------------------
Yow...
    It works...  I'll upload my copy with the executable so you can try it out
there.  I've added some routines to smooth out the interface.  The .obj file
now contains:

        int putlch(int);       display local char, or change current attr.
        void lclini(int);      initialize, set main window size
        void lclxy(int,int);   set cursor position
        int lclwx(void);       get current column number
        int lclwy(void);       get current line number

    How did you include putlc.obj in the linkage?  I didn't fool with it much
before I decided to just merge it into the standard CL.LIB file.  Then they
all act like standard C routines.
    Seems like some displays are output faster than others, and I noticed
you're using cprintf() a lot.  I think the file listings in the transfer
section scroll faster than posts.  Maybe it's just the line length.
    Control characters increment the column count, there should be a way to
avoid that.  When I used colors in posts or mail, I couldn't get to the end
of the line before it wrapped...

To   : Digital Man #1
Title: P.S.
Name: Ille Homine Albe #4 @2
Date: Wed Mar 13 18:22:15 1991

    Just an after-note: the copy of the bbs source I was working on was the 
March 10 version.  I included the source for reference, so you could see what 
I did, but it's not neat, since it has to be re-done anyway.  Look at the 
interface (it has to be made more efficient) and let me know how you would 
prefer it to work.
    I'll be "out" tonight, but leaf me some mail or a doughnut or something.
-----------------------------------------------------------------------------
(4/4): New stuff
Name: Digital Man #1 @2
Date: Tue Mar 19 01:54:38 1991

Umm... the logs are fully implemented now....
The version you have now has a major new user bug that I fixed.
System data (statistics) is now tracked in the system.dab file 
(auto-created)... but the daily reset isn't written yet.
New ultra cool commands: "//STATS" lists the system statistics...
'"' from the main or xfer menu allows the user to enter a command string that 
will execute.... ^=Ctrl... example: "t2l^m  will go to the xfer section and 
list all the files in dir #2... it's not really any faster but it's neat.

Linefeeds are now ignored.. finally... on input, so macros are killer.
-----------------------------------------------------------------------------
(1/1): Hey you!
Name: Digital Man #1 @2
Date: Thu Mar 21 02:40:40 1991

There weren't very many changes... real easy!

Works GREAT! Real fast.... Thanks a BUNCH!  Say, did you know that I had a 
macro for ^L (12).. it's FF... oh well.. I guess there's no need for the cls() 
function. A outchar(FF) would do just fine... 'cept if I wanted to do a screen 
of X's.. hm.. I foget, but I think I don't convert anything less than a space 
to X.. I foget.. well, anyways, it's late (2am) - I'm stoked. I'm probably not 
going to make any changes now till friday. I have to set up my drums tommorow 
night at the BR. Agenda: F2=Full screen system/user statistics, Find text in 
file descriptions, Flags saved as hex in user.dat and more...

Bye.                                                   digital man

To   : Digital Man #1
Title: Duh gee Tennessee...
Name: Ille Homine Albe #4 @2
Date: Thu Mar 21 02:58:34 1991

RE: Hey you!

    Did you put the changes from the one I uploaded into the one you had 
already? or did you put the changes from the one you had into the one I 
uploaded?...because the changes I made were splattered all over...
    Yeah, I saw the FF, but I'd changed clrscr()'s earlier.  I think there may 
be one or two putlch(FF)'s.  Was it putchar(FF)?  Hmm...
    Let me know if any bugs happen.  I doubt there'll be any, though.  If you 
looked at that LIOTST routine, I think I tested them in more ways than you're 
currently using.  Oh, I forgot to mention lclatr() returns the previous 
attribute that was set before it sets the new one.
    Bi bi bi bi bi....
-----------------------------------------------------------------------------
(1/1): Hey dude
Name: Digital Man #1 @2
Date: Wed Mar 27 01:27:04 1991

I figured out the transfer section idea.... Libraries.

When you enter the transfer section you will end up in your default library
and '*' will list the directories in that library, /* will change the current
library.

What do you think about the scans? Should they search all libs by default, or
should there be a '/N' & '/S' command? I was considering calling them volumes,
but I'm pretty sure I like libraries better.

Now, quite a few bbs programs have conferences, or SIGs (special interest 
groups)... basically the same ideas the libraries/directories idea in the 
transfer section, but in the message section. You have your main message bases
(SIGs) and then you have sub boards off of those... Vertrauen might have, 
Public, Pirate, Netted and Elite or something... I don't know.. it's only 
really handy if you have a million subs, but some boards do! The have like 10 
or so subs per SIG and they have SIGs for old people, programmers, techies,
trekkies and preppies!

I haven't had very much time to work on the source code.. I'm making a lot of
changes at once. It's kinda scarry. I wanted to know what you thought of the
bi-level message base idea though, before I implemented it. It really wouldn't
be much of an advantage for Vertrauen, but quite a few PD board out there
would use it....
-----------------------------------------------------------------------------
(3/3): Oh man...
Name: Digital Man #1 @2
Date: Thu Apr 04 01:20:07 1991

mega changes...

Things to check out:
//RAW (main menu)
^R (anywhere -r0dent input)
^O (anywhere -r0dent output)
The defaults section... (crazy cursor)
The terminal (from the WFC)
the 'V' command in Uedit
or ALT-S (toggle crazy cursor)
ummm......
lot's of little bug fixes...
Caller log ('L' command and when you log on)
Auto-Message
Sysop is ? stuff
-----------------------------------------------------------------------------
Two new options: 1) lf is output as cr/lf
                 2) tabs are expanded at 8-column boundaries

The argument to lclini(int) is treated as two bytes.  The high byte, if
non-zero, sets or resets the two translation options.  If the low byte is
zero, the screen is set to the number of lines the BIOS thinks it is.  The
function now returns the number of lines set, so you can find out.

E.g.,     lclini(1<<8); /* no lf translation, tab expansion off */
          lclini(3<<8); /* lf output as cr/lf, tab expansion off */
          lclini(5<<8); /* no lf translation, tab expansion on */
          lclini(7<<8); /* lf output as cr/lf, tab expansion on */

          i=lclini(7<<8);   /* translation on */
          ...
          lclini(1<<8+i-2); /* set to 23, 41, or 48 lines, translation off */

The object assembles to work with any memory model.  Use masm /Dmm=x where x
if the character s, m, c, l, or h.  Regarding the next production, there's a
bit of a problem calling any C routines in the bbs from an interrupt routine,
which is I don't know how to set up the segment registers.  I think I'll have
to read and write the com port directly.  And now, a poem:

          Do you have MASM,
          Or do you not?
          You told me once,
          But I forgot.
-----------------------------------------------------------------------------
(2/3): Hey mon...
Name: Digital Man #1 @2
Date: Wed Apr 10 01:18:16 1991

-ey, mon... braid yo hair for a dolla. Got big buds in bock mon... come in fa 
some cajun chickun. Need a toxi, mon?

(wearing a red and green striped hat....)

Okay, well for what I was really mailing you for (assuming that this gets to 
you and not some lamer on the board.), I've been checking out Borland C++ very 
intensly at work recently (since they bought it all legal and everything, and 
I've been using it there), and it has some pretty killer features that I 
thought would benefit the development of 'the bbs'. For example: It comes 
witha protected mode version of both the command line and integrated versions 
of the compiler that use all your available extended (or expanded) memory for 
compiling, linking and swapping! I thought that was trick.. couldn't use the 
protected mode versions at work though, cause I only have a meg my machine 
there, and it need 705k extended minimum. The editor (programmers' platform - 
corny) is pretty trick with all the clipboard, editing and windowing features, 
and it's AWESOME project facilities... granted, I wasn't going to write the 
bbs in C++, but this is Borland's latest ANSI 'C compiler as well... it only 
tries to compile files as C++ that have a .CPP extension. So, I installed it 
here at home, freed up a meg of extended and ran it... it complained about me 
not type casting my malloc statements, but other than that compiled just fine 
(afer I created the new project file format). Then I exited and looked at the 
.EXE file.. Remeber how I told you that the program at work compiled to 
500bytes smaller as a .C file, than as a .CPP file? Well I think it would have 
been even smaller as a Turbo C v2.0 file... The BBS.EXE was 31k bigger! That's 
%15 man! What slop! The only thing I can think that would explain this is that 
they're 'supposedly' using new HUGE arithmatic or something, so use of HUGE 
pointers is much faster now... Ha... I think I'll stick with the 'slow' HUGE 
pointers and keep my %15 of memory. Bummer though.. it was nice having 900k 
free to compile with!

(3/3): still more 'c shit....
Name: Digital Man #1 @2
Date: Wed Apr 10 01:36:59 1991

Well, after learing about how quickly the stack grows in 'C, I decided to 
check out the bbs code with this in mind... hm... much optimization needed. I 
had several functions the xfer section that were similar and some functions 
were unnecessary deep (functions calling functions calling functions etc.) and 
I could just see the stack growing in my minds retina (and what big eyes you 
have, grandma!). First, I decided to make two functions out of eight. (I put 
the functionality of newscan() and dirhdr() into listfiles with an option to 
not print the directory header - for future use. I put the functionality of 
download(), editfiledat(), multifileinfo(), removefiledat() and movefiledat() 
->new function into listfileinfo(). The brought the .EXE down 6k! (under 200k 
again!) and eliminated about 6K of source code! (Ha raw!) - and this is just 
the beginning! I figured I had better start cleaning up before I'm too far 
along  and lose sight of simplicity (like our good friend, Wayne). 

What do you think about writing the COM routines in ASM? You could define the 
global data there.. (the buffer pointers have to accesable from the 'c 
functions, or write an ASM routine to set the pointers to NULL - that's all I 
ever do with them -pointers, meaning Head and Tail pointers (combufbot and 
combuftop). Then you wouldn't have much trouble with the interrupt routine 
(since you'd write it).. I don't think it'd be that hard. Maybe I should wait 
till you've done the DOS interrupt routine(s) before I suggest anything 
else... Anything you do to help is greatly appreciated. Let me know if I'm 
asking too much of you (but programming is fun, Steve!).

Well, back to the source.. I'm going to see how much I can chop away at this 
thing before I start adding more functionality.

Se3 y4 l4t3r m0n.
-----------------------------------------------------------------------------
(1/3): Com routines
Name: Digital Man #1 @2
Date: Sun Apr 14 17:35:56 1991

Perhaps, we should have a Sysop Defined Output buffer...

There is a mod out for WWIV to have an output buffer (NEWCOM.ZIP in the PD Comm
directory). I figure you can have the size of the buffer specified in the 
node.cfg file. What do you think?

The most important thing is that 'SPACE' (or Ctrl-C or Ctrl-X) clears the 
output buffer. Otherwise the remote user would have no pausing or aborting 
power... yeah, Pause wouldn't really work right either unless you halted the 
output buffer immediately. Hmm... just a thought.

I took some time and looked at a few bbs oriented things in the file section 
today. I looked at Remote Access BBS (written by a group of guys in Australia).
I didn't run the actual bbs, but the configuration program was pretty hot. It 
had a shitload of Sysop defined parameters.. (including the size of the 
outgoing buffer!).  I looked Zedit (a full-screen editor that does it's own com
i/o). Not bad, but I'm not sure that it's all that useful. My biggest gripe is 
that all the full-screen editors clear the screen before you start the message.
I often like to look at the message I'm replying to as I type mine. I'd like to
have a full-screen editor available on the bbs... hmm... maybe I'll just make 
the local editor always ED (or whatever you specify in node.cfg)... just need 
to create the file with the header info before I invoke the editor and hope 
that the sysop (or whoever's local) doesn't mess it up.

Back to Remote Access: It's  mainly intended for those sysops running Desqview 
(or topview or double dos or whatever). I thought - What an idea! I can add a 
node without the expense of another machine. Just run desqview and add a 
modem... (once I'm up with the new software). But I guess you need an output 
or you get degredated performance. That's why that one guy wrote the NewCom mod
for WWIV - for multi-tasking sysops. You should take a look at his mod... I'm 
not sure that the pause would work correctly... maybe it would... hmm....

Well, anyways, I have anonymous message support now in the new bbs!
-----------------------------------------------------------------------------
Yeah...
    The farther I went through that application the dumber it got, which was
quite an achievement considering how it started...!  So it is WWIV?  That's
pretty sad.  I should create an application for them with questions like,
"explain why I should even LOOK at your juvenile distortion of WWIV..."
    If you're thinking of multitasking, an output buffer is a good idea.  It
doesn't have to be big, even 100 or 200 bytes would do.  I don't see any plus
in making it dynamic, though, unless there's a maximum (like 512 bytes).  If
it's totally dynamic, that's a DOS call to allocate the memory, and then if
you ever want to do something like shrink the bbs, you have to fool with it.
See what I'm sayin'?
    Yes, indeed, i/o buffers are always flushed on an interrupt (abort/break).
Your second letter ended in mid-line (mail pointer confusion?), while you were
talking about protecting the bbs source:

"...some way or another... Perhaps, I could just give .OBJs Mail {?} :"

    Was there more?/

(1/1): Yes,
Name: Digital Man #1 @2
Date: Mon Apr 15 11:53:00 1991

RE: Yeah...

There was much more, but fucking WWIV.... you know...

Yeah, I've been talking with mike a lot lately about how to protect the bbs 
from r0dentialism and possibly making a little money (?). I like I should give 
out the executable as shareware (if you use it, you're 'supposed' to pay for 
it) and if someone wants the source (and most WWIV sysops would), they'd have 
to send me a check and then I would send them all the source except for say, 
MAIN.C and LCLOLL.ASM... in MAIN.C would be an encrypted registration number 
that appeared at the NN: prompt or something (the logon code is in MAIN.C) and 
like do a checksum on one section of the .exe to make sure it hasn't been 
tampered with (the beginning, made up of MAIN.OBJ and LCLOLL.OBJ). Is that 
possible (to checksum just part of an .EXE). If you always linked it in the 
same order and used the same OBJs, wouldn't the first part of the EXE always be
the same? Well, anyways... that just to keep it somewhat copy-protected. Some 
people don't give out source code at all. But I don't think I'd get any money 
if I did that. That's what most sysops like about WWIV - being about to make it
'unique'. Wayne bell only sold the source to the BBS, not to his INIT.EXE which
is necessary for initializing the bbs (creating all the data files and menus 
and stuff) and for changing system parameters later (modem shit, sec levels 
etc.) You can't go too far with WWIV without the source to INIT. This was to 
keep most r0dents from tinkering with his code and calling it their own. I 
wouldn't want what's happened to WWIV (Carnage, Telegard, Hack, etc.) to happen
to synchro_net. EVERYBODY's got the source code too. It's 'supposed' to be 
$50.. I think the non-removable registration number would be cool. Of course 
I'd need your help in making it as non-crackable as possible, Mr. CrackMaster!
-----------------------------------------------------------------------------
To   : Digital Man #1
Title: Hey Mnan!
Name: Ille Homine Albe #4 @2
Date: Sun Apr 28 03:22:26 1991

    Fuck int 21h/40h!  See what I'm sayin'?  Think about what happens if you
redirect a program's output: it goes to the file AND over the com port.  I was
trying to figure out how to check to see if the handle was redirected, and it
was totally gay.  Completely flaming dancing and singing, tossing flowers in
the air, all pink and pastel, and the process would have to be done for each
character.  Too special.
    But then I got a terrific inspiration: INT 29h!  It's only used to output
a single character to the console, and every character that dos puts to the
console goes through it!  So it gets characters as a result of int 21h/40h,
but not if output is re-directed.
    It works with my ansi driver (the one with the special VGA crazy-border
feature), it works with NO ansi driver, but of course I don't know whether it
works with the standard dos ansi driver.  And I can't download it to see, Rob,
I just can't!1  Can you check it for me, please?  Huh, Rob, please?  Run pc-
watch, include int 29h, and see if characters you type at the prompt make it
go... Or if you have that device-driver listing program I wrote, run that and
see if the attr word for CON is 8013h.  k?
    You know what else?  Instead of intercepting int 16h/0,1,10h,11h, it would
be way easier, faster, and cleaner to use int 16h/5 (push char/scan code).  It
sucks that it's an AT-only function.
------------------------------------------------------------------------------
    "The Way," I think, to handle pausing is to do the checking just as you're
doing it now, to pick up the local pause, and for the com i/o routines to do
it also, to pick up the remote pause.
    So if you hit ^s locally, the bbs stops, but the user screen may continue
to scroll, until it catches up to the remote screen, and then the two will
look the same.
    If the user hits ^s, his display stops instantly.  The local display is at
this point ALREADY ahead, and will probably display the remainder of the
current line before it detects the output is paused.  In any case, if you
check for a remote pause before putting up the prompt, you'll always know if
the user is pausing, since the prompt won't come up until he releases it.
    In other news... how does our good buddy Wayn3 abort pkzip?  If you hit
space-bar during a "V" command, does he actually interrupt the program?  Or
does he just throw the rest of the output away?
------------------------------------------------------------------------------
(1/1): externals
Name: Digital Man #1 @2
Date: Mon May 06 23:13:20 1991

Yeah, the pause setup you mentioned is the way to go... (check local in inkey, 
and have incom do it's stuff setting a flag.... right?)

As for hitting 'space' while listing a zip, I guess that's one of his external 
modes, cause you can't have food fight abort if you hit space... I'm not sure 
about that one. It does abort if you hit space or ctrl-c or ctrl-x. Can you 
just make a mode that will abort on space?
                                                   digital man
------------------------------------------------------------------------------
[input] any character should clear field.
Inactive users?
Clearing Note doesn't put user through test.
------------------------------------------------------------------------------
(1/1): Dude
Name: Digital Man #1 @2
Date: Wed Jun 05 00:24:46 1991

I waited till midnite for your call. I called and it was busy. Sorry, but I 
got to hit the hay or I don't get up in the morning (I'm kinda tired too.)

I certainly didn't see anything obvious. I recompiled RTST and ran it. I 
didn't figure out the ascii values. We'll have to do this another time I 
guess... 

I'm tired. Good night and good luck!
                                                   digital man
------------------------------------------------------------------------------
To   : Digital Man #1
Title: Hey mnan!@*8
Name: Ille Homine Albe #4 @2
Date: Wed Jun 05 13:35:13 1991

    You probably think this is Telix I'm using, don't you?  WRONG!$@#@2  
It's...

     RTST.EXE!@!@$^#$*&^*$#  The hottest new term program from rAdWaErZ!

    It doesn't seem like the same bbs without a status line, and with the 
strange hex information the interrupt routine keeps writing at line 6...  
Well, let's see... Telix costs $45, I should be able to get... um... about 
$1.50 for this gadget, don't you think?  Or maybe someone will write a bbs and 
incorporate these nifty asm routines... you just never know...
------------------------------------------------------------------------------
ERROREM DETEGI!
    "I have uncovered the error."  As in "errorem detegere," "to uncover the
error," as opposed to "errorem detegisses," "you might have uncovered the
error," or "errorem ante Veneris diem detegerimus," "we will have uncovered
the error by Friday..."

    I had to change a "jz" to a "jnz" to make it work.

    Actually, it's by luck it worked at all.  It was intercepting the vector
for int 08 instead of int 0C, so it was actually running off the clock tick
interrupt.  When I realized that, I looked at my prompt, and it said 10:10,
then at my clock-radio... and it said 10:21!  But at least I know how much
time I spent running the test program.
    This is the sort of thing I would have caught if I'd gone through my usual
anal-retentive method of following the program flow in a listing before trying
to run it.  But I thought, what the hell, just takes a second, and it might
work!  Damned clock.  If it had locked up, like it should have, I would have
hit the listing right away, et errorem detegerim!
    No really... Virtus in segnitia est!  (Romans!)
------------------------------------------------------------------------------
To   : Digital Man #1
Title: yo...
Name: Ille Homine Albe #4 @2
Date: Wed Jun 05 13:39:28 1991

    You know what sucks: my tiny c program is so fast, the receive buffer only 
ever has 1 or 2 characters in it at a time... bumm3r...

    Alright, now I'm ready for the BIG test... I'm going to DROP DTR!!
    If it works, I won't be able to tell you, so if it doesn't work, I'll 
E-mail you again with the sad news.

here we go...
------------------------------------------------------------------------------
To   : Digital Man #1
Title: 0k.
Name: Ille Homine Albe #4 @2
Date: Wed Jun 05 16:44:21 1991

    There's a file in #27 for you to try out.  Meanwhile I have to compare the 
test source file I've been "folling" with against the original and see what 
needs to be changed, and get on with the rioifc() stuff.  I'll be out on a hot 
date tonight, but leave a doughnut if you find any bugs.

To   : Digital Man #1
Title: Duh...
Name: Ille Homine Albe #4 @2
Date: Wed Jun 05 18:18:04 1991

    Almost forgot... that one I uploaded contains debug routines that will die 
on anything but a 386.  I just uploaded RIOTXT.ZIP which contains a .OBJ with 
those routines removed, in case you should want to try running the bbs on the 
xt.
    I hope I don't think of anything else... (meaning that there isn't 
anything else to be thought of...)
------------------------------------------------------------------------------
33/34: Yep
Name: Ille Homine Albe #4 @2
Date: Fri Jun 14 06:36:16 1991

    Your USR manual says about five thousand times that if the uart rate is
faster than the line rate, HARDWARE FLOW CONTROL IS REQUIRED.
    This is another way of saying that the modem will suck characters faster
than it can handle them.  And if you think about it, why else would there be
a need for hardware flow control at all?  It could just stop taking characters
if the buffer got full and there would be no problem.  Sloppy firmware, man.
    I found a sequence of about seven instructions in outcom(), after it
checks to see if it can put the character directly to the uart, and before
it actually puts the character in the buffer, during which a transmit inter-
rupt could cause the pausing problem.  The interrupt routine would see no
characters in the buffer, so it would exit with no interrupt pending, and
then outcom would finish putting the character in the buffer, and nothing
would happen until some other event (like receive data available) caused an
interrupt.  This is all highly theoretical, of course, but I've fixed it, so
if that was the problem it should work alright now.

34/34: Other News
Name: Ille Homine Albe #4 @2
Date: Fri Jun 14 06:36:30 1991

    I noticed that the original list of C defines show CTSCK as being 0x800,
but it should be 0x1000.  Did we cover this on the phone at one point?  If
you are using 0x800, it should have no effect.  There may have been a hole
in the isr due to the order in which it was doing the checking for this and
other conditions on which to exit, but I straightened them out also.
    dtr() now waits 165-220ms if you call it with a number >1 and DCD is off
when DTR is put low.  If DCD is on and the arg >1, it only waits until DCD
goes away (which would mean the modem saw DTR, in which case there's no need
for any extra delay).  rioini(0,0) now preserves the state of DTR.
------------------------------------------------------------------------------
Name: Digital Man #1 @2
Date: Fri Jun 14 19:13:14 1991

RE: Other News

or however you spell that thing...

that's great man... Yes, I had CTSCK still at 0x800. It did something, though.
It made the com i/o not work. I'll change that to 0x1000 and re-link with the
new OBJ.

Yes, I remember now that the manual says that the modem has to have hardware
flow control if the DTE to DCE rate is faster than the connect rate, but I
forgot this fact when you asked: "Rob. Hardware flow control. Why?"

And I remit my statement about running telix with the modem set the same way
and working fine.. I never disabled hardware handshaking and tried telix or
WWIV. Should have. Sorry. (are you mad?)

BTW, I'm going to Seattle a week from Sunday. Those CDC guys are just gonna
love my hair! I gotta wear a tie and be a respectable representative for Mini
Control. It'll be fun. But the next week is a crash course in IEEE-488.
------------------------------------------------------------------------------
To   : Digital Man #1
Title: d00d
Name: Ille Homine Albe #4 @2
Date: Sat Jun 15 09:14:06 1991

    Everything works by golly.  Uedit stops and gives a prompt if you hit ^C, 
but if you hit ^C at the prompt, it redisplays the screen.  The only thing 
that's slightly hairball is if you hit ^C while the prompt is displaying, and 
then it just leaves you at a partial prompt...
    Ga-roo-vy, as we used to say back in the 1970's, when Nixon was President.
Did I ever tell you about the time, back then, when I wrote a prom that 
controlled six 5-meg drives with a 2MHz 6502?  Using interrupts, of course...
------------------------------------------------------------------------------
(1/1): newest rio
Name: Digital Man #1 @2
Date: Tue Jun 18 02:36:16 1991

works better.. the HST was having problems answering the phone before (getting 
too many RINGs (2's) and was interpreting them as result codes... but now, 
that hasn't happend once with the newer routines... might be coincidence.

no abort mode?

rioctl(IOCM|ABORT);
doesn't cancel the abort mode anymore...

other than that, don't see anything wrong with the newest.

To   : Digital Man #1
Title: ?
Name: Ille Homine Albe #4 @2
Date: Tue Jun 18 08:03:03 1991

    rioctl(IOCM|ABORT) doesn't turn off ctrl-c checking?  That I don't get.
The smoother communication with the modem might be a result of what I did, so 
I'll take credit for that.  But if it's a bug, it must be Microsoft.
------------------------------------------------------------------------------
To   : Digital Man #1
Title: Hey...
Name: Ille Homine Albe #4 @2
Date: Sat Jun 22 06:04:07 1991

    I can't run the board with a direct connection!  With a null-modem cable, 
DCD comes on when you turn on DTR.  When I run the board, it puts up the logon 
screen without initializing the modem.  I can log on locally, though, but if I 
hit "/O" it immediately logs on again and the only way out is to re-boot!
    If I unplug the cable, then it hangs up, tries to initialize the modem, 
fails, and bails...
------------------------------------------------------------------------------

If you're wondering why Vertrauen was ”@2“ (its WWIV-style network address), it's because King Drafus's The Beast Domain was ”@1“ (of DOVE-Net).

See Also