• Please review our updated Terms and Rules here

Xebec in expansion unit issues

SpidersWeb

Veteran Member
Joined
Feb 16, 2012
Messages
2,701
Location
New Zealand
I'll update this again later when I've had a second go at it.

So I got my 5161 expansion unit running, but with an original (Variation #1 on minuszerodegrees) Xebec controller and ST412 the system will 99% of the time hang the machine if a drive is connected.
If I disconnect the control cable, I get a quick 1701 and the system boots. But with any drive (I tried 3) connected to the drive cable, it just sits there with a flashing cursor.

There is a flicker on the drive after the RAM test is finished, and on one single boot up I got it to keep the light on, try and read, and then give a 1701 like it should.

I tried a Variation #2 controller also, and it has the exact same symptoms.
Tried different cables.
Tried different power supply.
Tried 2 x ST412's and a ST225 - all exactly the same behaviour.

I booted the system with the cable disconnected, then connected it while the unit was running and did a low level format - the drive activated but recalibrated after every track during the format.

WD XT-Gen worked 100% no problems, low level formatted an ST225 via ROM tool with debug no worries at all.

Extender card is set to 0011 to add a wait state in the C000-CFFF range.

No other cards in expansion unit except receiver. Main unit has AST SikPakPlus, MDA clone, FDC and extender.

The expansion planar is missing it's +12V and -12V tantalum caps, however I wouldn't expect an MFM controller to need a stable 12V? If this is wrong, I'll solder on some replacements.

Any thoughts or ideas I'd be keen to hear.
 
Ok, removed the 5161 setup completely, and tried each Xebec inside the 5150 itself (I have a 200W PSU in there).

No 1701 no matter what I did. (No drive, missing data cable etc)
System did attempt floppy boot.
MS DOS starts booting then flashes the HDD and stops loading, on one occasion the system rebooted.

Also tried booting off HDD with no success (Disk boot failure).

Both cards did the same thing.

Moved a Xebec + ST412 to a 486SX I use for testing things, and it booted straight in to DOS. Not bad for a drive made mid-1984 that appears to have been last used in 1989.

So the problem is something in the 5150.

Edit: after replacing a blown tantalum cap on Variant #1, it now behaves semi - normal in the 5150 - providing a 1701 with no drive connected, flashing the drive at startup and attempting to boot if no disk is present.
However MS DOS 3.3 starts booting, flashes drive, loads a little more off floppy (a couple of seeks) then sits with the drive light on and motor spinning and does nothing. CTRL+ALT+DEL works and it repeats the process. [This is with the OTHER ST412 that may not be formatted for use with this controller]. I can't get to debug, but might try making an Adv Diag disk and seeing if that boots.
 
Last edited:
However MS DOS 3.3 starts booting, flashes drive, loads a little more off floppy (a couple of seeks) then sits with the drive light on and motor spinning and does nothing.
That sounds similar to what is described at [here], specifically, the last sentence of the 'Symptoms' section of the 'Bug #1' topic.
 
Thanks modem7. Turns out RAM was part of the issue - as a diagnostic move I removed the AST card, but didn't bother changing the memory switches (I figured it'd just error and get on with life) - but that actually causes MS DOS to fail booting, I was so focused on the hard drive situation I'd become a bit blind to it. With all that moving cards about, the controller actually had started working in the 5150 (My Variant #2 board + booting ST412). I think my Variant #1 board is just faulty.

So it booted when installed in the 5150 tonight, but now back to square one where it doesn't boot when it's in the expansion unit - not even off floppy or going to basic, just sits there flashing a cursor for eternity.
WD XTGen does (and not intermittently, that card works every time any time in the 5161 unit).

I replaced the two tantalum caps that were removed from the +12V line on the planar (with exact replacements), didn't make a difference however I noticed C1 the trimmer cap was destroyed - totally missing it's top piece. I'm digging around trying to find an XT board that looks so nasty I'll never repair it and use that. Is that trimmer cap just used for CGA stuff or would it actually cause an issue with the clock generated in the expansion unit? Because that might actually make sense for once.
 
The trimmer is useful only for CGA applications as the amount it tweaks the clock is very small--just enough to make it possible to get clear video. Some non-IBM CGAs have their own oscillator and avoid the issue entirely.
 
Cheers Chuck.

Out of curiousity I popped a scope on the clock pin on the ISA bus and I get a 4.77Mhz square wave only when the 5150 is connected and powered up. Seems to be working fine.

I'm not sure what the next step is.
 
.. however I noticed C1 the trimmer cap was destroyed - totally missing it's top piece. I'm digging around trying to find an XT board that looks so nasty I'll never repair it and use that.
Out of curiousity I popped a scope on the clock pin on the ISA bus and I get a 4.77Mhz square wave only when the 5150 is connected and powered up. Seems to be working fine.
The C1 trimmer is part of the 5161's 14.31818 MHz clock generator. As shown at [here], whenever the 5161 is powered on, you should see a 14.31818 MHz clock on pin B30 of the 5161's expansion slots.

Looking at the circuit diagrams of the IBM/Xebec controller's, I do not see the controllers using the 14.31818 MHz clock.
 
