Print

[Al Kossow]

I'm trying to test Alex's priam interface board.
So far, no joy. Trying on a couple of different drives and controllers I can't get the drive to spin up.
In BLU, ID returns error 8000E5CB and spin down returns 9A40E5CB but I have no idea what those status
bytes correspond to looking at the DS101 document

[Al Kossow]

Hooked up a cable tap with a saleae on it
Here are the traces doing a boot, and blu ID and spindown
http://bitsavers.org/projects/datatower/d7-d0_a2-a0_wr_rd_rst_req

[Al Kossow]

i've been staring at the logic traces and i think the data bits ended up scrambled somehow

it is active high logic on the bus, the boot prom goes

send command 7 soft reset
wait for status 16
send command 82 spin up and wait
wait for status 0

but what i see is
wr adr 0 01100001
rd 0  00000000
rd 0  00000101
wr 0 01101001
wr 2 00011001


also, i'm not sure if BLU has code in it to spin up the priam

[Al Kossow]

I'm thinking I just need to sort out the cabling situation between the controller board and the interface and also build a little priam tester out of an arduino. There really isn't a compelling reason to stick with the 25 pin connector of the original lisa priam interface card. I think I have the last known stash of datatowers (4 complete ones) and I don't have any cables. the controller card in the priam has a 40 pin ribbon connector, that gets converted to a 37 pin d-sub, then that gets converted to 25. You can just use a 37 pin on the lisa card then use a ribbon to 37 d or 40 ribbon on the other end.

[sigma7]

In BLU, ID returns error 8000E5CB and spin down returns 9A40E5CB but I have no idea what those status bytes correspond to looking at the DS101 document

For BLU v0.92

Code: [Select]


* Priam Errors $yyzzE5xx ; xx are error code, yy is $80|transaction status (might be the same as the error code), zz is register 3 supplementary status
PriamErrCode EQU $E500
* when Priam returns an error, bits 6,7 are device select, so are always 0, so we set bit 7,6 for our errors
PriamErrIntNBsy EQU $E5C1 ; Priam did not accept command: "interface busy" not set
PriamErrCmdComp EQU $E5C2 ; Priam did not Acknowledge Command Completion: "interface busy" remained set
PriamErrNotRun EQU $E5C3 ; Priam is not attached or is not turned on
PriamErrWaitRFB EQU $E5C4 ; Priam did not Acknowledge Command Completion: "interface busy" remained set
PriamErrCmdRej EQU $E5C5 ; Priam rejected command
PriamErrInvSect EQU $E5C6 ; Priam invalid sector
PriamErrCmdTime EQU $E5C7 ; Priam command timeout with no data transfer nor completion request
PriamErrCmdCpl EQU $E5C8 ; Priam command completion timed out
PriamErrNoXfer EQU $E5C9 ; Priam asked for command completion before data transfer
PriamErrParity EQU $E5CA ; Priam parity error during read
PriamErrSoftR EQU $E5CB ; Priam error from software reset
PriamErrSoftRW EQU $E5CC ; Priam error waiting for register file free after software reset
PriamErrSeqUp EQU $E5CD ; Priam error from sequence up
PriamErrSeqUpW EQU $E5CE ; Priam error waiting for register file free after sequence up
PriamErrSetLog EQU $E5CF ; Priam error from set logical mode
PriamErrSetPrm0 EQU $E5D0 ; Priam error from set parameter 0
PriamErrSetPrm1 EQU $E5D1 ; Priam error from set parameter 1
PriamErrRdParms EQU $E5D2 ; Priam error from read drive parameters
PriamErrNotRdy EQU $E5D3 ; Priam error not ready for a command
PriamErrEndDD EQU $26 ; end of defect directory, not an error, but consumes this value
PriamErrNoDD EQU $27 ; no defect directory, not an error, but consumes this value


This error code info may change: now that I've seen the LOS Priam driver, I have worked a bit on improving the error reporting, mainly since my own DataTower is no longer working properly for mysterious (to me) reasons.

[sigma7]

i'm not sure if BLU has code in it to spin up the priam

When the Priam is selected as the object of any hard disk command (eg. identify device, read from, write to, etc.), BLU first attempts to verify there is actually a Priam there by sending it these commands:

$07 - Software Reset
$82 - Sequence Up & Wait
$08 - Set Logical Sector Mode

Not getting past the Software Reset command will prevent it spinning up. This would (probably) be the case if the controller has a self-test failure.

Edit: Selecting Logical Sector Mode is command $08 with parameter $40, not command $40

[sigma7]

i've been staring at the logic traces and i think the data bits ended up scrambled somehow

I suggest connecting the logic analyzer to the DS101 itself for testing that all the circuitry before it has the bits connected correctly (perhaps you've already done so); then use service mode to poke the individual bits to confirm they are correctly connected and unique.

Since the protocol is so simple, you can also send basic commands and read responses interactively using service mode. (Although commands that involve data transfer would be more practically done by calling a routine.)

[Al Kossow]

Do you have much experience debugging the DS101 board?
I've been off building a 40 pin cable tap for the analyzer, got it working last night and it does show the bits in
the right order. I also wired up two of the signals that aren't brought across, one is supposed to show if it passed
its self-test if i'm reading the docs correctly.

I am going to try poking at a SMART-E board with an arduino bolted onto the cable tap next, since I do have schematics for that, and it uses an 8085 and is a much simpler board. It uses the same interface protocol. That way I can follow everything that happens on the SMART-E after assertion of RST/

One thing I haven't tried yet is looking at the SMART-E board attached to the Lisa interface to see how it behaves

Will the DS101 pass self-test if no drive is connected?

[sigma7]

Do you have much experience debugging the DS101 board?

Not really. My only 'successful' efforts were the two boards that failed their self test that I've mentioned by email previously. The one with the invalid DRAM write timing (where the write signal was held after the address lines changed at the end of the cycle, causing erroneous writes to semi-random addresses -- "fixed" by adding some logic to terminate the write signal sooner), and the one isolated to a non-functional data bit in the DMA controller, which remains unrepaired in that state.

Since that effort some years ago, I have received a couple of more DS101s from eBay (Many thanks to James Denton), but when I've tried to test them, I find my Priam DataTower no longer works (drive spins up, seeks, and a data stream is present from the head amplifiers, but an ambiguous error occurs -- I presume the drive's digital section is the problem as the symptoms are the same with multiple controllers).

