Jump to content
InsaneMultitasker

Myarc cards for sale/repair tips

Recommended Posts

 

always bothered me that this wasn't well labeled as to where the hell pin1 is.. I assume its on the bottom based on this photo.. since I just moved (and again neglected to take pictures before unplugging) just confirming that..and where pin1 on the index cable is

 

Greg

I think you're right Greg, I'll check one of the cards for you to be sure. I remember using a black Sharpie to color the pin 1 from connector to connector, particularly on those 20-pin cables. Pretty sure pin 1 is on the 'bottom' for all connectors. Does the HFDC manual point this out anywhere?: I don't recall.

Share this post


Link to post
Share on other sites

My HFDC manual states the lower end of each connector is pin 1, when the card is upright in the PEB.

If you look at the photo, there is a number two showing. It generally follows on these devices that the connector on the other side corresponds to connector 1.

  • Like 1

Share this post


Link to post
Share on other sites

My HFDC manual states the lower end of each connector is pin 1, when the card is upright in the PEB.

Thanks!

 

Sent from my LM-G820 using Tapatalk

Share this post


Link to post
Share on other sites

If you look at the photo, there is a number two showing. It generally follows on these devices that the connector on the other side corresponds to connector 1.

excellent point! Now I really want to go look at a few cards to see if they all have that '2' and if there is a '1' on the other side of any of them. :)

Share this post


Link to post
Share on other sites

I

 

excellent point! Now I really want to go look at a few cards to see if they all have that '2' and if there is a '1' on the other side of any of them. :)

'll look at my two tonight, and I do remember that on a recent HFDC repair that, that HFDC, had this 2 on it.

Share this post


Link to post
Share on other sites

All of the HFDCs that I have (3) have the 2 on them. They were bought at different times too, so multiple lots of the circuit cards had them.

  • Like 1

Share this post


Link to post
Share on other sites

I took pictures of two cards. On the older revision card the '2' and '34' numbers are partially cut off. This isn't consistent among the older cards I have on the bench. It appears the final run (lighter green card, #41) cut off less of the edges on either side of the connector. The lighter green card style was problematic in that many of the boards had one or more shorted traces. In many cases the mask was missing in spots on the adjacent traces. Spent many an hour staring at boards BITD, looking for shorts...

post-25764-0-65790300-1557447788_thumb.jpeg

post-25764-0-29985300-1557447810_thumb.jpeg

  • Like 2

Share this post


Link to post
Share on other sites

I

 

'll look at my two tonight, and I do remember that on a recent HFDC repair that, that HFDC, had this 2 on it.

Mine look like the one with the 2 cut in half, like Insane One's lower picture.

Share this post


Link to post
Share on other sites

Spent some time today troubleshooting the last HFDC on my bench.

 

The card had been jumpered for use with a PC power supply and at some point was placed in a standard PEB. I've been chipping away at the problems over time and was left with an issue in the floppy drive circuitry. Since the hard and floppy ports share many of the same logic chips I was able to "rule out" some things.

 

Today I picked up the card and ohmed out the floppy circuit. Then it dawned on me: what about the 8Mhz crystal attached to the floppy disk separator (9216B) chip. So I unsoldered a crystal from my own HFDC and soldered it into the problem HFDC. The floppy disk cataloged on the first try.

 

Before today, I don't think I've ever had to replace any crystal on an HFDC card. Yet another 'first' ;)

 

Now I just need to track down a possible intermittent connection which I hope can be cured by replacing a few of the single-wipe sockets. Will be nice to get this card back to its owner.

  • Like 6

Share this post


Link to post
Share on other sites

Spent some more time working with the HFDC in the previous post. Everything works as expected with one exception: it will not format a hard drive. The card will format, read, and write floppy disks. The card will also read and write hard disks. When I encountered this problem in the past, the read/write transceivers caused the problem. I've replaced those chips and the circuitry all the way back to the 9234/9226 chips with no luck. Unfortunately, there is no error condition and the card/formatter never 'return'. The first cylinder is trashed in the process.

Share this post


Link to post
Share on other sites

I may as well mention that I will be posting a few HFDCs for sale soon. Just been bogged down by work and other things lately.

 

Taking a break from repairing the card from Hades. Available:

 

1. Myarc HFDC with 32K update, 9216B update (high density capable on Geneve), capacitors refreshed, tested with both hard drive and floppy, with TI and Geneve. Edge connector has been keyed. No case, so you'll have to procure/make one. Do not use a TI metal/composite clamshell unless it is modified! I may have one 20-pin cable but no 34 pin cables. Should work with DREM mfm emulator. $285.

