Looks like I've shot my RC2014 by mistake... please help

[Sebastian Kettner]

Hi everyone,

so I was just playing with my RC2014 and in this process was swapping around some of the modules on the backplane to order them in a more convenient way.

By mistake I plugged in the 512k RAM/ROM module shifted by one pin, so that the module's pin 1 was connected to pin 2 on the backplane and so forth.

Unfortunately I've noticed my mistake only after switching on the system, of course with all my other modules plugged into the backplane as well (correctly, though).

I switched of the system immediately and corrected my mistake. While doing this I noticed that the ROM chip got slightly warm.

The result of all this is that my RC2014 won't boot anymore. No output on the serial port at all.

My question to the more experienced builder/user is: which components should I check or replace first? Is it likely that by connecting one module incorrectly I could have killed the neighbouring modules as well?

Any help reanimating my RC2014 will be highly appreciated!

Thanks,

Sebastian

[Alan Cox]

My question to the more experienced builder/user is: which components should I check or replace first? Is it likely that by connecting one module incorrectly I could have killed the neighbouring modules as well?

Unfortunately - yes, although it's unusual to blow anything up if it's only been miswired briefly.

I would suggest

- Unplug all the cards

- Inspect the backplane soldering and look for dry joints and cracks. The RC2014 backplane takes a lot of force when removing and adding cards and is nowhere near thick enough to be properly robust. You may have a problem with the backplane needing a resolder that is everything to do with a bad joint and nothing to do with the misaligned cards. If you have a different backplane try it.

- Put back the clock card, check the power and clock with a voltage meter/frequency meter or similar

- Pull the ROM and test it by reading it back in a programmer, and if need be rewriting it

- Some programmers can also test RAM

- Stick the CPU card in and see if there is activity on the address/data lines (it'll be executing nonsense but it'll be executing so you should see activity on M1, RD, WR, MREQ and A0-A15). Also check voltages.

- Stick the RAM/ROM card back in and check voltages. You could also burn  "IN A,(FF), JP 0 into the start of the ROM and see if the CPU lines behave as you'd expect (you'll get some activity at other addresses due to the built in DRAM refresh) but should see lots of IRQ activity and so on

- Ditto the serial and see if it's now alive.

Otherwise starting with the highest density components is my rule of thumb - the size of the features has a lot to do with how destructible the chip is.  Apart from the components on the misaligned card I would start with the CPU if the clock is good and nothing seems to work.

Alan

[Steve Mastrianni]

I've seen this once before. I'd swap out the CPU and SIO (if you have it). Of course YMMV, but the CMOS versions of the CPU and SIO seem to be susceptible to those mistakes, even briefly.

--Steve

[Justin Skists]

Hi,

I did the same with the cpu module, once before. I had to replace the Z80 chip and luckily the rest of the modules were fine.

It's unfortunate that you did it with the most expensive module. Do you have any other ram and rom modules to try? Are you able to test the ram and rom chips separately?

Justin.

Get BlueMail for Android

[Sebastian Kettner]

Hi and thanks to all of you for your replys.

I will check the backplane for any mechanical defects or faulty solder joints first.

Unfortunately I do not have any spare components or modules/cards I could try right now.

I've just placed an order for a programmer and a USB logic analyzer - planned to buy these sooner or later anyway and now seems like a good time.

I do own an ancient 10 MHz CRT oscilloscope but it is currently of no use due to issues with the triggering.

The parcel should arrive Thursday or Friday, so I'll be able to properly check the signals and read (and write, if necessary) the ROM over the weekend.

I'll post an update as soon as there are any news!

-Sebastian

[Sebastian Kettner]

1st quick update: clock card seems to have survived.

I jumpered one clock for 300 kHz and the other one for 600 kHz (as my digital multimeter has its limit at 800 kHz) and I was able to measure both clocks on their bus pins.

-Sebastian

[Spencer Owen]

Hi Sebastian,

As others have said, checking that you can read the ROM is the first thing to check, as that is sounds most likely to be the point of failure.  Luckily, when others have had similar issues, it only seems to have affected 1 component - It is just a case of identifying that component though.

If the programmer you have ordered is a TL866 (or similar) that can also check logic chips, then it should be quite easy to identify if the problem has extended to any other chips.

Please keep us updated on how you get on.

Spencer

--
You received this message because you are subscribed to the Google Groups "RC2014-Z80" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rc2014-z80+...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/rc2014-z80/df48d3e5-e00c-4beb-81d5-6ea958b59e03n%40googlegroups.com.

