Tandon TM100-2 appears to be in mechanically working order, but never attempts to read disks.

[zanglucarson]

In the photo at [here], see how there is an "(XT)" appearing. It means that an XT version of the XUB is installed, something that will work on both an XT and AT. If your card shows "(AT") instead, then there is the problem.

I've attached a photo of my splash screen. However, I just read your last message:

Does your IBM XT have 640 KB fitted?

No it does not.. I think you may have found my issue.. it's got 128kb fitted. That's definitely a good push in the right direction though, thank you for that!

I've got an AST Six Pack memory expansion board which came with the computer, it should get the memory up to 640k, sadly with no functioning disk drive, there's no way to configure it, right?

Assuming I can get the floppy drive working, I should be able to get my copy of DOS 3.30 installed onto the CF, which supports 128k as far as I'm aware.

I was also possibly thinking of trying to use a virtual machine to install DOS 3.30 to the CF card? I think I'd done it for DOS 6.22 in the past for my AT..

In other news, I did attempt to have it boot a floppy using the XTCF bios, just so I can show you that it produces the "Error 2h!" I did some searching around but had a difficult time locating a solid reference as to what it might mean.

If the two floppy-count switches on the motherboard are set for 3 or 4 floppy drives, that can cause a booting problem.

I just checked the floppy-count switches, both have to be set to the ON position, which would indicate one floppy drive, correct?

I plan to try and record a video of the drive head attempting to seek the disk tomorrow and send it in, I'm not too sure how helpful it'd be but I figured if it is a mechanical issue that I'm not noticing then maybe that'll point it out.

I'm gonna have to call it for now, it's pretty late over here in California. Thanks a bunch for helping me troubleshoot today, Have yourself a good rest of your day! I'll get back to you as soon as possible.

 

[modem7]

I've attached a photo of my splash screen.

The only odd thing I see there is the 'Master at 0h', but I cannot see how that would cause the symptom.

It also shows a very old version of the XTIDE Universal BIOS (XUB). You may want to upgrade that at some point.

... it's got 128kb fitted.

Indicating to us that you have the 64-256KB version of the 5160 motherboard.
That ties with the photo showing motherboard switches 3 and 4 being set to enable only RAM banks 0 and 1.

I've got an AST Six Pack memory expansion board which came with the computer, it should get the memory up to 640k, sadly with no functioning disk drive, there's no way to configure it, right?

There a different versions of the SixPakPlus, and so your route to 640 KB is going to depend on which SixPakPlus version you have.

The early SixPakPlus version holds a maximum of 384 KB. If you have that version, you could populate the empty motherboard RAM banks to bring motherboard RAM to 256 KB, then use the early SixPakPlus to bring total RAM to 640 KB.

The later SixPakPlus version holds a maximum of 576 KB. So, that could be configured to provide 512 KB of RAM starting at address 128 KB.

I was also possibly thinking of trying to use a virtual machine to install DOS 3.30 to the CF card? I think I'd done it for DOS 6.22 in the past for my AT..

From what I read, it doesn't always work.

In other news, I did attempt to have it boot a floppy using the XTCF bios, just so I can show you that it produces the "Error 2h!" I did some searching around but had a difficult time locating a solid reference as to what it might mean.

See [here].
2 = Address mark not found

I just checked the floppy-count switches, both have to be set to the ON position, which would indicate one floppy drive, correct?

Correct.

I plan to try and record a video of the drive head attempting to seek the disk tomorrow and send it in, I'm not too sure how helpful it'd be but I figured if it is a mechanical issue that I'm not noticing then maybe that'll point it out.

I think the BASIC code that I pointed you to would be better.
E.g.
1. Command to go to track 10. Expect to see the heads move to about the quarter way point.
2. Command to go to track 20. Expect to see the heads step in to about the half way point.
3. Command to go to track 39. Expect to see the heads step in to the maximum position.
4. Command to go to track 20. Expect to see the heads step out to about the half way point.
etc. etc.

 

[zanglucarson]

I think the BASIC code that I pointed you to would be better.

