That puts a different spin on it. I think we all would love to see your write-up on the KLESI.
Between working code in pdp11_rq.c and the
MSCP specifications it should be possible to write code for this. My suggestion would be to try to interface your KLESI to something big enough to run Linux (e.g. Raspberry PI, Banana PI) so you can take advantage of existing network and USB stacks. That should give you a really flexible device that can do a lot more than just interface a modern disk.
Of course, if this was up and running it might have an effect on the availability and price of KLESI modules...
That's why i purchased a couple of KLESI modules already :^)
I can' get upload to work so in-line it is ;^(
KLESI ramblings ver 0.4
klesi controller would be better described as a host bus adapter
it has no internal intellegence or programability. It always acts as a
slave to the controller (the part I need to build). It has logic for DMA
(bus address counter,NPR logic) and for generating interrupts.
It has address decoding for SA and IP access. It has a 16 word RAM for
buffering of status,vector,and data(DMA)
Definitions:
host the pdp-11
controller the thing I need to build
wc word counter (address of on board ram)
cmd command register (controls access and function)
bal bus address low 16bit (DMA address counter)
bah bus address high 6bit+BBS7
status onboard status register (parity flags, NXM, poll)
cmd/data slects new command
stb strobe active data (or command) to/from klesi register
init reset mscp controller (bus init or IP write)
T1 test for command completion
protocol (if you can call it that)
some (well most actually) of this is a guess based on the hardware. details
that are wrong can be corrected when I have an interface to exercise the klesi
none of my protocol assumptions affect the hardware design of the controller
interface
watch the init line (at all times) and reset the MSCP emulation if it sets
in a real controller the init line goes to the controller reset line.
sending a command:
assert cmd
assert data to klesi (command word)
assert stb
negate stb (stb must negate before cmd/data)
negate data and cmd/data
loading a register:
send command to select register and direction
negate cmd/data (should already be negated)
$1 assert data to klesi
assert stb
negate stb
negate data
goto $1 to repeat (don't need a new command for same register)
(like onboard ram)
reading a register:
send command to select register and direction
$1 assert stb
input data
deassert stb
goto $1 if needed
DMA npr requests occur to/from the onboard ram (16 words)
do npr will transfer up to 16 words per request. the size of the request
is determined by the starting value for wc (wc=0 16 words,wc=15 1 word)
npr stops when wc overflows and is restarted by reading/writing the onboard
ram. When wc overflows again (due to controller access) the transfer continues.
This allows for efficent block transfers.
dma get
i'm going to leave out all the assert/negate stuff...
load bus address registers (bal and bah)
set wc to 0
set do npr and ram read
(klesi dma's to on board ram)
wait for T1
read 16 words (this is why the cmd was do npr + ram read )
(dma will restart when wc overflows)
(klesi dma's to on board ram)
wait for T1
read another 16 words
to stop npr, clear do npr before reading ram
if you need to read less than 16 words
set wc to 16-desired_count before sending do npr
or negate do npr,set wc and do npr
dma put:
load bus address
set wc to 0 (or 16-count for less than 16 words)
load 16 words to klesi ram
set wc to 0 (or 16-count for less than 16 words)
set do npr and ram write
(klesi dma's to host)
$1 wait for T1
write 16 more words to klesi ram
loop to $1 for more
when you dont want to put more clear do npr
interrupt host:
set wc to 0
load vector into klesi ram
load data for host status read into klesi ram
set wc to 0, slave access,do irq
wait for T1
init sequence:
set wc=0
load init stage1 into ram
set slave access
wait for T1
set wc=0
read data
repeat for next 3 init stages
Signal lines:
CONN DIR REGISTER
pin K-C cmd bal bah status
33 d0 <-> wc 0 bl0 ba16 0
31 d1 <-> wc 1 ba1 ba17 1
29 d2 <-> wc 2 ba2 ba18 0
27 d3 <-> wc 3 ba3 ba19 poll
25 d4 <-> ba4 ba20 1
23 d5 <-> ba5 ba21 host parer
21 d6 <-> ba6 bs7 lesi parer
19 d7 <-> byte ba7 nxm
15 d8 <-> rs0 ba8
13 d9 <-> rs1 ba9
11 d10 <-> rs2 ba10
9 d11 <-> npr ba11
7 d12 <-> irq ba12
5 d13 <-> dir ba13
3 d14 <-> slave en ba14
1 d15 <-> wc clr ba15
35 parl <-> low byte parity
17 parh <-> high byte parity
47 cmd/data <-- command or data
45 stb <-- strobe
37 init --> bus reset or IP write (latch edge)
43 ac clear <-- controller power good
41 t1 --> ready
function decode:
4 command register bits go to a 74ls138 to decode
the klesi function
r0 ls138 A
r1 ls138 B
dir ls138 C
r2 ls138 -ena
bits function
0 ram rd
1 status rd
2 clear poll bit
3 noop
4 ram wr
5 hal wr
6 hah wr
7 noop
8-15 noop
command words (OR the bits to make a command):
wcclr 8000 word counter clear
slaveen 4000 enable slave access
dir 2000 direction of transfer
irq 1000 do irq
npr 0800 do npr
rs2 0400 register select 2
rs1 0200 register select 1
rs0 0100 register select 0
byte 0080 byte transfer
0040 unused
0020 unused
0010 unused
wc3 0008 word counter 3
wc2 0004 word counter 2
wc1 0002 word counter 1
wc0 0001 word counter 0
register selects:
ramrd 0000 read interface ram
statusen 0200 read status bits
clearpoll 0400 clear poll bit
ramwr 2000 write interface ram
halwr 2200 write host address low
hahwr 2400 write host address high
status byte:
type 07 interface type bits (type bits always read 010)
poll 08 poll requested
10 reads 1
hparer 20 host parity error
lparer 40 lesi parity error
nxm 80 non existant memory
Base address: 77772150 (172150)
IP 172150
SA 172152
hardware needed to talk to this thing:
KLESI bus is active low open collector with 220/330 ohm terminators.
Some systems use ds8641 others use 26s10 tranceivers. if the cable is
really short you should be able to drive with ttl or cpld directly.
16 bit bidirectional port for data and commands
read/write access to the port should generate the strobe to load data
to or from the klesi
or you could use shift registers driven by SPI to get 16 bit parallel
and generate strobe with GPIO
parity generators for hi and low bytes:
the klesi checks parity on the cable so you need to generate it.
you could generate parity in software and send to output ports (slow)
or generate using ttl or cpld.
to control the klesi you need 2 single bit outputs:
set cmd/data (latched output)
set ac clear (latched output)
you may need an additional bit to enable klesi bus drivers depending
on how the parallel poer is implemented
and 2 single bit inputs:
read init (latched input you have to poll this but can't
afford to miss it.)
read T1 (input)
AC clear could be hardwired asserted but a CSR bit seems more elegant.
cmd/data must be deasserted between back to back commands. But need not
be desaaerted for back to back data/register access. (not a new command)
You need a way to clear the init bit latch. init could set at any time so this
needs to be failsafe. perhaps write init bit=1 to csr to clear( or GPIO bit).
The project I had in mind when I got a couple of KLESI-QA on ebay was to build
a 16bit ISA board to attach. It eliminates all the "make a drive" hardware
issues like what bus drivers can I get and how do I prototype a qbus board.
It moves development away from debugging a card in a qbus slot, to debugging
software in a PC envrionment.
This also eliminates the "but I wanted SCSI(CF,IDE,SDcard,flash)" argument.
Running on generic hardware with off the shelf OS..pick what you want!
You could even use SIMH files directly.
My current thinking is to do SPI and GPIO bits on something like a
raspberry PI. or Beaglebone. The SPI may be slow, but it makes a
perfect envrionment for getting everything working, before building
some really fast hardware.
So the hardware interface for a PI looks something like:
16bit shift register driven by SPI
init latch (set by klesi init, cleared by controller init-clear)
5 GPIO outputs
read - generate strobe and load bus into shift reg
write - generate strobe and enable drivers
cmd/data - select command or data to klesi
AC_clear - controller ready (could be hard wired)
init-clear - reset init latch
2 GPIO inputs
T1 - klesi done bit
init - the state of the init-latch
