Jump to content

Photo

Horizon 4000 mystery

Horizon RAMDISK

11 replies to this topic

#1 InsaneMultitasker OFFLINE  

InsaneMultitasker

    River Patroller

  • 2,364 posts

Posted Mon Mar 21, 2016 10:39 AM

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? 

 



#2 Ksarul OFFLINE  

Ksarul

    Quadrunner

  • 5,146 posts

Posted Mon Mar 21, 2016 5:13 PM

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. . .



#3 mizapf OFFLINE  

mizapf

    River Patroller

  • 3,506 posts
  • Location:Germany

Posted Mon Mar 21, 2016 6:54 PM

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


Edited by mizapf, Mon Mar 21, 2016 6:55 PM.


#4 InsaneMultitasker OFFLINE  

InsaneMultitasker

    River Patroller

  • Topic Starter
  • 2,364 posts

Posted Mon Mar 21, 2016 7:28 PM

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.



#5 marc.hull OFFLINE  

marc.hull

    Stargunner

  • 1,297 posts
  • Location:Oklahoma CIty.

Posted Mon Mar 21, 2016 7:45 PM

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

#6 InsaneMultitasker OFFLINE  

InsaneMultitasker

    River Patroller

  • Topic Starter
  • 2,364 posts

Posted Mon Mar 21, 2016 10:25 PM

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).



#7 InsaneMultitasker OFFLINE  

InsaneMultitasker

    River Patroller

  • Topic Starter
  • 2,364 posts

Posted Mon Mar 21, 2016 10:53 PM

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.



#8 RickyDean OFFLINE  

RickyDean

    Stargunner

  • 1,059 posts

Posted Tue Mar 22, 2016 5:42 AM

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



#9 ckoba OFFLINE  

ckoba

    Moonsweeper

  • 271 posts

Posted Tue Mar 22, 2016 6:34 AM

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.



#10 InsaneMultitasker OFFLINE  

InsaneMultitasker

    River Patroller

  • Topic Starter
  • 2,364 posts

Posted Tue Mar 22, 2016 9:18 AM

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.



#11 mizapf OFFLINE  

mizapf

    River Patroller

  • 3,506 posts
  • Location:Germany

Posted Tue Mar 22, 2016 9:24 AM

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?



#12 ckoba OFFLINE  

ckoba

    Moonsweeper

  • 271 posts

Posted Wed Mar 23, 2016 2:44 AM

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 by ckoba, Wed Mar 23, 2016 2:51 AM.






Also tagged with one or more of these keywords: Horizon, RAMDISK

0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users