CMD HD drive replacement

[dr.v]

I had the good fortune of acquiring a working cmd hd unit.  I need to replace the drive.  Does the cmd hd unit use a standard 50 pin SCSI 1 type drive?  I am aware of the 4 gig (254 partition * 65K blocks) limit for total system capacity.  While I have never used a cmd hd before, I have been using a ramlink for about 5 moths now (a wonderful little device) and I have read through the cmd hd users manual in the past.  All I need now is a parallel cable.  I found this drive on ebay.  Do you guys think this drive would do the trick?

http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=360236141659&ssPageName=STRK:MEWAX:IT

Thanks for your time.

Tom

[wte]

The connector is ok, but for a used (old) drive it is much to expensive.

Don't forget that you need the newes HD-ROM v. 2.80 if you want to use max size native partitions and a 4 Gig HD.

I'm working on an other solution (ok, much more expensive ). I've bought a SCSI/IDE adapter (not really cheap) and an IDE/SD adapter (a little bit cheaper than the other adapter). Now I only have to cut a little slit on the back of the unit. Hopefully I'll get next week my HD-ROM v 2.80 and than all data will be stored on SD cards. Backup images can be made on a PC. No risk of total data loss. Wonderful!

Regards WTE

[dr.v]

Making backup images to a PC certainly is useful.  Thanks for the information.  When you say "HD-Rom v2.80" I'm not entirely clear about what you mean.  Do you mean HDOS?  I have a few versions on various CMD utility disks.  I think the latest version I have is v1.92.  Does this version not support upto 254 partitions (each of which can be upto 65K blocks - or 16 mb - if they are native partitions) across a single 4 gig drive? 

[RobertB]

...for a used (old) drive it is much too expensive.

Yeah, a few years ago a -4gig SCSI mech was going for $29.95; now the going price is $49.95.

I'm working on an other solution (ok, much more expensive ). I've bought a SCSI/IDE adapter...

You have to be careful... not all SCSI-to-IDE adapters work with the CMD hard drive board.

Truly,
Robert Bernardo
Fresno Commodore User Group
http://videocam.net.au/fcug
The Other Group of Amigoids
http://www.calweb.com/~rabel1/
Southern California Commodore & Amiga Network
http://www.sccaners.org

[RobertB]

When you say "HD-Rom v2.80" I'm not entirely clear about what you mean.  Do you mean HDOS?  I have a few versions on various CMD utility disks.  I think the latest version I have is v1.92.

The two important chips on the CMD hard drive are the ones called the HD ROM and the HD DOS.  The latest HD ROM v2.80 lets you access up to 4 gigs on a SCSI drive.  The latest DOS is v1.92, and that contains all the operating system software.

Does this version not support upto 254 partitions (each of which can be up to 65K blocks - or 16 mb - if they are native partitions) across a single 4 gig drive?

IIRC, without HD ROM v2.80 (i.e., if you are using an earlier version), you'd only be able to access up to 2 gigs (or less if the version is really old).

Truly,
Robert Bernardo
Fresno Commodore User Group
http://videocam.net.au/fcug
The Other Group of Amigoids
http://www.calweb.com/~rabel1/
Southern California Commodore & Amiga Network
http://www.sccaners.org

[dr.v]

Thanks, Robert.  My unit is en route.  It is coming from an old friend.  Unfortunately I can't verify the version of the HD ROM chip yet.  I know he purchased it from CMD in 92.  So I have a few questions.

You referred to HD DOS as a chip.  I know the HD DOS can be updated simply by using REWRITE DOS.  Does this update firmware on a physical chip on the drive controller?

If an earler version of the HD ROM is present, can a drive of 4 gb be used and the controller will only "see" 2 gb or will a drive with physical capacity of more than 2 gb cause a problem?  For instance, during a low level format.

How does one go about obtaining HD ROM v2.80?  Unfortunately I don't have an EPROM burner.

[wte]

HD DOS ist not on a chip. It's pure soft.

