Amiga hardware info, help and support with a focus (but not limited to) North American NTSC experiences. Open to all.
User avatar
8bitSheep
Scotland

by 8bitSheep posted Thu May 30, 2019 5:24 am

Hello all,

I am hoping some of you more experienced Amiga users can help diagnose what I think may be a hardware problem with my Amiga 600.

One of the main things I use my Amiga for is as a serial terminal for my OpenBSD PC (the machines are connected via standard null modem cable). I have been using Term 4.8 as my Terminal software since I first got the Amiga a year and a bit ago and everything has been working well. However just recently I stopped being able to receive data from the PC to the Amiga. I verified that key presses on the Amiga were received at the PC but the key press echos (and responses to executed commands) are never displayed on the Terminal screen.

A google search led to a post that suggested that it could be the CIA chip at fault and to try swapping them. Of course in the A600 that is not really possible as they are not socketed (as far as I know). Another suggestion was to turn off hardware flow control on both machines and see if anything is received. When I tried that I almost immediately got a Guru Meditation error when I tried to start my Terminal program (I forgot the exact error number but google said it was a memory error). I also sometimes get the same error with hardware flow control enable when I try to close the terminal software.

For most of the time with my Amiga I have been running Amiga OS 2.1 but I did upgrade to 3.1.4 at the beginning of the year (a new physical ROM along with a fresh install of the new OS).

My A600 has A604n and A6095 memory extensions. I have tried temporarily removing the A6095 (it is an extension that sits on top of the CPU so I thought it could be a bad connection causing the memory error) but the error persists. Also, apart from the serial connection problem the Amiga seems to be working fine so if it was a general problem with memory I would expect other applications to crash as they tried to use the RAM.

So, from that description does it sound like the CIA chip has gone bad or something else? Is there anything else I can try? Is there any other information that I could provide to help analyse the problem?

Thanks in advance for any help.

8bitSheep
User avatar
EzdineG
Springfield, MO

by EzdineG posted Thu May 30, 2019 6:18 am

I have been able to reproduce the guru errors while turning on / off hardware flow control and swapping polarity in terminal on my working A600 w wifi232. Not the exact same configuration as you, but enough for me to think the issue isnt related to your problem.

I have had CIA chips “fail” in an A600 that could temporarily be fixed by putting pressure on the chip and attempting to reproduce the problem (in my case floppy drives not being detected.) The permanent fix was reflowing the chip.

Look at the board and see if there are any obvious marks on any of the resistors by the connector. Have a look at the schematics to see which of those are directly responsible for that pin.
User avatar
8bitSheep
Scotland

by 8bitSheep posted Fri May 31, 2019 2:55 pm

Hello EzdineG,

Thanks for the response and the information, that is exactly the sort of details I was hoping to get. I had read that the CIA chips are a little fragile so had not considered that it may be just connection between the chip and the board. I will take the board out this weekend and do an inspection (after I google for the schematics) and see what I can see.

I did speak to a colleague today who is willing to do the reflow of chip(s) if it looks like that is the problem so that is great :D

I will let you know what happens.

Thanks again!

8bitSheep
User avatar
Acill

by Acill posted Sat Jun 29, 2019 5:06 pm

Before you start tearing up your board I would start with using John Hertells DisgROM first. It will test your CIA chips easily. If you have access to an EPROM burner you can make it easily. The files for the last release are here: http://www.diagrom.com/

This is a kickstart replacement used for diagnostics and troubleshooting. Its indispensable!
User avatar
EzdineG
Springfield, MO

by EzdineG posted Sat Jun 29, 2019 7:42 pm

Acill wrote:Before you start tearing up your board I would start with using John Hertells DisgROM first. It will test your CIA chips easily. If you have access to an EPROM burner you can make it easily. The files for the last release are here: http://www.diagrom.com/

This is a kickstart replacement used for diagnostics and troubleshooting. Its indispensable!