Oh! I knew I forgot to mention something very important! I gave all three BASIC programs on your site a try (the crude register, turning the led and spindle on, and the head moving command). Attempting to move the heads using the program resulted in zero movement from the heads. I tried moving the heads to track 0, 10, 20, and 39. There was zero movement. I retried it several times, and rewrote the code three times. The head still did not move. I find it odd however considering that it clearly has the capability to move during startup.

It also shows a very old version of the XTIDE Universal BIOS (XUB). You may want to upgrade that at some point.

I will make a note to do that for sure, thank you.

From what I read, it doesn't always work.

I've had some trouble installing an OS to a CF card in the past, but I figure if nothing else works it may be worth a try.

There a different versions of the SixPakPlus

I see, I'll figure out which specific one I have and get back to you on that.

Indicating to us that you have the 64-256KB version of the 5160 motherboard.

Correct, I believe all the ram banks 0-3 are fully populated, however I had encountered a PARITY ERROR 1 message when attempting to load anything using the XT-CF and/or the original hard drive with all of the RAM banks enabled. (my MFM miniscribe hard drive's head stepper motor is non function , but that's another issue all on its own).

2 = Address mark not found

I've been looking for a page like this! thank you!

 

[modem7]

Oh! I knew I forgot to mention something very important! I gave all three BASIC programs on your site a try (the crude register, turning the led and spindle on, and the head moving command). Attempting to move the heads using the program resulted in zero movement from the heads. I tried moving the heads to track 0, 10, 20, and 39. There was zero movement. I retried it several times, and rewrote the code three times. The head still did not move. I find it odd however considering that it clearly has the capability to move during startup.

Hmm. Did you note that the head moving code (as shown) is for B: and needs to be modified if the target is to be A: ?

 

[zanglucarson]

Hmm. Did you note that the head moving code (as shown) is for B: and needs to be modified if the target is to be A: ?

Just saw that, I guess that goes to show me a little bit of reading goes a long way. I'll modify it, give it a try and report back.

 

[modem7]

Correct, I believe all the ram banks 0-3 are fully populated, however I had encountered a PARITY ERROR 1 message when attempting to load anything using the XT-CF and/or the original hard drive with all of the RAM banks enabled. (my MFM miniscribe hard drive's head stepper motor is non function , but that's another issue all on its own).

I note your "and/or". The "and" is expected to be a problem due to a resource conflict:
- The photo in post #21 shows that your XT-CF-Lite is configured to have its ROM starting at address C8000.
- The vast majority of XT-class hard disk controllers have their ROM starting at address C8000.

Just saw that, I guess that goes to show me a little bit of reading goes a long way.

So you're the type who doesn't 'read the manual'.

 

[zanglucarson]

So you're the type who doesn't 'read the manual'.

I'm the type who will skim over it but overlook things and have a meltdown when things "mysteriously" don't work. I'll admit it .
It's the San Diego way. Sorry to waste your time.

The photo in post #21 shows that your XT-CF-Lite is configured to have its ROM starting at address C8000.

I originally had the XT-CF-Lite set to start at CA000 when the hard drive and its controller were installed. I changed it to C8000 the other day to see if the address was conflicting and causing it not to load off the CF. As you discovered earlier, this was not the issue. I'll go ahead and swap that back to CA000.

 

[modem7]

I'm trying to boot using my XT-CF-Lite, using it and telling it to boot from the floppy simply produces a "2h error."

See [here].
2 = Address mark not found

I've been looking for a page like this! thank you!

So what is 'address mark not found' ?

At [here] is a data sheet of a controller chip used in PC family floppy controllers.
Figure 3 (on the last page) shows me the low-level format.
On page 5-12, you will see "MA (Missing Address Mark)" and a description of the conditions under which the controller chip flags that error.

I was able to replicate what you saw (the XUB displaying 'Error 2h!') by disconnecting the two heads on my TM100-2A, and having a known bootable floppy inserted.
A drive with bad head alignment would be another possible cause.
Dirty heads is another possibility.

