Let me present the A3660

[tnt23]

So I've checked the logics, everything seems OK. I have then started debugging GAL chips as they were rather flaky when programming. Sometimes verify failed, sometimes the chip just would not program at all. Ordered a bunch of ATF replacements, still no good.

Anyway, the RST GAL (U401) is OK, providing the CPU with nice clean reset.

Next the BCTL (U209, -3 revision) also appears working, as 060 requests and gets the bus access just fine, according to what is seen with /BR, /BG and /BB lines.

Then the reset exception processing should start as far as I get it. The 060 would read two long words, starting its first memory access cycle with /TS signal. This leads to BUSTERM (U205) which should convert 040 style cycle to 020 one, with separate /AS and /DS strobes etc. The cycle should be terminated to the CPU with /TA. However the cycle would never end, with the first /TS strobe after reset being the only one monitored.

So I've tapped the BUSTERM GAL to see what was going on with its output signals, namely /AS040, /BS040 and a couple of unused ones, which together form 4-bit states in a simple state machine inside U205, according to the sources. Quite naturally, all four lines stay at 1111 (all inactive) which means the state machine is stuck at initial 'sidle' state (http://www.thule.no/haynie/cpumods/a...v0/busterm.pld)

The only thing that should switch from 'sidle' to 'ts_reg' state is the combination of '(ts # cycpend) & bgack040'. The same very condition is present in BUSCON (U204) and appears to work there. The input signals are present at both U204 and U205.

So I have checked the U205, verified it has been programmed correctly with 391471-01 and even set it on a breadboard bench with external stimuli in order to see any activity on its outputs... to no avail. I'm pretty stuck here to be honest. Any ideas and input are much appreciated.

[Mathesar]

Anyone?


Still haven't build mine but as I will be using it in a 3000 as well I am very interested in TNT32's problem.

[tnt23]

'smee again. Upon a close inspection the U205 contents turned out to be wrong, shifted by one bit. Somehow the GALblast software did not signal verification error on this. I have re-flashed U205 anew and checked the readout to match original file almost byte by byte. Now the access cycle terminates properly at least for reset vector exception handling.

Sorry for the panic! Yet need to check other GALs thoroughly.

UPD reflashed U207 (OEBUS) due to no activity on OE pins, now the CPU is reading something.

[Chucky]

So. bad GAL... yes there are a lot of GAL programmers out there making strange stuff.

I got soo fed up with my TL866 So I got a Superpro instead. 500eur but just WORKS

[tnt23]

(Cannot afford spending that much money on a programmer just for GALs)

LA shows the CPU does two quick long reads and then goes fetching with big timeouts (9us). I suspect second long read which puts ROM start address to PC is not right. Tapped data bus on CPU side and got first two longs as FF 14 4E F9 and FF F8 00 D2. Looks like first 32-bit values from DiagROM except for the high byte.

This boils down to LEBUS(0) line from U208 LEBUS GAL. To be continued.

[tnt23]

Turned out I kept flashing wrong JED to U208 LEBUS GAL. After replacing it with the known good one (taken from http://www.amigawiki.de/doku.php?id=...s:pld_download), the board works just fine.

Big thank you John for work done on A3660 PCB and DiagROM.

[Mathesar]

Where did you get the "wrong"LEBUS jedec file?
I am planning to use the ones from Chucky's page.

[tnt23]

Originally Posted by Mathesar

Where did you get the "wrong"LEBUS jedec file?
I am planning to use the ones from Chucky's page.

I was using files from John's page, too. I suspect I might overwrite the file in question by mistake when reading out different GALs (GAL16V8 and ATF16V8) using TL866 software.

Perphaps you might want to binary compare the files, just to be sure.

Update. Did downloaded files from both sites, binaries are fully identical. This must have been my very own personal luck

[Chucky]

When it comes to GALs I have noticed that some programmers sucks BADLY in handling them. my TL866 simply program crapdata sometimes. verify pass. but if I load another file. program, it. loads the old file bac and THEN verify it will not pass anymore (and I never enctrypt GALs)

my Superpro 610S just works flawlessly! but that is a $500 programmer

[tnt23]

I've got an Amiga 1000 stuck in the US, probably instead of trying to ship it overseas I should sell it and buy $500 programmer :-)

On a serious note though. At some point I was thinking of pulling GAL programming algorithms from GALblaster software and making a cheap parallel port hack of it for Amiga.

[Mathesar]

I will use this programmer I salvaged from the garbage bin:

http://www.artbv.eu/support/programmers/up1/index.htm

Works only on Windows XP but it supports a lot of chips
Now I only hope that my ebay chinese PLCC to DIP converter is not messed up...

[tnt23]

Originally Posted by Mathesar

I will use this programmer I salvaged from the garbage bin:

http://www.artbv.eu/support/programmers/up1/index.htm

Works only on Windows XP but it supports a lot of chips
Now I only hope that my ebay chinese PLCC to DIP converter is not messed up...

My PLCC-DIP boards also came from China in a set with PLCC extractor, worked like a charm. At least your programmer works in Windows XP, I had to run Windows 95 on an LPT-equipped laptop

So far my A3660 runs rock solid, there is however an issue with SCSI2SD random failures. They are certainly not related to A3660 as I have seen them with original A3640, too. Wonder if a mysterious 'DMA FIX' can be applied, or just ditch SCSI entirely.