As far as I know the older HD ROMs will only see 2 GIG but works with bigger drives (but I didn't test this).

To use big native partitions with an older HD ROM you have to take the maximumsize-1 as limit (there is a bug in the older ROM soft that gives some problems if the full size is used).

There are ROM images available in the internet. Maybe someone can burn it for you (I can't)

Regards WTE

[dr.v]

wte - thank you for mentioning the bug in early versions of hd rom.  That is really good to know.  When you say (maxsize-1) you mean 1 less "256 block" multiple than the max allowable size of 65K blocks?

I will find the v2.80 rom.  I may even have the image on one of those eeprom image disks I have.  Until then - even 2 gigs might as well be an infinite amount of storage space for my needs.   

[RobertB]

HD DOS ist not on a chip. It's pure soft.

Heh, I must be misrembering (I should open up my CMD hard drive and look again).

Dr. V wrote:

I know the HD DOS can be updated simply by using REWRITE DOS.

Yes, that is what you do.  I've upgraded the DOS on my drives by using that program.

Truly,
Robert Bernardo
Fresno Commodore User Group
http://videocam.net.au/fcug
The Other Group of Amigoids
http://www.calweb.com/~rabel1/
Southern California Commodore & Amiga Network
http://www.sccaners.org

[RobertB]

How does one go about obtaining HD ROM v2.80?

Perhaps FCUG member and C128 Alive! forum member Andrew Wiskow can do it for you.  He is very knowledgeable in burning chips.  I also have another contact, if Andrew does not come through for you.

Truly,
Robert Bernardo
Fresno Commodore User Group
http://videocam.net.au/fcug
The Other Group of Amigoids
http://www.calweb.com/~rabel1/
Southern California Commodore & Amiga Network
http://www.sccaners.org

[brain]

I can also burn a new CMD HD ROM if needed.

Jim

[wte]

Do you have any scources of the HD DOS? It would be fine to implement some code to softswitch the SCSI-ID with an utility command ...

regards WTE

[dr.v]

Jim - thanks for the offer.  I may get back to you on that one.  The unit should be arriving in the next couple of days and then I can say with certainty what HD boot rom it contains.  Just for the record, I'm not simply fixing up this unit to turn around and sell it.  I have wanted one of these for units for a long time.  This SCSI controller is a long awaited addition to my c128 development system. 

Tom     

[dr.v]

The unit arrived a couple of days ago.  Along with a 4 gig seagate ST34371N scsi drive I picked up.

http://stason.org/TULARC/pc/hard-drives-hdd/seagate/ST34371N-BARRACUDA4L-4350MB-3-5-SL-SCSI3-ULTR.html

The unit has boot room v2.52.  It had an old (dead) rodime mechanism, but the controller card is in fantastic condition.  I removed the rodime and put in the seagate drive.  At first the drive motor wouldn't power up.  I read the tech manual (above link) and realized a jumper needed to be set to indicate the drive was last in the drive chain.  Power to the drive motor fixed.  LLFORMAT does a fine job of formatting the drive.  Takes about 2 hours and reports no bad blocks and a successful format.

The trouble starts with CREATE SYS.  When I run CREATE SYS it reports just over 8.3 million blocks (2 gig) and 4x10^9 bytes (of course, 4 gigs).  You guys warned me of this disparity.  The boot rom is obviously only allowing the controller card to see 2 gigs on a single drive.  Then it begins the process of writing the device table.  Both activity lights come on for a while then towards the end of the write device table process, the drive error light comes on.  The CREATE SYS then tries to begin the write partition table phase, and the drive just sits there (with the error light off).  I can't get CREATE SYS to work on the drive.

My guess is that either (1) I need to put in boot rom v2.8 or (2) use a drive with physical storage capacity <= 2gig.  Any other thoughts on this?  Thanks.

Tom

[RobertB]

My guess is that either (1) I need to put in boot rom v2.8 or (2) use a drive with physical storage capacity <= 2gig.  Any other thoughts on this?

Yes, Tom, your conclusions are correct.  The best thing to do is put in the latest boot rom.

Truly,
Robert Bernardo
Fresno Commodore User Group
http://videocam.net.au/fcug
The Other Group of Amigoids
http://www.calweb.com/~rabel1/
Southern California Commodore & Amiga Network
http://www.sccaners.org

[Pinacolada]

Two questions:

1) What is the filename that CMD HD's look for in order to be able to autoboot? I thought it was "copyright 89 cmd" -- I'm running a BBS and it'd be nice to have it autoboot if the power ever went out.

I tried renaming the BBS boot file to that, making sure the autoboot file was in the default power-on partition. No joy. Do I need an autoboot sector maker like on the C128 1571 drive? I don't see anything like that on the CMD HD Utilities disk I have.

2) Is there some SCSI command which can spin down the HD mechanism after some period of I/O inactivity? I saw the thread on changing the write-protect switch to do an immediate spin down, but I haven't assembled it yet.

http://codebase64.org/doku.php?id=base:hd-park-switch_-_how_to_patch_a_cmd-hd_to_your_own_needs

[dr.v]

I think I can help with your first question.  You need a 128, the cmd hd must be configured as device 8, and yes, you need an autoboot sector maker.  All native mode partitions automatically allocate track 1 sector 0 (in fact, I think this is true of emulation partitions also).  So you can create a boot sector in any of your partitions.  "Auto-boot 128" is a PD utility supplied with the cmd hd utils disk.  Just use @CP into the partition you want to autoboot, run the above program, and tell it you want it on device 0.