[Steve Mastrianni]

There are a few things that could be improved upon for the RC2014, one is a simple plastic insert into one of the bus sockets that would prevent backwards insertion, much like the old floppies did with the slot and connector that would only fit one way. This could be coupled with the more rigid card guide, something I may look into. Those bus connectors tend to weaken after several insertions as well. So many of the parts move around mechanically that I decided to put the RC2014 into something more stable.

[Tom Storey]

While the ROM may have gotten hot, it doesn't necessarily mean it has failed.

If you're using Alliance SRAMs, try testing those to see if they have failed. Ive found them to be particularly sensitive to "voltage mistakes" after I accidentally fed too many volts into a Z80 based device one time. * *Everything* survived except the SRAM, one brave soldier. :-)

If your ROMs are SST brand, I'd probably be less worried about them. They seem a bit more robust. I've got a 3.3V rated SST EEPROM running in a 5V system just fine and dandy, and it's been seemingly quite happy for the past few years, even through the above mentioned over voltage event.

Otherwise the CPU can be "nop tested" just by pulling the data bus pins down and observing for activity on the address lines - they should simply count upwards (ignoring refresh outputs).

Best of luck finding the culprit.

--
You received this message because you are subscribed to the Google Groups "RC2014-Z80" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rc2014-z80+...@googlegroups.com.

To view this discussion on the web, visit https://groups.google.com/d/msgid/rc2014-z80/730d0d18-9232-45c8-b33a-ccdde9be6f29n%40googlegroups.com.

[Sebastian Kettner]

Thanks everyone for your further replies.

Spencer, the programmer I have ordered is indeed a TL866II, so I will be able to check all the chips - ROM, RAM and logic.

Steve, I have been thinking about providing adequate housing for my system, too. I'm envisioning something made of transparent acryclic or even real glass, at least partially, as I have cards with optical output in my system (digital I/O, a 4 digit 7 segment display) and because I really like the looks of the system and don't want to hide it in a box.

But your approach looks neat, too!

Tom, thanks for your input.

I am expecting the programmer in my mailbox today or tomorrow, then I will start checking the chips and will include the RAM as well!

Sebastian

[Sebastian Kettner]

Short update: I have received the logic analyzer today, but still waiting for the programmer.

At least I could check some signals.

With RAM/ROM, clock and the CPU cards inserted into the backplane, I could see signals on CLK (obvioulsy), M1, Mreq, WR and RO.

I also got signals on the data lines D0 to D5. However, D6 and D7 remained silent.

So the CPU is trying to do something. Why the two data lines 6 and 7 remain inactive, however, I do not know.

What is your guess? Is the CPU or the ROM or maybe even the RAM the culprit?

Hopefully tomorrow I'll get that programmer and will be able to test the chips.

Sebastian

[Mark T]

you connected 5v to the 0v pin on the ram/rom module and 0v on A0. This would probable drive the power supply current through what should have been reverse bias parasitic diodes in the A0 pins of ICs on the ram/rom module, these have a max forward voltage of about 0.6v and probably limited to 10-50mA. The ICs most likely to be damaged are the rom, ram and 74hct670s. I think the other modules in your system might be ok.

You might try 1k resistor to ground on each data line, with the ram/rom module removed. This should run a nop test on the z80 and you should see all address lines toggle.

[Alan Cox]

On Thu, 3 Mar 2022 at 17:25, Sebastian Kettner <seba...@sebastian-kettner.net> wrote:

Short update: I have received the logic analyzer today, but still waiting for the programmer.

At least I could check some signals.

With RAM/ROM, clock and the CPU cards inserted into the backplane, I could see signals on CLK (obvioulsy), M1, Mreq, WR and RO.

I also got signals on the data lines D0 to D5. However, D6 and D7 remained silent.

So the CPU is trying to do something. Why the two data lines 6 and 7 remain inactive, however, I do not know.

What is your guess? Is the CPU or the ROM or maybe even the RAM the culprit?

Hopefully tomorrow I'll get that programmer and will be able to test the chips.

Sebastian

Pull the RAM and see what D6 and D7 do.

Alan

 

[Sebastian Kettner]

Alan, I did as you suggested, the result being that instead of silence I get some really short impulses on the two data lines, frequency aprox. 2 kHz (with the clock jumpered to the 614 kHz setting).

I put the RAM back into its socket after and, very strange, suddenly saw data on lines D0 to D6, but D7 still dead.

This erratic behaviour seems odd.

Well, I think testing the chips in the programmer which I will hopefully receive by tomorrow will bring more clarity into this.

