General Category > LisaList2
Corvus HDDs and the Lisa
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: --- 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;
}
--- End code ---
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:
--- Quote from: sigma7 on March 17, 2025, 05:50:41 pm ---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.
--- End quote ---
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.
--- Quote from: sigma7 on March 17, 2025, 05:50:41 pm ---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
--- End quote ---
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:
--- Quote from: jamesdenton on March 17, 2025, 06:29:47 pm ---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.
--- End quote ---
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:
--- Quote from: jamesdenton on March 17, 2025, 06:29:47 pm ---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.
--- End quote ---
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?
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version