Print

[compu_85]

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

[rayarachelian]

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.

[compu_85]

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

[stepleton]

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?

[compu_85]

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.

[stepleton]

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.

[rayarachelian]

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

[rayarachelian]

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

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.

[blusnowkitty]

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.

[compu_85]

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.

[compu_85]

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.

[jamesdenton]

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.

[sigma7]

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).

[sigma7]

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

Code: [Select]

/* 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

Code: [Select]

/* 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)

[jamesdenton]

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).