Given the inconsistent floppy boot behaviour that you appear to be seeing, might the problem be:
- Heads slightly out of alignment (sometimes reading okay, sometimes not).
- Dirty heads (sometimes reading okay, sometimes not).

And because we know that your machine sometimes reads the boot sector of a boot floppy okay, I don't expect the XUB to display 'Error 2h!' at every floppy boot attempt.

 

[SomeGuy]

Correct, I believe all the ram banks 0-3 are fully populated, however I had encountered a PARITY ERROR 1 message when attempting to load anything using the XT-CF and/or the original hard drive with all of the RAM banks enabled. (my MFM miniscribe hard drive's head stepper motor is non function , but that's another issue all on its own).

If it were me, I would fix that before doing anything else. Even if bad RAM is disabled, there is a chance it can still interfere with other things. Are you sure you had the RAM DIP switches set right when you experienced the parity error? Sometimes having them set wrong can cause DOS to use memory that isn't there and go boom. I'm guessing it passed the initial RAM test? That can be tricky to track down. Ideally you would want to use a RAM tester like Checkit,
If it were me, I would REALLY want to get the machine booting with either another 360k drive or a 720k-1.44mb drive and test the motherboard first.

 

[modem7]

Did you note that the head moving code (as shown) is for B: and needs to be modified if the target is to be A: ?

Just saw that, I guess that goes to show me a little bit of reading goes a long way. I'll modify it, give it a try and report back.

To stop the possibility of someone else making the same oversight, I have modified the head moving code to use A:

 

[zanglucarson]

To stop the possibility of someone else making the same oversight, I have modified the head moving code to use A:

I'll respond to this first since it's where I made the most "groundbreaking" discovery.
I ran the head moving program (this time making sure to read the instructions and change the the lines in the code to use A: instead of B: ) and I got the head to move.
Immediately I noticed a very glaring issue. I had the head move to the same location then go back several times.
More than half the time, the head would be quite far off where it needed to be. I marked spots on the rail just to make sure I wasn't seeing things.

