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).
