After a bit of research, it seems that part of the Lisa ID is stored in the shift register at U976. When the Lisa ID is queried. If the incorrect ID is returned, it can mean that AGA modes are not available in workbench.
These are the two bits used in the Lisa ID shown tied to ground:
I confirmed these pins were indeed connected to ground on the motherboard.
So, on with the probes:
and here's what I see when the Amiga Test Kit queries the Lisa ID:
The fourth visible clock pulse (when S _L is low ) is loading data into the shift register, and the next 15 clock pulses are clocking the data out of the shift register (both this chip and it's companion at U975) note that in all the 15 pulses, the top output trace (in red) is stuck high... there should be at least two low pulses (at the the sixth and seventh clock edge when S _L is high) representing the two Lisa ID bits. Clearly this register ain't shifting!
Another visit to my trusty electronics part retailer and I ordered replacements for both shift registers U976, U975. I also ordered a replacement for U177, which is a 5 bit flip-flop, that latches the output of the real time clock chip... datasheet here:https://www.farnell.com/datasheets/2030248.pdf. I figured I'd replace this as well, as although it appeared functional , I'm not sure I trusted it to last with the level of corrosion it had suffered.
Once the chips had arrived, I masked up the board ready to replace the chips.
Before:
One hot air session later:
After:
So, did it work?....
Great! Lisa now has the right ID (fcf8, rather than fff8), and Amiga Test Kit is happy, thus I am happy....
Well, a bit happier.... what I'm not too happy about is all those bodge wires added by myself, and previous owners. You may have noticed in the chip replacement images above that I had already replaced some of those bodge wires with tidier repairs.... in my next post I'll cover what I did there in more detail, and tidy up all the other fixes on this board...
Running DiagROM's fastmem scan I found that only bit D7 of the lowest byte was faulty, all other bits worked fine. After a bit of SIMM swapping to rule out bad sticks of RAM, and a thorough connectivity test of the FastRAM data bus showed that everything was connected as it should be (and not obviously shorted to anything it shouldn't!) I turned my attention to the chip U891, which is a 74F245 bi-directional tranceiver connecting the lower 8 bits from the FastRAM to the Amiga bus. Here's the datasheet for the component: https://docs.rs-online.com/4604/0900766b80024d3b.pdf.
There was noticable corrosion around the pins of this chip from when the original Varta battery of doom vented it's wrath, but connectivity appeared to be fine, so I fired up my trusty Oscilloscope and probed the chip:
looking at both the faulty D7 and a randomly selected known good bit D1 for comparison. Here's what I found:
When T_R is high, and _OE is low, as occurs at the trigger point in the middle of the trace, this is when the chip is reading data from the RAM (pins D1_R and D7_R) and buffering it onto the A4000's data bus (bits D1 and D7 shown here). D1 should follow D1_R and D7 should follow D7_R.
D1 does this as expected (see green highlight above), but D7 immediately drops like a stone to logic 0 (see red highlight above) as soon as _OE (active low output enable) goes low regardless of what's happening D7_R (orange highlight)... which would seem to imply an internal short somewhere on this chip.
Off to my trusty electronics part retailer for a replacement 74F245,
One quick hot-air aided replacement, and...
Success!
FastRAM is now up and running!
At this point everything was looking pretty rosy in DiagROM. so it was out with DiagROM, and in with Kickstart (3.1 vintage in this case). and on to Kier Frasier's excellent Amiga Test Kit (grab it from here: https://github.com/keirf/Amiga-Stuff/releases):
Sometimes breakthroughs can come from the strangest places, but diagnosing a hardware fault through analysing a ROM's source and hex file is, I think, this one is the oddest, and yet strangely most satisfying debugging moments I've had yet...
It came about from me trying to work out what DiagROM was telling me with it's odd output:
e on A1000 version
This message wasn't documented anywhere, so I decided to take a look at the hex file for DiagROM (Available from: http://www.diagrom.com/files/stable/DiagROM.zip ), to see how this message comes about...
It turns out that 'e on A1000 version' is not the ravings of a rabid Yorkshire Amiga fan, but is actually part of the longer string:
This function is not available on A1000 version
As shown in context here:
Note that the 'e' of 'available' appears at address 0xDF0E...
Maybe when DiagROM goes to print something on the serial port, it ends up pointing at the wrong string?.... I turn to the source code (available here:
to find out how the code for writing to the serial port works. There's a few examples early on and they all take the form:
lea <named address pointer>,a0 ; <description of message to send>
lea <return address>,a1
bra DumpSerial ; Dump [string at a0] to serial, after it jump to where a1 points at.
.<return address>
So, the memory address of the string gets loaded into CPU register a0, and the return address loaded into the register a1. The CPU then branches to the DumpSerial code, which (simplified pseudocode):
1> Reads data (a character) from address a0 and spits it out the serial port
2> Increment a0
3> Repeat the above until a termination character (0x00) is read from a0, at which point:
4> Jump back to the return address (stored in register a1)
So, I know that the address of the first string that is output is 0xDF0E , but where should it have been pointing?
Let's do a bit of dissassembly of one of the first calls to DumpSerial: See that address on the first line: (0x)D70E ?... that's remarkably similar to the address 0xDF0E of our 'e on A1000 version' string...
In fact, it's this close:
Just one bit out... bit 11 (out of 15-0) appears flipped
So, could it be a problem with bit 11 when it's being used as an address?.. What could be causing this?:... It could be many things, for example:
A problem with the CPU, a faulty bit in register a0 maybe?...
A problem with the addressing in the DiagROM chips I have?
A bad connection from CPU card to mainboard?
1. seems unlikely, but hard to rule out without a second CPU or CPU card...
2. is possible... I guess, but I was still having issues with the original Kickstart ROMs, so maybe not as likely
I reason 3, a bad connection somewhere is probably the most likely, and given that I had a potential lead on it being an addressing problem, potentially around bit A11 I had a lead to go on...
I started tracing the signal 'A_11' on the address bus aound the board... which is when I found no connectivity from A_11 on the CPU connector to either ROM A_11 pins. Aha! It was about then that I spotted what I really, really should have seen earlier:
That rather chewed up socket is where the upper kickstart ROM lives, and note the equally chewed up board to the right of it... I remove the socket to get a closer look:
Oh dear... Looks like at some point when someone was swapping ROMs they were a little careless with a screwdriver (wasn't me... honest guv'nor!)
Thankfully all of the trace was still there, it had just been cut and shifted, so I was able to reposition the trace and re-tin it to make the connection:
(Not shown, but as I had to remove them to gain access to the traces, I replaced the rather battered DIP40 sockets with shiny new ones in the process.)
After loosely reassembling, again, with Diagrom installed and fingers crossed, I hit the power button and...
Hooray! We're into Diagrom! 2MB of Chip RAM detected, ah... but no FastRAM... OK so that's our next issue to fix... but for now I will just take a moment to reflect on the journey to diagnose this problem that went from a bizzare half string being spat out the serial port, through to examining both DiagROM's source code and hex file, to finding one address bit difference in where DiagROM was supposed to fetch a string from, to where it ended up, and finally to tracing that one address bit to a damaged trace under the ROM socket.
Other than the PCB trace damage and pad damage to U977 around the battery with attempted bodge wire fixes, it wasn't looking *too* bad. Certainly nothing glaringly obviously broken. So it was out with Kickstart, in with DiagROM and power on... Nothing...
So... nothing on screen, but could I see anything on the serial port? (DiagROM talks on the serial port as well as trying to display to the screen.)
With the A4000 Serial port connected with a jury-rigged null modem cable. I wasn't seeing anything when I powered on. But when I tried a "Ctrl + A + A" keyboard reset, I'd get a bunch of uninteligable garbled characters out of the serial port:
Progress!
That's somewhat good news, in that it tells me that the CPU is at least alive enough to be sending something across to the custom chip Paula to spit out the serial port. So, I turn my attention to the data bus, focusing on the bits that go across to Paula (DRD_31 - DRD_24). Sure enough, I found that DRD_27 and DRD_20 were open somewhere between Bridgette and Paula.
A couple of (temporary!) bodge wires were duly installed to make the connection... I'd later go back and do a proper repair on these... but for future reference, the red marks below show exactly where the breaks were:
(Huge shoutout to the maintainers of https://www.amigapcb.org from which the above image was captured. This site proved invaluable in tracing down opens)
After the quick patch-up I hit the power switch again.... Nothing....I try a Ctrl + A + A and I'm greeted with this out of the serial port:
Well that's interesting... I'm getting some useful text on the serial port now (still nothing out the video port), but clearly something is still off. The message that the 'Garbage' before the text is for debugging bit errors to Paula makes sense (And had this not been the first time I'd used DiagROM, might have sped up my earlier data bus fault finding!) , but what's this odd message: 'e on A1000 version' all about??? I didn't think the author of DiagROM, John "Chucky" Hertell was from Yorkshire in the north of England!?...
I assumed the '0 Motherboard memory' was just telling me that it couldn't find any memory, and started to think about how to debug this further. but that 'e on A1000 version' was niggling at the back of my head, what's that all about?... Something to mull over...
First of all, a bit of background to my interest in the Amiga
'Back in the day', in addition to the legendary Amiga 500, our family used to have an Amiga 4000/030 CR, both of which are sadly lost to the mists of time through many a house move. When the pang of nostalgia hit around the end of 2020, I went looking to see if it was possible to get hold of a working A4000 for a 'reasonable' price. I guess I shouldn't have been too surprised to find that prices for a coveted A4000 have shot up due to, I suspect, a combination of people with more free time during the pandemic, and my suspicion that we're probably at 'peak nostalgia' for the early 90's and the Amiga's heyday right about now! So, I decided to adjust my expectations and keep my eyes open for a non-functional A4000 that I could nurse back to health.
It took a while (even faulty A4000s are pretty hard to come by it seems!) but eventually I was able to purchase a faulty Amiga 4000/040 with keyboard for a price that I considered... let's just say 'not extortionate'.
So, here it is:
This A4000 was described by the seller simply as having a motherboard fault of some kind, as the machine itself would not power on. It had clearly suffered from the typcial battery leakage in the past, and said battery had previously been removed and replaced with a coin cell (more on that later...). Alkaline damage to the board had been patched up with bodge wires and the SIMM sockets had also been replaced and the board "somewhat" re-capped.
The A3640 processor card shown below was apparently working as the seller had tested it as working in another machine.
So upon receiving the well packaged Amiga, First thing to test? Power supply. It's a 145W Skyent model. Unloaded, the +5V rail was reading 4.97V, the +12V rail was 11.95V, with barely any ripple. (-12V was also pretty close to -12V from memory). A visual inspection of the internals of the supply didn't reveal any suspicious looking caps...(I'd actually end up recapping the supply anyway, but my readings on the caps I removed suggested this was a bit of a waste of time, as they were all well within spec...).
So, with the power supply looking ok, I hooked everything up and hit the power button.... Yep, I can confirm... definitely doesn't boot (even leaving more than the ~40 seconds it can take to get to disk insert screen if it can't find a hard drive...). However, at least the Green power light is on, and hard drive was making encouraging noises... So next job: strip it down, inspect the board for obvious damage/faults and break out DiagROM...
By using our website and services, you expressly agree to the placement of our performance, functionality, and advertising cookies.
Learn More
Graham Knight
One hot air session later:
See that address on the first line: (0x)D70E ?... that's remarkably similar to the address 0xDF0E of our 'e on A1000 version' string...
Aha! A_11 !! 
