• Please review our updated Terms and Rules here

Newly aquired Tandy 6000HD! Lots of questions to follow...

I have lost what remaining hair I had trying to figure out what is wrong with this 68K board. I checked the data lines and address for shorts to ground. None.
Also to 5 volts same none. All mods done on rev A. board. Even upped the power supply +5 volts from 5.01 to 5.15 according to service bulletin. Where by you add a 10K resistor in parallel with R40. That didn't get it going either.
 
Have an idea for the inventor types out there. Extender boards for the II,12,16,6000. It is nearly impossible to work on boards in a card cage without one. Or an extender cable. 80 pin edge to 80 pin socket.
 
An extender would be handy, but I don't see the required 80 pin 0.125" pitch female card edge connectors in stock at Mouser or Digi-Key. :(
 
Does your 68k board have "dog ears"? That is, does the headers for the memory cards stick out a bit and there is a cut out space between them? If so, they will not run Xenix 3.x. There are no mods publicly available to make them run Xenix 3.x.

If the edge of the board is straight across, then you have to make sure U34 has an upgraded PAL. Checksum on the sticker should end in D4. If not, then it will also not run Xenix 3.x.
 
Remember this used to run Xenix 3.x! So it has the right PAL's in it. Had it installed on the hard drive and booting Xenix.

Then it started dyeing a slow death. It is a 8 MHz board.

Now whenever trying to start Xenix the bughlt no68k error shows up. Every time.

Did what I could to try to get it going again. Reseat socketed chips. Clean edge connector clean header pins which connect to memory card. Replaced any chip that is socketed with another like chip reheated solder joints. Clock circuit? memory refresh circuit?

If any of the PAL chips went bad or the PROM at U50 then I am pretty much screwed there.
 
The Tandy solution at this point back in the day would have been "Replace the 68K CPU card". I suggest trying to find another 68K CPU card (I know...easier said than done) or go into detailed chip-by-chip testing of the board. Unfortunately, when it comes to these machines I have found that you need a few donor/test systems on hand to keep 1 working well.
 
I sure share your frustration, but this doesn't sound like a simple mechanical failure since reseating chips and cleaning contacts doesn't fix the problem. Can you run any of the diagnostics that are available (if I recall correctly) on billdeg's site? I was fiddling with one of the diagnostic disks on my Model 12 on Saturday evening when my power went out for 18 hours due to local lightning taking out a nearby pole.
 
I'm also curious about the specific hardware behavior that triggers the "bughlt no68k" error message. But unless one of the original Xenix developers drops in here, the only way we're likely to figure this out would be by reverse-engineering the code, and that task is probably a bit too advanced for me at this time.
 
I do have the diagnostics disk titled z8068000 it has a few diags for the 68k board.

Specifically the ND68 test program. Which has run successfully in the past. Now when I run it I get loading program into 68000 memory then is says executing program then after about a minute I get an error screen Z80 - 68000 something about not communicating which makes sense.

I also ran the MEMII test to test the basic system and all passed there. This does not touch the 68000 board at all.

Next time I run the ND68 I will take some pics of the error I am getting.
 
NF6X said:
I'm also curious about the specific hardware behavior that triggers the "bughlt no68k" error message. But unless one of the original Xenix developers drops in here, the only way we're likely to figure this out would be by reverse-engineering the code, and that task is probably a bit too advanced for me at this time.
Click to expand...

The one person to ask would be Frank Durda IV, as he maintained the z80ctl codebase. And due to Bob Snapp making Tandy Support's job more difficult, Frank put in intentionally obfuscated code to try to thwart patching of z80ctl (even if Snappware's software was at fault, customers demanded that Tandy fix the problem; there's a post on comp.sys.tandy out there detailing that frustration). Frank is very busy these days, and likely wouldn't have the time to try to dig that source up (he has sources of z80ctl on 8 inch disks). Oh, and one thing to know about Frank: the more people ask him about something, the less likely that he will actually do that something (he said as much in multiple comp.sys.tandy posts over the years; while Frank is a nice guy and his information is golden, he has a very low tolerance for people making too many requests of his free time).

Reverse engineering of z80ctl will be absolutely required for any patching of the hard disk driver in Xenix to use the Lo-Tech IDE solution.
 
Last edited:
lowen said:
The one person to ask would be Frank Durda IV, as he maintained the z80ctl codebase. And due to Bob Snapp making Tandy Support's job more difficult, Frank put in intentionally obfuscated code to try to thwart patching of z80ctl (even if Snappware's software was at fault, customers demanded that Tandy fix the problem; there's a post on comp.sys.tandy out there detailing that frustration). Frank is very busy these days, and likely wouldn't have the time to try to dig that source up (he has sources of z80ctl on 8 inch disks). Oh, and one thing to know about Frank: the more people ask him about something, the less likely that he will actually do that something (he said as much in multiple comp.sys.tandy posts over the years; while Frank is a nice guy and his information is golden, he has a very low tolerance for people making too many requests of his free time.

Reverse engineering of z80ctl will be absolutely required for any patching of the hard disk driver in Xenix to use the Lo-Tech IDE solution.
Click to expand...

Would be awesome if Frank D dropped in here occasionally. I think he would like to know folks are still playing with some of his creations after all this time. As you said, his posts are worth their weight in gold for this community.
 
Well I found something odd. I wired up 2 jumper wires to the 5V line on the 68000 board and ran them out the back. I hooked up a meter and my 5V is reading between 4.5 & 4.7 volts. That seems low to me.

Especially after a tech bulletin said to modify the power supply to up the voltage from 5.05 to 5.15 measured at the floppy connector which I did. This was to help with Xenix errors.

@Lowen I did send an email to Frank. Wonder if he will respond?
 
That voltage does look low to me, too. Right about where I'd expect things to start getting flaky, in fact!

If we start from a hypothesis that the 68k board is seeing low voltage, then the next step is to figure out why. Is the power supply itself outputting the proper voltage? Is the 68k board drawing excessive current which is dragging down the voltage? Is the voltage dropping at the power supply, through the interconnect, or on the 68k board itself?

It'll take some effort to look into this due to the accessibility issues of cards in cages, but if power interconnect might be the issue then this needs to be done with the cards in place and not on an extender anyway. You'll need to figure out the physical path that the +5V takes from the power supply to the 68k board, and measure the voltage at various points along that path to get an idea of what is going on.

There could be something drawing too much current on the 68k board due to a failure, or a weak power supply, or too much power wiring resistance for the load being drawn, or some combination of those. But measuring the power on the 68k board with it installed like that was a good first step, and might just point towards the issue that you are seeing.

Edited to add: I have zero experience debugging one of these systems yet. I'm just talking about generic electrical principles here, and guessing about what I might do next if I saw the same symptoms in my own system.
 
Oh, and one more thing: DO NOT just crank up the power supply voltage more to see if it fixes the problem. That could apply too much voltage elsewhere in the system and fry things very badly. You'll need to methodically probe around to find out what is really going on without blindly changing anything in the process.
 
Disregard my alligator clips I was using to connect to the meter were flaky. I tossed them! I measured right at the pigtail wires I added to bring to the outside with a meter and got 5.14 volts.
 
You must log in or register to reply here.
Back
Top