Recapping, the present situation is:

You have an IBM/Xebec controller (variant #2) and ST-412 combination booting successfully in your 5150. You simply move that combination (including same data/control cables) from your 5150 to the attached 5161, and get the symptom of, 'At POST, no progress past the flashing cursor.'

* Voltages in the 5161 per spec.
* Extender card switches set to cater for the IBM/Xebec controller's BIOS ROM.
* Cable is third-party, but length very close to what IBM used.
* WDXT-GEN controller is working in the 5161.

Questions/thoughts:

When you write that the WDXT-GEN "card works every time any time in the 5161 unit", confirm that that is the WDXT-GEN booting successfully from a hard drive (any drive).

In the 5161, is the receiver card in slot 8, per IBM direction ? (Always good to follow the makers direction.)

Reducing variables: When you move the IBM/Xebec controller to the 5161, are you using the same slot as you used for the WDXT-GEN ?

Are you sure that the extender card switches are set properly ? A hypothesis I am forming here is that the BIOS ROM on the IBM/Xebec controller is slower than that on the WDXT-GEN, definitely requiring a wait state, but for some reason (e.g. extender card switches not set properly, extender card switches faulty, extender card's wait state circuitry is faulty), not generating a wait state. Some bytes of the BIOS ROM successfully read by the CPU, others not.

You should be able to test that hypothesis by comparing a dump of the BIOS ROM when the IBM/Xebec controller is in the 5150, to a dump taken when the controller is in the 5161.
 
Thanks modem7, that's the kind of stuff I'm after as I often overlook things.
I did some retesting this afternoon.

Measuring directly at the two power input caps on the bottom of the Variant #2 board I see voltages within spec on the scope - however there is quite a bit of fluctuation on +12V
So I switched the PSU for the one that was in my 486 test box which had booted the combo just fine previously, no change to symptoms. This is the 4th PSU I've tried.

When you write that the WDXT-GEN "card works every time any time in the 5161 unit", confirm that that is the WDXT-GEN booting successfully from a hard drive (any drive).
I retested and...
WD XTGen booted MS DOS 3.3 off an ST-225 (previously the one I used for testing wasn't bootable because track 1 was damaged, so switched it for another, and DOS boots fine)
Tested Xebec+ST412 combo still hangs at cursor.

In the 5161, is the receiver card in slot 8, per IBM direction ? (Always good to follow the makers direction.)
Actually I had no idea this was in the manual, however that's where I put it since I first started testing.
Reducing variables: When you move the IBM/Xebec controller to the 5161, are you using the same slot as you used for the WDXT-GEN ?
In the retest, I made sure to use the same slot for both cards. I also used the same cables, and had the drives mounted in the same location.

Are you sure that the extender card switches are set properly ? A hypothesis I am forming here is that the BIOS ROM on the IBM/Xebec controller is slower than that on the WDXT-GEN, definitely requiring a wait state, but for some reason (e.g. extender card switches not set properly, extender card switches faulty, extender card's wait state circuitry is faulty), not generating a wait state. Some bytes of the BIOS ROM successfully read by the CPU, others not.

You should be able to test that hypothesis by comparing a dump of the BIOS ROM when the IBM/Xebec controller is in the 5150, to a dump taken when the controller is in the 5161.

Yes I've triple checked the extender card.
I used debug to dump the ROM of my Variant #2 Xebec while it was in the expansion unit (I can boot if I disconnect drive cable - generates a 1701 but allows the system to boot).
I downloaded the Xebec ROM from your website, and ran a file compare (using HxD hex editor for Windows) - no differences.


I'm not completely familiar with what happens when a disk request is made, and if it varies between older and newer controllers.
But I'm happy to do any tests and have a variety of hardware + the scope I can plug in if it might help diagnose.
 
Some more testing:

- pondering if it might still be power related, I piggy backed 4.7uF tantalums to the existing power caps (+5 and +12, 3.3uF) . No change.
- retried the original controller (Variant #1) still no dice
- reset machine back to 256KB and completely removed AST card
- tried alternative MDA card
- removed floppy controller
- moving and reseating both extender and receiver cards
- tried running two drives

No changes, it's pretty consistent about it.

One thing that is interesting (but doesn't help) is that setting the extender card to 0000 (no wait states) stopped the ROM from reading on start up - changing it back to 0011 fixed it - so the wait state stuff seems to be working. If I have the energy, I'll grab my spare 5160 motherboard and build a little desk system to see if it works on that (I don't have any working spare 5150 motherboards).
 
As a quick experiment, what about trying the IBM/Xebec card in slot 7 (i.e. right next to the receiver card) ?
Yeah I had tried quite a few combos including slot 7+8, even slots 2+1 as well.
Judging by the placement of card supports, I think it may have originally had the controller in slot 4 or slot 2.

I'm going to take my working 256K 5160, and try the controller from that, as well as trying to hook the expansion unit to it. If it fails as well, then at least it may help narrow things down a bit.

It doesn't even seem to access the drive, is the source available or anyone have knowledge on the start procedure for the card?
Also on the clock signal, I noticed it was 0 to 4V with an overshoot to -2, not sure if that's an issue or not as I haven't compared it to anything.
 
Actually it was slot 6, I tried, not 7, 7 looks like too tight of a fit without bending the card.

Anywho, tried the known good Xebec from the 5160 (another Variant #1) and still does the same thing.
Tried using the 5160 as a host instead of the 5150 and it counts to 640KB then just sits there with a flashing cursor - no errors, no disk access, just flashing away.

So ROM access is good, but obviously talking to the card fails somehow. It's like the computer sent off an instruction and is just patiently waiting but the answer never comes.


Edit: using the 5160 at the base I can see clear signals on the bus, including a busy address bus (guessing RAM refresh??) while it's sitting there waiting. No undershoot like when using the 5150, just 0 to 4 volt pulses. Also checked the 14Mhz clock and that was perfect despite the broken adjustment cap, and so was the 4.77 clock. I'm trying to think what the the Xebec might use that the WD doesn't - but coming up dry.
 
Last edited:
I realise that you guys may not be able to help here but I wanted to keep this updated. I apologize for the lack of specific detail.

So the WDXT gen was working great, then I did a livestream where I unboxed and fitted a new-old-stock IBM CGA card.
System fired up, network started, and as requested by a viewer I started alley cat which worked great.

Then, not remembering the key to exit Alley Cat, I rebooted the system - only to get a 1701.
From that moment on, the WDXT-Gen couldn't read the drives. I needed to low level format, and reinstall all my software again.

I then experimented with other controllers I had around. I lost track of which controller had which fault but the common fault I had with the WD's was after a bit of use - I'd magically need to low level format the drives again. With one WD controller, I got corrupted ROM contents (first time I'd seen this).

Then I tried non-WD controllers...
ST11M - seems to work 100%, but I keep getting "Bad drive" when the formatter hits a bad sector, even though I've mapped it out, BIOS 2.0
OMTI 5520 - seems to work 100% and this is what I plan to leave in it, fingers crossed it doesn't randomly trash the drives.

Network card (280 address, CC00 RAM address, IRQ 3) has worked fine the entire time, no faults :confused1: Racal-Interlan NI5210 8 bit.

During the installation of the CGA card, I would've disconnected/reconnected the cable but I always make sure it's screwed in tight.
This makes me wonder if perhaps the pins on the DB68's need cleaning and/or I should order another cable from a different supplier.

Keeping in mind the Xebec's still don't work - there has to be something awry here.


Edit: detail I should add here now that I've thought about it more, two specific situations:
- Alley Cat was being run direct off the network share after booting off the ST412.
- Another situation involved copying files to an ST225 off the network, after about 15 seconds of copying the drive suddenly failed - I was able to continue by running the software direct off the network share, but that drive had to be low level formatted again to be used.

So these two specific situations both involve the network card.
But I haven't had any errors with the network card, e.g. software runs fine off the network share with no bugs or hiccups.
 
Last edited:
Have you thought about the possibility of the software on the network share being infected with a virus? Is it on a machine with a scanner?

Bobby.
 
I'm fairly confident this is a hardware thing. e.g. the Xebec's still don't work in it.

Host is MS-DOS 6.22 running under VMWare Workstation on Ubuntu 14.04. I haven't scanned it recently however it doesn't happen on other PCs that use the network share and software is all from reputable locations (its a library I've slowly built up). So I can run a scanner on it, but I can't imagine myself getting off that easy.
 
Ok, so I'm done with it and it's working well enough that I'll just cross my fingers and hope it doesn't get worse.

Final changes were to use an ST11M and moving the network card to the main system unit.

ST11M - seems to only work with some drives, I have two ST412's with bad sectors - one it'd map them out, the other would give Bad Drive [4] - even though both are tested drives and the errors were in the defect map that I entered! (Also happened with ST225's, same scenario where it'd only work for some - and yes I retested multiple times).

WD XT Gen - ROM corrupt
WD XT Gen 2 - ROM ok but couldn't write
OMTI card - ROM ok but failed to start LLF
WD card, unsure model, basically an XT Gen - didn't initialise at all
Xebec - variants 1 & 2, 3 versions, none will work properly

I'd also seen some 5161's with video cards in them, dubious on wether this would work or not I tried a few tested MDA cards - only the parallel port function operated.

Honestly seems like if it's not C0000 to CFFFF or an IO port, it aint having any of it.

Also installed a SB Pro 2.0 - get sound in Prince of Persia and Carmen Sandiego but 8088 Corruption refuses to start with a Sound Blaster initialization error (I set the BLASTER variable correctly). 8088MPH works but no sound. Suspect that it may be a DMA thing - as the SB is in the expansion unit.

Moved NI5210 card to use D0000 and poped it in the main system unit. I would occasionally get hangups when copying from the card to the hard drive - moving it seemed to fix this.

Also reseated the cables multiple times.

Seems to be fairly consistent and happy now, but I know something is awry.
5161.jpg

Edit: the MDA card not working is likely because of my misunderstanding regarding the wait states - I still had it set to C0000 when I probably needed to change it to B0000.
 
Last edited:
Back
Top