• Please review our updated Terms and Rules here

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

Ok a quick question the bughlt no68k error can that be caused by a bad memory card as well? Or would I see a different error? I think I did see a couple of time bughlt Memory error. So I am not sure.
 
Ok a quick question the bughlt no68k error can that be caused by a bad memory card as well? Or would I see a different error? I think I did see a couple of time bughlt Memory error. So I am not sure.

I doubt that anybody here knows what causes the "bughlt no68k" error. It was probably only known to the person or people who worked on that specific code in the 80s. Unless source code turns up somewhere, disassembling and reverse-engineering the binary code is probably the only way any of us will uncover this information.
 
If I was debugging this, I think I'd try to see if I could get any insightful failure messages from the diagnostic disk first. Then if that didn't pan out, I think I'd have to resort to finding the code the issues the "bughlt no68k" message, then disassembling and reverse engineering whatever calls that code to determine what behavior causes it to detect the error. For example, maybe it tries reading from a particular I/O port or memory location, and throws the error if it doesn't like what it sees? Then once I figured that out, I'd dig into the schematic diagrams to try to figure out what hardware is involved that might have failed. I don't think it'll be easy, but don't give up!
 
From what I was told the bughlt was a catch all error. Typical Microsoft. Same as the infamous Unrecoverable Application Error (UAE) in window 3.0

I have been trying to get the Diags to run with partial success. The MEMII which tests the Model II side of the computer runs without errors. And some of 68000-Z80 tests also run ok like the Bus Arbitration Test. The Memory refresh is partially working. Replaced a 74LS138 to get that going. Used to stop after the first iteration than throw an error. Now it gets to the 2nd error and passes then gets to the 3rd test and complains about memory decay. So errors after 3rd test.
Small progress. Also the interrupts seem to not be going right as well. So multiple errors. As I thought
 
Oh yeah in Model II mode it works fine. Can boot TRSDOS 2.0b, CP/M, LS-DOS all no problems. It's just that xenix is choking! So as a model II compatible it works great. No problems and the MEMII & SYST diags run just fine.

So now running the 68000 diags to try and narrow down where the problem is. So far it seems to be the refresh circuit acting up. And possibly the interrupts as well driven by the 9519 at U15 and it's associated circuits.
 
Ok ran a memory test and here is what I get! Really odd everything appears to be off by 10? And then what is causing it? Stuck bit? Not sure :confused:
Or does it not know how to test the 512K/1 Meg board?
 

Attachments

  • 100_1643.jpg
    100_1643.jpg
    95.8 KB · Views: 1
Ok ran a memory test and here is what I get! Really odd everything appears to be off by 10? And then what is causing it? Stuck bit? Not sure :confused:
Or does it not know how to test the 512K/1 Meg board?

Stuck bit, D4 on the Z80 side. As all accesses to the 68K memory from the Z80 are arbitrated and buffered by the 68K CPU board, something in the data path has D4 either shorted to ground (in the positive logic sections), shorted to 5V (in the negative logic sections), or open (in the negative logic sections). That something could be a bad RAM chip, a solder bridge, or a bad buffer, either writing the data incorrectly or reading the data incorrectly. Do all locations have the same bit set to 0, or does it vary at all?
 
Bad RAM on 68K mem board! Now running. Had to do quite a bit of chip swapping but isolated the bad RAM. Now full 1 meg and all is well and Xenix is running. I hate troubleshooting the symptom in this case no68k when it was the ram board all the time.

So everyone is probably asking Frank why didn't you run the RAM test earlier. Well I did but thought it might have been a conflict between the memory board possibly older test program being a newer memory board. (What I get for thinking) Well I was wrong and I admit it. Slaps self on wrist. You may all slap me to (virtually) that is!!! So all good and I am happy.

Till the next problem shows up!
 
Woohoo!

I guess that the "no68k" error just means that the Z80 isn't able to communicate reliably with the 68k board, and in this case it was because of the bad memory on the 68k side.
 
That's what it seems like. 68K couldn't talk to memory so gave up and threw the no68k error out there. As I said it is a generic error code. So if anyone in the future has the same problem. Look at the 68k mem board and run diags!!! what I didn't do and misinterpreted the mem test output when I did.
 
Can you share the MII and 68K diagnostic disk images that you used to troubleshoot? Thanks!
 
Thanks Pete and Mark and Kelly and Lowen and KC9UDX and all else who pushed me in the right direction. :p;):D

It's all on 1 disk. Check your PM pete!
 
You may all slap me to (virtually) that is!!! So all good and I am happy.

'Kay
smiley-slapping.gif


Mike
 
I am glad you were able to figure it out. I have to seriously work on imaging what documentation I have. It may not have helped in this instance, but it probably wouldn't hurt. I have at least four ten gallon totes full of radio shack documentation (brown binders) plus a bookshelf full.
 
Back
Top