Print

[jamesdenton]

The guide mentions the following:

http://www.bitsavers.org/pdf/corvus/7100-03289_DiskSysTechRef.pdf Pages 1-2.

The drive indicates its readiness to accept a command by raising the READY line. The computer then puts a command byte to the data lines and pulses -STROBE. Upon seeing the -STROBE pulse, the drive drops the READY line as an ack to the computer. When ready for the next command byte the drive again raises the READY line.

At the end of the command sequence, the drive will keep the READY line low until the desired operation has been performed. Upon completion of the operation, the drive will lower the DIRC line, raise the READY line and allow the computer to read data and status information.

The drive starts a computer read sequence by lowering the DIRC line. The drive then puts a byte to the data lines and raises the READY line. The computer then pulses -STROBE line, capturing data on the rising edge. The drive then lowers the READY line until the next data byte is ready to send. After the last byte is transferred, the drive raises the DIRC line prior to raising the READY line.

The service manual https://bitsavers.trailing-edge.com/pdf/corvus/service/7100-04703_B-Drive_6MB_Service_Jun83.pdf Section 4.8.5 states:

When the host system needs to access the disk, it first checks the BUS DIRECTION signal, and if the bus is in the
host-to-drive direction, and the READY signal is high, the drive is ready to accept a new command. The host now sends
command bytes to the drive.

During a read or write command, the bus will remain in one direction without turning around, until all bytes have been
transferred. The drive will acknowledge the acceptance and execution of commands by setting the bus direction bit of
the status port. This is a signal that the return code is on the data bus, which must be retrieved before the drive will
accept new commands.

I can see the value of getting a logic analyzer on here, just don't have the time to do it until next week at the earliest.

--

What's also interesting is the purpose of Block 1 and Block 2, the ones it appeared to try and read:

Block 1 = Disk parameter block, including spare table, interleave info, and track offset.
Block 2 = Diagnostic block.

[sigma7]

In the initialization section of https://github.com/arcanebyte/uniplus/blob/master/v1.5/sys/cv.c

lines 119-131:

Code: [Select]

if (devp == PPADDR) {
devp->d_ddrb &= 0x5C; /* port B bits: 0,1,5,7 to in, 2,3,4,6 to out */
devp->d_pcr = 0x6B; /* set controller CA2 pulse mode strobe */
devp->d_ddra = zero; /* set port A bits to input **/
devp->d_irb |= CMD|DRW; /* set command = false  set direction = in */
devp->d_ddrb |= 0x7C;
devp->d_irb &= ~DEN; /* set enable = true */
} else {
devp->d_pcr = 0x6B; /* set controller CA2 pulse mode strobe */
devp->d_ddra = zero; /* set port A bits to input **/
devp->d_irb = CMD|DRW; /* set command = false  set direction = in */
devp->d_ddrb = 0x7C;
}

