PDA

View Full Version : Question regarding 8272/765 programming



Mike_Z
December 9th, 2016, 10:08 AM
I've been converting my monitor/cold start loader for CPM from my old home made assembly language to ASM. In the process I found some old bugs that I repaired and I wanted to improve my Wait Interrupt routine for CPM. I found something that confuses me.

My new Wait Interrupt routine
1. Waits for the interrupt to occur
2. Checks to see if the FDC is busy
3. If Busy then do result phase of READ/WRITE
4. If Not Busy do a Sense Interrupt
a. If status Register 0 Bits 7,6,5 = 001 means Seek/ReCal OK
b. If status Register 0 Bits 7,6,5 = 011 means Seek/ReCal Bad
c. If status Register 0 Bits 7,6,5 = 100 means Read/Write Bad
d. If status Register 0 Bits 7,6,5 = 110 means Drive Status Chg
e. If status Register 0 Bits 7,6,5 = 100 means Invalid Command

Then each case above is handled, followed by an additional Sense Interrupt which is supposed to result in an Invalid Command, which jumps out of the interrupt loop, does and End of Interrupt and then returns.

I read about the Invalid Command in both the 8272 and 765 spec's. But it either doesn't work this way or I'm doing something wrong.

My Cold Start Loader begins with initializing a bunch of stuff, then does a Specify, followed by a ReCal on A: then B:. The recall on A: works but it fails on B:, which never Recal's.

A little debugging, I found that after the ReCal of A: and the Sense Interrupt I found 020H in ST0. This is correct. It means bit 7,6 is normal completion, bit 5 = 1 Seek End was correct, bit 4 = 0 no equipment error, but 3 = 0 drive is READY, bit 2 =0 head 0 bit 1,0 = 00 drive A: All is good.

But after the next Sense Interrupt which is required (at least as far as I have read) causes ST0 to return 0C1H. Not Correct. It means bit 7,6 is Abnormal completion, Drive Ready Change, bit 5 = 0 Seek End was incorrect, bit 4 = 0 no equipment error, but 3 = 0 drive is READY, bit 2 =0 head 0 bit 1,0 = 01 drive B:. Yet drive B: was not even tried yet. I thought that maybe the drive polling caused this. So I checked the B: drive for ready. I saw some odd waveforms, which I want to digest some first, but don't think is a problem. I was expecting an Invalid Command not Abnormal.

I know that everything works, because my old CSL works, so it has to be my new code. So just on a flyer I changed the programming to not do a second Sense Interrupt after the RECAL. Just do the EOI and return. This works as normal. Both drives ReCal and CP/M boots and works normally.

I a little confused on how and Invalid Command can occur if a invalid command code is not issued. The second Sense Interrupt is a valid command, but there is no interrupt to sense.

I thought of timing problems, but the A: ReCal should not issue an interrupt until it is complete and no other interrupts should occur.

The Intel book states "A Sense Interrupt command must be sent after the Seek or ReCal interrupt; otherwise the FDC will consider the next command to be an Invalid Command." I agree with this and it does work this way. Then Intel furthermore states, "Also, when the last 'hidden' interrupt has been serviced, further Sense Interrupt command will result in Invalid Command Codes." I read this in two places in the Intel doc's and also in the NEC 765 doc's. Even though much of the text seems to be copied from Intel.

I want to do some more testing, but I'm still confused about the Invalid Command result from the extra Sense Interrupt. Any Ideas? Thanks Mike

Chuck(G)
December 9th, 2016, 12:37 PM
Actually, I think that the text is originally from NEC.

I was under the impression that SIS could be issued at any time the FDC wasn't busy. I assume that you're checking for busy before you attempt to issue a command--if you don't, I believe that the current command is aborted.

My first question is if you are using a real interrupt or simply polling the status.

Mike_Z
December 9th, 2016, 01:00 PM
I've been reading the Intel datasheet and the Intel AP-116. The NEC uPD765A datasheet. I also have Intel's iSBX218 FDC reference manual.

You may have hit it. I'm jumping to an address just after the MSR Check for busy. This could be the problem.

