Help wanted: Amiga 1200, black screen, no power led

[EduardoLM]

Hello people, I would like to ask for help on a though repair.

This Amiga 1200, rev 2B, has correct /RESET signals, correct voltages all over, it's already recapped, and has no physical damage or missing components. However, it only displays a black screen, and the power led doesn't light up.

At first, it showed no bus activity at all. /HALT was low, meaning CPU was halted. To find out if it was the CPU or Gayle asserting /HALT, I lifted the pin on the CPU, and found out that it was the CPU asserting it, not Gayle.

Checking more signals, I found ROMs /CS was ok, but /OE not, it was high, so the ROMs were never selected. I hunted where this signal is generated, and I found it was in the GAL XU1. It was pulling /ROMOE to high. I decided to take the GAL off the board and reprogram it. I found the Jed file for Amiga 1200 rev 2B online. After reprogramming and resoldering, /ROMOE went good, low level.

However, I had the same symptoms still, nothing changed, same black screen, no led, no bus, and /HALT still low.

I then did some research and tested /AS on the 68EC020. It was constantly high. I lifted it, and noticed something on the board was pulling it high, because measuring the lifted /AS pin, I found it pulsed high during power on, and then went low forever.

After some more tests and head scratching, I suspected of the GAL, since it had a connection to /AS pin. I removed it from the board, and powered the Amiga. I got bus activity! But only during the first 3 seconds after /RESET is released, then it freezes.

Well, this is the current situation. Please, does anyone have any clue on what to do next? The GAL seems to be fine, I downloaded the JED file here: https://www.amigawiki.org/doku.php?id=de:parts:pld_download, itś XU1, for 2B revision. My TL866 programmer verifies the GAL correctly, it seems it's nos damaged. I  can see only two possibilities:

- GAL is driving /AS, but it shouldn't, beacause /AS pin is an input for the GAL
- GAL is receiving garbage signals, and outputting something that is locking the processor

Since I know little about what this GAL does internally, I'm asking for help. Is there any signals this GAL generates, that could hang the CPU this way? Or, does anyone know if the jed I found at amigawiki website is really working?

Any tip, help or insight is greatly appreciated, thanks!

Eduardo

[lionstorm]

could it be a fried video port ?
I am asking bercause I fried my A500 video port and got the same symptom (black screen that is).

good luck in your investigation...

[Castellen]

As you've probably found already on the rev 2B board, _ROMCS is permanently pulled low (active) by R959, and R597 is not fitted on production boards - the schematic is slightly confusing.  You're correct that XU1 generates _ROMOE, which should normally be high, and only strobe low while the system is reading the $F80000 ROM area.

Given your fault description, it sounds as though _ROMOE might not be generated at the correct time (or is it incorrectly being asserted all of the time?);  or if that's working correctly, then the CPU is possibly just executing garbage - in which case are you absolutely sure that the ROM contents is valid, and U6A/B are not exchanged in the sockets?  And both ROMs are correctly located at the bottom of the 42-pin sockets.

Regarding the function of XU1, I copied the A1200 programmable logic data and source code off a 5.25" disk from Commodore development many years ago, the contents of which is on my webserver: http://amiga.serveftp.net/eprom_binaries/A1200_PAL/

I've no idea if this is the same as what was used in production or not, or if the .JED files will work on a production board or not.  But since the CUPL source is there, you'll get an idea of what they're making the PLD do.

Since XU1 is a big unknown at this point, i.e. the original device is suspect, and you don't know if reprogramming it has actually fixed it or introduced more problems, I'd suggest getting a known good XU1 from somewhere and try that.


Edit - the PLD source I referenced above is from XU9 on the rev 1 A1200.  Not sure what the differences are between this and XU1 on the rev 2 boards, I don't have the source for XU1.  The XU9 source may be similar enough to give you an idea of how the logic is intended to operate.

[EduardoLM]

