• Please review our updated Terms and Rules here

2nd 8 inch drive

Well, I've been making progress, but at a snails pace. I finally got two drives that will work alone with my 8080. They will both load and run CP/M. I also got them to kinda work together. I set the Shugart as A and the Siemens as B and the Shugart will load and run CP/M and do all the functions. Yet when I do a DIR B: I get a bad sector error. Then a ctrl c will re boot and A will run CP/M again. So, I switched the drives so that the Shugart was B and the Siemens is A. Same problem, the Siemens will load and run CP/M do all the functions, but if a DIR B: is requested I get a bad sector on B: error. I have the CPM disk in A and a formatted blank disk in B. So I think I'm back to having a bug in my CBIOS. When the command DIR B: is requested, first the A: drive has to find the DIR software on drive A then access directory on drive B I can see from the activity lights that A is accessed first and then B, then immediately after the error comes up. There must be a problem with the drive number being issued, yet the B drive is selected. Could the B drive get the bad sector error from being on the wrong track? Here I'm getting a little fuzzy, For the command A>DIR B:, the current drive is A and stays that way. Yet the DIR command has to call the CBIOS to read the B drive directory, which is a different drive, track and sector number. If I would put a short routine in my READ routine of the CBIOS I should see Drive=0, Track=something and Sector=something for the DIR command then after that read or reads (if more than one sector). Then for the B directory Drive=1, Track=something else and Sector=something else. Is this correct? It just came to me that the DIR command is a resident command, does the A drive need to be accessed at all? It's coming but slow. Mike
 
No, with a DIR on B:, A: should not be accessed. You should get an access to A: if you hit Ctrl-C, which forces a warm boot. The 765 maintains the position of each of 4 drives internally; however, you have to make sure that all drives after initialization are at cylinder 0 (issue a recalibrate to all drives).

