#ramlib prog missing
14 messages in this thread
Whenever I attempt to run MUI or a MUI-based program I get;
ramlib
Program failed (error #80000004).
Wait for disk activity to finish
Suspend Reboot
Checking the various dirs and running the command 'resident' finds that no such
command exists.
Would somebody please refresh my memory and tell me where this should be
located and where I would find this if I'm missing it.
TIA
– Phillip, on AutoPilot 1.80 _____T_____
Going Amiga 'till the Sun goes Nova! * * O * * B5>ST.all
one of your librarites in L: got corrupted…
replace the ram-handler
and any ram based things in L:
tanks, but I've even gone so far as to delete files and reinstall wb3.0
Seems that something really bad is going on. Whenever I try to boot w/o startup
all I get is a black screen. Not even the early startup scrren will show.
BTW – 1230/50/50/8, wb3.0, zappoCD, MUI, ToolsDaemon, MagicMenu, etc
Any more hints? Anybody, anybody?
– Phillip, on AutoPilot 1.80 _____T_____
Going Amiga 'till the Sun goes Nova! * * O * * B5>ST.all
Phillip,
well, that _is_ different. If it boots with the startup-sequence, I don't
have a clue what is going on. You might try one of the RAM check programs of
the off chance one of them is defective. Still strange though.
You did try reseating all the chips?
Brian
Been there…. Done that…. Better.
MUI could not make a RAM chip error show itself. There may be an
incompatibility between MUI and another program, like MagicMenu or something.
Take all these programs off temporarily.
Ian,
sorry, but any program can cause a RAM chip error. All that is required is
that the program allocate the memory and actually utilize the memory location.
Now, if MUI doesn't allocate any RAM whatsoever, nor does it ever look at RAM
to read a value, I could accept your statement. But given the fact that it
allocates structures and refers to them all over the place, I have to take what
you said with a serious grain of salt. Sorry.
Brian
Been there…. Done that…. Better.
>>sorry, but any program can cause a RAM chip error.
What are you talking about? The original problem dealt with the "ramlib" task.
This is the file handler for the RAM disk. There is absolutely no evidence
whatsoever that there is a hardware flaw with the chip, a crash of the ram disk
file handler does not mean the ram chips are bad.
Any and every program can be using ram, so if the chips are flawed, any program
could crash due to a ram error. If the ram chips were defective, the problems
associated with it could be slowdown, data loss, random program crashing and
misoperation, or a complete system hang.
The RAMLIB is a task, and all I was saying is that to consistently crash the
Ram-lib a program is making an error with the ram disk, or a program that deals
with the ram disk. Many programs use the ram disk unknowingly since T: is
assigned to ram:, and is used by some system functions. For example,
preferences (and MUI prefs) uses the RAM disk for the ENV: directory.
I don't think you understood what I was saying. Someone brought up the
possibility a ram chip was flawed, and I was simply trying to say this would
not consistently cause a ram-lib error, associated with only MUI. MUI is the
problem, and not in its allocation of memory, but likely in its handling of
RAM-based files.
With MUI's history of being fairly buggy, I think its hard to claim MUI can't
be the source of the problem. I've gotten MUI to work alright on my 3000 now,
but have had crashes in the past, and I have also heard from many other people
that have had it cause intermittent problems, mainly if they are running any
other specialized commodities or whatever.
Holy Freakin' Cows!!!! What did I start?
Yo, guys! I believed I posted the answer a few days ago.
The problem turned out to be that 'muimaster.library' was in my LIBS: instead
of the MUI/LIBS drawer.
MUI was looking for a library that simply wasn't where it was supposed to be.
It was already in ramlib and MUI couldn't recognize the fact. It's not so much
of a bug as me doing a (bad) manual install. The Installer sorted it out for
me.
As interesting as this conversation was turning out to be, and you _both_ might
be right (different circumstances, same results), the debates getting a bit
circular.
Thanks to everyone for their pointers, BTW.
^^^^
– Phillip, on AutoPilot 1.80 _____T_____
Going Amiga 'till the Sun goes Nova! * * O * * B5>ST.all
You may be right. Time to reseat all the chips.
Now where's that screwdriver?
– Phillip, on AutoPilot 1.80 _____T_____
Going Amiga 'till the Sun goes Nova! * * O * * B5>ST.all
Your problem is NOT a corrupted file. The ramlib is a handler used by the
Ram-Disk. If a DOS error occurs to a file on the Ram Disk, like a file closed
twice, or a handle accessed in a bad way, this error can occur. It would be
sort of like if you saw "DF0 – Program Failed". Maybe you have never seen that,
but it can happen.
MUI is the problem. It must be installed wrong. Make sure you have a version
installed for the right processor. Maybe you have the 020 version installed
and you only have a 68000.
Reinstalling Workbench is not going to fix anything, just mess things up. If
you cannot get MUI working correctly, contact the author via e-mail. It is
MUIs problem, so ask him for advice. He may know what might cause it.
Ian,
>>The ramlib is a handler used by the Ram-Disk
sorry to disappoint you, but that's wrong.
The RAM-Disk is handled by the RAM-handler (L:RAM-Handler up to KS 1.3, a
resident module since OS 2.0).
`ramlib' is an extension to the exec.library, that will be called whenever exec
is going to open a library or a device that is not already in memory.
`ramlib' will call DOS to LoadSeg() the library/device from the given path, or
the libs: or devs: directories, respectively. It will then made resident by
InitResident().
`ramlib' also will be called by exec.library whenever a memory allocation
fails. It will look through memory and will remove any libraries and devices
that are not in use (the same thing that `avail flush' does).
The only reason for `ramlib' causing and showing up in a software failure, is
that a library or device file on the disk is corrupt. I ran in that one quite a
bit when I had to program some library code.
– wkc – … via AP from Hamburg, Germany
and mui also handles thhe ramlib too fool,how else it is going to eat up your
memoory by loading dozens of mui images?
This is getting quite informative.
BTW, I traced it to a corrupt system-configuration file. The file size was the
same, but the bad one had the word 'generic' in it twice. Oh well.
Thanks ya'll.
– Phillip, on AutoPilot 1.80 _____T_____
Going Amiga 'till the Sun goes Nova! * * O * * B5>ST.all
tanks, reinstalled MUI. seems that it doesn't like muimaster.library in any
other lib but it's own.
BUT……
I'm still getting a black screen on startup. AND I discovered that the prompt
is still there, just hidden by the black screen if I 'boot w/o startup'.
Hmm…. okay time to take this sucker apart…….. again. sigh. don't worry,
it'll be something simple. it always is. just gottat find that 'last thing'.
– Phillip, on AutoPilot 1.80 _____T_____
Going Amiga 'till the Sun goes Nova! * * O * * B5>ST.all