PDA

View Full Version : IBM Music feature card problems



per
August 25th, 2010, 04:20 PM
Note, the following problems have been present since I obugth this card, but I have not tried to examine the problem before now.

Recently I discovered a problem with my IBM Music Feature Card. This problem is the fact that it doesn't seem to activate the IRQ line properly, and thus it can't comunicate with the host computer. This doesn't stop the card from working (as the host-computer can comunicate with the card perfectly fine), but it prevents programs like "Composer" to work.

Ok, so there must be something wrong with the IRQ generating cirquits... According to the IBM MFC techref, only 4 devices on the card can produce interrupts. That's the TxRDY, RxRDY, Timer A and Timer B. All of those signals are or-ed together, then masked, and then run through a tristate-buffer which can completely mask the signal too. Several status-registers will provide internal information about the interrupt state of the card.

So it can be several things that have gone wrong:

The interrupt signal the program is looking for isn't being generated by the spesific device on the card.
The OR gates combining the interrupts are failing.
The AND gate masking the main interrupt signal has gone bad.
The signal going from the total control register to the AND gate is permanently low.
The tristate buffer is tristating when it shouldn't.
The NOT gate treating the signal from the total control register is misbehaving.
The signal going from the total control register to the tristate buffer is permanently low.
Some conductor on the PCB is broken.


Now, I recently did some testing on this (In Debug). What I did was to unmask all interrupts ("o 21,00"), and set up timer A to generate an interrupt. After this, I verified that the interrupt signal had reached the total status register properly (something which it had), and then I tried to do an "i 20" command to se if the interrupt was invoked. The "i 20" returned zero, so I assume the fault must be somewhere in the masking.

I only found one chip that tristate independent signal, which is U11 (74LS125AP). Now i only has to find what output goes to the interrupt lines, then I need to test this with a multimeter (something I am very unhappy about since multimeter probes often slip).

-----

My question to you is:
Did I do something wrong while testing? I am unsure if Debug automaticly clears interrupt lines, or if this is done by some other routine in the BIOS (unless Debug takes over the IRQ vectors). I will not try to test with a multimeter before I am 99% certain that chip is the problem.

Cloudschatze
August 25th, 2010, 06:00 PM
I've encountered the same problem using three different IMFC cards in my 486 system. It seems to be an issue with the KAPI driver and "faster" systems:

http://groups.google.com/group/comp.sys.ibm.pc.hardware/msg/bad5330e456da458?dmode=source
http://groups.google.com/group/comp.sys.ibm.pc.misc/msg/7b89b5ef659f64e8?dmode=source

Have you tried it in either of your PC/XTs?

mikey99
August 25th, 2010, 06:03 PM
I don't know much about the Music Feature card or this level of testing, but if another forum member has
the same card and could try the Debug test would help verify this.

For the multimeter try using some of those mini-grabber leads .... you can clip them on the IC pins before
powering up. Or some normal probes with a very fine point to reduce the chance of shorting to another pin.

per
August 25th, 2010, 09:19 PM
I've encountered the same problem using three different IMFC cards in my 486 system. It seems to be an issue with the KAPI driver and "faster" systems:

http://groups.google.com/group/comp.sys.ibm.pc.hardware/msg/bad5330e456da458?dmode=source
http://groups.google.com/group/comp.sys.ibm.pc.misc/msg/7b89b5ef659f64e8?dmode=source

Have you tried it in either of your PC/XTs?

Yes, I have tried it in both of my XTs, and I have even tried withouth the IRQ jumer installed at all. Same ressults in all of the cases.

When I get time I'll make a small program that properly tests the interrupt state.

per
August 30th, 2010, 03:43 PM
I have now completed my test program I will use to test the card with, something I will do as soon as I get the time. In the meantime I would just like to share the program in case anybody else finds it usefull.

Description:
This program is a crude thing hacked together by me with the sole purpose of monitoring incoming IRQ signals, while providing some manual controll of the system bus. As a ressult, this software is not a piece-of-art and userfriendliness wasn't even on the agenda while designing it. It works in the wat that every function in the program got its own keyboard key, and when certain keys are pressed, the corresponding functions are executed in the program. Every time an IRQ line is triggered, the program will register it and add one to the respective counder, which is updated durning the next cycle of the program. I originally planned to make some sort of GUI-ish interface, but I threw that idea away due to the fact that GUI-ish things are a pain-in-the-@rse to program in ASM.