In addition, your retry (I hope you have a retry routine because CP/M doesn't) should do a restore, seek and then repeat the operation.
 
During my initialization, a recalibrate of both drives is done, just after the SPECIFY and before the cold load. So I was right that the DIR command is a resident command and A drive access should not be needed. Something isn't right here. As I said before, right after I press the enter key on A> DIR B: the A drive is selected for a bunch of reads, (I wonder if a read of the A: directory is being done?) then the B drive is selected for a short time, then the bad sector error appears. I have to re check my blank disk to be sure that there are no sector errors, but I pretty sure there are none.

RETRY, no I don't have anything like that in my code. After a SEEK, READ or WRITE, I check for a couple different errors and set an error code for CP/M and then return. It should be a simple matter to add a routine, as you suggest to RESTORE, SEEK and repeat that last command. Thanks Mike.
 
Well, I found that I had a slight bug in my initialization recalibrate routine. For some reason the B: drive would not recalibrate. I wasn't watching it closely enough to notice that it was not working. After this repair, the A>DIR B: will not access A: first. It will only try B:. BUT, I still have the sector error. This is another matter. The Shugart for some reason is not seeking properly again. This is the second time it failed like this. I'm going to lengthen the step rate in the SPECIFY. I wonder if I'm stepping it too fast. Thanks Mike
 
Well, my Shugart drive still has trouble seeking properly. It will sometimes step and then not. I had thought that the trouble is similar to the last time, but that's not so. This time the trouble seems to be in the 3 state counter. But, I'm having difficulty trouble shooting this feedback or sequential circuit. I believe that there are three stable states for this circuit and each step pulse should step through these states. I have included a diagram of the circuit. The XOR's are just controllable inverters. When the direction is one way the XOR's will invert and when the direction is the other the XOR's will not invert.

View attachment DriveLogic.pdf

When the direction is set so that the XOR's will not invert the inputs to the D latches, the 7474's are

Da = NOT(Qa + Qb) Da being the top latch
Db = Qa + NOT(Qb)

I made a bounce less switch to pulse STEP and hardwired the DS and Direction pins so that a STEP would step the drive. I had thought that I could just watch Da and Db as I stepped, but with the drive failure what I see makes no sense.

I checked my step pulse for multi pulse and there is only one good clean pulse. I checked the XOR's for invert and not invert on direction and that seems good, it always follows what as I expect. I made sure that the set/reset pins on the latches are always high. I expected that Da and Db would show a low for two step pulses and a high for one. I get some changes, but nothing like I expect. Is there anything that I can do short of pulling a chip to detect which chip is bad? I'm thinking that it's either the NOR, the NAND of the D Latch. Mike
 
First, try stepping your drive at the slowest rate, say 15 msec. Often, in these old drives, grease and other gunk pile up and the drive won't step quickly. You should also ensure that the step pulses issued by the FDC are clean at the drive connector.

i.e., first try the simple stuff and don't get carried away too quickly.
 
I'm pretty sure that something is wrong. I can connect the drive up to IMD and 'most' times it will step one step forward or back at a time, but will not step 10 steps at a time. When asked to step from 0 to track 10, it will at most go one step. I set the step rate at 8 ms then lengthened it to 15 ms. IMD will not allow anything longer than 16ms. Funny thing the drive will calibrate to track zero, ok. I'm going to try and look at the Latch inputs while the drive is connected to IMD, maybe I can tell something from that. Mike
 
This is getting a little frustrating. Seems I can not get any repeatable results with the Shugart. There are times when it works and then times when it doesn't. I think I have to look for a bad connection or something like that. I have been exclusively testing the drive on my DOS machine with IMD an 22DISK. I know that my cables, drive power supply, programs and DOS machine are OK. I know that because when I have the Siemens connected, everything works fine. About the only consistent response I get out of the Shugart is the in use light when the drive is selected.

Then to add some more questionable results to the mix, the cushion pad on the head loading arm popped off and went missing. For a while the DOS FDC was reporting 'No Interrupt from FDC'. Well that was due to this pad popping off. I replaced the pad with one from a broken Siemens drive. Seemed to fit. What can I use to repair it? I was thinking some felt, maybe cut with a paper punch and glued to the button? What do you think, do you know of anything better? Mike
 
Make sure that jumpers T3 and T4 are installed on your drive (STEP and DIRECTION pullups).

Dense felt might work--I've always wondered if billiard cue tips might be a better solution--they're hard enough that they won't collect grunge or slow the disk rotation--most are made from phenolic-impregnated linen. They're available in a bewildering number of hardnesses and materials. I think you'd want the flatten the tip just a bit with some sandpaper.

You could also look to your local home-improvement store for some chair-leg felt pads--they're a bit harder than normal soft felt.

Just about all of my drives are DS, so I don't run into this problem.
 
Last edited:
Well..... this is a hard one to figure. When you suggested that I make sure I had T3 and T4 jumpers in place. I thought, geezz, I've had these in place all the time. Yet I toke some time to look and test a little. Turns out that the T4 jumper, the one for STEP was not making contact all the time. This was my intermittent. Having a good jumper improved the performance a lot, but there was still some problems. I found that the step pulses coming into Pin 36 were not going low enough to be a good zero. So I added a little resistance to the pull up on Pin 36 (22 ohms) and this made it all work a bunch good. The Siemens didn't have this problem. The Siemens pull up scheme is a divider, rather than just a pull up resistor. I wonder if my 7438 on the STEP line is not up to snuff. Anyway with this resistor and a good jumper, the drive works consistently.

I got the Siemens drive to quiet down by adjusting R100. This is an offset adjustment for the differential amp. The drive was creating READ pulses from nothing, no disk in and the head not loaded. So, I adjusted R100 while watching the noise pulses on my scope. I found that turning the pot CW reduced the number of noise pulses. So, I turned it a full turn and the noise was gone. BUT, so was the real READ pulses. So I had to turn the pot back some. There is a small area (maybe 1/8 to 1/4 turn on the pot) where the noise is gone and the real READ pulses are strong. So, I connected up both drives to my 8080 machine. The Shugart as A: and the Siemens as B:. Loaded my Cold Start Loader and Miracles of Miracles occurred. CP/M loaded with both drives connected. At the A> a dir command correctly listed all the files on A: AND a DIR B: gave a NO FILES response, which was correct. B: only had a format disk in it. Then I tried a PIP command to copy a file from A: to B: and it worked! Imagine that.

I think I'll try putting the Siemens drives on the end of the cable and use it's pull ups and place the Shugart on the middle connector and remove it's pull up jumpers. Maybe then I will not need the extra 22 ohm resistor.

On another note, I was thinking about the head load pad. What do you think of making a Teflon pad? It's slippery, yet hard. I use some Teflon buttons as pads on floating wrist pins in engines. They keep the wrist pin from rubbing on the cylinder walls. What do you think?
Mike
 
This morning, I switched the drives around and after fiddling with the jumpers and resistors, I got both drives to work without the 22 ohm extra resistor, but I was getting a few Bad Sector errors. I fixed this with an adjustment on R100 on the Siemens drive. I also found that this adjustment is sensitive to the orientation of the drive. When the drive is standing on it's side, I can adjust R100 for proper function, but when the drive is sitting on it's bottom, I need to adjust R100 some more. I suppose the loading on the head is different. So I tried the drive upside down and it doesn't work very well at all. (Still have to add the re-try routine on error).

A curious thing, When I first boot the system and I do a A>STAT command, all I get is information regarding the space on A: drive. Then if I switch to B; (A>B:) then back to A: (B>A:), then a STAT command will list the space available on both drives. Seems at the onset the system is not aware of the second drive. Is that correct? Or is there some thing I need to do something else? Mike
 
I have tested DIR, ED, ERA, PIP, REN, STAT, TYPE and USER. I tried most of the options with each command and they all seem to work. I tried a bunch of cross drive commands and they all worked.

I then tried SYSGEN, but it didn't seem to work. Here's what I and it did.

A>SYSGEN
SYSGEN VER 2.0
SOURCE DRIVE NAME (OR RETURN TO SKIP) then I entered A

The computer did a bunch of accesses to A: then it responded with
A>

Nothing was transferred to B: Did I do something wrong? I wonder if my copy of SYSGEN is good. Mike
 
No, you've got the the drive business correct--STAT doesn't look at drives not "logged in" unless you specifically tell it to. Mostly, it just reads tables and reports on what it finds.

As to SYSGEN--it's one of those OEM-custom programs. DRI gives the vendor a skeleton program and the OEM is supposed to fill it in with routines to write out boot tracks. After all, it has no information as regards your boot tracks.

If you have the bare OEM copy, it will do nothing.
 
OK, so how does one 'fill in the routines' to SYSGEN? Since I do not have a vendor in this case, how do I fix up SYSGEN to work? Got any sites or documents to look at? Mike
 
I found some source code for SYSGEN for the MDS. It doesn't look much different than the code I wrote to make my CBIOS in the first place. It just has some handy text prompts and the ability to copy to another drive. I could write a SYSGEN of my own for my machine pretty easily. What is the purpose of distributing a skeleton SYSGEN in COM form, if you can't use it? Mike
 
I'll have to look at my OEM redistribution copy, but basically, just as in the BIOS, DRI left any low-level disk stuff (including the boot tracks) to the vendor. Just the way they did things, I guess.

I don't know about teflon and how resistant it is to picking up dirt, but it might be worth a try.

Oh, one more thing--are you using 74LS38s or 7438s as your output buffers? The 38 has something like twice the current-sinking capacity of the LS38. With equipment of this vintage, I'd go with the 38 and not the LS38.
 
Last edited:
Yup, I'm aware of that. I'm pretty familiar with TTL, it's the 'other stuff' I never really worked with. I do have 7438's as output buffers. It's not to say that this particular chip isn't up to snuff. Anyway, it's working with the set up as it is now. Seems like a long hard fight with a short stick. I yanked out my 8080 machine about 2 years ago, after it sitting for more than 30 years. Two winters ago I was struggling to get the DMA to work right and this winter getting the drives to work. I'm pretty happy with how it works. I thought that maybe I'd try my hand at some CPM assembly programming, maybe write a SYSGEN program that will work with my machine, since I'm the vendor.

This morning, I came across another short coming in my software. While CP/M was running, I opened the door on one of the drives and the program hung. Turns out that in my interrupt service routine I don't do anything for when the FDC issues a not ready interrupt. I'll have to trap that, but I'm not sure what to do when it happens. Obviously, the user is intending to change the disk. Should the program wait for the door to close again, maybe recalibrate the drive and wait for the user to re log the drive? Not sure. Any ideas? Thanks for the help Mike.
 
Well Mike, you've just discovered one of the uglinesses of CP/M and, for that matter, early versions of MS-DOS. This is the complete separation of the CBIOS and the file system. The CBIOS has no way of knowing what the BDOS is doing; namely, what files are open and if they're being written to. Just naked sectors. CP/M 2 does have a mechanism to tell the CBIOS if a sector being written is newly allocated, but that's mostly for the benefit of blocking/deblocking routines that use a larger sector size than 128 bytes.

So, my answer would be--"Do nothing". You don't know what the user is doing; whether a disk is being changed for another legitimately or not. Without any sort of information about what files are open or even if the user application has issued a "reset drive" message, you really have no choice but to leave things to CP/M's BDOS and hope things work out for the best.

When I was with a firm who was building a floppy-based system for running business applications, we made a trek down to PG to talk to Gary et al. about our concerns. We discarded CP/M as our primary platform simply for the ugly disk handling and the fact that at the time (1.4) there was no way to time-stamp files.
 
You must log in or register to reply here.
Back
Top