jbm@uncle.UUCP (John B. Milton) (01/14/89)
In article <426@polyof.UUCP> steve@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@uncle.UUCP, n8emr!uncle!jbm@osu-cis.cis.ohio-state.edu (614) h:294-4823, w:764-2933; Got any good 74LS503 circuits?
sbw@naucse.UUCP (Steve Wampler) (01/18/89)
This discussion leads me to another question: What version(s) of
the Unix-pc's version of UNIX will this hardware revision work
with. I think I've inferred that 3.0 is out. Is 3.5? (I ask
because that's what I have - I could afford the $100 to go from
3.0 to 3.5, but not the $600 to go to 3.51.) Will any of the
3.51 do, or must one have one (which) of the fixed disks.
If I must have 3.51, is there a way to get it these days?
Thanks.
--
Steve Wampler
{....!arizona!naucse!sbw}jbm@uncle.UUCP (John B. Milton) (01/20/89)
In article <1127@naucse.UUCP> sbw@naucse.UUCP (Steve Wampler) writes: >This discussion leads me to another question: What version(s) of >the Unix-pc's version of UNIX will this hardware revision work >with. I think I've inferred that 3.0 is out. Is 3.5? (I ask >because that's what I have - I could afford the $100 to go from >3.0 to 3.5, but not the $600 to go to 3.51.) Will any of the >3.51 do, or must one have one (which) of the fixed disks. > >If I must have 3.51, is there a way to get it these days? All you need is UNIX version 3.5 or later. You do not have to have 3.51 John -- John Bly Milton IV, jbm@uncle.UUCP, n8emr!uncle!jbm@osu-cis.cis.ohio-state.edu (614) h:294-4823, w:764-2933; Got any good 74LS503 circuits?