HRD 4000B

[Gary from OPA]

2 hours ago, InsaneMultitasker said:

That's cool, seeing all of those cards in the same system    What is the device at >1400?  

It's the avpc card, but I am running my own custom DSR which is currently missing the device called VIDEO so not doesn't show up. My next update to my DSR I will add back the dummy VIDEO device so that appears.

 

I have P-CODE installed as well but of course the power switch is off so it doesn't appear, but at some point I going to mod it's DSR so I can leave it running as well.

 

I am still trying to figure out why the pgram card which is at 1700 doesn't like the SAMS card once I do that, then the only CRU address free will be 1C00 and when I can afford it that will be for the new IDE card by shift 838, which will be cool as I will then have all 3 types of hard drive storage working at the same time.

 

Need still to setup two more outside boxes for more floppy drives as well since I am running both myarc floppy and hdfc floppy I can have 8 physical floppy drives, but currently only got 2 drives on each, I need to find some more affordable 3.5 drives, to bring it up to all 8 from the 4 I have now, dual 3.5 1.44mb in one peb and one 3.5 720k and one 5.25 360k in the other PEB.

 

Also finding the right mixture to get both pebs running smoothly without any weird crashes was hard, I found having one flex cable on the left closest to the console and the TP sitting in the middle with the second flex cable on the axiom at the end was the only way it worked without data errors.

 

Plus the AMS needed to be in the PEB that is connected nearest to the console. I think that is also why currently the pgram doesn't work as I tried it in the second PEB, so there is some buffer lag with all these cards running and two firehoses.

Edited July 16 by Gary from OPA

[RickyDean]

On 7/14/2024 at 11:06 PM, NewcomerTI said:

I’m trying.  I had gone over this board trying to see where there might not be a connection made or where there may be an inadvertent solder ball or connection made where there should not be and I keep coming up empty handed. Still trying!

Hows it going, any good news yet. BTW, you probably have already thought of this, but have you tried changing out all the IC's, memory included with the other card and see if it works properly then? Also try the chips you remove from this card on the working one to see if it still works?

[Gary from OPA]

33 minutes ago, RickyDean said:

Hows it going, any good news yet. BTW, you probably have already thought of this, but have you tried changing out all the IC's, memory included with the other card and see if it works properly then? Also try the chips you remove from this card on the working one to see if it still works?

another good tip, is to test the 74 chips, i been using my T48 programmer, and checking all my chips, i found a couple of bad 259's and 244's that way. -- slowly trying to get my older horizons working, i got like 4 2000's and 2 3000s' i need to get working.

[RickyDean]

I have 3 4000's 1 old and 2 new that I've built and they were all working fine a year ago, But I hadn't used them since my PEB box issue and now, they all three are displaying issues. Some of these could be that I recently upgraded them all to 512k chips, and some of those came from China. Just got my seconds SAMS card function after finding a bad 74ls244, and got my second Corcomp fixed after finding I had a bad 74ls74 and a bad 9901. So slowly getting there, trying to get full size tipi's working now.

[NewcomerTI]

1 hour ago, RickyDean said:

Hows it going, any good news yet. BTW, you probably have already thought of this, but have you tried changing out all the IC's, memory included with the other card and see if it works properly then? Also try the chips you remove from this card on the working one to see if it still works?

I just tried that option yesterday without changing out the memory and my board still is not configuring but the other board works. I will try swapping out the memory while I’m at it to see if that may cause the issue, the card still lights up continually when it is plugged in and set to ‘on’. It overrides the disk controller - in that it won’t allow me to run any disk without first turning off the HRD 4000 and turning it back on. This temporarily allows the card to toggle the front blue LED. 
Thanks for the recommendation. 
Ray

[NewcomerTI]

56 minutes ago, Gary from OPA said:

another good tip, is to test the 74 chips, i been using my T48 programmer, and checking all my chips, i found a couple of bad 259's and 244's that way. -- slowly trying to get my older horizons working, i got like 4 2000's and 2 3000s' i need to get working.

Good luck on getting the older horizons working.  I'll keep posting any interesting new developments that I find. 

[RickyDean]

29 minutes ago, NewcomerTI said:

I just tried that option yesterday without changing out the memory and my board still is not configuring but the other board works. I will try swapping out the memory while I’m at it to see if that may cause the issue, the card still lights up continually when it is plugged in and set to ‘on’. It overrides the disk controller - in that it won’t allow me to run any disk without first turning off the HRD 4000 and turning it back on. This temporarily allows the card to toggle the front blue LED. 
Thanks for the recommendation. 
Ray

I doubt that it is the memory, but you could have one shorting internally causing an issue. If you get tired of trying to fix it, I'll be glad to see if I can find your issue. PM me if that time comes up.

[NewcomerTI]

I switched out the memory and that did not move the problem. The board that loads the ROS did so without any problem. I’m still having trouble with the card I built not able to load the ROS and giving ‘phantom’ cards show up in the CFG program. It also lights the LED in the front constantly when the console is turned on disallowing the disk access to run until I reset the RAM disk board (via the switch on the board) then I can run CFG 1.