Sorry for answering Your 1st question last. I'm using real interrupts. The polling I talked about is the FDC device polling for disk status changes.

Maybe tomorrow I'll change the code and try it again. Thanks Mike

Mike_Z
December 10th, 2016, 08:56 AM
Well... that was not the problem. Same results. So, I think my next step is to make a test program which only has the initialization and the two Recal calls. Make it so I can better see how it progresses thru and display the Status Registers to see exactly where stuff happens. Mike

Chuck(G)
December 10th, 2016, 10:47 AM
It may not matter in your code, but it's worthwhile noting that the 8272/765 does not have updated status immediately available when reading status bytes after an interrupt. That is, you cannot simply get the result phase bytes by issuing a block input for 7 bytes in a row. You have to go through the RQM/DIO ballet for each byte. Also, it's good practice to kill about 50 microseconds when reading the result bytes after DIO shows that the 765 is ready to hand you a status byte. You can see this in the 5150 BIOS listing quite clearly at EF94 et seq. "Read in the status"/label J43.

This could have been a glitch in the original 8272 silicon, but it's a good idea to hew to this rule on general principles.

Mike_Z
December 10th, 2016, 11:22 AM
I use a routine FDCIN: and FDCOUT: during the command and result phases.



FDCIN: IN MSR
ANI 0C0H ;strip bit 6&7
CPI 0C0H
JNZ FDCIN ;Loop until 11

;Are you suggesting I place a 50uSec delay here?

IN DATAREG
RET

FDCOUT: IN MSR
ANI 0C0H
CPI 080H
JNZ FDCOUT ;loop until 10

MOV A,B
OUT DATAREG
RET


Thanks Mike

Chuck(G)
December 10th, 2016, 01:51 PM
It's primarily when reading status. After you read a status byte, you have to allow time for the FDC to reset the RQM flag; otherwise, there's a danger that you can loop back around and read before the controller has the next byte. So you delay a bit after each status byte read. If you're using DMA for data, there's no big issue, as the FDC calls out the timing with DRQ.

