Publisher: Fido 1/1
Editor in Chief: Thom Henderson
Review Editor: Allen Miller
Chief Procrastinator Emeritus: Tom Jennings
Fidonews is published weekly by SEAboard, Fido 1/1. You are
encouraged to submit articles for publication in Fidonews.
Article submission standards are contained in the file
FIDONEWS.DOC, available from Fido 1/1.
Disclaimer or don't-blame-us:
The contents of the articles contained here are not our
responsibility, nor do we necessarily agree with them;
everything here is subject to debate. We publish EVERYTHING
received.
HAPPY NEW YEAR
Table of Contents
1. EDITORIAL
110 Baud and Teletypes
2. NEWS
FidoGram Ramblings
More Fido rewrite ideas
MEDNet - Medical FIDO Network
Sanyo Questions, Answers, & Comments
3. COLUMNS
Avoiding Snow on the Color Graphics Adapter
FIDO Sysop's Utilities
Rainbow Corner
4. NOTICES
The Interrupt Stack
Does anybody remember 110 baud? I just checked, so I know I
can set my serial port for it, but I don't think I've seen a
comm program that'll do it. Maybe I'll write my own, just
to see what it's like.
I remember when I first started with computers, we had four
teletypes connected to a mainframe computer three hundred
miles away. (You've heard of mainframes -- big things that
filled a whole room? They still make 'em.) It was two years
before I saw the machine I was using.
Those teletypes (ASR 33's they were) ran at 110 baud, or ten
characters a second, and made the most incredible noise;
especially when confined in a small cinder block room. You
think the fan on a PC is loud? You ain't heard nothin'!
When we REALLY wanted to make noise, we'd start up the paper
tape punch (which only one of them had). At the time, and
for a few years after, paper tape was really the only
standard method of moving files from machine to machine.
They made expensive high-speed paper tape readers, and the
first micros were usually booted from paper tape. We mainly
used it to make "dots" (the parts that were punched out to
make the holes), which were great for "snowing" someone's
room.
110 baud was the industry standard at that time. We could
take down three of the teletypes and hook up a Tektronix
terminal for graphics at 300 baud, but it was frowned upon
unless we had a really good reason. I was once told that
300 baud is like sex; once you've had it, it's hard to give
up. I feel that way now about 1200 baud.
Those teletypes had all of their guts in what would be
called the powerhead on an outboard motor. The mechanism
was all in the top. The stand was mainly empty space. When
I saw my first microcomputer (an Imsai 8080) I was
immediatly struck by two things: (1) it was hooked up to a
teletype, at 110 baud, and (2) the entire computer would fit
into the empty space inside the teletype stand.
You couldn't really have put it there, though. You needed
access to the front panel switches so you could toggle in a
bootstrap loader, which then loaded the system from the
paper tape reader on the teletype.
But do you want to know the most incredible part? This was
only about ten years ago.
????????????????????????????????
? ARE YOU SERIOUS ABOUT THIS ?
????????????????????????????????
By Rives Mc Ginley
Fido 105 Net 101
I guess you are not!
Heck of a way to start a discourse, to make a statement
that is so decisive. But history is a real teacher, and
this Sysop is a quick study, after a number of months.
We have been trying over the last few months to provide
you the Sysop of Fidos across the country, with a free
communications service. You've read about it, FIDOGRAMS.
At our expense, we have been responding to requests
from around the country, and even Europe, to send along the
files that explain the system. We have had a fabulous
response. Actual numbers of Fidograms are being counted
right now. At Christmas time as you'd expect, the system is
humming with cheery messages.
We love doing this. We are Amateur Radio operators who
have been looking for years to be able to interface Computer
users and Amateur Radio. At the moment, we are angered by
some Fido's who have requested this material. We believe
some of you are not serious about this whole FIDO thing.
We have experienced a great number of Fidos perhaps ten
out of 35 requests, who are not prepared to receive our
messages and files when we send them during the national
mail time. Either there is no connection, or we connect and
the system is not on line, or we connect and the FidoNet
programming is not running.
It may seem unimportant, but your wrong. Here's an
example: an attempt to send a message and file from Cape
Cod to Texas was made eight days in a row. Fido, as he is
supposed, tried each night, thirty times, to dial and
connect. Fido reported each morning, with a gasp, "No
Connection". Had there been a connection, the message and
file would have been transfered as expected , or Fido would
have given up after two connections (both of the later would
have cost 22 cents each, and no message delivered).
Eight times thirty equals 240. That's a lot of calls.
Surely sometime during that period, eight days, Texas should
have answered. Eight days worth of trying, no answer, and
the call was requested by the Fido in Texas, we did not
decide to send it there for the heck of it.
Fidonews Page 3 30 Dec 1985
Here is the ultimate irony of the whole episode.....Ma
Bell believes with all her motherly heart, that we connected
each of those times. 240 times 22 cents. Even without Lotus
123 you can see that's a lot of public service.... Poor Ma
Bell, she is totally convinced that we made those calls,
connecting each time. The lady said, "See, that's what
happens when you use a computer to automatically make calls.
It can go haywire". We were kind, and did not remind her
that she was using a computer to talk to us. We didn't even
remind her that haywire was the reason that 2400 baud
doesn't work on each call. If good wire were provided,
....Oh well.
So how about it. Read your documentation. If you ask
someone to send you a file, remember, Fido by-passes all
Host and Region-host routing. The message and file are
directed right to you. If you choose to not be on during
National Mail time, and instead pick up your messages during
your regional time, then ..........
---------> DON'T ASK ANYONE TO SEND YOU A FILE. <----------
We will continue to respond, as requested, with the
file and appropiate message to help you get into the
FidoGram habit. If we don't connect after a reasonable
number of calls, made throughout the National Mail time, and
within a couple of days of receiving your message, we will
not try again. You can call us. Go to File area Number
four, Fidfile, and download a file called FidoGram.ARC. It
has what you need, and your most welcome.
More importantly however, a lot of you should start
getting serious about Fido. You are not living up to the
deal. Fido's are to be on line, available, and willing to
accept mail and files during NATIONAL MAIL TIME. If the
people who make up the Nodelist each week want a list of the
offending Fidos, send us a message, we will tell you.
As long as everyone is talking of rewriting Fido, I might
as well toss in my 2 bits worth...
Problems with current BBS's
The learning curve of a new BBS is long and slow. (That's
what makes FIdo so nice; you know one, and you know them
all. When using a remote system through a modem (slow)
things like help menus, long prompts, etc are a pain. Even
more so if you don't know the system. The sequence I seem
to go through learning a new system is
HELP DIR HELP UPLOAD HELP DOWNLOAD ...
It would be nice to have the help screens available
localy (capturing/printing works, but is not always possible
if you don't have a printer)
Another problem is that in order to get things done
quickly people set the prompting level to expert to bypass
the long (slow) novice prompt. Why should I have to choose
between understanding and boredom?
Still another problem is that file transfers are all done
HALF DUPLEX! WHY? Cuz XMODEM does it that way, and no one
has bothered to update things to FULL DUPLEX.
Suggestions/solutions:
The December BYTE issue on conferencing said a lot. In
fact, it said much of what I had been thinking, but thought
no one would be interested. (anyone out there have a black
book program?) One of the ideas I've been working on is
that of taking advantage of the fact that many (?most?)
users of a BBS are using computers with telecom programs.
Why not set up a "Fido" designed with the Kermit server idea
where it responds to requests like:
READ MESSAGE n
REPLY TO MESSAGE n
ENTER A MESSAGE
LIST DIRECTORIES
LIST FILENAMES IN directory
UPLOAD FILE name WITH protocol
DOWNLOAD FILE name WITH protocol
and have the telecom program provide all the user interface!
Help menus in windows at local processor speeds, screen
scrolling to see the last n pages, the ability to be
retrieving the next message while the user is reading the
current one, integrated LOCAL full screen editors to compose
messages...
Fidonews Page 5 30 Dec 1985
The great part of this would be that the "Fido" server can
change without affecting the interface, and the user can
hack up his interface program as much as s/he wants to. The
worst that can happen if the user hacks up the user
interface too much is that that user gets screwed.
If the interface is done at a PACKET LEVEL, (rather than
at a character level) the systems could provide virtual
circuits to allow such things as simultaneous uploads and
downloads, downloads while reading messages, etc.
If the FULL DUPLEX protocol was implemented for FidoMail,
the sending node could say to the receiver something like "I
have 3 minutes of stuff to send you, you may send me up to
that time limit of stuff to me for free" (sort of like the
LISTGEN POLL command).
With the advent of Wendin's Operating System Toolbox, and
their multi-tasking PCUNIX/PCVMS systems for the PC world,
these protocols can be *easily* implemented. Right now I
have the basic code (in C) which allows a single virtual
circuit between machines (NO BBS, just some rickety stand
alone code), and as soon as I figure out the system calls to
the Wendin OS's, it will become a multiple virtual circuit
system. (a virtual circuit allows you to treat the com line
as an ERROR FREE link to another program; more than one
virtual circuit may be mapped onto a single physical
comunications link). I'd like to hear from Bob Hartman
about what he has been doing with the Rover networking
implementation...
Right now these are nebulous ideas waiting for some free
time to get implemented. It would be a shame to miss this
opportunity to upgrade FidoNet into an even lower cost
messaging system!
I will follow this up with a more coherent note after I
get a working system (small, no frills...) up and can
benchmark its performance -vs- Fido and other systems. Send
NetMail messages to me at
121/90 (John Plocher)
if you want to participate in this brainstorming...
Several FIDO systems around the United States have linked
together to form MEDNet. MEDNet is a alternate FIDONet for
FIDO's that have an interest in the medical sciences. One
of the prime purposes of MEDNet is to allow easy
distribution of medically related files to all interested
FIDOs by using a HOST system and POLLING. This allows each
system to share interesting files with all other MEDNet
members without having to go through the expense of multiple
long distance telephone calls.
We invite other FIDO systems to join MEDNet - all that is
required is an interest in the medical sciences and the
williness to POLL a HOST board once a week to pick up new
files. If interested, please send Netmail to FIDO 114/15.
EJ McKernan, Sysop
The Bit Bucket BBS
Node ------ 14/386
(316)343-8028 24hr
300/1200/2400 Baud
In this column we will attempt to answer users questions
concerning sanyo computer hardware and software. If you have
any questions you'd like answered, please send them via
FIDONET mail to the BIT BUCKET (node 14/386,) Or if you
don't have an account for fidomail call the board and leave
your question in a message area.
Let's get right down to business by answering one of the
questions most often asked by sanyo owners wanting to use
the machine for telecomunications.
Q. When using some communications programs on the sanyo
(minitel and fido included) why does my modem disconnect
when I try to access my disk? How do I fix it?
A. The problem is that when sanyo wrote the drivers for the
disk controller they decided to disable all other hardware
interupts when they were expecting an interupt from the disk
controller. What they did was command the 1851 UART, used
for serial I/O, to drop the data terminal ready (DTR) line
going to the modem.The problem with this is that when the
DTR goes low the modem disconnects the phone line unless we
have set up the modem to ignore DTR. That's not exactly what
we want to happen when we're accessing the disk drive. There
eat my shorts yis another way to disable interupts from the
UART, use the interupt controller mask register. Sanyo does
this as well as drop the DTR line. They didn't need to do
both. You may state, "Why all this technical jargon. Just
Tell me how to fix the problem! OK OK, I just wanted to give
you techy types something to read.
FIX: There are available patch programs that will remove the
code from the BIOS that switches OFF/ON the DTR line. Tom
Jennings original patch for MSDOS 2.11 (sanyos' original) is
named SYOPATCH.COM. There are others for all the different
version of MSDOS available for the sanyo. Problem is that
they have different names. Look around different sanyo BBS's
and download them all (they are very small, about 386 or so
bytes) and find one that works with your dos version. My dos
is DSDOS 2.11+ from michtron. The patch I use is
SYDSPTCH.COM. It and a few others are available on the BIT
BUCKET BBS. If you can't find something that will fix your
dos leave me a message spelling out exactly what dos version
your using (all the version numbers you see when you boot up
your machine,) and I'll see what I can come up with.
Well that's all I've got for this week. Send me your
questions and I'll see what I can do in the way of answers.
The snow on a color graphics adapter occurs when you change
the values in screen memory during a raster scan, i.e. while
the electron gun is updating the screen from screen memory.
I'm not sure of the exact mechanism, but this definitely
causes interference with the screen update, and the end
result is that ugly snow.
One way to avoid this is to wait for "vertical retrace",
that time period during which the electron gun shifts its
beam from the lower right-hand corner of the screen to the
upper left. During vertical retrace, bit 3 of port 3DA
(hex) is set on, and the test in TURBO can thus be made:
Repeat until ((port[$3DA] and $08) = $08);
{*** perform screen update ***}
{*** note: port $3DA is a read-only register ***}
This is how the IBM ROM-BIOS writes a character to the
screen, does scrolling, etc. But the problem is that
vertical retrace lasts a mere 1.25 miliseconds or so, not
enough time to perform complicated and/or large updates.
The other way, the way Sidekick does it, is to turn off the
display, do the update, and turn the display back on. This
is why, when you bring up a Sidekick window, you see a
momentary "flash" on the screen. The display enable/disable
function is controlled by port 3D8 (hex), a write-only
register.
One thing you should know about this is that this whole
concept applies only to the IBM color graphics adapter.
Monochrome displays do not get snow, and the Enhanced
graphics adapter will crap out on you if you turn off the
display in this way. This is why earlier versions of
Sidekick bombed on the Enhanced graphics adapter. Current
versions of Sidekick work just fine on the EGA.
Use the following, or a similar routine to test what kind of
display you are running on, and then to update the screen:
type
Registertype = Record
case boolean of
true : (AX,BX,CX,DX,BP,SI,DI,DS,ES,flags : integer);
false : (AL,AH,BL,BH,CL,CH,DL,DH : byte)
end;
video_mode_ptr = ^video_mode_type;
video_mode_type = (cga,ega,mono);
function get_video_mode : video_mode_ptr;
var
Fidonews Page 10 30 Dec 1985
regs : registertype;
equipment : integer;
ega_info1,
ega_info2 : byte;
temp_return : video_mode_ptr;
begin
intr($11,regs);
equipment := regs.AX;
regs.AH := $12;
regs.BL := $10;
intr($10,regs);
ega_info1 := regs.CL;
ega_info2 := regs.BH;
new(temp_return);
if ((equipment and 52) in [0,16,32]) and (ega_info2=0)
then
temp_return^ := ega
else
if ((equipment and 48) in [16,32])
or (((equipment and 52) = 4) and (ega_info1 in [4,5,10,11]))
then
temp_return^ := cga
else
temp_return^ := mono;
get_video_mode := temp_return
end;
begin {* screen update *}
video_mode := get_video_mode;
if video_mode^<>mono
then
if video_mode^=cga
then
begin
port[$3D8] := $21;
{*** perform screen updates ***}
port[$3D8] := $29
end
else
saved_screen := cscr
else
saved_screen := mscr
end; {* screen update*}
There seems to be a bit of controversy as to whether the
"snow" or the "flash" is more ascetically displeasing, but I
prefer the "flash".
I have finally attempted to organize all of those great Fido
sysop-type utilities that I have collected over time, and put
them in some fashion that may benefit others of you. I have
used the ARChive utility to 'rename' some of them to avoid
conflicts. I also have, for each file, another file named
filename.ZZZ. This file lists members of Archive, author, and
brief description of the program.
Below is the current list of the files I have available.
If you know of others, or later versions, I would appreciate
your sending them to me for addition. Thanks.
This week's column starts off with a few thank you's. While
many of you have the impression that churning out columns
and articles is a solitary task, in reality, this is simply
not the case. Sure, I put the words together, but many
other people are also involved. Without these people
participating, the writing process would be much more
difficult, if not impossible., I appreciate the assistance
and encouragement, and would like to give credit where
credit is due. The FIRST BIG THANK YOU goes out to you, our
readers. Because of the publishing time lag, this is being
written several weeks after the first Corner appeared. In
those few weeks, your response has been very encouraging.
So thank you, dear reader, for your kind words, comments,
and questions. Let me again take this opportunity to
encourage you to write. Paper mail goes to P.O. Box 668,
New City, NY 10956; Source Mail to TCA920; and MCI Mail to
"THEODORE NEEDLEMAN".
The next bunch of thanks go out to some people at DEC who
have been extraordinarily helpful. Gary Mikkola, Pam
Hamilton, Eileen Stokes, and Jim Alosi have all been very
helpful in sharing their time and resources.
And, of course, much thanks to my friends and associates on
the Hardcopy editorial staff.
Enough of this maudlin stuff, the next bit of business is
reader mail.
This week's mail has several questions on word processing.
Phil Pistone asks how I rate SAMNA III, and Hans Brey
inquires about a word processor able to do mathematical
symbols as well as compose simple diagrams and charts.
Having never used SAMNA, I can't comment on it. I've heard
nice things said about it, but I remain stubbornly loyal to
WordStar. Actually, I remain loyal to WordStar for several
very good reasons. It was the first micro-based word
processor I learned, it runs on most of the varied systems
we've got here in the "SWAMP", and it still meets our needs.
Like most people, I tend to stay with the first product I
learn to use, as long as it continues to provide a good
measure of use. Sorry Phil, but if I get any feedback on
SAMNA III from other "Corner" readers, I'll be sure to pass
it on.
The specs on SAMNA III sure look impressive, and one of them
will be of interest to Hans. Both SAMNA III, and DEC's new
WPS+ for the Rainbow, list the ability to use math symbols.
Neither of these packages seems to be able to do the kind of
graphics Hans is interested in, but the IMAGE word/graphics
processor from MicroArt Corp. (200 Market Bldg., Portland,
OR 97201, phone 1-800-MICROART) offers the ability to
manipulate not only text, but any of the built-in Rainbow
graphics characters. IMAGE offers an impressive array of
Fidonews Page 14 30 Dec 1985
word processing functions. The graphics creation and
manipulation features work well, and can be used to produce
some very interesting images. These graphics can be
integrated within the text, and the package is quite
reasonably price $295).
Other questions from Phil and from Del Merritt concern
hardware. Phil is interested in the 8087 numeric
coprocessor and discusses the slot contention between the
hard disk controller and extended communications board
option. Del, on the other hand, is interested in expanding
his 100A at the least cost.
Well guys, to give myself a bit of a plug, in either this
issue, or next week's you'll find an article by yours truly
addressing just these concerns and containing reviews of
hard disks, memory expansion boards, and some software.
While I wasn't able to obtain an 8087 board to review, there
are two things to keep in mind about the numeric
coprocessor. The first is that unless your application
involves a lot of number crunching, you will see very
little, if any, improvement in speed. Secondly, the
software you're using must look for, and be able to use, the
8087. Much of the software out there doesn't bother to
check if the 8087 board has been installed. If you write
your own, make sure that the particular language you're
using can take advantage of the numeric coprocessor before
you rush out to buy it.
I had a bit more success researching the issue of slot
contention. I wasn't able to find anyone who makes a
combination hard disk controller/extended communications
card. I did, however, as part of the above article, find a
company that offers some interesting combinations.
Univation, Inc. (1037 N. Fair Oaks Avenue, Sunnyvale, CA
94089, phone 408-745-0180) offers a variety of products for
the Rainbow including RAM memory, fixed and removable hard
disks, and an Ethernet LAN controller. Not only are their
prices very reasonable, but their Ethernet board can be
piggybacked over the hard disk controller.
Their hard disk controllers, whether for the fixed or the
removable hard drives, all contain at least 64K of
additional RAM, and can be obtained with up to 448K of RAM.
While this doesn't solve the problem of the HD
controller/Comm Board slot contention that Phil asked about,
it does show that Univation is concerned about providing the
most expansion capability for a machine with a limited
amount of expansion slots, and I commend them for their
efforts.
I'm running out of space here, but before I close this
week's "Corner" let me ask that if you haven't yet "cast
your vote" about "Project Transport" discussed in last
week's column, please do. My addresses are listed above,
and if you're a new reader, drop me a line and I'll send you
a copy of last week's "Corner" so that you'll see what I've
Fidonews Page 15 30 Dec 1985
proposed. Your questions and comments are also very welcome
at these addresses.
That's it for now, see you next week.
(c)opyright 1985 by Ted Needleman-all rights reserved