If I'm not mistaken that "copyright 89 cmd" thing you are referring to would allow you to load a program into the DRIVE memory and immediately execute it.

Hope this helps.

Tom

[dr.v]

Hi guys.  Turns out, I have another question on this topic.  I got the bootrom v2.80.  As promised, it allows me to see a full 4gigs on a single drive.  But I'm having some problems.  To begin, some of my earlier difficulties stemmed simply from jumper settings on the drive mechanism.  The seagate barracuda mechanism I'm using requires both a "terminator enable" and a "terminator power from drive" jumper to be set.  (And I only had 1 jumper so I had to quest for another jumper that fit... but that's another story).  I'm pretty certain the jumpers are now set correctly.  I have read the extensive documentation I found for this drive.

So I can get CREATE SYS to run on the drive with no problem.  I can load up HD TOOLS and make partitions.  The partition table looks to be as it should.  It's recognizing the default device number and partition number, etc.  BUT when not in "install" or "configuration" mode, the drive just locks up my bus.  That is to say - I can create sys and partitions because the drive is put into one of the aforemtnioned modes.  But if the drive is powered up it will go through it's boot sequence (NOT throw an error) and sit there with the power light on while taking complete control of the serial bus.  If I reset the drive - it loads HD DOS and then sits there holding my bus hostage.

I get the same results with bootrom v2.52 and v2.80.  So it's not the bootrom chip.  I have tried connecting the HD directly to the 128 (i.e., no other drives on the bus) and I get the same result.  I have a Ramlink, and I have tried all of this with it both enabled and disabled.  I have ensured all of the chips on the controller card are seated correctly. 

I'm about out of ideas.  Any thoughts?  FWIW - when the HD takes control of my bus the "swap 8", "swap 9" and "write protect" don't seem to activate when pressed.  But again, I can put the drive in it's "special modes".  I'm hoping the answer isn't a bum controller.  It seems to work in all other respects.

This particular drive mechanism requires 1 of 3 possible power modes be set via jumper.  The options are "Term power from drive", "Term power to SCSI bus", and "Term power from SCSI bus".  The default setting for the mechanism is "term power from drive".  I didn't want to randomly experiment with the power settings out of fear of possibly damaging the mechanism or controller.  Is it possible the controller requires one of these other two settings?  I know very little about SCSI drives.

Thanks.

Tom   

[RobertB]

To begin, some of my earlier difficulties stemmed simply from jumper settings on the drive mechanism.  The seagate barracuda mechanism I'm using requires both a "terminator enable" and a "terminator power from drive" jumper to be set.  (And I only had 1 jumper so I had to quest for another jumper that fit... but that's another story).  I'm pretty certain the jumpers are now set correctly.  I have read the extensive documentation I found for this drive.

(snip)

BUT when not in "install" or "configuration" mode, the drive just locks up my bus.  That is to say - I can create sys and partitions because the drive is put into one of the aforemtnioned modes.  But if the drive is powered up it will go through it's boot sequence (NOT throw an error) and sit there with the power light on while taking complete control of the serial bus.  If I reset the drive - it loads HD DOS and then sits there holding my bus hostage.

(snip)

Any thoughts?  FWIW - when the HD takes control of my bus the "swap 8", "swap 9" and "write protect" don't seem to activate when pressed.  But again, I can put the drive in it's "special modes".  I'm hoping the answer isn't a bum controller.  It seems to work in all other respects.

I say it's the drive mech.  FWIW, the non-modified CMD hard drives I've examined are Apple/Quantum mechs.

This particular drive mechanism requires 1 of 3 possible power modes be set via jumper.  The options are "Term power from drive", "Term power to SCSI bus", and "Term power from SCSI bus".  The default setting for the mechanism is "term power from drive".

Very strange.  The Apple/Quantum mechs mentioned above don't have those jumpers (or at least, they aren't visible).

I didn't want to randomly experiment with the power settings out of fear of possibly damaging the mechanism or controller.  Is it possible the controller requires one of these other two settings?  I know very little about SCSI drives.

Possibly.  I will PM you the address of the TOGA technician who works on our SCSI drives (albeit for Amiga computers).  Perhaps he can figure it out.

Truly,
Robert Bernardo
Fresno Commodore User Group
http://videocam.net.au/fcug
The Other Group of Amigoids
http://www.calweb.com/~rabel1/
Southern California Commodore & Amiga Network
http://www.sccaners.org

[dr.v]

Thanks, Robert.  I contacted him.  I have a strong suspicion that you are correct about it being the mechanism.  I tried the other power configurations on the mechanism - and the drive will only spin up if I have it set to the default config.  The controller seems to be functioning just fine.  In the meantime I will keep my eyes peeled for a more appropriate mechanism.