2. Myarc 80-track floppy controller. $225.00.

3. Myarc RS232 card, black shell, $30.00

4. MiniMem cartridge with the Compute! game programming book. $10.00

 

Same expectations apply as in first sale post regarding contacting me, shipping, customs, etc. Busy week so I may only be able to respond to PMs during the evening hours, local time.

  • Like 4

Share this post


Link to post
Share on other sites

Couple more items to release to the wild:

 

1. Geneve 9640 with the 384K fast RAM expansion installed using a single 512K chip versus the original 3x128K chip stack.  The card was recently used for TIPI PEB testing.  I am not interested in refreshing capacitors, regulators, etc. (as the card is working fine).   It comes in a case though the the case clasps are not all there, as they are a little brittle. Nearly all chips are socketed.  I am selling this as-is.  No mouse, keyboard, or video cable. You will need to make/obtain your own.  There are keyboard/scart/hdmi options that have been discussed in the forum.  $425.00

 

2. PGRAM+ card with triple tech/mbp clock emulation support. I believe this is the 80k model.  I did verify the clock works and loaded Super XBASIC into it for testing purposes.   Lithium 3v battery appears to be long-dead so it didn't hold the time/charge.  This card did not/does not come with a case. Comes with 3 software disks.   $160.00

 

3. IDE hard disk controller card.  Last time I checked the card it was functioning properly and the battery level was OK. DSR v11 was installed.  I may be able to include the formatted memory card, though I must first check the contents. My plan for this card was to use it to implement IDE hard drive support in the Geneve OS, however, I am no longer interested in pursuing this effort. A few people like Swim and Fred use these cards successfully with their TI systems and Fred supports the DSR.  $325.00.  This card did not come/does not come with a case.

 

4. Myarc RS232 is still available. ;)

 

Same sale stipulations apply.

 

 

  • Like 2

Share this post


Link to post
Share on other sites

The buyer of the IDE card graciously allowed me to revisit some code I wrote in 2009, when I was attempting to integrate IDE low level support into the Geneve operating system.  As of this weekend I successfully updated my routines to allow the Geneve OS to use the IDE card in both MDOS and 99/4a modes.  If time permits this week I will modify SCSI/SYS loader code (for IDE) though booting from IDE will require an updated Geneve EPROM. The simplest method may be to hack the Geneve EPROM  v1.0 for the time being, provided there is anyone that has an IDE card and wants to use it with the Geneve.

 

The method I used to integrate the IDE low level support sacrifices some speed for future compatibility. Instead of trying to forklift the low level IDE code and Fred's partitioning routines into MDOS, I set up an environment that calls the on-card DSR sector read/write function.  Fred's DSR does all the partition and IO heavy lifting;  MDOS does the file management.  If Fred changes how the partitions work, it won't matter to the Geneve. Additionally, this means the devices will be compatible if one wishes to use ROMPAGE to access the IDE card as if it were in a TI. 

 

I did experience corruption of my two SCSI drives -- unrelated to the IDE code - so I am concerned that either v7.0 introduced a bug into the level 3 file system or that an old bug has reared its ugly head.  I don't yet know which and will be trying to create an image where I can replicate the issue.  If I cannot replicate it, then I may have to revert back to an older version of the OS source to implement all the changes to this point.

  • Like 5

Share this post


Link to post
Share on other sites

Thought I would throw out on Tim's advice a repair job I did on my Geneve yesterday.  Back about 2 weeks ago, the fan went out on my PEBox and I was unaware.  While working on the Geneve, I started getting erratic behavior.  Finally, I shut the PEBox down and for some reason, removed the cover.

 

The side of the PEBox was almost burning hot, and the adjacent cards to the power supply were extremely hot.  Those being the TIPI, Memex, and GenMod Geneve.  I let everything cool down for the night with the cover removed.  The next day, I swapped out the PEBox.

 

Geneve swan would display, but no access was taking place on the HFDC.  Swapped Geneve's around, things booted fine.  In the other PEBox with the previously hot GenMod Geneve, I had one other card, a HFDC I knew was working.  Geneve would not access the HFDC and would just sit there with no response.  Pulled the HFDC, and the Geneve would transition saying it could not find System/Sys.  I figured it was the bus chips.  Discussed with Tim, and had to order some 74LS245's and 74LS244's.  Replaced the 74LS245 and all was well.

 

Fifty cent repair job.

 