See the little timing diagram on p. 465 of the datasheet (http://www.classiccmp.org/dunfield/r/765.pdf). It's a fine point that many miss and wonder why they're getting erratic operation.

Dwight Elvey
December 10th, 2016, 03:58 PM
I use one with out interrupt on my NC4000 and found I needed delays
at some point.
Dwight

Chuck(G)
December 10th, 2016, 04:04 PM
Yes, apparently some think that the 765 is just a bunch of combinatorial logic. Not so--there's a microsequencer inside and things do take a finite amount of time to change.

Mike_Z
December 11th, 2016, 10:47 AM
Am I correct in thinking that what the diagram and what you are saying is that the MSR values are available immediately but the Data Register is not and one should wait 50 uSec before reading it? Mike

Chuck(G)
December 11th, 2016, 11:33 AM
That's the general idea--the MSR isn't indexed in any way and is always available. But the data register has changing content and you have to be patient for the microcode in the 765 to catch up. Of course, if you're reading using DMA, this doesn't matter, since the 765 calls the timing on data transfers. But status is a different matter. Note that, in the timing diagram that when reading detailed status, the DIO essentially goes to an output state during the whole 7 byte transfer, but the RQM is the thing that strobes the bytes out. Since your code can't see waveform edges, just levels, you have to allow time for RQM to drop before you grab the next byte. You could, in theory check for the RQM drop and then the rise, but there's always the possibility that you could miss the event.

Mike_Z
December 11th, 2016, 04:16 PM
It's been a rather frustrating day. My B: drive, the Shugart 800 has been causing a LOT of errors and my original software that works only has a set error when that happens. Odd thing, when I test the disk with ANADISK there are no errors on the disk. The bad sector errors occur mostly when I use ASM, which has many disk accesses. To avoid this problem I have been using A:, the Siemens which never has had a bad sector error. I wonder if the Shugart needs some work?

Another oddity is, I wanted to make certain that a Sense Interrupt all by itself would generate an Invalid Command. And I can not make it work. Here is what I did;



;Initialize some stuff

Start: CALL SPEC ;sets FDC/drive parameters
CALL SDS ;Sense drive 0

;ST3 = 00110000 no fault, not write protect, Drive Ready,
;Track 0 true, not two sided, head =0, drive=00

MVI A,01H
STA DRIVE
CALL SDS ;Sense Drive 1

;ST3 = 00110001 no fault, not write protect, Drive Ready,
;Track 0 true, not two sided, head =0, drive=01

CALL SIS ;Sense Interrupt when there is no
;interrupt
STOP

;ST0 = 11000000 Drive status change on drive 00



I added a 50 uSec delay in the FDCIN routine, There is no interrupt involved and I still do not get an Invalid Command. I'm stumped. Mike

Chuck(G)
December 11th, 2016, 05:26 PM
As I said before, I believe that SIS will always return a valid status.

Here's a question: Do your errors always occur after a head-load? You may not be waiting long enough for the head to settle. How about occurring right after a seek? Same idea.

Anadisk also uses a the PC's 765, so there might be a clue to your doing something differently.

Mike_Z
December 13th, 2016, 08:44 AM
Well..... I think I got this one solved. My goal was to get the new Monitor/CSL rewritten in CPM, as the old one worked, which I did. Then make some improvements. The first was to improve the interrupt handling. Actually my old software didn't really use the interrupts as intended. So I made some changes and one these changes was the problem. Sometimes I can't help catching my britches with my own pitch fork! The real problem was that I moved the End Of Interrupt out of the Interrupt Service Routine to a spot later in the process. This effectively caused the software to occasionally miss it. This is why the Sense Interrupt was failing. After the first recalibration the EOI was skipped screwing up the entire thing. I moved the EOI back into the ISR and now the program seems to work. I want to take some time making sure and then start thinking about how to do the retry's. I did run the program until my B: drive caused a Bad Sector error. I checked ST1 & ST2 and found CRC errors. Maybe I need to clean the head on B: head and maybe install a new head pad? This brings up a question. I read somewhere that floppies can be cleaned, aligned and tested. Is this something that I should look into? Who would do this? Thanks for the help, Mike

PS, I ruined another EEPROM. Someone mentioned a wrist strap? How does this work and where can I get one?

Chuck(G)
December 13th, 2016, 09:29 AM
Not the floppies, but the drives. Cleaning is a pretty simple matter, but alignment requires special reference disks and is no task for a beginner.

Amazon has the wrist straps (https://www.amazon.com/Corpco-Anti-Static-wrist-strap-removable/dp/B01D0O7M4E/ref=pd_lpo_147_lp_t_3?_encoding=UTF8&psc=1&refRID=M1FNKCGH1EN6AEKEG61C)

On my own diskette routines, I simply set a flag in the ISR saying that the interrupt has occurred and mask the interrupt and then do an EOI. The rest of the code takes place outside of the ISR. The idea is to keep the ISR as short as possible.

Mike_Z
December 13th, 2016, 09:34 AM
Hey, thanks, I'll have to get a couple of those straps.

Yes, that is about all my ISR does too. At the time I thought it was a good idea to move the EOI, but that's me. I can make plenty of mistakes, but don't have any trouble back tracking once in a while.

Do you know of anyone that does the drive alignment stuff? Thanks Mike

Dwight Elvey
December 13th, 2016, 09:40 AM
For anti-static, you need a surface that is conductive to work on. You can
use some dilute dish washing liquid to coat the surface. This will leave a
thin film that will conduct static.
I think the last time I needed to coat some plastic meter movement I used
Dawn ( sp?).
You need to connect a wire from that surface to an earth ground.
The wrist strap is relatively simple. It just needs a wire to the ground and
the wire must contact the skin. For safety reasons, there should be a 1M
resistor in series before this is attached to the grounded table.
You also need to avoid wearing wool, or synthetic fabrics. Cotton is
best if you don't have a anti-static lab coat.
Use good handling practices. Although, you often hear people saying to not
touch the leads, that is incorrect and often the source of actually causing damage
to parts.
Make sure the board you are installing or removing parts from has a path
to ground. Your hand and a static strap will do.
If you need to move the part away from the bench, make sure it is always
in a Faraday shield. One method is to wrap in aluminum foil first.
The other is to simply wrap your clean dry hand around it ( leads and all ).
Always put your hand on the surface you intend to transfer it to before
setting it down. Always put one hand on the surface you're going to pick it
up from while using the other to puck it up.
Never, ever, carry the part at arms length with the leads exposed.

As for cleaning heads, you can use a head cleaning kit.
I usually just remove the drive from the machine and clean with
a q'tip and some isopropyl alcohol.
You can get swabs with long sticks but I just use q'tips.
Use care to not flex the heads too much and inspect for
fibers of the swab after.
If it is a single sided drive, make sure the felt pressure tip
is clean. If it has crusted on crud, I use the edge of a dull knife
to scrape it off. Try to keep the pad flat and don't remove more
than crud. Do not put alcohol on the pad.
Dwight

Mike_Z
December 13th, 2016, 11:08 AM
Wow! Thanks for the tips. What if I would fashion an aluminum plate atop the bench and ground it. That should work for the bench top.

I don't wear wool, but synthetic fabrics? What doesn't have that these days. I could wear some of my old white shirts from my long ago work days, they are cotton, but it's cold here in Wisconsin. Below zero this morning and it is cool in the basement. So I generally wear a sweat shirt and a hat. Don't have a anti-static lab coat.

Since the last post I have been moving my EEPROM's while they are in one of those conductive tubes. So my failures must have been occurring while I'm pulling them or installing them. Maybe the hand strap and conductive bench top may reduce this.

My drives are old. I have been cleaning the heads with Qtips and Iso alcohol. All the head pads have been replaced with some felt I have. Seems these old pads have either fallen off in the past or when I tried the drive the first time. Some guy in Texas sent me some self adhesive felt which is 1/16" thick. This works pretty good as a head pad. I use a 3/16" hole punch to make the pad and add a small drop of super glue to help the adhesive hold the pad in place. Other wise the pad will fall off rather quickly.

I use mostly new Athana disks in the drives, occasionally an old disk when testing. I picked up another Shugart 800 drive, but the electronics failed. I'm waiting on replacement parts. Maybe this drive will be better. I found the Shugart Maintenance Manual. There they talk about alignment. I could try it, but must likely would louse it up, so I will not.

Thanks again for the help, Mike

Tor
December 14th, 2016, 02:03 AM
Wow! Thanks for the tips. What if I would fashion an aluminum plate atop the bench and ground it. That should work for the bench top. That may not actually be the best idea.. you don't want it to be that conductive. You want something that conducts, but slowly (which is one other reason for that 1M resistor Dwight mentioned for the strap). Fast discharge == zap. Slow discharge == no zap. Those anti-static bags that boards and components come in, for example, are made of slow-conducting plastic so that a charge can dissolve safely without creating a spike.

So, for workbenches, you will sometimes see some kind of rubber-like mat, with a ground connection in one corner. Same principle, conductive, but not metallic-conductive.

Mike_Z
December 14th, 2016, 07:21 AM
Along these lines, I was curious about the IC tubes that some chips are in. I have a bunch of short pieces that had chips in them when I purchased them. They are all sizes, long and short, different colors, shapes. Some have markings most don't. I was curious about the conductivity of them. So I tried to measure the ohms with a meter. They all read infinite, but I suspect that they are not actually? Mike

Chuck(G)
December 14th, 2016, 10:41 AM
I believe the tubes are primarily static-dissipative, vs. static-shielding. The deal is that the static-disspative tubes will not generate a static charge when rubbed. That is, they're not particularly conductive. Most tubes are dissipative, although I have a couple black carbon-doped tubes in my collection--they do show a finite resistance.

See EEVblog (https://www.youtube.com/watch?v=imdtXcnywb8) for a discussion.

Dwight Elvey
December 14th, 2016, 12:32 PM
That may not actually be the best idea.. you don't want it to be that conductive. You want something that conducts, but slowly (which is one other reason for that 1M resistor Dwight mentioned for the strap). Fast discharge == zap. Slow discharge == no zap. Those anti-static bags that boards and components come in, for example, are made of slow-conducting plastic so that a charge can dissolve safely without creating a spike.

So, for workbenches, you will sometimes see some kind of rubber-like mat, with a ground connection in one corner. Same principle, conductive, but not metallic-conductive.

That is why I mentioned the dilute dish soap. It is slightly conductive and will bleed off charges even when dry.
Also, remember, if the thing you are working on is on plastic feet, it is insulated from your bench.
Make sure there is a path to the bench.
The parts that I'd come on that are the most static sensitive are the CMOS 4051, 4052 and 4053.
The are analog gates. The analog lines have little protection between them and the gates
of the transistors used.
I always put these parts in last to any project I'm working on and careful while handling.
Dwight

Mike_Z
December 15th, 2016, 01:48 PM
That EEVBLOG was quite interesting. I had a couple of those dark bags, but since it was difficult to see through them I tossed them. Oh well.... I was interested in the bench mat the guy had. I looked up ESD mats and found that a small one cost between 50-75 dollars. Do you think that is worth it? So far the only chip that I've had any trouble with are the EEPROMs I have. I sent for a couple of wrist straps and am going to keep all the bags and tubes I get. Seems that they provide some protection. I was surprised to see the guy zapping the chips with 10Kv. But when it is cold here, the house gets rather dry and it's not uncommon to drew a spark after walking around a little. So, I think Dwight is right, be careful is probably more than 50% of the solution, the rest is some simple equipment. I want to try the soap idea. Thanks Mike

Mike_Z
December 16th, 2016, 06:32 AM
Getting back to questions regarding the 8272/765 FDC. Reading the paragraphs about the READ command. When the read command finishes with the execution phase an interrupt is issued and the result phase is completed. The Interrupt Service routine must determine whether or not the FDC is busy when this interrupt is issued. If BUSY then the result phase is done. If an error occurs during the execution phase, the documentation says 'the command is terminated'. Does that mean after the interrupt has been issued, that the FDC will be NOT BUSY and maybe the result phase is not needed, because the error will be caught doing the Sense Interrupt? I'm a little confused at which path a READ error will be caught. Whether the FDC is busy or not after the execution phase of a READ command. Here is a flowchart of my interrupt handling. Thanks Mike

34764

Chuck(G)
December 16th, 2016, 06:43 AM
No--there's always a result phase with a read. One nice thing about the 765. Illegal commands do not, IIRC, produce a result phase, but you shouldn't be issuing those anyway.

Mike_Z
December 16th, 2016, 07:12 AM
So, does that mean, even with an error on a read the FDC will still be busy? The errors will be caught when the result phase gets the status registers? And checking for a bad read when the FDC is NOT BUSY is a waste of time? Thanks MIke

Pardon me, I'm a little behind on abbreviations. IIRC, I Googled it "If I Remember Correctly"? I first was thinking what kind of interrupt is this? There will be an invalid command result after a Sense Interrupt with no Interrupt. That is how I get out of the NOT BUSY Loop. There is no Result phase for that through.

Chuck(G)
December 16th, 2016, 09:50 AM
I think you're over-complicating things. My "issue command" routine looks something like this:

1. If this operation involves DMA, set up the DMAC for the transfer.
2. Send the command bytes.
3. If this was not a SEEK, RESTORE, DRIVE_STATUS, or SPECIFY command skip to 5
4. Wait (timed) for SEEK_COMPLETE. exit.
5. Wait for INTERRUPT. If timed out, quit
6. Sense interrupt status, exit

Note that, particularly in the IBM PC world, the "ready" input to the 765 is tied high, so it's possible for the FDC to hang waiting for an event that will never come. Hence, the deadman timers.

Mike_Z
December 17th, 2016, 12:45 PM
Well.... it's been snowing to beat the band here and my snow removal process is slow. I use the blower and a shovel. The blower is also giving me trouble. I think there is a vacuum leak around the carburetor. It takes me about 4 tries to clear everything out. So, in between try's, when I come in to warm and rest up, I'm sitting at the kitchen table reading over my FDC code step by step. AND... I found that I have to pay closer attention to my PUSH/POP instructions and I had a couple conditional jumps that should have been conditional calls. I also heeded Chuck's comment on keeping it simple, so I commented out some of the extra stuff for now. Anyway, after getting a chance to recode an EEPROM, I found that this new code works pretty good. I had the most trouble when I would assemble my 2k monitor/cls program. The assembly would run for almost 2 minutes and there are a bunch of disk assesses. On my good Siemens drive, I got to do 10 complete assembles (PRN & HEX made) with no errors. Then on my questionable Shugart drive, I got 8 out of 10 good assembles. So I think the code concerning the READ, WRITE, Sense Drive, Sense Interrupt, SEEK and RECAL are good. I skipped the drive ready stuff for now.

I remember Chuck suggesting that I increase the SPECIFY parameters. I currently have the Step Rate at 10 mS, the Head Load at 40 mS and the Head Unload at 32 mS. I thought these were reasonable. If I were to increase these which should I do and by how much? Thanks Mike

Chuck(G)
December 17th, 2016, 01:10 PM
Those times look reasonable. I don't recall the model drive you're using, but you might get quieter operation at a faster step rate. If your drive sounds like an angry lawnmower when moving between cylinders, a faster step rate will definitely quiet things down.

Mike_Z
December 17th, 2016, 02:39 PM
I'm using a Siemens FDD-100 and a Shugart 800. The step seems quiet enough. The specify parameters were set with the Siemens's numbers I found in the their document. I have not been able to find the Shugart numbers and have just assumed they would be similar. We are supposed to get 6 or more inches of snow tonight. Maybe tomorrow, in between snow flakes, I can start to un-comment some of the extra's and see what works and what doesn't.

Recently I picked up another Shugart 800 drive from eBay. It would not work at all when I got it. So far I had to replace a few IC's and now it will select and step, but will not read very well at all. Probably needs more work time on it. Thanks Mike

Chuck(G)
December 17th, 2016, 02:49 PM
Just digging out from the devastation that a 3/4" layer of ice put on the landscape. Trees down everywhere; the roofer won't touch things until the ice has melted, the contractor won't touch things until the trees have been removed and the tree guys say that they've got enough business to keep them busy through March. I cleared a foot of frozen tree droppings off the driveway and took a chainsaw to the trees that had fallen across it, so at least I'm accessible.

At least power's back up and I can go back to nursing my lovely wife who's down with the flu. Life is interesting right now. Given that weather moves from west to east, you're in for more entertaining weather.

archeocomp
December 17th, 2016, 11:37 PM
That is the price for living next to ocean, I guess. I never experienced that kind of weather here deep inside continent.

Mike those of yours are 250kB drives? I am using these drives
https://www.flickr.com/photos/lisovy/albums/72157624593790414/with/4834445954/
I really like the looks of it. And it is SS/DD - 500kB

Mike_Z
December 18th, 2016, 07:13 AM
Sorry to hear about the ice. We had a bad ice storm here back in 1976. I remember the horses could not even walk across the yard without falling. I have a friend from Seattle visiting until January. He's wondering about what he will find when getting home. We got almost a another foot of snow last night. The blower was running better this morning and most of the clearing is done. Now for the cold. It's below zero now and they are talking about -15 tonight.

Arch, yup. All of my drives are single sided. I have 4 Siemens, 2 work and 2 Shugarts and one works kinda.
Here's a picture of the drives above the open drawer that has my 8080 machine.
34818 Mike

Mike_Z
December 18th, 2016, 10:52 AM
My Shugart 800 started to squeak again, so I was watching it while ASM was running, with a lot of disk accesses. I thought that maybe I could see where it was squeaking. But I mistakenly made the other drive work and I noticed that the head load travel on the Siemens is less than the Shugart. So I tried to measure the distance between the head pad and the head with the door closed. No disk in the drive. The Siemens was less than 1/16". The Shugart is about 1/8". So I did the same measurement on the other Shugart drive I have that currently does not work. The distance between the head pad and the head is about the same as the Siemens, 1/16". So maybe the Shugart that is giving me occasional errors has too much distance for the head pad to travel in the Head load time I have set in the SPECIFY command. I have a copy of the Shugart Maintenance manual, but it says to use a special tool to set the head load actuator. But I'm thinking that the distance I am measuring is set by the 'Up Stop adjustment screw'. Where as the 'Down Stop' screw should just release the upward pressure on the head pad, so it can quick pick it up, yet allow full pressure on the Media. Here again both Shugart adjustments are very different. So.... I think I may need to adjust the Head Actuator, but without the tool, I'd be guessing.

This is what I have Door closed distance between released actuator, the head pad to head is 1/16" on Drive 1 and 1/8" on Drive 2.

Then with the actuator energized the distance between the actuator bar and the head pad arm is 0" on Drive 1 and 3/32" on Drive 2.

Drive 1 is the good drive that occasionally errors. So, before I arbitrarily make some changes any ideas on a coarse of action? I was thinking to try and copy the measurements from Drive 2 to Drive 1. Thanks Mike

archeocomp
December 18th, 2016, 11:41 AM
Usually head load mechanism does two things. Presses a sponge on the sleeve of the disk so that the disk is squeezed a little in its sleeve. This is a measure to wipe out any dirt from the disk surface. Secondly the disk is pressed onto the head to ensure tight surface contact and error free read/write.

Mike_Z
December 18th, 2016, 12:28 PM
Yup, I think you are right about those items. Though, in my mind if there is double the distance to travel, it will take twice the time to make contact with the media. And with the additional travel, head pad will gain more velocity before contacting the media and will most likely bounce more. Making it possible for a mis read. So, I think it is important to tighten up this spacing. Just looking for how to do it. I think that I'll just mirror the settings of the other Shugart, assuming that it could be set correctly. The Shugart manual talks about an adjustment tool P/N 50391. The picture makes it look as if it is just an gauge block of some sort. Mike

archeocomp
December 18th, 2016, 12:41 PM
If you look here, you will see how close is the pad to the other side of the disk (on the MOM6400 floppy I am using). The disk hardly passes through when it is being inserted.

https://www.flickr.com/photos/lisovy/4834447650/in/album-72157624593790414/

Chuck(G)
December 18th, 2016, 01:02 PM
Yup, I'd get out the ol' feeler gauge and go from there. The other problem with a too-large head-llift is that when the head loads, it will tend to "bounce" for a time; the larger the distance, the larger and longer the bounce. There's method in the Shugart madness.

Mike_Z
December 18th, 2016, 02:08 PM
Here's another issue, how thick are the head pads supposed to be. I have one that is twice as thick as the other. This thickness will chance the head load adjustment. Mike

Mike_Z
December 20th, 2016, 06:41 AM
Well... I spent all day yesterday fussing with the head actuator adjustment. I could not make it any better. I could, in fact make it worse. There has to be something amiss with this drive unit. I get occasional errors in the Shugart drive on different media, but using these same disks in two other Siemens drives these errors never show up. I'm getting the feeling that the errors occur in one particular spot on the disk, maybe pointing to an alignment problem. Reason I say this when I have the STAT and PIP files as the 3rd and 4th file on the disk, they can occasionally fail, that is I get the CRC errors. Then when I erase the disk and copy the STAT and PIP as the first two files they work fine. But, I am unsure as to whether the trouble is with the Directory entry or with the file. Many times after I receive an error I run ANADISK on the disk and I could not repeat the error. Although maybe 2 or 3 times in the many times I used 22DISK to move files around I would get a bad sector on the disk which occurred on Cyl 2 Sector 1, which is where the Directory is. I'm thinking that I'm going to change out the Shugart Drive with a Siemens I have connected to a modern computer. This is the drive I use with ANADISK, 22DISK and IMD. Maybe I can use the Shugart there instead. One problem is the Shugart needs -5 volts, so I'll have to add that.

Does anyone know of someone who can do an alignment of a these 8" drives? Thanks Mike