Features:
The program is capable of detecting any signal of the IRQ lines, while allowing the user to peek/poke anywhere in the first 1MB of memory. It also allows the user to manually do I/O from/to any of the 64K lower I/O ports, and it allows the user to emulate incoming IRQ signals by calling the Interrupt routines through software.

Disclaimer:
This program is 100% hackware, which means that you will problably not be sharing it at all. However, if you do; you must do it for free. You also use this program at own risk, and I take no responsibility if you mess up something in your computer using this program.

***File removed because it turned out to be so slow that it was almost impossible to use it in a 4.77MHz PC/XT***

per
August 31st, 2010, 01:04 PM
I tested the interrupts today, and the strange thing is that the IRQ signal from the timers actually generates an interrupt.

This means that the IRQ line itself isn't the main problem, and what can be the problem is now limited to:

Something is wrong with the TxRDY/RxRDY signal generator.
Program expects the card at a different IRQ address (I curently use IRQ3).
System resource conflict (VGA card/AST sixpackplus/AT-style HD floppy controller/XT-IDE).
Timing fault, due to the card being used in an XT;
- maybe due to slow CPU/System speed.
- maybe due to the fact that this system got the unpatched rev 0 PCB.
- maybe due to some issues with the early XT BIOS.


Any thoughts? I would be glad if anybody got the ability to test a known good card in another XT with about the same contnents as mine.

Cloudschatze
September 1st, 2010, 11:17 AM
I'm still of the opinion that the KAPI driver has timing issues, but since I lack an XT to test with, you may want to check with Trixter.

Just for grins, which address do you have the card set to, and have you tested with any other IMFC-compatible software (Sierra's SCI0 games, the FM-PAK utilities, etc.)?

per
September 1st, 2010, 11:25 AM
I'm still of the opinion that the KAPI driver has timing issues, but since I lack an XT to test with, you may want to check with Trixter.

Just for grins, which address do you have the card set to, and have you tested with any other IMFC-compatible software (Sierra's SCI0 games, the FM-PAK utilities, etc.)?

Most of the sierra games relies on I/O, and they don't require interrupts. I have tested silpheed without the interrupt jumper present, and it still works.

FMPAKA works for the most parts. However, when I try to enter voice-edit mode, it fails with the message of "unable to access synth". Same ressult withouth the IRQ jumper present.

I have now tested a little more, and I get quite unusual ressults. It interrupts quite random when it is supposed to interrupt, but for some reason it seems more stable at IRQ3. I don't know if this was just random or not.

When the interrupt fails, the total IRQ register shows no interrupt for some reason (while the devide making interrupt actually produces an interrupt signal). As of I have understood, this is not supposed to happen, and there may be something wrong with the OR gates.

Cloudschatze
September 1st, 2010, 11:43 AM
Most of the sierra games relies on I/O, and they don't require interrupts.

Right. If these hadn't worked, I would have suspected that an address other than the default was being used.


FMPAKA works for the most parts. However, when I try to enter voice-edit mode, it fails with the message of "unable to access synth".

I don't recall whether I tried the voice-edit mode or not. I'll check to see if I get the same message later this evening.

Edit: I do not receive these errors, so I'm not exactly sure what that may suggest regarding your card. Possible hardware fault?

Frankie
September 3rd, 2010, 07:19 PM
If I were you, I'd thoroughly inspect the card for any physical damage, you never know if your problems are being caused by a loose soldering connection. Also it wouldn't hurt to clean the ISA connector with a q-tip and rubbing alcohol, just in case it's dirt that's not allowing the IRQ from going through...

per
September 4th, 2010, 01:28 AM
If I were you, I'd thoroughly inspect the card for any physical damage, you never know if your problems are being caused by a loose soldering connection. Also it wouldn't hurt to clean the ISA connector with a q-tip and rubbing alcohol, just in case it's dirt that's not allowing the IRQ from going through...

Oh, well, I found some rust on the legs of two ICs, so I guess this board has not been stored under optimal conditions at one opint.