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.
Recent Posts