I am going to try poking at a SMART-E board

I suspect the DS101 variety of controller is only needed to access the QIC Tape.

Will the DS101 pass self-test if no drive is connected?

I think so... I'll see if I can try it.

[Al Kossow]

there is something wonky going on with the interface.
I put up some jpgs of traces in http://bitsavers.org/projects/datatower/traces
The boot is really strange I tried booting twice and there are two reads of the status register
a second before it does then it does a two byte write of 00 then 07
Looking at the smart-e schematic, it flags if there is a back to back command write

The BLU commands make a little more sense

the cmd 7 in ident is failing with a ram failure ?

wr 2 0
wr 4 0
wr 6 0  <--- this would make sense if the params are written to the word-write adr. I wonder if the byte/wrd adr is flipped on the interface just for writes?

wr 0 0
wr 0 7

rd adr 2 -- completion code 1a
rd adr 3 is 0
then it reads 2 and 3 again ??

[sigma7]

there is something wonky going on with the interface.

I may be mistaken, but I have the impression you are using a prototype reproduction interface card that hasn't been tested before... any chance you could borrow one of the Priam cards from the museum's collection to see if it behaves differently?

https://www.computerhistory.org/collections/catalog/102673923
https://www.computerhistory.org/collections/catalog/102673924

The RAM failure error is what I observed with the extended write signal that corrupted memory... although I can't imagine they were shipped that way. Perhaps there is some part that was marginal and performance decayed.

Similar to what I think you're reporting, I have a vague recollection that I found the RAM failure wasn't reported in response to the software reset command, but turned up later in response to trying to actually do something... I assumed I had somehow missed it as a response to the software reset, but maybe it does behave that way.

Regarding accessing registers twice/redundantly:

Before attempting to interact with the Priam controller, the host must check to see that the "register file" is not busy.

Then (BLU at least) calls a preliminary command setup routine that will write zeros into all the parameter registers, which will also (re)check that the register file is not busy before writing those null parameters.

After performing a command, BLU reads the interface status and transaction status registers to see if the command succeeded, and if not, jumps into the error reporting code which reads those registers again to ensure it has the latest values.

Those redundancies are not necessary but are there in BLU to minimize troubleshooting mysteries.

[Al Kossow]

"I may be mistaken, but I have the impression you are using a prototype reproduction interface card that hasn't been tested before... any chance you could borrow one of the Priam cards from the museum's collection to see if it behaves differently?"

I guess that is the next logical step. I have an untested prototype and it is possible there was an error somewhere in the
reproduction. I don't have a Lisa with easy access to plug a logic analyzer onto the card

[sigma7]

Will the DS101 pass self-test if no drive is connected?

It appears that without a drive attached the controller will get through the Software Reset command successfully, then fail at Sequence Up...

Here are some results from various configurations with no drive connected:

Priam card in slot 3

• Nothing connected or With Cable connected at host end only
  Attempt Boot (Command 8) - 3 beeps, delay, Error 80
  BLU - Hd Identify : No device detected at that port
  
  
• With cable connected to DS101, but powered off
  Attempt Boot (Command 8) - 3 beeps, delay, Error 82
  BLU - Hd Identify :  Error Code 8000E5CB
  
  
• With cable connected to DS101 S#000298, powered on, no Hard Disk or tape interface connected
  Attempt Boot (Command 8) - 3 beeps, delay, Error 82
  BLU - Hd Identify :  Error Code A2FFE5CD
  -- Priam Docs say Error 22 is "Device Not Present"
  
  
• With cable connected to SMART S#008842, powered on, no Hard Disk or tape interface connected
  Attempt Boot (Command 8) - 3 beeps, delay, Error 82
  BLU - Hd Identify :  Error Code A200E5CD
  -- Priam Docs say Error 22 is "Device Not Present"
  (Don't know how to tell which type of board this is: SMART, SMART-E, etc.)
  
  
• With cable connected to DS101 S#0001312, powered on, no Hard Disk or tape interface connected
  Attempt Boot (Command 8) - 3 beeps, delay, Error 82
  BLU - Hd Identify :  Error Code 9D01E5CB
  -- Priam Docs say Error 1D is "PROM checksum error" - persists after reseating EPROMs
  -- this board has remnants of a toe-tag string tied to one of the corners.
  
  

From earlier BLU Priam Error list:
Priam Errors      $yyzzE5xx   ; xx are error code, yy is $80|transaction status (might be the same as the error code), zz is register 3 supplementary status

PriamErrSoftR   EQU   $E5CB      ; Priam error from software reset
PriamErrSeqUp   EQU   $E5CD      ; Priam error from sequence up

[Al Kossow]

https://oldbytes.space/@bitsavers/112672777398617184