Thanks a lot for your insights, @Castellen! I'll comment below:

Given your fault description, it sounds as though _ROMOE might not be generated at the correct time (or is it incorrectly being asserted all of the time?);  or if that's working correctly, then the CPU is possibly just executing garbage - in which case are you absolutely sure that the ROM contents is valid, and U6A/B are not exchanged in the sockets?  And both ROMs are correctly located at the bottom of the 42-pin sockets.

Yes, the ROMs are in the correct sockets, and I'm leaving an empty socket row to the left. I think /ROMOE may be wrong indeed, but what puzzles me in fact is that the mere presence of the GAL (XU1) makes the processor freeze completely. When XU1 is fitted, /AS is not asserted even a single time since power on! Today I was studying the schematics to see if XU1 can assert some signal in a way it could block the CPU completely, but I found nothing conclusive. As far as I know, even if ROM is wrongly enabled, I would see the processor trying to fetch some instructions, right? That is not happening when XU1 is on the board..

Regarding the function of XU1, I copied the A1200 programmable logic data and source code off a 5.25" disk from Commodore development many years ago, the contents of which is on my webserver: http://amiga.serveftp.net/eprom_binaries/A1200_PAL/

I've no idea if this is the same as what was used in production or not, or if the .JED files will work on a production board or not.  But since the CUPL source is there, you'll get an idea of what they're making the PLD do.

Since XU1 is a big unknown at this point, i.e. the original device is suspect, and you don't know if reprogramming it has actually fixed it or introduced more problems, I'd suggest getting a known good XU1 from somewhere and try that.

Thank you very much for the source! Even if it doesn't help here, it's a great resource!

Unfortunately, finding a working XU1 from a A1200 rev 2B is something next to impossible for me right now.. But this morning, with the help of chatgpt and the jed2eq utility, I managed to find very useful info. I sent the JED file, the EQN file generated by jed2eqn and the XU1 pin labels to chatgpt, and it returned this:

NAME XU1;
DEVICE GAL16V8;

/* Pinout (your labels) */
PIN  1 = CLK;
PIN  2 = AS_N;        /* _AS */
PIN  3 = ROMEN_N;     /* _ROMEN */
PIN  4 = FC1_N;       /* _FC(1) */
PIN  5 = FC0_N;       /* _FC(0) */
PIN  6 = CC_ENA_N;    /* _CC_ENA */
PIN  7 = A16;
PIN  8 = DSACK1_N;    /* _DSACK_1 */
PIN  9 = OPTION;
PIN 10 = GND;
PIN 11 = OE_N;        /* _OE (global OE, active-low) */
PIN 12 = DSACK0_N;    /* _DSACK_0 */
PIN 13 = CB_ENA_N;    /* _CB_ENA */
PIN 14 = OUT14;       /* registered output (unnamed in your map) */
PIN 15 = XRDY;        /* registered output */
PIN 16 = OUT16;       /* unused/Hi-Z in JED */
PIN 17 = OUT17;       /* unused/Hi-Z in JED */
PIN 18 = OE0_N;       /* not driven in EQN (no logic) */
PIN 19 = ROMOE_N;     /* _ROMOE */
PIN 20 = VCC;

/* Helpful aliases (positive-logic versions) */
AS     = !AS_N;
ROMEN  = !ROMEN_N;
FC0    = !FC0_N;
FC1    = !FC1_N;
CC_ENA = !CC_ENA_N;

/* ------------------------------------------------------------------ */
/* Equations (decoded from your .EQN)                                  */
/* ------------------------------------------------------------------ */

/* ROMOE_N (pin 19):  /o19 = /i2 * /i3  -> ROMOE_N = AS_N + ROMEN_N  */
ROMOE_N = AS_N # ROMEN_N;
/* .OE not explicitly listed in EQN (defaults to device/global behavior) */

