====== Digital Man's Discussions w/Steve on Synchronet Development (1991) ====== Steve Deppe ([[person:Ille Homine Albe]]) archived his emails (to 5.25" floppy disks!) back in 1991 and he saved the following exchanges with Rob ([[person:Digital Man]]) discussing some of the earliest development of "the new BBS" (which you can see here had been given the name "synchro_net" by April of 1991). These message exchanges took place on [[bbs:Vertrauen]] which was still running WWIV v4 BBS software at that time. **Note:**\\ We talked a lot by telephone (POTS landlines!) in those days too, so there's significant parts of these conversations between Steve and I, not represented here. 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 [[person:King Drafus]]'s The Beast Domain was "@1" (of [[network:DOVE-Net]]) at that time. ===== See Also ===== * [[:history:|history index]] {{tag>wwiv development deppe}}