The rails themselves are very well lubricated, so the only reason I could think of this happening is that the stepper motor is more stuck than I realized (the motor seems fine to me as the head seems to move with light force, but then again, I've never owned a working TM-100 before so I wouldn't know. I've already attempted to lubricate it from the outside. But my best bet would be that my lubricant isn't able to fully penetrate the motor bearings.
Would that be a safe guess to make? If it were just an alignment issue, it would still be moving to the same spot consistently, correct?

The last thing I noticed. I noticed some of the wires on connector 5 on the floppy drive had been pushed out. I pushed them back into the connector and tested the continuity to make sure they were ok. It seemed fine, until I realized that everything except for the black and exposed wires were making continuity? I'm not sure if there's a short somewhere on the head itself or if it's just supposed to be like this. But I found it really weird. I checked to see if it was an issue with the main board itself, but none of the pins that connect to connectors 5 and 6 have this short. I've attached a photo of which pins are shorting out. The pins colored red are shorted on connectors 6 and the blue colored pins are shorted on connector 5.

So what is 'address mark not found' ?

At [here] is a data sheet of a controller chip used in PC family floppy controllers.
Figure 3 (on the last page) shows me the low-level format.
On page 5-12, you will see "MA (Missing Address Mark)" and a description of the conditions under which the controller chip flags that error.

So in other words, the floppy controller just isn't finding what it's looking for in the place where the head moves to?

I was able to replicate what you saw (the XUB displaying 'Error 2h!') by disconnecting the two heads on my TM100-2A, and having a known bootable floppy inserted.
A drive with bad head alignment would be another possible cause.

Hmm, I wonder if it could be relating to that short on connectors 5 and 6 I noticed? Aren't connectors 5 and 6 the ones which connect the heads to the main board? But I guess that wouldn't make much sense considering that it sometimes reads.

Dirty heads is another possibility.

I'm fairly certain the heads are clean, I've gone over them with isopropyl alcohol multiple times now. From what I can see there doesn't seem to be any other visible forms of corrosion or debris that would be causing the heads not to read.

And because we know that your machine sometimes reads the boot sector of a boot floppy okay, I don't expect the XUB to display 'Error 2h!' at every floppy boot attempt.

I did another experiment last night to test this theory after running the stepper motor movement program. I did this with the XT-CF removed, I figured for the most part, any error codes the XT-CF BIOS would throw up would be mostly irrelevant since it seems like it's just an issue with the stepper motor not going where it needs to.

Anyway, I inserted my DOS 3.30 disk, and attempted to have the floppy drive read the disk 10 times. 2 out of the 10 times, the computer gave me a "disk boot failiure" error. the other 8 times it would just go straight to cassette BASIC.
Based on what you said, it seems like those 2 specific instances where I got an error would be times where the head actually moved to the boot sector, then failed to move where it needed to read on the disk next.

If it were me, I would fix that before doing anything else. Even if bad RAM is disabled, there is a chance it can still interfere with other things. Are you sure you had the RAM DIP switches set right when you experienced the parity error? Sometimes having them set wrong can cause DOS to use memory that isn't there and go boom. I'm guessing it passed the initial RAM test?

I did some experiments to check on the RAM last night. It seems like whatever is causing the parity error is in BANK 2. I enabled BANK 2 on the DIP switches and it produced the parity error 1 once again. The first time the parity error happened, all 4 banks were enabled.
It does pass the initial RAM test with 128K regardless of whether I enable banks 2 and 3.

That can be tricky to track down. Ideally you would want to use a RAM tester like Checkit,
If it were me, I would REALLY want to get the machine booting with either another 360k drive or a 720k-1.44mb drive and test the motherboard first.

I definitely plan to try the known working 360k drive I have in my AT on my XT, assuming fixing the movement of the head doesn't resolve the read issue. I just.. really don't want to take the AT out.. (it's been in the box most of its life and it's an AT so it weighs a ton. That and I just don't have space to bring it out most of the time). If or when I do try the AT's 360k drive, I will give Checkit a try for sure.

In regards to the stepper motor on the floppy drive, I've seen a couple videos of people completely disassembling the stepper motor and lubricating the bearings individually. Is this advisable?

 

[modem7]

I did some experiments to check on the RAM last night. It seems like whatever is causing the parity error is in BANK 2. I enabled BANK 2 on the DIP switches and it produced the parity error 1 once again. The first time the parity error happened, all 4 banks were enabled.
It does pass the initial RAM test with 128K regardless of whether I enable banks 2 and 3.

Background #1: The display of a parity error is disabled during the actual RAM test. If any parity error happens during the test, it is displayed near the end of the POST, when NMI's get enabled.
Background #2: At [here], read the section named 'Flawed methodology for determining total conventional memory size'.

The symptoms are pointing to a RAM related issue in bank 2.

This could be as simple as a poor connection, and so if you haven't already, re-seat all of the RAM chips in bank 2. And perhaps do it multiple times in case of a bad connection.

If that doesn't fix the problem, swap over the bank 2 and 3 chips, then enable bank 2. If the parity error doesn't appear, that would really point to a bad chip, obviously now residing in bank 3.
Considering that you are not seeing an accompanying 201 error, perhaps it is the parity chip itself that is at fault - see [here].

 

[modem7]

I definitely plan to try the known working 360k drive I have in my AT on my XT, assuming fixing the movement of the head doesn't resolve the read issue. I just.. really don't want to take the AT out.. (it's been in the box most of its life and it's an AT so it weighs a ton. That and I just don't have space to bring it out most of the time). If or when I do try the AT's 360k drive, I will give Checkit a try for sure.

Good, because putting in the known-working (includes alignment) 360K drive is going to tell you a lot. It could save you a lot of time. For example, a stepping problem (consistent or intermittent) could be caused by the controller card. For example, a data problem (consistent or intermittent) could be caused by the controller card.
Obviously, if use of the known-working 360K drive removes all floppy related symptoms, then quickly, you have just eliminated the controller and cable as a problem source.

 

[modem7]

I'll respond to this first since it's where I made the most "groundbreaking" discovery.
I ran the head moving program (this time making sure to read the instructions and change the the lines in the code to use A: instead of B: ) and I got the head to move.
Immediately I noticed a very glaring issue. I had the head move to the same location then go back several times.
More than half the time, the head would be quite far off where it needed to be. I marked spots on the rail just to make sure I wasn't seeing things.

The rails themselves are very well lubricated, so the only reason I could think of this happening is that the stepper motor is more stuck than I realized (the motor seems fine to me as the head seems to move with light force, but then again, I've never owned a working TM-100 before so I wouldn't know. I've already attempted to lubricate it from the outside. But my best bet would be that my lubricant isn't able to fully penetrate the motor bearings.
Would that be a safe guess to make? If it were just an alignment issue, it would still be moving to the same spot consistently, correct?

The hardware involved in head stepping is much more than the stepper motor. Have a read of the description at [here]. At the high level, controller+cabling+drive need to be functional.

In that description is the 'track 0' sensor. That can get 'muck' in it causing problems. That (and associated circuitry) would be eliminated if you see stepping problems when repeatedly moving between two tracks (and not going back to track 0 during that test). E.g. Move to track 20, then move to track 30, then back to track 20, then back to track 30, ...

Again, try that known-working (includes alignment) 360K drive first, and prove that the problems are indeed caused by the drive.

BTW. Confirm for us that your drive (the only one on the cable) terminated.

 

[modem7]

The last thing I noticed. I noticed some of the wires on connector 5 on the floppy drive had been pushed out. I pushed them back into the connector and tested the continuity to make sure they were ok. It seemed fine, until I realized that everything except for the black and exposed wires were making continuity? I'm not sure if there's a short somewhere on the head itself or if it's just supposed to be like this. But I found it really weird. I checked to see if it was an issue with the main board itself, but none of the pins that connect to connectors 5 and 6 have this short. I've attached a photo of which pins are shorting out. The pins colored red are shorted on connectors 6 and the blue colored pins are shorted on connector 5.

You are diving too deep at this point. The 'heads' are coils, and therefore will be of low ohms.

BTW. In the 'Multimeter' section of [here], read my comment on the 'continuity' setting.

 

[modem7]

Regarding the apparent intermittent data issue.

Radial head alignment is only done for floppy interchangeability purposes; being able to read floppies formatted/written on other drives.
Radial head alignment is not done on hard drives.

As I wrote, one of the possible causes for your apparent intermittent data issue when reading known-good (including track position) floppies is the drive's radial head alignment being slightly off. Once you get the head stepping issue sorted out (irrespective of cause: controller or cable or drive or connections), and also be able to boot to DOS (e.g. XT-CF-Lite card), you then format a blank floppy in the suspect drive and see how other read/write operations perform on it. If all good, that would suggest a head alignment issue.

Assuming good floppy controller and cable, another way to boot to DOS would be to have your known-good drive as A: and the suspect 360K as B:
Per [here], only one drive is to be terminated.

 

[modem7]

Further regarding the apparent intermittent data issue.

Assuming that the floppy drive is at fault, something else yet to be verified is that the drive's spindle is not only rotating at 300 RPM (plus or minus the allowable deviation), but also consistently at that speed.
Spindle speed is discussed at [here].

 

[zanglucarson]

This could be as simple as a poor connection, and so if you haven't already, re-seat all of the RAM chips in bank 2. And perhaps do it multiple times in case of a bad connection.

It seems my chip puller is missing. I have a new one arriving in the mail today, I'll go ahead and give that a try as soon as it arrives. I did notice a few of the chips were slightly out of their sockets (mostly just banks 1 and 0), I pushed them back in with no change. Hopefully it's just a chip that needs re-seating like you said.

Considering that you are not seeing an accompanying 201 error, perhaps it is the parity chip itself that is at fault - see [here].

I'll certainly check. As far as I can recall since I started working on this computer, the 201 error hasn't presented itself.

Obviously, if use of the known-working 360K drive removes all floppy related symptoms, then quickly, you have just eliminated the controller and cable as a problem source.

I managed to get my AT out tonight and removed the 360k drive from it and put it in the XT.. and it worked! I was able to boot into DOS 3.30 and install it to the CF, so now I have DOS as a tool at my disposal.
I put CheckIt 1.0 onto my CF, and attempted to run it, but unfortunately, it requires 256k of memory so I'll have to sort out the RAM issue before progressing.
I believe that rules out the cable and controller as the issue.

 

[zanglucarson]

The hardware involved in head stepping is much more than the stepper motor. Have a read of the description at [here]. At the high level, controller+cabling+drive need to be functional.

In that description is the 'track 0' sensor. That can get 'muck' in it causing problems. That (and associated circuitry) would be eliminated if you see stepping problems when repeatedly moving between two tracks (and not going back to track 0 during that test). E.g. Move to track 20, then move to track 30, then back to track 20, then back to track 30, ...

BTW. Confirm for us that your drive (the only one on the cable) terminated.

Regarding the apparent intermittent data issue.

Radial head alignment is only done for floppy interchangeability purposes; being able to read floppies formatted/written on other drives.
Radial head alignment is not done on hard drives.

As I wrote, one of the possible causes for your apparent intermittent data issue when reading known-good (including track position) floppies is the drive's radial head alignment being slightly off. Once you get the head stepping issue sorted out (irrespective of cause: controller or cable or drive or connections), and also be able to boot to DOS (e.g. XT-CF-Lite card), you then format a blank floppy in the suspect drive and see how other read/write operations perform on it. If all good, that would suggest a head alignment issue.

Assuming good floppy controller and cable, another way to boot to DOS would be to have your known-good drive as A: and the suspect 360K as B:
Per [here], only one drive is to be terminated.

Further regarding the apparent intermittent data issue.

Assuming that the floppy drive is at fault, something else yet to be verified is that the drive's spindle is not only rotating at 300 RPM (plus or minus the allowable deviation), but also consistently at that speed.
Spindle speed is discussed at [here].

I plan on giving all of these a try, I mostly focused on getting DOS installed to the CF card yesterday. I'll respond to each post individually as I troubleshoot and give you the results, I just don't want it to seem like I'm overlooking them.

You are diving too deep at this point. The 'heads' are coils, and therefore will be of low ohms.

BTW. In the 'Multimeter' section of [here], read my comment on the 'continuity' setting.

Just read through this, did not know that about the continuity setting! I've always used that as my go-to for detecting short circuits. I won't be doing that anymore. The more you know

 

[modem7]

BTW. In the 'Multimeter' section of [here], read my comment on the 'continuity' setting.

Just read through this, did not know that about the continuity setting! I've always used that as my go-to for detecting short circuits. I won't be doing that anymore. The more you know

This is it. I can buy medical equipment on eBay, but that doesn't mean that I can then successfully diagnose people's medical problems. I need to know how to use the medical equipment, and in using that equipment, know what to expect in the way of readings/measurements. Etc.

( And if Mrs. Hausler is reading this, I am truly sorry that I diagnosed your lip lesion as bovine spongiform encephalopathy. )

An example of where I might use the continuity setting:

I have a 200 foot long cable, a cable that has 100 wires in it. I need to verify that there are no breaks in any of the 100 wires. If I was to use the resistance setting on my multimeter, I would need to glance at my multimeter every time that I move the probes to a different wire. My job would be much easier if I didn't need to look at the multimeter. That's where continuity mode helps me. After I move the probes to a different wire, the beep informs me of 'continuity' in the wire.

The continuity setting works for me there because, on my multimeter, the setting beeps on anything less than 100 ohms, and I am expecting the resistance of each wire to be in the rough order of 5 ohms (for that cable).

However, if I needed to ensure that end-to-end, no wire measured more than 7 ohms, then the continuity setting on my multimeter is not applicable. For example, if a particular wire is 9 ohms, my multimeter would beep. For this task, I will have to use the resistance setting, and glance at the multimeter every time that I move the probes to a different wire.