It looks to me that this means the initialization code is slightly different for the internal parallel port and expansion card ports (although I'm not certain the two blocks are functionally different in the end). Is it possible to test against the internal port as well?

Maybe too late to ask, and maybe I just forgot... is the drive known working or are we troubleshooting the drive and the connection at the same time? If the latter, then I think you can't avoid the logic analyzer since you can't use "it works!" to eliminate connection error theories.

[jamesdenton]

In the initialization section of https://github.com/arcanebyte/uniplus/blob/master/v1.5/sys/cv.c

...

It looks to me that this means the initialization code is slightly different for the internal parallel port and expansion card ports (although I'm not certain the two blocks are functionally different in the end). Is it possible to test against the internal port as well?
analyzer since you can't use "it works!" to eliminate connection error theories.

It will be difficult to test against the built-in port without installing the root OS to something off the parallel port. I can try it, though.

Maybe too late to ask, and maybe I just forgot... is the drive known working or are we troubleshooting the drive and the connection at the same time? If the latter, then I think you can't avoid the logic

The drive was not verified to work against another host, like an Apple II, and the previous owner had no way to test, either. It does appear to pass its power-on tests, though. And the fact that it attempts to read under a mount operation leads me to believe it's functioning. But I don't know if there's some format operation that needs to happen using the Corvus tooling, first. I have no idea what this was connected to in the past.

Re: OCD - the parallel card manual https://bitsavers.trailing-edge.com/pdf/apple/lisa/service/029-0176-A_Lisa_Parallel_Interface_Card.pdf Page 12 indicates:

OCD Open cable detect. If this line is high, Lisa
assumes no device is connected to the
connector.

Should this be pulled LOW while powered on? And is the "Lisa assumes" driven by an operating system rather than some hardware logic? I tend to lean to the former since the facilitates activity despite not being connected.

[sigma7]

OCD Open cable detect. If this line is high, Lisa assumes no device is connected to the connector.

Should this be pulled LOW while powered on? And is the "Lisa assumes" driven by an operating system rather than some hardware logic? I tend to lean to the former since the facilitates activity despite not being connected.

It is the software that makes the determination... for use with ProFiles, if OCD is not low, the ProFile driver determines there is no ProFile, and so does not wait ~2 minutes for it to come ready*.

However, logically it is just a connection to a 6522 VIA pin, it is up to the driver/software to determine what it means. From the source on your github project, it seems clear to me that the Corvus driver uses the pin that Apple calls OCD as the DIRC signal. ie. it no longer means OCD.

*A consequence is that if you have a ProFile connected but not turned on, there is a long delay while the ProFile driver waits for the (turned off) ProFile to respond. One can re-wire the OCD pin on the ProFile's controller board with a transistor that pulls the OCD signal low only when the ProFile is powered up, so when connected but off it does not induce the long delay. The X/ProFile has unpopulated pads for implementing this behaviour too.

[sigma7]

It will be difficult to test against the built-in port without installing the root OS to something off the parallel port. I can try it, though.

Can you boot it up, then hot-disconnect the OS drive and hot-connect the Corvus, or is the software you need to access it not loaded in RAM?

[sigma7]

This looks like it could be the source of the error message...

Line 321

Code: [Select]

if (status = addr->d_ira) {
err:
printf("%s error: /dev/c%d%c blkno=%d\n",
bp->b_flags&B_READ?"read":"write", punit,
'a'+logical(bp->b_dev), bp->b_blkno);
cvlog(status);

If you can find where cvlog is sending it, hopefully the "status" obtained from the drive after the read request will provide a clue.

[sigma7]

RESET<->RESET

Perhaps try disconnecting RESET in case it isn't what it seems.

[jamesdenton]

RESET<->RESET

Perhaps try disconnecting RESET in case it isn't what it seems.

Disconnecting RESET results in no behavior at all. Attempting to mount the disk just hangs with no activity of lights and no read errors. According to the respective manuals, both the Corvus and the Lisa expect the drive this line.

[sigma7]

http://www.bitsavers.org/pdf/corvus/

I see now that there are quite a few documents there with schematics. Do you know if any directly apply to your Corvus unit, or can you provide specifics as to what model it is?

[jamesdenton]

http://www.bitsavers.org/pdf/corvus/

I see now that there are quite a few documents there with schematics. Do you know if any directly apply to your Corvus unit, or can you provide specifics as to what model it is?

It's the Corvus Hard Disk, Rev B/H (specifically H, IIRC). Some additional tech specs here:

https://bitsavers.org/pdf/corvus/7100-05945_General_Technical_Information_Mass_Storage_Oct84.pdf

Serial: 183-CH5581-M

(183) 18th week of 1983
(CH) 20MB H-Series
(5581) 5581st made
(M) Internal Mirror Card

[jamesdenton]

Ok, I've got the Saleae on there and here's what I'm seeing as the default state:

RESET - HI
READY - HI
STROBE - HI
DIRC - LO

When attempting to create the filesystem, here's what we see:



Here's an example of a working(?) handshake:



Will continue to play around.

[sigma7]

When attempting to create the filesystem, here's what we see:
(reset pulses low twice)

This doesn't make sense to me... if RESET going low is the first thing to happen, then the Lisa must be driving it.

a) To drive RESET low, PB7 must be set low. I don't see this in the bits of code I found.
and
b) According to the Corvus schematics I've looked at (maybe not the one that is applicable to your device), RESET is an output. If that's the case for your device, then the Lisa wouldn't be trying to drive RESET low.

So, I'm guessing some options are: some important code is hidden somewhere else, or I didn't find the appropriate schematic, or there is a wiring error, or I'm missing something obvious, etc.

[sigma7]

an example of a working(?) handshake

I think you need to connect the data bus, so when the bus direction turns around and the Lisa reads the status byte from the Corvus, you can see what code it is returning.

[jamesdenton]

an example of a working(?) handshake

I think you need to connect the data bus, so when the bus direction turns around and the Lisa reads the status byte from the Corvus, you can see what code it is returning.

I will work on refactoring my adapter to make it easier to debug. My logic analyzer only has 8 channels, so this might take a few attempts.

(reset pulses low twice)

I am wondering if RESET on the Corvus should not be tied to RESET on the Lisa, but perhaps something else? There's an adapter here https://bitsavers.trailing-edge.com/pdf/corvus/flat_cable_interfaces/mnaberez_flat_cable_experiments/pictures/ showing RESET wired up to one of the IDC16 connectors, and a reference to it at https://github.com/mnaberez/corvus/blob/main/corvus/client.py#L15. Maybe the Lisa is driving it LO and I just need to wire it HI to avoid an unintentional reset?