Beery

  • Like 6

Share this post


Link to post
Share on other sites

today's challenge involved revisiting a Geneve that has been particularly challenging.  The Geneve was functional but tended to crash and at times failed to boot.  Putting tension on the card sometimes improved the situation, so the prevailing thought was a bad solder joint or cracked internal trace.   I did some basic tap-testing without much success.  I inspected the sockets and ended up replacing single-wipe sockets for the buffer chips, PAL, video ram, 9901, and 9995.  When I got it all put back together the Geneve would not start no matter what.  I eventually took the PAL out which allowed the Geneve to boot, though at times the screen was corrupted a likely result of the missing PAL and missing wait states.  

 

Fast-forward to today.  I took the Geneve to the woodshed where I touched up the V9938 and many of the empty through-holes.  Took be about two hours to finish, cleaned up the flux a bit, then took out my 10x loupe to inspect the board one last time.   There was a pin that caught my attention because it was a little higher than the rest and had a small hole in the solder.  The pin was one of two leads for the 9995 crystal.  I was able to wiggle the crystal and watched the pin go up and down; the other pin wobbled slightly.   This surprised me as my tap-testing didn't cause any immediate crashes.  So I unsoldered the crystal and resoldered it to the board.  Without the PAL the Geneve fired up like before without the periodic black screens.   So I put the PAL back in and... nothing.  black screen.

 

I found no continuity issues between the PAL and its connections. I found no issues with the schematic connections.  Somewhat frustrated I tried to isolate the offending pin by removing a few of the pins.  Eventually I narrowed it down to the SNDRDY pin that connects to the sound chip, gate array, and pull-up resistor.  The PAL appears to take the SNDRDY signal and processes it,then sends it to the 9995 via a PAL output. Seems the PAL input is being held/set LOW which in turn is generating wait states, holding the processor in limbo.

 

I am presently stuck.  Removing/replacing the sound chip does not cure the problem. Replacing the gate array has no effect.  The resistor network is connected to ground and +5 and ohms out correctly.   I'm thinking there is something upstream from the gate array or sound chip that is causing this hold but i'm not quite sure how to go about finding the problem. 

 

Share this post


Link to post
Share on other sites
Posted (edited)
12 hours ago, InsaneMultitasker said:

I found no continuity issues between the PAL and its connections. I found no issues with the schematic connections.  Somewhat frustrated I tried to isolate the offending pin by removing a few of the pins.  Eventually I narrowed it down to the SNDRDY pin that connects to the sound chip, gate array, and pull-up resistor.  The PAL appears to take the SNDRDY signal and processes it,then sends it to the 9995 via a PAL output. Seems the PAL input is being held/set LOW which in turn is generating wait states, holding the processor in limbo.

 

I am presently stuck.  Removing/replacing the sound chip does not cure the problem. Replacing the gate array has no effect.  The resistor network is connected to ground and +5 and ohms out correctly.   I'm thinking there is something upstream from the gate array or sound chip that is causing this hold but i'm not quite sure how to go about finding the problem. 

 

Have you attempted to swap the PAL out for another, if you have access to one? The PAL could have an issue itself.

Edited by RickyDean
  • Like 1

Share this post


Link to post
Share on other sites
1 hour ago, RickyDean said:

Have you attempted to swap the PAL out for another, if you have access to one? The PAL could have an issue itself.