Sebastian

[Sebastian Kettner]

Mark, thank you for your explanation of what I have actually done to my RAM/ROM card!

I will try your suggestion with running the NOP test on the CPU in addition to testing the RAM, ROM and the card's logic chips - just to see what it does.

Sebastian

[Sebastian Kettner]

I've received the programmer today and could test those chips, at last!

So the ROM and RAM seem to be dead.

The ROM can neither be read nor erased.

About the RAM I am not 100% sure, as the Alliance chip is not in the programmer's database.

However, I have found a "standard RAM" called 628512 which should be the generic name of the AS6C4008. I have compared the datasheets of both chips and they seem interchangeable.

To make sure that the programmer itself is working properly I put the ROM and RAM out of the Gigatron TTL coputer kit I am just building through a test and they both passed.

The TTL logic chips of the ROM/RAM card seem to be fine.

However, I was not able to test the CD74HCT670E chips as there is no profile for them available in the programmer's database and I don't really understand yet how to create custom chips.

Mark pointed out that these two chips are likely to be dead as well, so I will just replace them, they don't cost much.

I could not find the HCT type at the online shop where I usually order my components, they only offer HC types.

Is HCT critical in the circuit in this case or will HC work fine?

Sebastian

[Mark T]

The 74hct670s have a slightly better chance to survive than the rom and ram but its probably best to replace them if you are not able to test them.

74HC670 might work, if the inputs are driven only by cmos outputs and if there is not enough load on those inputs from other modules. It might cause a problem if you have 74LS inputs loading the address or data lines on other modules. The issue for HC inputs is the threshold voltage for high logic level is 2/3 of the supply voltage, HCT threshold is 2v. 

If you fit 74HC670 and it doesn’t work then it might leave some doubt about the reason, making it a little harder to debug the problem.

If they are cheap and easy to source it might be worth a try.

[Sebastian Kettner]

I have just ordered the ROM and RAM chips.

The 74HC670 cost 0,23 € a piece, so I've added four of them to my order.

I'll leave the 74HCT670 on the card and see if they work (or figure out how to create a custom entry for them in the programmer's chip catalogue so I can test them).

In case I will suspect them to be damaged I can fit the 74HC670 and see if they work.

I am hoping to receive the order Tuesday or Wednesday.

As for the contens of the ROM, I just have to download the latest release of RomWBW from github

Releases · wwarthen/RomWBW · GitHub

and program the ROM with the included RCZ80_std.rom file?

Does anybody know if it is in binary or Intel hex format?

Sebastian

[Wayne Warthen]

On Friday, March 4, 2022 at 10:14:13 AM UTC-8 seba...@sebastian-kettner.net wrote:

As for the contens of the ROM, I just have to download the latest release of RomWBW from github

Releases · wwarthen/RomWBW · GitHub

and program the ROM with the included RCZ80_std.rom file?

Does anybody know if it is in binary or Intel hex format?

All RomWBW ROM images are straight binary.  Just write them byte for byte starting at address zero of the ROM.

Good luck!

-Wayne  

[Sebastian Kettner]

Update, at last!

It took the post a little longer this time to deliver my package, but today I received the ICs.

The new ROM and RAM both tested okay on the programmer.

Writing RomWBW to the chip worked flawlessly.

After putting the chips in their sockets, the RC2014 booted right up - this is with the "old" 74HCT670, I didn't even need the 74HC670 I've ordered.

So in the end, all that got fried were the two ICs, ROM and RAM.

I've also thoroughly tested all the other cards and it seems none of them took any damage - lucky me!

Thanks again everyone for your help and advice and be sure that from now on I will check at least (!) twice if all the cards are aligned correctly before applying power to the system!

Sebastian

[Spencer Owen]

Excellent to hear that you're back.up and running again, and thank for letting us know.

Spencer 

--

You received this message because you are subscribed to the Google Groups "RC2014-Z80" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rc2014-z80+...@googlegroups.com.

To view this discussion on the web, visit https://groups.google.com/d/msgid/rc2014-z80/5b0a2b75-8d32-4a8b-80df-272403be0f26n%40googlegroups.com.

[Earth Person]

Hello Sebastian,

Hopefully you did order a few of RAM/ROM devices for the future. These days, it takes so long to get some devices, good to get multiples.

Glad you found the problem and fixed it!

Sincerely,

William Harrington

[Sebastian Kettner]

Hello William,

yes, I did order three of every chip, for exactly that reason. I just hope I won't need them anytime soon...

Sebastian