LisaList2
General Category => LisaList2 => Topic started by: compu_85 on February 22, 2021, 08:07:01 am
-
I've seen some tidbits saying that a Corvus hard disk could be connected to the Lisa:
- The Lisa OS Guide: https://lisaem.sunder.net/cgi-bin/bookview2.cgi?zoom=-1?page=4?book=22?Go=Go
- This post from someone using Unisoft back in the day: https://macgui.com/usenet/?group=9&id=914
"...if anyone hears of a RAM disk for the Uniplus System V, I'd love to hear it.
(PS: one of our staff has a Lisa with a Corvus disk. Aside from the fact that the Corvus disk has failed a few times, he loves it.
The problem is strictly with the slowness of the Profile.)"
- These notes from the Lisa Handbook, page 27 https://www.apple.asimov.net/documentation/applelisa/The_AppleLISA_Handbook.pdf
"Any additional drive must always be connect via a parallel card, whether its augmenting a profile drive or a 10-megabyte drive.
Lisa now supports a 70-megabyte drive manufactured by Priam and distributed by Tecmar.
UNIX and XENIX users have the option of attaching drives from Corvus and Sunol in sizes from 20 to 100 megabytes. "
- References in the Uniplus (and I think Xenix?) manuals for the procedure to create the device file for a Corvus and format the disk
So here's the question... how was the Corvus disk attached? It also used an 8 bit parallel interface, but looking the the pinouts it seems quite different from the ProFile.
CHM has a prototype Lisa with a Pippin (Profile) / Corvus card: https://www.computerhistory.org/collections/catalog/102719928
Al has some pictures of the card here (which looks quite similar to the 1 port Parallel card I got last year..):
http://www.bitsavers.org/pdf/apple/lisa/pcb_pictures/Pippin_Corvus_F.jpg
http://www.bitsavers.org/pdf/apple/lisa/pcb_pictures/Pippin_Corvus_B.jpg
Does anyone have more info on this? A friend has some Corvus drives and I'd love to give this a try.
Thanks,
-Jason
-
Every LOS 3.x has a Priam specific driver on it, just like it has one for the profile. Actually there's two files, one is for the running OS, and another is for booting. (There is a third driver for the parallel port itself when used with ProFiles/Widgets.) I don't yet know enough about why a different driver is needed during booting, perhaps it's invoked by the loader blocks (BB,BB).
UniPlus has drivers in the kernel for these as well, and there is source for the kernel (and these drivers). The schematics and drive manuals are up on bitsavers for this drive. These are a totally different protocol than the ProFiles.
I know there were several drives compatible with the ProFile protocol, SunRem made a controller also that accepted an MFM/RLL drive. It's possible Corvus had an interface to this or a model that supported this protocol. Perhaps it needed a driver (or not.)
OSCONFIG is a clue for me, thanks for finding that. I did see differences in BLU widget dumps from profile dumps in SYSTEM.CONFIG - the clue there is the boot device failure and moving from say motherboard parallel port to expansion slot parallel port, or profile to widget, etc. I'll have to figure out more info about OSCONFIG and perhaps how to replace it when moving data from a Widget to a ProFile.
-
The Priam drive had its own dedicated controller card.
I've not seen mention of a specific Sunol / Corvus card, which makes me think they were hooked up to a standard system somehow.
I'd love to have a DataTower... but I think they are very very rare at this point.
-J
-
Here are pictures of a "Corvus/Pippin" card on Bitsavers:
http://bitsavers.org/pdf/apple/lisa/pcb_pictures/Pippin_Corvus_F.jpg
http://bitsavers.org/pdf/apple/lisa/pcb_pictures/Pippin_Corvus_B.jpg
I'm pretty sure that Pippin was the codename for ProFile, based on some of the docs surrounding the Monitor. Now, this card is obviously a prototype, but it's interesting that both the Corvus and the Pippin ports have 34 lines. If Pippin was ProFile at some point, this card must have talked to an earlier version of it!
The board is simple enough that you might be able to guess a schematic --- you can't see where the lines go when they go under the chips and resistor packs, but you might be able to figure it out. One bit of good news is that the chips are just a VIA and some glue logic; there aren't any ROMs or anything.
How many pins do the cables for your friend's Corvus drives use?
-
To Bitsavers again :) http://www.bitsavers.org/pdf/corvus/7100-03289_DiskSysTechRef.pdf
See PDF page 7 (1 in the document). The signal that I didn't spot on the ProFile interface was bus direction.
The Corvus disk has a pin header on the back, the same type as the proto board you linked to. If it is usable with a standard parallel card it wouldn't be a hard job to wire up to a DB25.
I've also seen that the dev name for the ProFile was Pippin.
-
Great find! There seem to be lots of close analogues between these pins and what the ProFile uses, and so using a Corvus drive from a Lisa parallel port seems tractable to me.
* DIRC: seems like ProFile PR/~W, but the drive sets it
* READY: seems a lot like ~PBSY
* STROBE: seems like a combination of ~PSTRB and ~PCMD
I don't see a parity line like the ProFile uses, and one thing I might be curious to find out later is why the drive is the one that controls ~RESET, not the computer (cf. ~PRESET on the ProFile).
Either way, at a glance it looks like you could probably bash together some software to repurpose my device into "Cameo/Cepheid" I guess (Corvus Parallel Hard Drive, compare Apple Parallel Hard Drive) without very much trouble.
-
Here's the corvus driver for uniplus, it does look like it attaches to the parallel port, there's references to CA2, port a, port b, and it even includes profile structures.
https://github.com/arcanebyte/uniplus/blob/master/v1.5/sys/cv.c
-
So there seem to be a couple of these on ebay, here's a 20MB one: https://www.ebay.com/itm/VINTAGE-CORVUS-SYSTEMS-20-Mb-HARD-DRIVE/332876241872 (https://www.ebay.com/itm/VINTAGE-CORVUS-SYSTEMS-20-Mb-HARD-DRIVE/332876241872)
Both seem to have a VCR interface with a remote, presumably for backups? As well as a connection to a processor and another drive. Not sure if they could be chained together or if they were used on some kind of LAN server.
Not sure if these are the same ones for the Lisa.
(https://i.ebayimg.com/images/g/YC0AAOSwXVNbX4HC/s-l1600.jpg)
-
http://www.bitsavers.org/pdf/corvus/service/
So it looks like those particular drives also came in a 6MB variant too. The manuals seem to imply that the video ports could be used to get into some kind of low-level OS with the drive, but their primary purpose (and the VCR REMOTE port) was indeed for making a tape backup of your hard drive (to VHS, Beta, and Technicolour 212!) with the Corvus Mirror. Neat! It seems these things were used a lot with the Atari 800 from a little bit of quick research.
-
Yup, they back up to video tape.
They also had a system where you could network the drive and share it among several Apple II's.
Processor goes to the computer, drive is for hooking up a 2nd disk I believe. There are switches hidden under the front panel for setting up / formatting the drive.
-
From the UniPlus+ "Lisa Specific" notes, page 5: http://bitsavers.org/pdf/unisoft/UniPlus-Lisa-specific.pdf
So yes, it can hook up to any Lisa parallel port.
-
Time to revive an old thread.
I've got a 20MB Corvus hard drive that I've connected to the Lisa on the bottom port of a parallel card in Slot 1.
To Uniplus, this is /dev/c1a with the following attributes:
brw-rw-rw- 1 root root 2, 16 Jan 4 08:41 /dev/c1a
This existed already, but can be recreated using mknod and would result in the same.
I've created an adapter to adapt the IDC34 connector to DB25, and made the following connections:
PROFILE<->CORVUS
D0<->D0
D1<->D1
D2<->D2
D3<->D3
D4<->D4
D5<->D5
D6<->D6
D7<->D7
STROBE<->STROBE
BSY<->READY
RESET<->RESET
RW<->DIRC
So far, so good. Now, when attempting to straight up mount /dev/c1a using mount /dev/c1a /t the Corvus comes to life, and the FAULT lite is solid while the BUSY light blinks. The console reports the following every 3 seconds or so:
read error: /dev/c1a blkno=1
After roughly 30 seconds that, it reports this every 3 seconds:
read error: /dev/c1a blkno=2
After roughly 30 seconds, activity stops and a console prompt returns.
So, the preferred course of action was probably to create a file system on the disk using mkfs1b as describe in the docs:
mkfs1b /dev/c1a 32420
Where 32420 is the size of the root partition (max for a 20MB disk).
mkfs1b /dev/c1a 32420
bytes per logical block = 512
total logical blocks = 32420
total inodes = 8104
gap (physical blocks) = 7
cylinder size (physical blocks) = 400
It's at this point that nothing happens - the console is effectively locked up and I'm unable to stop the process. It will sit here for hours. There is no activity or trace of activity on the drive itself. This behavior is different than what is seen with, say, a ProFile connected to /dev/c2a - the mkfs1b operation takes less than 5-10 seconds. I CAN trigger an NMI by pushing the interrupt switch on the back, so the kernel is still responsive.
I don't have a scope handy, but when I have some extra time might try to put the Saleae on there to see if anything interesting can be found.
-
read error: /dev/c1a blkno=1
This terminology makes me think more of a communication problem rather than a no file system problem.
To test this theory, you could intentionally miswire the connection (eg. disconnect strobe) and see if you get the same or a different error.
I'd also check the source of the DIRC signal; if it is indeed driven by the Corvus, then it needs to be connected to a different pin than RW (which is driven by the Lisa and not reversible).
-
I'd also check the source of the DIRC signal; if it is indeed driven by the Corvus, then it needs to be connected to a different pin than RW (which is driven by the Lisa and not reversible).
Line 453 of https://github.com/arcanebyte/uniplus/blob/master/v1.5/sys/cv.c shows the direction line (aka Host To Controller I guess) is masked with ST_HTOC
/* wait for controller to host direction or timeout */ /*
cvctoh(a)
register struct device_d *a;
{
register i;
for (i = 20; i-- > 0;);
i = 100000;
do
while (--i > 0 && ((a->d_irb&ST_BUSY) == 0));
while (i > 0 && (a->d_irb & ST_HTOC));
if (i <= 0) {
printf("cvctoh: timeout\n");
return -1;
}
return 0;
}
Line 19 of https://github.com/arcanebyte/uniplus/blob/master/v1.5/include/sys/cv.h gives ST_HTOC as 1
/* cv_stat bits */
#define ST_BUSY 0x02
#define ST_HTOC 0x01 /* host to controller direction */
And looking at the dual parallel card schematic, the 6522 PB1 (which would be masked with 2) goes to BUSY as expected, and PB0 which is masked with 1 goes to OCD.
Hence I think DIRC needs to be connected to OCD (DB-25 Pin 19) rather than RW (DB-25 Pin 3)
-
To test this theory, you could intentionally miswire the connection (eg. disconnect strobe) and see if you get the same or a different error.
I'd also check the source of the DIRC signal; if it is indeed driven by the Corvus, then it needs to be connected to a different pin than RW (which is driven by the Lisa and not reversible).
First, I moved DIRC to OCD from RW. No change in behavior for mount or mkfs1b. Still get read errors with some activity on the corvus (busy lights). Perpetual hang with mkfs1b and no activity on the drive.
Then, I removed STROBE. No change in behavior - still get read errors with some activity on the corvus (busy lights).
-
The guide mentions the following:
http://www.bitsavers.org/pdf/corvus/7100-03289_DiskSysTechRef.pdf (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 (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.
-
In the initialization section of https://github.com/arcanebyte/uniplus/blob/master/v1.5/sys/cv.c
lines 119-131:
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.
-
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 (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.
-
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.
-
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?
-
This looks like it could be the source of the error message...
Line 321
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.
-
RESET<->RESET
Perhaps try disconnecting RESET in case it isn't what it seems.
-
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.
-
http://www.bitsavers.org/pdf/corvus/ (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?
-
http://www.bitsavers.org/pdf/corvus/ (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
-
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:
(https://i.postimg.cc/qM8gC5FV/Screenshot-2025-03-24-at-3-40-47-PM.png)
Here's an example of a working(?) handshake:
(https://bitsavers.trailing-edge.com/pdf/corvus/flat_cable_interfaces/mnaberez_flat_cable_experiments/pictures/handshaking_14297561969_o.png)
Will continue to play around.
-
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.
-
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.
-
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/ (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 (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?