28 Apr
2018
28 Apr
'18
4:34 p.m.
Hi, All,
I've been doing component-level diagnosis of a bad Amiga 1000 WCS
board and since I was unable to find this information anywhere, I
thought I'd post it to the list so that it's in the hands of more than
one person.
For an Amiga 1000 that starts up with a turquoise screen and never
asks for Kickstart, it means that the WCS RAM test has failed. Common
causes are one or more bad 4464 DRAM chips on the WCS board or a bad
PAL. I don't happen to have the PAL equations but I did spend some
time with a sick Amiga 1000, a Fluke 9010A and a cheap digital scope.
There are hand-drawn schematics floating around but they don't appear
to match the production hardware in either part placement or
completeness (the schematics describe 2 PALs, DAUGCAS and DAUGEN, but
the production hardware has two additional PALs, DPALCAS and DPALEN,
for one specific example).
If one has a Fluke 9010A and 68000 pod, one can test the WCS RAM by
pressing [RUN UUT] and turning on the Amiga and waiting a second or
two for the ROMs to set the right memory map bits to make the WCS
writable. One can then do simple [READ] and [WRITE] tests to the
Amiga at $FC0000-$FFFFFF and even run a [RAM SHORT] on part or all of
that range (a RAM SHORT test on 256Kbytes will take more than a few
minutes).
The memory itself is a bank of 8 4464/50464 64Kx4 DRAMs at U1B-U1E and
U2B-U2E, arranged sensibly in two banks of 128Kbytes. The chips in
row 2 are the lower half ($FC0000-$FDFFFF) and the chips in row 1 are
the upper half ($FE0000-$FFFFFF). The individual bits are arranged as
follows:
U1E/U2E $000F D0-D3
U1D/U2D $00F0 D4-D7
U1C/U2C $0F00 D8-D11
U1B/U2B $F000 D12-D15
For those that want to trace individual bits the order on each DRAM is
pin-3, pin-2, pin-15, pin-17 which is slightly off the given order on
the 4464 datasheet of 2,3,15,17.
By way of verification, the WCS board I'm repairing failed the RAM
test with bad bits at $F000 when I pulled the defective chip from
position U1B. The same chip failed testing in a Ming HT-21 "Handy
Tester" DIP logic and DRAM tester (but passed when tested as a 4416,
because the fault was not in the first 25% of the memory cells).
-ethan
30 Apr
30 Apr
7:07 a.m.
On Sat, Apr 28, 2018 at 6:34 PM, Ethan Dicks via cctalk <
cctalk at classiccmp.org> wrote:
Hi, All,
I've been doing component-level diagnosis of a bad Amiga 1000 WCS
board and since I was unable to find this information anywhere, I
thought I'd post it to the list so that it's in the hands of more than
one person.
I wonder if one might be able to use the excellent Diagrom in place of the
A1000 ROMs to do some testing.
At least then you might be able to put some known patterns into the WCS to
read back and see if they make sense.
7:29 a.m.
On Mon, Apr 30, 2018 at 10:07 AM, Geoffrey Oltmans <oltmansg at gmail.com> wrote:
On Sat, Apr 28, 2018 at 6:34 PM, Ethan Dicks via
cctalk
<cctalk at classiccmp.org> wrote:
When I started debugging these dead A1000s, I took a look at Diagrom...
https://github.com/ChuckyGang/DiagROM/blob/master/DiagROM.s
There's code in there to handle the A1000 as a separate case, but it
seems only to remove features to make it fit in smaller EPROMs, and
that is a recent update. The original DiagROM was written for all
later machines, without a WCS board.
Hi, All,
I've been doing component-level diagnosis of a bad Amiga 1000 WCS
board and since I was unable to find this information anywhere, I
thought I'd post it to the list so that it's in the hands of more than
one person.
I wonder if one might be able to use the excellent Diagrom in place of the
A1000 ROMs to do some testing. At least then you might be able to put some known
patterns into the WCS to
read back and see if they make sense.
One could use the DiagROM as a starting point and _add_ those tests
in. I haven't gone over the specifics, but there is some code in the
real A1000 ROMs to write enable the WCS board before reading in the
Kickstart disk. The exact value to write to which address is
documented somewhere but I haven't done any digging to find it. I've
just been using the Fluke and running the processor for a few seconds
(UUT button) to let the ROMs do their thing, _then_ using the Fluke
for RAM tests at $FC0000-$FFFFFF.
If I hadn't had the Fluke handy, I'd probably have taken the route of
writing some new ROM code to test WCS RAM. Fortunately I also have an
old Grammar Engine PromICE so I could plug that into the ROM sockets
and do some quick turnover on the code development before burning real
EPROMs.
-ethan
8:24 a.m.
On Mon, Apr 30, 2018 at 10:29:13AM -0400, Ethan Dicks via cctalk wrote:
[...] The exact value to write to which address is
documented somewhere but I
haven't done any digging to find it. I've just been using the Fluke and
running the processor for a few seconds (UUT button) to let the ROMs do their
thing, _then_ using the Fluke for RAM tests at $FC0000-$FFFFFF.
I disassembled the A1000 boot ROM recently. There's a lot of interesting
debugging cruft left in there, otherwise it could have fitted on a smaller
chip.
As far as I can tell from the code, a 68000 RESET sets the latch such that
F80000-FBFFFF contains the boot ROM and FC0000-FFFFFF is the writable WCS. A
*write* to F80000 (and probably any other address up to FBFFFF) flips the latch
such that the WCS is write-protected and is mirrored throughout the region
F80000-FFFFFF. Playing with the UAE debugger confirms this theory is correct
for it, but I don't own a suitable hardware debugger to test on my real A1000.
Without a debugger, one could also build a Zorro-I board for the edge slot
which presents a debug ROM at F00000-F7FFFF, and provided it starts with the
right magic number, will be executed with the WCS still write-enabled. (The
CDTV puts its CD-ROM driver and fancy animated boot screen in that space.)
9:08 a.m.
On Mon, Apr 30, 2018 at 11:24 AM, Peter Corlett via cctalk
<cctalk at classiccmp.org> wrote:
On Mon, Apr 30, 2018 at 10:29:13AM -0400, Ethan Dicks
via cctalk wrote:
Hi, Peter,
Cool. I've always wondered what's in there (but not enough to do the
work myself ;-)
[...] The exact value to write to which address
is documented somewhere but I
haven't done any digging to find it. I've just been using the Fluke and
running the processor for a few seconds (UUT button) to let the ROMs do their
thing, _then_ using the Fluke for RAM tests at $FC0000-$FFFFFF.
I disassembled the A1000 boot ROM recently. There's a lot of interesting
debugging cruft left in there, otherwise it could have fitted on a smaller
chip.
There probably wasn't any point to worrying about making it fit. I'm
sure the time pressure was far too great to let them spend extra time
trimming that stuff out.
As far as I can tell from the code, a 68000 RESET sets
the latch such that
F80000-FBFFFF contains the boot ROM and FC0000-FFFFFF is the writable WCS.
That makes perfect sense. The boot ROM is echoed throughout the
memory map (from my exploration), including $000000, which is typical
for any 68000 system, but at many other address ranges too.
What I've been doing to use the Fluke for testing WCS RAM is to power
up the Fluke (pod must have power before being attached to computer),
plug the pod into the 68000 socket, hit [RUN UUT] on the Fluke, which
responds with "UUT POWER FAIL -ATTEMPTING RESET", then power on the
A1000. At that point, the A1000 runs code from the boot ROMs, blinks
the power light, then hangs while displaying a turquoise screen
(because of the bad RAM). The ROMs leave the WCS writeable and I do
my tests.
A
*write* to F80000 (and probably any other address up to FBFFFF) flips the latch
such that the WCS is write-protected and is mirrored throughout the region
F80000-FFFFFF. Playing with the UAE debugger confirms this theory is correct
for it, but I don't own a suitable hardware debugger to test on my real A1000.
I have a Fluke 9010A and will be soldering in the replacement RAM chip
today (I found it in a box of spares I got when my local Commodore
dealer closed up shop). I can easily test writing to $F80000 and
other addresses to test.
It also seems to me to be handy to look at building a clip-on
diagnostic LED to show the state of that flip-flop. Not essential,
but would be interesting to watch.
Without a debugger, one could also build a Zorro-I
board for the edge slot
which presents a debug ROM at F00000-F7FFFF, and provided it starts with the
right magic number, will be executed with the WCS still write-enabled.
Hmm... interesting thought. Presumably one could also easily put a
textual LCD on it so no matter what state the custom chips are in, it
could still display text as long as the bus wasn't totally bunged up,
but if it were that bad, it wouldn't be running code anyway.
-ethan
P.S. - I found another A1000 looking for parts for this one... so now
I definitely have more things to test.
9:39 p.m.
On Mon, Apr 30, 2018 at 12:08 PM, Ethan Dicks <ethan.dicks at gmail.com> wrote:
On Mon, Apr 30, 2018 at 11:24 AM, Peter Corlett via
cctalk
<cctalk at classiccmp.org> wrote:
Yep. Confirmed with the Fluke. You can write any value to $F000 000A
and the pod will reset the processor, which _does_ enable the WCS RAM
for writes.
On Mon, Apr 30, 2018 at 10:29:13AM -0400, Ethan
Dicks via cctalk wrote:
> [...] The exact value to write to which address is documented somewhere....
> As far as I can tell from the code, a 68000 RESET sets the latch such that
> F80000-FBFFFF contains the boot ROM and FC0000-FFFFFF is the writable WCS. > A
> *write* to F80000 (and probably any other address up to FBFFFF) flips the latch
> such that the WCS is write-protected and is mirrored throughout the region
> F80000-FFFFFF.
Confirmed with the real hardware. A write to any address from $F80000
through $FBFFFE does flip the WCS write-protect latch and does mirror
WCS at $F80000
I have a Fluke 9010A and will be soldering in the
replacement RAM chip
today
Replacement 41464 installed. Fluke tests pass! All the RAM is good!
The Amiga won't boot to Kickstart with the Fluke in place (there are
known effects of having the pod in place of a real CPU, including a
15ns delay on everything) but with the original CPU in the socket, it
boots right up to the Kickstart screen now.
-ethan
2379
days inactive
2382
days old
5 comments
3 participants
participants (3)
-
abuse＠cabal.org.uk -
ethan.dicks＠gmail.com -
oltmansg＠gmail.com