Can the 7300's modem go 2400 Baud?; HwNote11

[John B. Milton]

In article <426 at polyof.UUCP> steve at polyof.UUCP (A2 Steve Weiss ) writes:
>
>	While browsing through /usr/include/sys I found several
>things which would lead one to believe that the on board modem on
>the 7300 can go 2400 baud.  
Here we go again...

>	Those things are as follows:
>
>hardware.h:/* D5-7 are used for 2400 baud modem */
>hardware.h:#define BAUD2400	0x0020			/* Select 2400 baud on modem */
>modem.h:#define Baud2400_SCM_Wr1	0x10  /* also need R8b3 to be set  */
>modem.h:#define at2400Baud_SCM_Rr2	0x0C
>modem.h:#define SetSynchMode_SCM_Wr4		0x80  /* 1200 and 2400 baud only  */
>modem.h:#define Set2400Baud_SCM_Wr8		0x08  /* R1b4 should also be set  */
>
>	Can the modem go 2400 Baud?  If not, why were these #define's made?

Those 2400 things are there BECAUSE...

Convergent Technologies, the OEM of the S4 (safari 4) a.k.a UNIXpc, was working
on the next model of the machine. This was to be mother board revision P6.
Things to be added:

1. 2400 baud internal modem.
2. Provisions for a second hard drive.
3. Addition of a 4th hard disk head select bit.
4. Addition of a floppy tape drive, simlar to the external one, but slower!
5. Addition of a some cicuitry so that the kernel could sense a P6 mother
   board and react properly.

Some of the software needed to make all this work was completed and put into
the standard distribution. Notably: support for the 4th head select bit and
the second hard drive (/dev/*fp01?). The 2400 baud modem stuff was only put
in as stubs. There is no real code to drive the 2400 baud modem if it was
there. The 2400 baud modem DID work on machines inside Convergent. It used
a proprietary AT&T 2400 DSP modem chip. This is the sort of thing AT&T uses
to make their own modems. It is not something the rest of us could get ahold of
for reasonable prices. These days, there is no point with 2400 baud modems
coming down in price.

The internal floppy tape is an interesting story. The external tape drive
for the UNIXpc is also a "floppy tape". Floppy tape is a very appropriate name,
as the connectors and pin definitions for the connectors are almost identical
to a regular 5 1/4" floppy drive. It can also be controlled with a regular
floppy disk controller chip. The idea for the P6 was to use the existing
internal floppy disk controller. The problem here is this: the floppy drive
is the regular double density drive. It has a bit transfer speed of 250k. The
external tape drive has a bit rate of 500k, just like 8" floppy drives and
AT 1.2M 5 1/4" floppy drives. The Floppy Disk Controller (FDC) chip used in
the UNIXpc, the Western Digital 2797 can deal with both bit rates.

The trick is that the clock it uses must be able to shift from 1MHz to 2MHz,
and the yucky analog stuff for the phase locked loop must also "shift". The
external tape drive has it's own controller board, with its own FDC, tuned to
the 500k data rate. Well, to make a long story short, the guys at Convergent
could not get this to work. To get around the problem, they used a slightly
different model of the tape drive used externally. This other tape drive could
write a tape IN THE SAME FORMAT, and yet use a 250k data rate. How, you ask?
This other drive moves the tape past the head TWICE AS SLOW. Crude, but it
works. Since these drives are targeted to existing floppy systems, it is
understandable. For those of you have seen the UNIXpc external tape in action,
you can imagine just how slow it would be going twice as slow. I imagine
Convergent would have worked out the problems to use the high speed drive, but
the P6, and indeed the whole machine was shot down.

I looked at adding the circuitry to do the floppy tape stuff to the board I'm
making, but I decided against. The software to support the internal floppy
tape drive IS NOT provided with UNIX. I am looking at adding/substituting a
1.2M floppy for my next project.


The 2,3,4 above are going to be on the board I'm building. I have the PAL done
and simulated, but not burned. I was going to use the "P5.1" PAL to do the 4th
head select bit and the version feedback, and then a new PAL to do the 2nd
hard drive select and hard disk data multiplexing. Oh, you noticed I said "was".
Yes, I changed the design again. I have integrated both sets of functions on
ONE PAL. This makes the design a total of 3 chips (PAL, driver receiver),
which is as low as it can get without going full custom or macro cell. The PAL
I have chosen is a relatively new, somewhat more expensive one, the 22V10.
This is a WONDERFUL PAL to work with. I have barely scratched the surface with
my needs as far as what this PAL can do. I mostly went with this PAL because I
need lots of I/O pins, and output configurability. That "V" stands for
versatile, and it means it. If I goof something up, there should be lots of
slack with this PAL to fix things.

As has been said before, if you don't want to use the 4th head select stuff
(you already have the P5.1 PAL installed), you simply don't connect up all
the wires. I like Gil's idea of using a socket on one of the spares. The
logical way to have the best of both worlds is to use the P5.1 wiring pattern.
This will work, since there are some NC pins that can be used WHEN DUMPING THE
ON BOARD P5.1 stuff. It's 2:30, time to go to bed and think.

It is looking more and more like I won't be re-writing the gd driver. It would
probably be a small loadable driver that would use almost all of the gd driver
in /unix. The extra arrays needed to support two more (for a total of 4) drives
could be allocated by the driver when it is loaded. Basically, the loadable
driver would provide another character, and another blocked major device. These
would mostly act as drive select front ends. Unfortunately, there are a lot of
details to be worked out. I may have to do a drive table swapping kind of deal
to make it all work.

Now for the important part. As lenny and others have suggested:
All of this would be much easier if some of the tables in /unix were increased
in size. A very few things could be tweeked before UNIX is compiled for the
next fix disk. This would make life MUCH easier for some of us.

I suggest:
  gdisk.h:
    DISKS from 3 to 7 (4 HDs, 3 floppys) (from 2 bits to 3)
    (see DISK_n, and gdsw[])
    HDMAXCYL from 1400 to 2048 (might be a disk format change)
    HDMAXBADBLK from 128 to 512 ""
  usr/src/UTS/kern/cf/conf.c: (guess)
    NMOUNT from 4 to 16 (lots of partitions on lots of drives)
    NLBDRV from 4 to 8 (blocked drivers)
    NLCDRV from 10 to 20 (character drivers)

I probably missed a few, and some of this is based on how other UNIX systems
do configuration. I guess my dream would be to have a set of libs and .o files
for UNIX, JUST LIKE EVERY OTHER UNIX system I've worked on. For those of you
who don't know, most UNIX systems are shipped with a set of lib???.a, *.o and
some *.c files. The system is configured by modifying .h or .c files, compiling
them and re-linking the kernal. With our system, they chose to do system
re-config through the ktune(7) stuff, and only provide a subset of the changable
stuff. If ktune were expanded, that would work too, and might be quiker and
easier to implement. It would require an extra line for each parameter here
and there, a new ktune program, and a new man page. Anyone who can pass this
through to AT&T, please do. If you have a contract whereby you can INSIST on
these sorts of things, do that. PLEASE!

I'm looking to have Beta boards ready to roll by the end of the month, or
early Feb. I don't want to pay the nasty prices for rush PC board work.

As always I appriciate any comments. I may not appriciate it too much after
I have boards made...

The price of tea in China remains unaffected.

John
-- 
John Bly Milton IV, jbm at uncle.UUCP, n8emr!uncle!jbm at osu-cis.cis.ohio-state.edu
(614) h:294-4823, w:764-2933;  Got any good 74LS503 circuits?