/* CB_ENA_N (pin 13): /o13 = /i2 * /i6  -> CB_ENA_N = AS_N + CC_ENA_N */
CB_ENA_N = AS_N # CC_ENA_N;
/* o13.oe = VCC -> always enabled */
CB_ENA_N.OE = 1;

/* DSACK0_N (pin 12): o12 = i8 -> DSACK0_N follows DSACK1_N */
DSACK0_N = DSACK1_N;
/* o12.oe = /i2 * /i3 -> enable when AS & ROMEN */
DSACK0_N.OE = AS & ROMEN;

/* OUT14 (pin 14) registered:
   rf14 := /i2*/i3*/i5*/i9 + /i2*/i3*/i4*/i9 + /i2*/i3*/i7*/i9
        -> AS*ROMEN*(FC0 + FC1 + !A16) * !OPTION
*/
OUT14.CLK = CLK;
OUT14     = AS & ROMEN & !OPTION & (FC0 # FC1 # !A16);
/* rf14.oe = OE -> enable when !OE_N */
OUT14.OE  = !OE_N;

/* XRDY (pin 15) registered:
   ro15 := /i2 * rf14 -> AS * (same rf14) = same expression as OUT14
*/
XRDY.CLK = CLK;
XRDY     = AS & ROMEN & !OPTION & (FC0 # FC1 # !A16);
XRDY.OE  = !OE_N;

/* OUT16 (pin 16): /o16 = gnd, o16.oe = gnd -> permanently Hi-Z */
OUT16.OE = 0;

/* OUT17 (pin 17): /o17 = gnd, o17.oe = gnd -> permanently Hi-Z */
OUT17.OE = 0;

/* OE0_N (pin 18): no equation present in EQN -> not driven here */
OE0_N.OE = !OE_N;   /* safe default; remove if you want strict Hi-Z */

/* Global note: OE_N is active-low. Where .OE = !OE_N, output is enabled. */

And then it made these final comments:

What this means (plain talk)

ROMOE_N asserts low when either AS_N or ROMEN_N is low: ROMOE_N = AS_N OR ROMEN_N.

CB_ENA_N asserts low when either AS_N or CC_ENA_N is low: CB_ENA_N = AS_N OR CC_ENA_N.

DSACK0_N simply mirrors DSACK1_N, and only drives the pin when AS & ROMEN are both true; otherwise it floats.

XRDY and OUT14 are registered and have the same D:
they go high next clock when AS & ROMEN & !OPTION & (FC0 OR FC1 OR !A16) is true; tri-stated otherwise unless /OE is asserted.

OUT16/OUT17 are hard Hi-Z (not used).

OE0_N had no logic in your EQN; I left it as enabled by /OE. If you want it always-Hi-Z, set OE0_N.OE = 0.

I'm not very good at this, but I'm studying and trying to understand. And I also made the same analysis with the JED file I dumped from the XU1 chip BEFORE reprogramming, and it turned out to be IDENTICAL to the one I pasted above. So, XU1 programming was fine since the beginning! I'm now suspecting the chip might be alive for programming, but may have fried output drivers? I don't know, but I think the only reasonable thing to do in this scenario, is to get a new chip, the original one is probably bad.

Thank you very much for the help once again, and if you have any other insight based on this new information, I would be glad to hear!

Eduardo

[EduardoLM]

could it be a fried video port ?
I am asking bercause I fried my A500 video port and got the same symptom (black screen that is).

good luck in your investigation...

Thank you for your help, but it's not a video fault, the CPU is not executing any code!

[Castellen]

Yes, the ROMs are in the correct sockets, and I'm leaving an empty socket row to the left. I think /ROMOE may be wrong indeed, but what puzzles me in fact is that the mere presence of the GAL (XU1) makes the processor freeze completely. When XU1 is fitted, /AS is not asserted even a single time since power on! Today I was studying the schematics to see if XU1 can assert some signal in a way it could block the CPU completely, but I found nothing conclusive. As far as I know, even if ROM is wrongly enabled, I would see the processor trying to fetch some instructions, right? That is not happening when XU1 is on the board.

I think you're on the right track, though I don't know why you're not seeing any address strobe cycles.  In that state, they'll be generated by the 68020 CPU.  What you should normally see immediately after the system comes out of reset is:

[copied from my A4000 notes, but the A1200 should be mostly the same]

The initial CPU procedure after reset is:
1. Place $00000000 on address bus
2. Set both _AS and _DS low
3. The system acknowledges the address/data strobe by pulling _DSACK0 and _DSACK1 low (It does this twice to read the longword at $00000000)
4. Execute ROM code read from $00000000

On the scope you should see two low-going strobes of _AS, _DS, _DSACK0 and _DSACK1 and at the same time ROM pin 12 (_ROMEN) will strobe low.

If the _DSACK0 and _DSACK1 strobes are present, but there is no activation of _ROMEN then the ROM address might be incorrectly overlaid at $F80000 - check that CIA U350 pin 2 (OVL) is high at power on, if not then replace U350.  OVL is normally set low after the first few CPU cycles when correct ROM data is executed from $00000000, after which the entire ROM moves to $F80000 and $00000000 becomes read/write chip memory.

I'm not very good at this, but I'm studying and trying to understand. And I also made the same analysis with the JED file I dumped from the XU1 chip BEFORE reprogramming, and it turned out to be IDENTICAL to the one I pasted above. So, XU1 programming was fine since the beginning! I'm now suspecting the chip might be alive for programming, but may have fried output drivers? I don't know, but I think the only reasonable thing to do in this scenario, is to get a new chip, the original one is probably bad.

I'd agree, something doesn't sound healthy with XU1.  Just because the fuse contents validate, it doesn't mean the inputs and outputs are all working correctly.

Regarding the AI interpretation of the CUPL source:
"ROMOE_N asserts low when either AS_N or ROMEN_N is low: ROMOE_N = AS_N OR ROMEN_N."

I'm definitely no expert in CUPL, but I don't think that ROMEN should be enabled whenever address strobe is asserted, I don't know how that would even work.  The clue on the schematic is "Generate fast ROM OE".  Not sure what they're trying to do exactly, not that it probably matters either.  If you can't easily find a replacement XU1, perhaps try and find a new compatible 16R4 PLD and program that, you might be able to source some from AliExpress.

[EduardoLM]

It was the GAL! I bought a new one (16V8), programmed it, and soldered it. The A1200 booted! It's alive!

Now, there are two other issues:

1 - Video shows only when the image is whitish, bright. But vanishes when image is mainly black. For example, diagrom menu doesn't show, I can see what is happening by listening to serial port. But it's a video encoder problem, I connected an external A520 to the RGB port, and I get perfect composite image.

2 - No led works, power, floppy and hd. To be honest, I'm not sure yet if floppy and hd leds are failing, because I didn't plug a floppy drive or hd yet, but power led doesn't turn on. I think I need to check one if the CIAs for this.

But anyway, huge improvements, I'm very happy!

Thanks a lot for the help!

Eduardo

[EduardoLM]

Quick update: floppy and hd leds are working! Only power led is bad. I have to investigate that. But I'm not too worried, the CIA chip that deals with that is the most important one, and the machine is booting, so I'm confident this CIA is not bad. I hope it's a problem elsewhere.

And video is bad indeed, but I'll make the cxa2075m mod, that shall fix it, and give me a slightly better composite output.

By the way: is it easy to convert a PAL A1200 to NTSC? Without hacks? This one is PAL, but since I'm in Brazil, NTSC is a more compatible standard.

Many thanks!

Eduardo

[EduardoLM]

Great, some quick research and I already found out that if I connect pin 41 of Alice to ground, machine will be NTSC, at least regarding the 50/60Hz part. Then the cxa encoder should deal with the color encoding part.

Eduardo