[BigDumbDinosaur]

A couple of comments.  First the disclaimer: I have never used or otherwise worked on any CMD product.  My experience is with the Lt. Kernal, which also used SCSI drives.  My company also builds high-end workstations and servers, all of which are equipped with SCSI hardware.

   
• Almost all SCSI-1 and all SCSI-2 "narrow" (8 bit) embedded controller mechanisms have a "remote start feature," which is enabled with a jumper on the embedded controller.  When enabled, the drive will not spin up and go ready unless the host adapter tells it to.  As far as I know, CMD's boot PROM does not send a SCSI "start unit" command to the mechanism and instead polls the mechanism until it reports that it is ready.  Remote start must be disabledâ€"the mechanism must be configured so it spins up when power is applied.

   
• By default, SCSI drives are shipped from the factory with parity enabled.  There's a good possibility that the CMD circuitry does not use SCSI parity, in which case be sure to disable parity on the mechanism's embedded controller.

   
• I seem to recall that CMD at one time had a bug in which sometimes the firmware in the drive would not give the mechanism enough time to come on-line after power-on and would fail to boot.  Many of these older Barracuda mechanisms took a while to spin up, execute controller diagnostics, re-calibrate and then respond to a "test unit ready" SCSI command.  Make sure you have the most recent firmware to avoid this issue.

   
• All SCSI buses require termination at both endsâ€"never in the middle.  The Barracuda mechanism has a jumper to enable on-board termination.  This is not the same as providing termination power.  I don't know if the CMD host adapter applies term power to the busâ€"check the documentation.  The Barracuda can be made to get its term power from the bus, apply term power to the bus or internally power its terminators.  Do not have the drive apply term power to the bus if the host adapter does.

   
• Carefully examine the condition of the internal SCSI cable.  The bus operates at a very high speed and errors can occur if cables are faulty or the aforementioned termination is not correctly configured.

[RobertB]

A very good analysis of the Barracuda drive mech in relation to the CMD hard drive controller!

Truly,
Robert Bernardo
Fresno Commodore User Group
http://videocam.net.au/fcug
The Other Group of Amigoids
http://www.calweb.com/~rabel1/
Southern California Commodore & Amiga Network
http://www.sccaners.org

[dr.v]

Thanks, BDD.  That is a very useful piece of analysis you have offered.  One of the problems I am having is finding the information regarding whether or not the CMD controller requires parity enabled or disabled and whether or not the controller supplies term power to the bus.  Not for lack of reading the documentation, mind you.  The docs I have read, (such as the CMD HD manaul) don't seem to cover this material.  I am playing the trial and error game right now.  I have another SCSI mech en route - hopefully I will have an easier time with this mechanism.

The drive seems to spin up ONLY if I have it set to "term power from drive".  But then it takes control of by bus.  I will keep you guys posted on my progress.  I appreciate all of your comments and contributions to my trouble shooting.  People like you guys make it possible for people like me to enjoy and pursue my C= passion.  Thanks!

Tom

[BigDumbDinosaur]

One of the problems I am having is finding the information regarding whether or not the CMD controller requires parity enabled or disabled and whether or not the controller supplies term power to the bus.

I'd be surprised if it does use parity.  In the time-frame when products like the CMD and Lt. Kernal products were being developed, parity was not widely used, even in more mainstream applications (e.g., minicomputers, the first applications of SASI/SCSI).  Although parity was part of the formal ANSI SCSI specification of 1986 (which was essentially SASI with a different name), it was considered an optional feature and was often ignored.  Nowadays, usage of parity is universal.

As the Barracuda N-series drives are 100 percent electrically compatible with the Lt. Kernal, they should also work with the CMD circuitry.  All bets are off if you use a drive with a wide or LVD interface (W or LW series, respectively).  You should go to Seagate's site and see if you can find the product summary by searching on the ST model number.  That should link you to a page with the jumper settings, etc.  Some of that info is also on the sticker attached to the drive's cover.

The drive seems to spin up ONLY if I have it set to "term power from drive".  But then it takes control of by bus.

How do you know that the drive is taking control of the bus?

[dr.v]

Just thought I would offer to bring some closure to this thread.  I got it to work!

BDD - I greatly appreciate all the time you gave me in offering up your insight into SCSI drives in general, mine specifically, and in the context of the Lt. Kernal drive.  Try as I did to get that barracuda drive to work it wouldn't budge.

I finally got a hold of a quantum fireball SCSI mechanism.  (Thanks for the tip on this one, Robert!)  I have to say - when using a mechanism the controller card likes, it is a hell of a lot easier 

Tom