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

[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.

[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.