#bad zip chips?
32 messages in this thread
I just installed 1 meg of chip ram and 4 megs of fast ram into my
3000. when i booted my 3000, the extra meg of chip ram showed up, but
the fast ram was the same as before i installed the new chips. to be
sure i checked with showconfig, and it listed 2 megs chip (correct)
and 3.5 megs of fast (incorrect, that is what i had before i added
the new ram chips). the fast ram chips i installed are 1×4 1Mb SC ZIP
chips. i checked my jumper and that my zips that came with my 3000
are 1×4 1Mb's. i also ran sysinfo and artm and the new fast ram did
not show up anywhere. if i put them in backwards (which i doubt, i
checked the location of pin 1 several times before i installed the
chips and checked before i turned the machine on, i do have a degree
in electronics and i've blown many a chip in lab by putting it in
backwards (i learned to tripple check the location of pin 1 the hard
way <g>), so i should know what i am doing <g>), or used the wrong
chips shouldn't my 3000 guru or give me some indication that there is
an error (it screaming "danger! danger!" would help)?
any suggestion on how to get my 3000 to recognize the new ram or to help figure
out what i might have done wrong?
it's times like this that make me wish i had just put a gvp '030 card into my
old 2000 (which has nice SIMM's that are halfway easy to get to) or a 1200…..
🙂
bob
Bob;
If anyone pin on any one chip failed to make contact, the whole bank will
not be recognized. It can be unbelievably easy to "miss-install" one of
the chips. Even with good lighting and eyesight, you really need a
magnifying glass to verify that none of the pins have "folded under".
In particular some of the chips are supplied with very soft leads and
these are the worst.
-bill
do you happen to know why the operating system does not warn me that one of the
banks is bad? i would think that function would be pretty important. i also
wonder why the amiga itself does not tell me. even the lowly ibm pc could warn
you about that, though you have to have a degree (or access to the right
manuals <g>) to figure out what it's warning signs are. 🙂
i'll keep a look out for bent leads when i check the chips later tonight. i do
not really look forward to it, but i guess i have to do it. 🙂 either that or
trust a repair person but i never want to go through the agony i did with my
2000 with a blown cia chip. it took weeks for the thing to get back…. it
seems the only store in town does not keep a proper amount of parts in stock
and they had to wait for commodore.
i would just pop in a memory card so i would not have to bother with gutting
the machine, but with the amax & picasso i only have two slots left which i
need for my future bridgeboard. sigh.
there was one thing odd that i noticed when installed the chips. instead of
having a bank filled with chips, they were spaced out (one in each, i believe).
any special reason why the chips would come that way? the only thing i could
think of was heat, but i though the banks had to be filled before the computer
would recognize the memory?
bob
Bob;
The OS does warn you that one (or more) of the banks is bad. If a bank is
bad then the title bar of the workbench will not show the memory as being
present.
The Ami software (firmware) appears not to necessarily "lock" you into any
particular memory configuration system. The power up memory check is
really intended to determine the amount of memory in the machine and
perform a memory diagnostic. When Ami "runs off the end of memory" she
gets an error in the verification. As far as the software is concerned,
when it hits a bad region of memory it has run off the end. The machine
really does not know the difference between the bad chip and a floating
bus at this point.
The machine holds four banks of 4 meg chips. Roughly, each nibble (4
bits) of memory from each of the 4 meg blocks are in the same location on
the MB (thus the data lines for each group of four chips are wired
together and the corresponding socket in each group has its "chip select"
wired to the same line that is unique to that group). The whole thing is
a matter of efficient circuit board trace layout and C= way of doing it is
quite typical. This has nothing to do with heating.
That does bring up the issue that if any one chip is in the wrong socket
then the memory will also not function.
-bill
you were right. I had some chips out of place. interesting way of laying out a
pcb. i must admit they do have a pretty good design as far as efficiency goes,
but i still feel they should have done more to make it easier to maintain. one
should not have to gut the machine in order to add simple ram chips. but oh
well, i can't change that so i have to live with it. 🙂
now all the memory works, but when i boot the machine off of my hard drive
(AmigaDOS 2.1) it gives me a software error. here is the actual message:
Error: 8000 0003 Task 0780DA78
this also happens when I boot from the 2.1 floppies (the original cbm disks). i
can only boot from my old 2.04 floppies and my hd will only boot if i install
2.04 on it. i tried formating the hd and then restoring my original system
files from backups (backed up with ABackup, which I downloaded from here).
so there seems that there is little that i can do, other than reformating
the hd again and installing 2.04 and working my way back up again. i'd rather
not do that, but it looks like i have to. after using 2.1 for a while, going
back to 2.04 is going to feel like a step backwards.
i really wish i knew what was wrong and that cbm had created a better method of
reporting errors other than numbers. oh well, even big blue does not tell the
little people what there error codes mean. 🙂
bob
Bob;
I tend to agree on the "pain" associated with accessing the MB for work
however, at least it is not something that I have had to do very often. I
am really glad to hear that it was only a mislocated chip and that no
damage occurred.
The Error: 8000 0003
The "8" is unrecoverable alert. The "0003" is "Illegal memory address
access error". The Task number is the program counter address at the time
of the alert.
Actually AmigaDOS is very good about its built in reporting. The message
that you received is roughly equivalent to the message that you get on an
MSTrashBox that decodes to "Bus Error" when the machine locks up. At
least with the Amiga you get told "What kind of bus error occurred" and
even the program counter address. With a terminal hooked up to the serial
port it would be possible to begin debugging the problem.
The Amiga's "Alert System" is quite ingenious. The Ami is usually able to
provide important information even when the system is no longer able to
function. The reason why the alert system is designed such as it is, is
because it is designed to both report failure information and go into a
debug mode even when virtually any of the system structures could be bad.
>… even big blue does not tell the little people what there (sic) codes
mean.
I assume that they do… somewhere, somehow but, the information is
usually almost worthless. The information of the Amiga Alerts is
available to anyone that has either developer docs or the include files
for most programming languages (Forth, C, and ASM for sure). Again, the
use of numbers is because the reporting system is designed to work even
when the system is so corrupt that it can not safetly make a reference
outside of the ROM.
Since you are at the point where you are willing to completely rebuild the
disk…
Put the l:fastfilesystem on a bootable disk with HDToolBox.
Using HDToolBox and that disk:
Select the drive from the list and choose "Partion Drive".
Select "Advanced Options" and write down ALL the information about the
drive.
Select "Add/Update…" and write down the information. If no filesystem
is listed then Choose "Add New Filesystem" else Choose "Update
Filesystem".
Choose "OK". This should return you to the "Partitioning Drive" window.
Make sure that none of the numbers changed and select "OK". That action
should return you to the opening window. Choose "Save Changes to Drive".
Quit HDToolBox and try rebooting. If the problem persists then go back
into HDToolBox select the drive and choose "Change Drive Type".
Choose "Define New…"
Choose "Read Configuration". Answer the requester.
Record the values reported. I would suggest that you also turn off
reselection (if you have only one HD, leave it off as the system will be
faster with it off anyway).
Choose "OK" and answer requesters but DO NOT "Save Changes to the Drive
Yet!"
When you get back to the opening window, choose "Partition Drive." Reset
your partition values to what you had when you recorded them the first
time that you looked at the values (before you added or updated the
filesystem). Choose "OK" and answer requesters until you are back to the
main window. Now choose "Save Changes" and exit.
If you do this right (and don't change the geometry of the drive) there is
an excellent chance that all of the warning given to you by HDToolBox
about how you are destroying all of the data on your drive may be for
naught. The problem is that you can of course do just that, destroy all
of the existing data.
It is possible for either the filesystem or the RDB to prevent a machine
from booting (particularly the RDB). I recently had a drive who's
filesystem was so bad that if if was the first drive on the chain, then
the machine would not boot at all (even from floppy). The only way that I
was able to recover that disk was to put it on another machine at a higher
scsi address than a working drive.
-bill
Yes, at $20 for a ZIP chip, adding ram is something i will not be doing very
often too. 🙂 though i did wish that i ordered another meg of dips since they
were only $5 a piece. i could have filled that dip section of fast ram.
i figured the task number was more or less equalivalent to the task number
given during a dos/vse & os error. then i had a text book next to me so i could
calculate the location of the error in my code, unfortunately i do not have
that for my amiga (not that enjoyed any of my mainframe programming classes
mind you <g>). are the rom error codes covered in the ROM Kernal manuals? since
i do not program my amiga i thought they were a bit pricey for getting them
"just out of curiousity". but i would like to get one of them if they can help
me figure out the error codes.
i have already run HD Toolbox and check the file system and such on my drives.
another tech i talked to suggested that i migh have a virus on my system (which
could explain why my system partition started behaving oddly during the last
two days, but disksalv did report problems so i was not entirely sure), so i
went ahead and low leveled my drive. i had to restore the OS using v2.04 since
my 2.1 dos disks will not boot at all and still give me the above error
message. everything works as it should, except for amigados 2.1. if i try
restoring my system part back ups (which was an amigados 2.1 boot part), i
continue to get the same error. i can not updated my present system part (which
is 2.04) since my 2.1 disks will not boot and generate the same error.
bob
Hadn't thought about it quite that way but you are right. I have added
memory exactly twice. The machines that are "full boat" are still "full
boat", the ones that are not are still the same, and I have messed with
neither since. There used to be (and probably still are) programs on CIS
that had the ability to convert an Alert to its english language
equivalent. One such program was called "GURU".
I don't believe that you can mix memory types in the fast section. That
section of dip sockets is "wired in parallel" with the first bank of Zips.
That would mean that you would have to not have zips in the first bank
which then means that there would be a 3 meg gap in the memory and it
would not autoconfigure.
Yes, the "Alerts" are covered in the RKMs (Libraries volume if I remember
correctly). I also think that buying the RKMs for only that reason would
be a bit pricey.
To make use of the address part of the Alert you would need to either know
where the task loaded (in advance) or be running ROM-WACK over the
internal serial port. In your particular case it could be a bit difficult
as you can't get the machine to come up enough to help you. If you had
another Amiga you could then hook the machines up by their serial ports
and use the working one to run the debugger and also provide the
"standard" for comparison.
I am doubtful as to the value of attempting the operation however as the
ROM-WACK debugger was really designed for use by someone with extensive
knowledge of the code that is causing problems and in this case that means
C= engineers.
I know that all of this can be a real pain… but have you tried putting
the l/fastfilesystem from the 2.1 disk set onto the 2.04 install disk? It
seems to me that I remember a problem with one on the OS version install
disk sets. It did not have the fastfilesystem on the correct disk (the
install disk itself) and in any event, the latest fastfilesystem that you
can get is the one that you should use.
If the disk does not have a filesystem on it then the filesystem in ROM
will be used (or at least attempted). I doubt that the ROM version will
support OS 2.1 (at least for booting from the HD anyway).
Do I understand you correctly that the 2.1 floppy disks will not boot the
machine?
Is this an old machine? Does it require a "SuperKickStart" disk to boot
when the HD is not working?
-bill
thanks for clearing up the matter about that dip bank sitting next to the zip
that acts as fast ram. i did not know about the wiring of the memory bank and i
am not sure how the 3000 manual covered the subject. i remember one of the
upgrades they suggested was to move the dips in fast ram to chip and then add
zip. i'll have to check, but 1 meg is not worth me waiting for the chips to
arrive and then gutting the machine again. 🙂 so until i check my manuals, i'll
take your word for it. 🙂
no, i have not tried copying the fastfilesystem from the 2.1 disks to the 2.04
disks. i checked my 2.1 install and wb disks and both have a copy of the
fastfilesystem on them. the wb disk contains the crossdos, aux, port and queue
handers. unfortunately i doubt any of those are estential to booting as the wb
2.1 disk crashes the machine just like the 2.1 install disk does.
my 3000 was purchased in march of 92 and the motherboard is a rev 5. it does
require a super kickstart disks if the hard drive is out.
bob
Are you sure you put the chips in the right sockets?
-Richard
I checked and I had two out of place. now the memory works, but when i turn my
machine on i get a software failure "8000 0003" task
"0780DA78". it gives me that even when i boot off of my original amigados 2.1
floppies! argh….
bob
Try running enforcer somewhere early in your startup sequence. I'd
bet something is generating some enforcer hits (probably something
having to do with the monitor or screen setup). Try altering or
replacing the offending lines or program. You might just go ahead and
try replacing all referrences to monitors in the 2.1 startup with
those from 2.04.
Ok, I tried putting the enforcer in, but it just re-kick my machine
(a Super KickStart 3000) and it crashed after it kicked and tried to
boot off the 2.1 disk. i added the option "noreloadkick" to the
enforcer command, but it still re-kicked. i will check my command
setup again just to be sure. i'll also check the monitor & screen
references, though i'm not sure why if they worked before they were
stop working after i only put in more fast ram.
needless to say i'm doing all of this on backups of my 2.1 floppies. 🙂
bob
Bob;
Iqnore my question about old superkick machine 🙂
What kickstart are you running?
In addition to the other suggestions you just received (from Richard?) you
might want to delete your system configuration file on the copy of your
2.1 disk. Several of the "preferences" files can cause problems if there
is something wrong with them.
-bill
my super kickstart file is of a 2.04 rom (at least that is what it says when it
kicks). ok, i'll try deleting my system configuration file from my 2.1 disk.
thanks. i'm willing to try anything at this point. 🙂
bob
My kickstart is version 37.175 and when it kicks the superkickstart file says
"2.x" and not 2.04 like i though (though i suspect it is 2.04 since it came
with those disks).
i tried deleting my system config file from my 2.1 install backup, and it did
not work. i tried copying the file system onto a 2.04 disk and it did work. in
fact i fired up hdtoolbox and updated my filesystem on the hd from the 2.1 disk
and the hd boots but neither 2.1 floppy will boot and i doubt my hd backs
(which were 2.1) would work either.
i'll try taking out a few preference files on my 2.1 install backup, just to be
sure.
bob
Bob;
I'm grasping for straws here but have you tried installing the
superkickstart disk and cold booting?
See if the kickstart will reload off of the superkickstart disk. If so,
then try booting from the 2.1 install disk.
Also, you might play around a bit with "early startup control" (holding
the mouse buttons down while booting).
-bill
I tried disconnecting the hd and running off of the floppy, but it
still crashed when i kicked off of the superks disk and tried to boot
from the install 2.1 disk.
i'll try fiddling around with the ks disk again just to see if anything will
work.
bob
Just a thought here, have you tried using the INSTALL command on a copy of the
2.1 disk? Just a chance that maybe it wasn't done before and it isn't bootable.
INSTALL will make it a boot disk.
Chris
i'll give it a try, but i'm pretty sure it is bootable. thanks for the tip.
bob
Bob;
Is there anyone around you that has an Amiga that might be able to give
you a copy of the installation set from their disks?
-bill
Bob;
As I try to think about what might be the problem <some musing follows>:
You have one of the earily A3000s, thus the bootable HD must have a device
name of WB_2.x and also have a copy of the kickstart file on the drive.
Basically, when you turn on your machine, the ROM does the basic sanity
check, a check for some CHIP and FAST RAM, while the A2091 (equiv) checks
itself and then goes looking for things on its bus.
An attempt is made to read the RDB's off of the drives that are found and
reported that they were HD type devices.
I am pretty sure that if a disk called "SuperKickStart" is found in DF0:
(or maybe any floppy drive) the machine will immediately attempt to load
the kickstart.
When it reports having found a device named WB_2.x the machine's ROM
attempts to load the kickstart file.
Following the successful load of the kickstart file, the disk devices are
rescanned looking for the highest priority bootable device.
Now it appears that this works reasonably well for your system IF you have
the HD setup for AmigaOS 2.04 but not for 2.1 version.
Possible problems:
1. Your 2.1 disk set is bad.
2. Your kickstart is bad but works under 2.04 (which raises its own
questions).
3. Your HD is actually not formatted/structured properly.
4. Actual hardware problem with the machine.
Solutions (hows that for arrogance?):
1. Can you test your diskset on someone elses' machine?
2. Borrow a disk set from someone else (both sets) and start over?
3. Using HDToolBox:
a. Check that the DOStype matches what should be there:
Fastfilesystem: ID 0x444f5301
International FFS: ID 0x444f5303
b. Mask: 0x7ffffffe
c. Max Transfer: 0xffffff
d. Reserved cyls: 2
e. Buffers: at least 30
f. Check the numbers to be sure that the geometry matches itself and
physical size of the drive (total number of blocks)
g. Be sure that buffer memory type is set to any though you might
want to try restricting it to CHIP and then to FAST for testing.
It is possible to have an error in some of this that
will be version specific as far a failure is concerned.
4. Have you run a memory test program. It is possible for a memory
problem to show up in one version of the OS and not another.
I don't know if any of this helps but still interested in learning what
might be wrong.
-bill
i just ran my install 2.1 disk (backup copy) through DiskSalv2. i used the
salvage mode and restored the files that it thought was bad (i disagree, but
i'm just the user). i rebooted and bang, the same error popped up. i'll trying
doing it again, but i think the results will be the same. so i do not think the
disks are bad.
what type of hardware error would generate this problem and not report it when
using a different os?
i wish i had a 1200 so i could try installing os 3.0 and see if that worked.
right now i'll probably sit & wait for os 3.1 to be released instead of giving
myself headaches by watching that alert display…. 🙂
bob
i think i have found the AmigaDOS 2.1 problem. for some reason it is the
SETPATCH command that causes the system to crash. once i rem'ed it out of any
startup-sequence file it was in, the machine booted and installed 2.1 without
any problems.
do you happen to know why SETPATCH would cause the system to crash like that
after i added 4 more megs of fast ram?
so far everything is working…. i'm off to make a backup of the sys: partition
just in case. 🙂
bob
Shouldn't- unless somehow you got aholt of an older or incompatible
version. Where did you get yours?
//
-Karl \X/ Amiga and Autopilot: The *only* way to fly!
straight off the AmigaDOS 2.1 disks. they have been write protected
since they arrived back in may. i do not know how anything could have
happened to them.
2.1 started to crash only after i put in the 4 megs of zips, and the setpatch
was causing the problem. go figure….
bob
Bob,
Check your memory chips and see if you are mixing Paged mode and static
column ZIPs. If you are then 2.1 WILL NOT BOOT! Remove the paged mode
and replace them with static column ZIPS. That should fix your problem!
Clark -|-
Williams –O-o-O– Via George
Bob;
The "loading kickstart 2.x" is the proper message. At the point where
that message comes up, the machine really does not know what it is
loading.
-bill
The fact that you can use 2.04 with no problems but have problems with
2.1 shows that there is probably no hardware problems. The 8000 0003
or 0004 error is usually caused by some illegal instructions that
cause enforcer hits. If you have some way of reading the enforcer
report, it will show you what program is at fault. A number of the
preference programs can cause these hits as well as instructions to
change the preferences. It's a hassle, but you might want to slowly
transform your 2.04 disk to 2.1, adding one thing at a time to the
startup sequence and adding 2.1 files until it crashes. Then you can
find the culprit and leave it out.
Richard;
I am gathering that his problem is compounded by the fact that the machine
will not get far enough to even run enforcer.
I was personally pretty suspicious of the RDB and filesystem (since I have
seen that sort of problem with both of those recently) but since the
machine will not boot the 2.1 Install disk with the HD disconnected, the
indicates that either the disk set is bad in some way or there is a
hardware problem.
Difficulty is that between 2.04 and 2.1 is is possible for a hardware
problem to prevent one from booting and not the other.
-bill
Yea. It looked like he was unable to start enforcer and since setpatch
was the problem, it makes sense. I guess you can never totally rule
out hardware problems but what Bob was experiencing sure reminded me
of some of the problems I had with my 3000. I had forgotten about
setpatch, which along with some of the prefs stuff had caused me the
most problems.
Except that crashing when setpatch runs is a symptom not a problem.
If setpatch crashes the machine then there IS something wrong. Now
it is possible that a setpatched function does not correctly
determine machine configuration but that is not directly setpatch's
fault.