Note that Diagrom has historically had issues correctly determining problems with CIA chips in NTSC Amigas (it says they’re bad when they’re not.)

This was still an issue as of 1.0, I am not sure if it has been corrected since and Chucky isn’t big on release notes. This doesn’t apply to the OP, but something to note if you see the failure on your NTSC machine going forward.
User avatar
obitus1990
New Orleans, LA, USA

by obitus1990 posted Sat Jun 29, 2019 9:06 pm

On the diagrom.com changelog:

2019-05-03: New experimental CIA test should be working. This I would add much more early but due to some idiots having the totally wrong way of asking for a function I just simply ignored the request of having a CIA test that works in NTSC mode aswell. Remember HOW you ask
for functions/features. Do not be a dick. Anyway. it now hopefully works. I have no
real NTSC machine to test on, so please test and report (bugreports@diagrom.com).
remember that result is dependent on current screenmode so OK can be on the PAL side
even on a NTSC machine.
User avatar
Acill

by Acill posted Sat Jun 29, 2019 9:09 pm

Even before it worked. It just reported timing was off. It's great now.
User avatar
EzdineG
Springfield, MO

by EzdineG posted Sun Jun 30, 2019 4:53 pm

obitus1990 wrote:On the diagrom.com changelog:

2019-05-03: New experimental CIA test should be working. This I would add much more early but due to some idiots having the totally wrong way of asking for a function I just simply ignored the request of having a CIA test that works in NTSC mode aswell. ... I have no real NTSC machine to test on, so please test and report (bugreports@diagrom.com). remember that result is dependent on current screenmode so OK can be on the PAL side even on a NTSC machine.
Thanks for pointing this out.

Note that the current "stable" download link from http://www.diagrom.com nets you a version dated 10/27/18, much older than last month's update you linked correcting this issue - which will net you this:
diagromv1_0.jpg

Since this project has existed since 2016, an NTSC user would have to have a very recent "daily" burn in their possession and be in the correct screen mode to not see this behavior. At least the version above does warn you about NTSC results (not sure how far that goes back), but to be honest as an end user that blue line would get TLDR'd as I wouldn't get past the block of red FAILED text if I didn't already know better.

Acill wrote:Even before it worked. It just reported timing was off. It's great now.

The primary test here is CIA timing, which fails on NTSC machines. If the May 2019 build fixes it for NTSC users in PAL mode, then great! I would bet money against most users incapable of burning their own ROM possess a version this new, though. [Edit] I've seen many bad CIAs properly fail this test just like "good" NTSC CIAs do.

So, yea, if you're on an NTSC machine, take note of this behavior (or send me your "failed" CIAs!)
User avatar
obitus1990
New Orleans, LA, USA

by obitus1990 posted Sun Jun 30, 2019 5:14 pm

Did you understand what he was saying about the screenmode used being important? I take that to mean you have to select PAL mode from early startup (or whatever he has implemented in diagrom - I haven’t used it in probably a year now, and don’t remember). Is that how you also understand how diagrom needs to be used on NTSC machines, or am I totally off base?
User avatar
EzdineG
Springfield, MO

by EzdineG posted Sun Jun 30, 2019 6:26 pm

obitus1990 wrote:Did you understand what he was saying about the screenmode used being important? I take that to mean you have to select PAL mode from early startup (or whatever he has implemented in diagrom - I haven’t used it in probably a year now, and don’t remember). Is that how you also understand how diagrom needs to be used on NTSC machines, or am I totally off base?

I understand it as that the 5/19 update would allow NTSC machines to properly complete the test if switched to a PAL mode (I believe hitting space at the main menu will toggle it now? It’s been a while.).

In the past, I can confirm that it was tied to the oscillator too, as an NTSC A500 i tested failed even though it had a PAL Agnus on an earlier build running in PAL mode. So the screenmode switch having relevance is a new development as far as I’m concerned. Perhaps this issue is just model or motherboard revision dependent?

Who is online

Users browsing this forum: No registered users and 3 guests