A4000 Acill - Issues booting with Diagrom

[Castellen]

With a A3400 CPU card installed, it detects Chipmem ok but get stuck at this stage:

Code: [Select]

---- Startupflags done

I gather that's a standard A3640 board, that's working correctly in another A4000?

Would help to copy the entire trace from DiagROM here to see everything that happened before that, or is that the only thing you see?

It will sometimes show:

Code: [Select]

---- Startupflags done

Testing if serial loopbackadapter is installed: <> NOT DETECTED
And occasionally fill the screen with repeating garbage characters after this.

That kind of thing can happen if the CPU board and the main board clock are running asynchronously.  With the A3640 CPU board fitted, both clock source jumpers (J100, J104) on the A4000 main board need to be in the EXT position.  I don't know if the reproduction board is labelled differently.

Might pay to check the various other system generated clocks all look OK.

Scope traces with the A3400 CPU Card:

Address
https://drive.google.com/file/d/1o18e7uQAPMfzgIrXc9zU3iPK14wg8qKL/view
https://drive.google.com/file/d/1iwEmi1CTxtlL1LohLnuBYj7dMuu8zNNU/view

Data - this does not look right at all ?
https://drive.google.com/file/d/1rMXfwuInlokitBYgWkAUu1qwJwkGUHlD/view
https://drive.google.com/file/d/1uxz-XCAC1Wjt8l3__8PWp5qqn91aNh0f/view

The data lines often appear 'noisy' as you've observed, compare with a standard working A4000.  The main point is you're not getting any 2.5V logic transitions, so it doesn't look as though there are collisions where two devices are getting enabled as outputs at the same time.

Scope traces with the BFG:

Address – why am I only getting around 3.5v ?
https://drive.google.com/file/d/1Yzml4t_dvluUD604lfJoE-LN6TciUWWG/view

Data – what is going on here ?
https://drive.google.com/file/d/1J4XWSmgVVbGp4zWJkzcwf-8HfTiJEl3P/view

I'm not familiar with the BFG or its design, but it's probably something modern using 3.3V logic as it's harder to find CPLDs that operate at 5V these days.  And instead of using bus transceivers that perform 3.3V to 5V logic translation in both directions, they're probably relying on a TTL logic high being anything above 2V - so it's probably OK.  If in doubt, check it in another A4000.

In the last image link, the file doesn't appear to be enabled for sharing.

[Castellen]

I've tried various different SIMM's - same results every time.
Buster and Ramsey are not installed.

I see you're using the new v2 DiagROM.  I'm not familiar with it, though as I recall from previous version DiagROM, the point where it's stopping for you is around the point where it actually starts using the memory.  If the memory isn't working correctly at that point, it will behave as you're describing.  The newer DiagROM suggests it's only doing a quick memory scan in 64k blocks, not a complete (slower) memory test as the v1.21 DiagROM did.

Might be worth using DiagROM v1.21 which will do a complete memory test, so you can be more confident that the memory is all working correctly, as opposed to the faster 64k block test.