On 7/27/2024 at 12:13 AM, RickyDean said:

If you get tired of trying to fix it - 

I’m not there yet still hoping to find something out on this board and learn something…

 

Ray

[Gary from OPA]

3 minutes ago, NewcomerTI said:

I switched out the memory and that did not move the problem. The board that loads the ROS did so without any problem. I’m still having trouble with the card I built not able to load the ROS and giving ‘phantom’ cards show up in the CFG program. It also lights the LED in the front constantly when the console is turned on disallowing the disk access to run until I reset the RAM disk board (via the switch on the board) then I can run CFG 1.

I’m not there yet still hoping to find something out on this board and learn something…

 

Ray

have you tried removing all the logic chips, totally, and just plugging in the bare 4000b board with no chips on it, to see if the led is on and the phantom part still occurs.

 

if so then its a problem somewhere on the board with the a short in one of sockets, or resister or diode.

 

if not, then i would try certain chips at first, just the 244's and 245's then just the 138's and then the 156's and then the 259's each stage testing to see what it starts that phantom operation, then you can narrow down what to look for.

[NewcomerTI]

Hope this answers the question…

I can turn off the switch of the CRU (switch 1) and the phantom boards go away and only the disk controller and RS232 board show up (LED remains out on the front of the RAM board). As a note as soon as it is made say in the 1700 position the LED comes on and stays lit until I toggle the reset button (switch 2).  

[Gary from OPA]

28 minutes ago, NewcomerTI said:

Hope this answers the question…

I can turn off the switch of the CRU (switch 1) and the phantom boards go away and only the disk controller and RS232 board show up (LED remains out on the front of the RAM board). As a note as soon as it is made say in the 1700 position the LED comes on and stays lit until I toggle the reset button (switch 2).  

i know you mentioned that before, but for fun of it, no harm in trying, remove all the chips, leaving in dip switch set as you have it, and see what happens.

 

then just add the 244's and 245's

 

then just add the 138s

 

then add the the 259s

 

then add the 156

 

and finally the 241

 

and if still ok, then add the 8k/32k dsr chip

 

if possible do these tests without the 32k onboard as ram, if you have a 32k memory card.

 

it should fail if logic is correct around when adding the 156/241 chips, then you need to carefully check out all the wiring from those sockets to the 259's to make sure their is no shorts.

Edited July 30 by Gary from OPA

[NewcomerTI]

I will attempt this sequence with the switch in the circuit and try to determine which one sets the LED on.

[Gary from OPA]

4 minutes ago, NewcomerTI said:

I will attempt this sequence with the switch in the circuit and try to determine which one sets the LED on.

have you tried as well, taking the 74ls logic chips from your working 4000b and placing them on your screwed up version.

 

i know you tried swapping the ram, but it would be worthwhile to try the other logic chips as well.

 

if you have a programmer like the t48 you can also test them on it, each 74ls chip that is worthwhile.

 

i didn't mention the 74hct154 chips in my earlier writeup, but those should not matter as they mainly just to select the various 128k/512k chips on the ramdisk part, outside of everything.

[NewcomerTI]

No LED on a bare board.

 

scenario.         LED         Phantoms?

 

Added 244’s

and 245 chips.  No.              No.

 

added 138’s.     No.              No. 
added 259’s.     No.              No.

added S00N      No.              No. 
added 139.       Yes.             No. 
       note:    CFG   Loaded from disk

(removed 139 chip)  wasn’t on your list

added 156.        No.             No. 
added 241.        No.             No. 
reinserted 139.  Yes.            Yes

 

error in trying to load CFG. can’t access the drives - had to toggle sw2 to get CFG to load. 

I’m assuming I should be looking at the socket for the 139 chip, correct?

 

 

[Gary from OPA]

2 hours ago, NewcomerTI said:

I’m assuming I should be looking at the socket for the 139 chip, correct?

 

 

Yes, best to look at everything around the 139 socket. Try another 139 as well, and then spread out from there what feeds the inputs, you have the 00 chip and it's resistors and the jumpers and the diodes again. All that needs to be doubled checked. Compare it to your working board with a meter changing to see both are the same. Look at the schematic and see how the 139 is connected to the other chips.

[RickyDean]

I'm working to fix another's 4000B and in the process I've discovered I have an issue myself.

I built two Horizon 4000B's back about 5-3 years ago and they were working fine.

They've been laying in storage for a bit as my PEB's were broke, now resolved, and I had populated them with max 1 layer of 512k chips.

One of them is giving me errors about U2B, and I'm suspecting that it needs to have the second 154 chip installed due to being over 2 mb in size. The other however is giving me errors about the U9 sram chip and I've tested it with three different 32k chips. These chips test good in my minipro. I've also removed all the 512k chips with no success.

I've tested all the logic chips except the 154 and the 259's and I replaced the 259's, so would I be looking at the 154 or should I be looking at a diode or transistor?