Hi Ricky, I tried a PAL and Gate array from a known working system to no avail. FarmerPotato shared some intel about the SNDRDY line which suggested that removing the sound chip might alleviate the issue but that had no effect.  I wonder if there is another input to the SNDRDY logic - either at the PAL or elsewhere - that is the culprit.  Not having PAL documentation makes this a little more challenging... :(

 

  • Sad 1

Share this post


Link to post
Share on other sites

What I guess is going on is that the PAL combines the READY inputs of more than one chip, then sends it to the 9995's READY pin.

 

READY pins are either low or Hi-Z, with a pullup resistor to +5. If the CPU sees a low value, it goes into wait state for another cycle.

If there is a short to ground or the pullup is not there, you would get stuck in wait states.

 

I would take on the task of reverse-engineering that PAL.

 

Here's a first scan of the available info:

 

U202 PAL16R4
GA = gate array

1 clkin GA clk, inverted
2 i1  GA we*/cruclk 
3 i2  GA sndrdy
4 i3  GA csr*
5 i4  9901 P7 pin 23 INT15*/P7
6 i5  GA memen*  
7 i6  GA dben*
8 i7  GA pin 36 ? "MEBS" 
9 i8  GA csw*
10 gnd

11 i9/oe*  "1" arrow
12 io1 output to Pbox 244 buffer: we or cruclk, ambiguous
13 io2 output to Pbox 244 buffer: we or cruclk, ambiguous
14 o3 unused
15 o4 unused
16 o5 unused
17 o6 unused
18 io7 9995 RDY
19 io8 9901 p9 pin 28 INT13*/P9
20 vcc



GA 32 ready*  goes to Pbox 4 ready* with a pullup.
I wonder if this is an input or output for the GA.
My guess is an input from other Pbox cards.

Perhaps GA 32 is input from Pbox READY and GA 36 is output READY.


244 buffer for (top to bottom) dbin memen* we* cruclk* 
2 go to GA:  dbin abus-/holda (is this for memen?)
next two would be we* cruclk*


http://ftp.whtech.com/Geneve/schematics/

 


QUESTION for InsaneMultitasker: does MDOS ever enable these 9901 interrupts, or does it leave them as I/O bits?

LI   R12,0
SBO  15     * change pin 23 from i/o to interrupt 15
SBO  13     * change pin 28 from i/o to interrupt 13

Interrupts are disabled on 9901 reset. Explicitly disabling these would use SBZ. Also, INT15 and INT13 are kinda weird. How many interrupt levels does MDOS actually use? Just INT1 like the 4A?

 

If the pins are used as I/O then there will be these type of statements:

SBO 23    * send a 1 to the PAL input pin 5
SBZ 23    * send a 0 to the PAL input pin 5

And my guess is there would be:

TB  25    * read PAL pin 19


It's also possible that that 19 is used as a PAL INPUT too.

It's possible they could be set with LDCR (this would be awkward).

Can you check whether any of these instructions are used?

 

  • Like 2

Share this post


Link to post
Share on other sites

Do you think i2 - which connects to the sound chip and gate array - is fed from both chips depending on other logic states? I was assuming SNDRDY fed from the sound chip to both the gate array and PAL.   

 

If the gate array is also generating RDY to i2, the gate array signal could be the culprit.   I will investigate the gate array trace to see if it can be temporarily isolated. If I have a socketed Geneve I will confirm that it starts up without the four buffer chips.  Perhaps my own troubleshooting memory is faulty in that regard (I don't think so but I want to confirm). 

3 i2  GA sndrdy

Share this post


Link to post
Share on other sites
8 hours ago, FarmerPotato said:

What I guess is going on is that the PAL combines the READY inputs of more than one chip, then sends it to the 9995's READY pin.

 

READY pins are either low or Hi-Z, with a pullup resistor to +5. If the CPU sees a low value, it goes into wait state for another cycle.

If there is a short to ground or the pullup is not there, you would get stuck in wait states.

Operating under the assumption that the gate array pin tied to SNDRDY is a gate array output (which may be false and needs to be confirmed) I got to thinking about the removed buffer chips and 'coincidence'.  You posed the following 'question':

GA 32 ready* goes to Pbox 4 ready* with a pullup. I wonder if this is an input or output for the GA. My guess is an input from other Pbox cards.

 

Thinking along these lines I looked at how Pbox 4 is tied into RN54.  I ohmed out RN54 - all pullups checked out.  I then tested for continuity between +5 and each pin of RN54; all normal.  I then checked continuity between GROUND and each pin of RN54 and found a problem.  Pin #2 was shorted to ground.  This is the pullup for the external peb -HOLD line.

 

Working from RN54 pin #2 I followed the trace under a capacitor I had replaced; no issue there.  The trace flipped to the back side of the board where it meandered past a few chips among them one of the buffer chips I removed.  The  trace is missing some solder mask (like many other traces on this board) where it curves around the buffer chips GROUND through-hole. I found a very thin strand of solder bridging the HOLD trace to ground. I removed the solder bridge and confirmed HOLD was no longer grounded.  I placed the card into my PEB with PAL pin 3 in place and the Geneve displayed the swan.  

 

When I first started working on the Geneve I noticed that flexing the card slightly could stop the card from booting. It is possible this strand of solder was making intermittent contact, forcing HOLD low and halting the Geneve from booting. 

 

Thank you, FarmerPotato, for digging further into the PAL and steering me in the right direction.  I truly hope that after the sockets are installed the Geneve will work as expected, with no odd behavior or periodic lockups. 

 

 

 

 

  • Like 3
  • Thanks 1

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...