Subject: KL8JA enhancements?

From: [email-masked] (Douglas W. Jones,201H MLH,3193350740,3193382879)
Date: Tue, 16 Mar 1993 22:32:10 GMT

While decyphering the myriad options offered by my M8655 KL8JA board,
I hit on the following idea, which is described in the following
optional section of the KL8JA technical notes:

===========================================================================

?) Unused sockets.                         \\____//           \\____//
                                   _________||__||_____________||__||_____
The KL8-JA board contains two       o _o    _     _   o _ o  _   _ _ _ _ o|
sockets that were apparently         : :   | |   | | ..| |  | |          ||
used in production line testing      : :   | |   | |   | |  | | |  CAN    |
of the board.  Nothing should        :_:   |_|   |_| ..|_|  |_|  _ _ _ _ ||
be plugged into these sockets         ^                        _     ___  |
for normal operation.              unused!                    | |   |   | |
                                                              | |   |OSC| |
An interesting option would be to use these sockets to        |_|   |___| |
hold the logic needed to implement software selectable         _      _   |
baud rates.  This would involve cutting the unneeded          | |    | |  |
traces to the sockets and using them for the flipflops        | |    | |  |
to hold the baud rate.  The flipflops outputs would drive     |_|    |_|  |
the inputs currently driven by switches B1 B2 and B3                      |
(see section 4), and the inputs would come from bits           _      _   |
7 8 and 9 of AC on a KIE instruction when the SWD             : :    | |  |
jumper is present (see section 2).                   unused! >: :    | |  |
                                                              :_:    |_|  |

===========================================================================

This enhancement shouldn't be a hard one to implement, but I don't want to
recommend that anyone undertake it until we can hash out whether or not it
is desirable and how it should be standardized.  I don't want to see 100
different hackers (well, how many PDP-8 hardware hackers are out there?)
produce 100 different and incompatable designs, but if we could all agree
on the same enhancement, with the mechanics of the change set down about
as firmly as they are for DEC's field changes, we might be able to come up
with a useful board revision and get a significant population of compatable
hardware.

Of course, the biggest place this would help anyone is in modem control,
for example, if someone wanted to set up a PDP-8 based BBS.  In this case,
you'll probably need an M8653 KL8M modem control board to handle the rest
of the RS232 lines that the KL8E ignores, and you'll probably also want to
be able to diddle the parity bits and stop bits under software control.

					Doug Jones
					[email-masked]

---

From: [email-masked] (Charles Lasner)
Date: Wed, 17 Mar 1993 07:18:41 GMT

There already is a standard for PDP-8 baud-rate control.  The implementation
is 6xx3 where xx is the receive device code.  The baud rate is obtained by
the contents of AC[8-11] and is used to dump the 4-bit quantity into the
selection register of a 5016/8016 baud rate chip.  Curiously enough, the
same 5.0688 MHz. crystal is used for this chip, so it is compatible on 
several levels.  (The chip has an option to run directly a series-resonant
crystal, or can be run by a TTL clock can.)

The circuit is used on the VT-78 for the serial ports and serial printer,
as well as for the same functions on all of the DECmates, including the
baud rate for the relevant comm sections, etc.

All of the options implement the same rates:

AC bit#         Rate

8 9 1 1
    0 1

0 0 0 0       50   Baud
0 0 0 1       75   Baud
0 0 1 0      110   Baud
0 0 1 1      134.5 Baud
0 1 0 0      150   Baud
0 1 0 1      300   Baud
0 1 1 0      600   Baud
0 1 1 1     1200   Baud
1 0 0 0     1800   Baud
1 0 0 1     2000   Baud
1 0 1 0     2400   Baud
1 0 1 1     3600   Baud
1 1 0 0     4800   Baud
1 1 0 1     7200   Baud
1 1 1 0     9600   Baud
1 1 1 1    19200   Baud

Thus, true compatibility can be had by imitating this standard.  Likely most
of the gating is already on the card.  By eliminating the discrete logic used
to run the dip switches, this software controlled verison can be implemented.
Any additional gating can be placed in the saved real estate, etc.

Eliminating the odd R=150 option is quite reasonable, as few of us can even
take advantage of it.  (I have a VT05 and I don't even bother!)

Perhaps a clever design could come about that enables/disables the on-board
DIP switches used for the current 3-bit select and the R=150 option to form
a 4-bit register that overrides the programmable value should the SWD or
some other jumper not be set.

cjl

---

From: [email-masked] (Douglas W. Jones,201H MLH,3193350740,3193382879)
Date: Wed, 17 Mar 1993 13:55:35 GMT

>From article <[email-masked]>,
by [email-masked] (Charles Lasner):

> DIP switches used for the current 3-bit select and the R=150 option to
> form a 4-bit register that overrides the programmable value should the
> SWD or some other jumper not be set.

In 2 chips?  I doubt it!  And the table of baud rates looks different
enough from the table supported by the KL8JA that the mapping may be quite
difficult.  My suspicion is that compatability with this existing standard
would be very hard to achieve.
				Doug Jones
				[email-masked]

---

From: [email-masked] (Charles Lasner)
Date: Wed, 17 Mar 1993 16:02:47 GMT

>would be very hard to achieve.

Enabling the DIP switches to be a default override for the program-controlled
values may be difficult unless you allow the switches to OR into the data
a program might use.  Thus, a program ignorant of the extension would work if
the DIP switches were set to the desired value for the benefit of said program
while a "smarter" program would fail to set the rate correctly unless you
lucked out that the rate you wanted ORed with the DIP switches was the value
you wanted.

In any case, the implementation is rather simple:

the decoded 6xx3 for receive should be available already and properly
conditioned, etc.  Use it to load the AC data into 4 flip-flops.  I think one
of the 82xx specials is literally this function.  So, that's one chip.  The 
other chip is the baud rate generator 8016/5016 which goes to the TTL 
oscillator can 5.0688 MHz.  Also, this baud rate chip can take its own
crystal if necessary; I can provide the appropriate series-resonant crystal.
(I purchased a lot of them from the crystal vendor recommended by the
chip manufacturer; they turned out to be local to me, and would only sell me
a lot of 25, but at a cheap price :-).  This was for a different project to
create a baud-rate generator, but not for the KL8-JA, etc.)

In the process of doing this, some other logic may become totally package
obsolete, thus freeing more space to perhaps do the DIP switch "frill"
part better, etc. (Use a 2-way 4-bit multiplexor to select either the 4 DIP
switches or the outputs of the data flops as the source of the data for the
baud-rate chip, etc.)

cjl