I also don't know how DiagROM might behave with a partially populated board.  Unless you know for sure it'll work (I don't), it might be worth populating missing parts.

Motherboard jumpers J100 and J104 are set to INT with the 68030 CPU card, it does not boot if they are configured any other way.
The 68030 board is original (not a reproduction) and sold as working but I don't have a spare machine to test in to verify this.

That's the correct configuration for the A3630 CPU board, at least you've verified it with a known good main board.

I was thinking of removing the PLCC sockets as I've heard they can add extra capacitance and cause noise, but I've seen some people use them without any issues.

While the IC sockets have minimal impact on signal integrity, they can add an element of unreliability, and sometimes introduce more problems than they fix.  They can work OK so long as they're soldered perfectly and all contacts on the sockets and IC leads are completely clean.  But if everything isn't perfect, there can be permanent or intermittent problems.  It makes sense to have IC sockets on something if the part needs to be replaced sometimes, e.g. you're doing some kind of development work or it's needed for software updates (ROM sockets).  But adding sockets for parts that would never usually need replaced is often false economy if they create problems.

[Castellen]

Here are the results with DiagROM v1.3:

There's the problem, obviously an address fault with the memory.  If you're using a known good 2MB memory SIMM, then you'll need to fault find what's happening with the address lines at the SIMM, one of which might be open circuit or there may be a short between address lines.

Refer to pages 5 and 6 of the schematic: http://amiga.serveftp.net/Schematics/A4000_schematics/A4000_Rb_schematic.pdf
The address data is generated by U211 and buffered by U216.  With a 1μs/division time base, you should always see blocks of four strobes on the scope on all of the address lines CMA0 to CMA8.  CMA9 should be around 3 to 5V with no activity.  Also check that the column and row address strobe signals are working correctly - with valid looking activity; if not there's possibly a problem with the U212 IC socket.

[Castellen]

I found some bad connections on U212 so the column / row signals weren't getting to the SIMM socket.
The address lines all look good with activity as you describe.

With that fixed, I'm still getting exactly the same errors in DiagROM so not sure if the SIMMs I'm using are compatible.
I have some 4mb and 8mb SIMMS which do work in an A1200 accelerator, I read that on the A4000 SIMMS larger than 2mb can be used for Chipmem with anything over 2mb being ignored.

Sounds as though there's more than one problem, not helped if you're not confident that the SIMM is working correctly.  If you use a single sided 4MB SIMM (fast memory) as chip memory, it'll still work, but the system will only show 1MB.  Some larger sizes of SIMMs can apparently work correctly as 2MB chip memory, though I've had mixed results.  I got annoyed with constantly trying to find compatible SIMMs so I designed my own, see this thread, I've still got some in stock.

If the correct address data isn't getting to U211, which functions as the DRAM controller for chip memory, you'll also have memory address problems.  Check you have correct system address data at all 22 address lines at U211.

Since you've found some bad solder joints at U212, there's a good chance there are more problem solder joints elsewhere, meaning there are potentially other problems that haven't shown up yet.  I'd suggest a complete inspection of all solder joints.  You can use a scriber to check individual joints by pressing the IC lead sideways; if it moves easily then it's not soldered.  Also do a visual inspection to check for possible solder shorts between leads/pads.

[Castellen]

Having an issue with the display though, here's a video of what's happening:
https://drive.google.com/file/d/1C8woa8CZmVo20MxgregjlW7PXLK-wSqe/view
This display sequence is consistent every time.

What does the display look like with standard OS3.1/v40.68 ROMs?  The board will need U700 and U890 fitted, after which it should be able to boot to the insert disk screen.  Without U700/U890, I expect you'll get a yellow screen.

I doubt there's any issue with the video DAC.  If there is a problem, it's more likely to be something related to the display generator, U450.  Given what you've seen so far, a problem solder joint somewhere would seem likely.

I still have U400, U211, U450, U300, U350 in sockets, do you think it's worth soldering them also?
U700 and U890 are not fitted for now until I get the display working.

You've clearly had a lot of problems with the sockets already, they're not likely to get better.  If you want reliability, solder the parts on.  If you enjoy the frustrations of chasing intermittent problems, stick with the sockets.

Not sure what's to gain with the sockets.  If you do get a failed IC, which should not be a regular occurrence, it's a few minutes soldering job to replace a PLCC part.

I'll send you a message about some 2mb SIMMs as it would be nice to have some proper 2mb modules.

If you've already ordered other 2MB SIMMs, the A4000 should be in a state to correctly use them now.  You'll find they'll either work, or won't.  You shouldn't need to spend more unless the SIMMs you've ordered don't work, I'd suggest trying them first.

[Castellen]

With standard Kickstart ROMs and U700 and U890 removed I get a yellow screen. This is the same if U700 and U890 are installed.
If I try DiagROM with U700 and U890 installed, I get the same sequence of screens as shown in the video. No FastRAM is detected either.

If the DiagROM v1.3 menu is working correctly via the serial terminal and most of the various tests appear to be working, but the RGB video output video isn't working correctly, that would suggest a problem around U450.  Check at U450 that there is valid data on all 32 data lines, all 8 address lines, the address strobe (CCCAS) has a valid signal, the two clock inputs have a valid clock on them, and that there is valid signal on the three clock outputs.

Since you're getting a yellow screen using v40.68 ROMs and a fully populated board, that suggests another fault may exist, which may or may not be related to the RGB video issue.  That can be more complicated to find if DiagROM doesn't identify any problems, as the yellow screen exception error can be caused by many different things.  Were the ICs you used all confirmed to be working?

Ignore the lack of fast memory for now, that won't stop it booting.

[Castellen]

Made some progress with the FastRAM, it is all now being detected correctly and error free over multiple passes.

Great, what was the problem with that?

The IC's are all supposed to be working, either new old stock or tested used.
U700 is not installed at the moment until this issue is solved.

What's unusual is when comparing the DiagROM display sequence on startup between the A1200 and A4000, the A4000 shows the same sequence, up until the point when the menu should be displayed. I wonder what DiagROM is doing just before it displays that screen. I'm using the same DiagROM in the A1200 and A4000 so it's not an issue with the ROMs.

As mentioned, I don't know exactly how DiagROM might behave with a partially populated board.  You mentioned earlier that U700 and U890 were installed, I gather you've since removed U700?

I've previously seen DiagROM behave as you've described where there's sometimes no menu displayed on the monitor, but some of the video tests (as operated from the serial terminal) do show the expected image on the monitor.  I've no idea if this was due to a hardware problem at the time, or some kind of quirk with DiagROM.  I don't usually do much low-level fault finding with the monitor connected, so never looked into it any further.  I typically either use DiagROM or my own design in-circuit debugger to diagnose more complex hardware faults, and once these are resolved, the hardware is typically in a state where it can run the standard OS.

I'm not fully convinced there's a problem with U450 since you're mostly seeing the expected video output.

My suggestion would be to get the board more complete (i.e. U700 fitted) and try to get it running with the standard OS3.1/v40.68 ROMs.  If you get nothing but yellow screen exception errors, I can send you a specially modified ROM that sends out debugging detail when it boots to better understand where the software is having a problem.  I can't share that publicly since it contains parts of the original Commodore code.

[Castellen]

OK, so in summary:
   - The ICs which were all "supposed to be working" weren't necessarily working
   - You were still trying to persevere with the IC sockets, and these were continuing to introduce intermittent problems
   - There were multiple bad solder joints
   - The oxide wasn't cleaned from IC leads before soldering or trying to fit them into sockets

I don't think sockets are any use with these old IC's and less than perfect finish on the legs. I also know next time to apply new solder to the legs and remove with solder wick to refresh the coating before soldering to the PCB.

Next you'll be telling me you used 100% tin solder instead of 60/40 tin/lead with a decent flux   If anyone cares, I'd recommend one of the Kester leaded solders with 3.3% 245 no-clean flux, which is a great all-rounder for this type of work.

If you're trying to solder to heavily oxidised IC leads, I'm not surprised there are so many soldering issues.  You can do the solder wick thing, or a much faster/easier way is a couple of wipes with a fibreglass scratch brush to expose a clean surface, then brush IC leads and PCB solder pads with a no-clean liquid flux pen immediately before soldering.

Sounds as though you may still have intermittent solder joints somewhere based on some of the occasional problems you're seeing.  With the board running normally, you should be able to gently flex/twist it and it should continue to run normally.  If it freezes, resets, crashes when you flex the board, then you've likely got other solder joint issues to track down.

Regarding the system not booting with the RTC/U178 fitted, than can happen if U178 doesn't have 5V at the supply pin (18).  The system will run normally without the 32.768kHz crystal fitted, only the stored time won't increment, it'll stay 'frozen'.  While powered on, the system RTC will increment normally since that uses one of the CIA hardware timers, but it'll always load the frozen time from U178 at every boot.