Horizon 4000 mystery

[+InsaneMultitasker]

I've been trying to repair a Horizon RAMdisk 4000 and have run into a snag.

 

Using the minimem debugger, I can turn on the card and access the 8k/32K ROS (Ramdisk OS) chip at 0x4000-0x57ff. When I write even bytes to this space, I can read the byte back. When I write to the odd bytes, it always reads back as "00". I have tried both a working 8k and 32k chip, and set the jumper to 8k/32k with no change in symptoms.

 

In the rack space from 0x5800-0x5fff, both odd and even bytes work as expected. This 2k space is not part of the ROS 8k/32k chip; it is banked in from the rest of the on board sram chips. As a test, I placed the ramdisk in the Geneve, formatted it with the OS, and it reads/writes data just fine. (The geneve does not require the 8k/32k ros).

 

I reviewed the construction manual but haven't come up with any ideas or clues. It seems to me that a stuck address line would cause an odd read/write to overwrite an even address, yet that doesn't happen either.

 

Any ideas?

 

[+Ksarul]

I've been mulling this one over for the last two days. Your test data just poked a hole in my first thoughts there. Is it possible the data is being shifted to another address when you're trying to write the odd data? It might not show up in the even side if the stuck bit is being forced to zero. . .

[+mizapf]

Also note that the TI console always writes full words, and it writes its odd byte first, then the even byte.

Edited March 22, 2016 by mizapf

[+InsaneMultitasker]

Also note that the TI console always writes full words, and it writes its odd byte first, then the even byte.

So if the address line was being held low... if the odd byte was written incorrectly to the even address (on the chip) the TI's full write would result in 'fixing' the even byte to look as expected?

 

I've been mulling this one over for the last two days. Your test data just poked a hole in my first thoughts there. Is it possible the data is being shifted to another address when you're trying to write the odd data? It might not show up in the even side if the stuck bit is being forced to zero. . .

That's what I was thinking but couldn't piece together how it would be happening. I may have to try the card in the Geneve with a debugger to compare results given Michael's comment.

[marc.hull]

Just in case.... you do have the ti-geneve jumper set correctly when it's in the ti ?

[+InsaneMultitasker]

Just in case.... you do have the ti-geneve jumper set correctly when it's in the ti ?

Checked - the two jumpers are in the right spot. I also set the card to CRU 1700 to ensure nothing silly was going on with the Phoenix mod. (IMHO, removing the Phoenix and RAMBO mods would be a good thing - not missed and simpler - in a redesign).

[+InsaneMultitasker]

I found some memory locations such as 0x4400-0x440F where the 2nd odd byte held data. Again, no real pattern at the moment.

 

After messing around with the card in the TI, I stuck it back in the Geneve and loaded SBUG. When I inspected the 8K RAM I found that where the TI was reading 0s, I was seeing the data I input on the TI. For example, from 0x4000-0x400F I had entered "FF" for all 16 bytes. In the TI system it returned as "FF00FF00FF00FF00..FF00"; in the Geneve it returned "FFFFFFFF...FFFF".

 

The plot thickens.

[RickyDean]

A problem in the flex card or the chips inside the TI?

[ckoba]

Based on that last bit, I'd pull all of the '244s and '245s on flex/interface/HRD4000/TI interface (starting in reverse order). No point in testing them unless you're on a tight budget; replace all of them with sockets and 74ACT24x and your problem may well go away. And in the future, you're just a chip-pull and a quick TL866 test from verifying correct behavior.

 

I have a nasty habit of not checking to see if my PEB is off when I pull a card for testing, and I've blown a number of '244s on the interface card. You might have done something similar without noticing.

[+InsaneMultitasker]

Based on that last bit, I'd pull all of the '244s and '245s on flex/interface/HRD4000/TI interface (starting in reverse order). No point in testing them unless you're on a tight budget; replace all of them with sockets and 74ACT24x and your problem may well go away. And in the future, you're just a chip-pull and a quick TL866 test from verifying correct behavior.

 

I have a nasty habit of not checking to see if my PEB is off when I pull a card for testing, and I've blown a number of '244s on the interface card. You might have done something similar without noticing.

My current PEB still has the "jet engine" fan installed for exactly that reason. A quiet PEB is a dangerous PEB when testing cards. I installed a few bright LEDs in my last PEB to warn me that I was about to make a mistake.

 

I had not considered the flex to be a factor since the other peripherals have been working (including a Horizon 3000) with the same setup. I'll try to find my spare flex cable before I go down the chip replacement path, and order some parts in the meantime. This RAMdisk was used in a HSGPL system at one time; I wonder if the problem simply did not manifest there for the same reason as the Geneve. Hmmm.

[+mizapf]

In the TI system it returned as "FF00FF00FF00FF00..FF00"; in the Geneve it returned "FFFFFFFF...FFFF".

 

Just to rule out some other causes: If you write 01 23 45 67 89 AB CD EF FE DC BA 98 76 54 32 10 with the Geneve, do you get those bytes again?

[ckoba]

I mentioned this in PM to IM, but it's important enough to go out to the general audience: the HRD4000, if built per instructions, has a part specification flaw.

 

It specifies that 74HC154s for the chip demuxes. The rest of the logic is LS.

 

The problem is that CMOS-family devices can drive TTL logic, because CMOS logic is nearly rail-to-rail for 0 and 1. It cannot, however, reliably receive TTL-sourced signals.

 

TTL-family logic (F, S, LS, ALS, basically anything that doesn't have a C in it) has much looser tolerances for 0 and 1. I can't remember the low/high-end cutoff voltage for the LS (TTL) family off the top of my head, but it's several tenths of a volt higher/lower than the HC (TTL) family.

 

Sometimes, maybe even most of the time, plugging the output from a LS into the input of a HC works okay. It won't work 100% of the time. That's why the HCT family exists -- the T means that the inputs are TTL-compatible.

 

If you've got a mystery problem, especially with aftermarket or homebrew devices, have a look at the board and make sure that the logic family of each chip is congruent with the rest. If you've got one HC in a sea of HCT, you're fine, but if you have a HC with a bunch of LS you might have just found your problem. Replace it with a TTL chip and see if that doesn't make it go.

Edited March 23, 2016 by ckoba