Bear in mind that this was working fine some years ago and it has no damage on the board.

 

I just placed a 2nd 74ls154 in the socket designed for it, and the first ramdisk checked U9 just fine. Running more comprhensive testing now. Learned me something tonight.

Edited August 25 by RickyDean

[RickyDean]

When testing a Horizon 4000/4000B using the Megtest, is it testing the first two chips M0 and M1, if they are 512k chips? When I did the comprehensive adress test in TST i got some errors, suspecting some of the Chinese procured hitachi 512k chips as the culprit. So I want to move them around.

[+Ksarul]

You should only need a second 154 if you start putting chips on the second layer--which generally only comes into play if you are using 128K RAM chips. The board is designed to operate with either 8K or 512K chips in one layer with a single 154.

[RickyDean]

5 hours ago, Ksarul said:

You should only need a second 154 if you start putting chips on the second layer--which generally only comes into play if you are using 128K RAM chips. The board is designed to operate with either 8K or 512K chips in one layer with a single 154.

Understood what you're saying, but the manual states

"Note 1: One 74HCT154N will support 2M of 128K x 8 memory. Boards populated with
between 2M and 4M require a second 74HCT154N (a space for this is provided on the board).
These chips must be the .300 skinny-DIP “J” package."

 

And when I placed in the 2nd 154 the U2B message went away on the next test. And when I did the Megtest using first the option just to test U!! and then the 1st meg, there was no errors. Bear in mind this is the 1st time I've ever had a fully populated board with 512k chips. I was going to remove the Hitachi chips today and replace with my Allianced Memeory chips from Mouser and see if the errors go away during the #5 option and doing a comprehensive testing.

[+Ksarul]

3 hours ago, RickyDean said:

Understood what you're saying, but the manual states

"Note 1: One 74HCT154N will support 2M of 128K x 8 memory. Boards populated with
between 2M and 4M require a second 74HCT154N (a space for this is provided on the board).
These chips must be the .300 skinny-DIP “J” package."

 

And when I placed in the 2nd 154 the U2B message went away on the next test. And when I did the Megtest using first the option just to test U!! and then the 1st meg, there was no errors. Bear in mind this is the 1st time I've ever had a fully populated board with 512k chips. I was going to remove the Hitachi chips today and replace with my Allianced Memeory chips from Mouser and see if the errors go away during the #5 option and doing a comprehensive testing.

You are correct as far as 128K chips are concerned. 16 128K chips gives you one full layer and 2M. Anything more than that, and you have to insert the second 154 and connect wires from the set of pads immediately to its left and right to the chip selects of the second layer of 128K chips. The second 154 has no output functions without those wires.

 

When using 512K chips (and changging the jumper blocks on JP1 and JP3 to the 512K position), the board is now set up so that up to 16 512K chips can be installed (you must follow the correct installation pattern from the manual when installing less than 16 chips). This gives you 8M maximum on the board--with a single 154. That's generally how I build them, usually with Alliance chips, but I have used others at times to test.

[RickyDean]

1 hour ago, Ksarul said:

You are correct as far as 128K chips are concerned. 16 128K chips gives you one full layer and 2M. Anything more than that, and you have to insert the second 154 and connect wires from the set of pads immediately to its left and right to the chip selects of the second layer of 128K chips. The second 154 has no output functions without those wires.

 

When using 512K chips (and changging the jumper blocks on JP1 and JP3 to the 512K position), the board is now set up so that up to 16 512K chips can be installed (you must follow the correct installation pattern from the manual when installing less than 16 chips). This gives you 8M maximum on the board--with a single 154. That's generally how I build them, usually with Alliance chips, but I have used others at times to test.

Well that's what I'm trying to get across. With a full (16) 512k chips and only (1) 154 chip, when I ran the Megtest and tested only the U11 option, it gave me some good test values then started saying that there are issues with the U2B pins.

Now when I removed the 2nd 154 and run the same test, U11 tested good without the U2B pins being mentioned, don't have a clue as to why they were mentioned at all in the initial test that led to me installing the 2nd 154, but they aren't showing at all now with the 154 removed.

BTW, How do these U#'s correspond to the M#'s on the 4000B board, so I can know which one I'm looping and testing? Would make it easier than moving 512k chips around trying to find the bad ones. The M numbers start at 0, ie:M0, M1, etc. Is that defined in the manual?

Edited August 25 by RickyDean
spelling

[RickyDean]

Well I now have all 3 of my Horizon 4000's operational, (2) 4000b'S AND (1) 4000.

the second one (the one that wasn't working at all), turned out that when I was checkimg the logic chips, when I plugged it back in, the pin 11 leg folded up directly double and wasn't working.

After finding it and straightening it, the Ramdisk is working running test's on it now. The U9 passed already, performing the Megtest now.

Still haven't figured out why the 1st one was checking the U2B pins, the second 74ls154 socket, the first test though.

Edited August 26 by RickyDean
added content