#GURU TABLES
17 messages in this thread
Does anyone know where I can find "real" documentation regarding
the guru meditation numbers and what they indicate:
If not, does anyone have a clue regarding the following numbers:
000000003.00208E8
000000005.???????
System ROM : v1.3
-thanks, ken
Ken,
Not a clue on docs for GURU but do have a program that tells me.
000000003.00208e8 -> Is an odd address error,ie. some program called for an odd
memory address. 000000005.??????? -> Is an Division by zero error.
Hope this helps…I whould look at your software as the problem.
—Stephen—
===Cruisin' on Auto Pilot 1.77–From Kansas to OZ===
Stephen and Ken,
I have received the 8000 0003 with a couple of newer programs,I and was told it
was indeed an odd address error and that 680000s can only go to even addresses
and not odd.So it goes to the address before the one it wants and you end up
getting the guru.
I don't know if there's any way around it.Hope this helps.
keith hicks ===AP=1=75===>
Keith and Ken,
I have uploaded a very good GURU lister into library system utilities, in
Amigatech. This is named Showguru.lha. I run it on my A500 and it shows a full
description of all GURU's. I whould recomend downloading it to everyone who has
ever wonder'd what their system was trying to tell them.
I hope that this will help you.
—Stephen—
===Cruisin' on Auto Pilot 1.77–From Kansas to OZ===
Stephen:
> 000000003.00208e8 -> Is an odd address error,ie. some program called for an
odd
> memory address. 000000005.??????? -> Is an Division by zero error.
> Hope this helps…I whould look at your software as the problem.
As I feared, and thanks for the offer <G>, but i doubt you really would want
to…
> I have uploaded a very good GURU lister into library system utilities, in
Amigatech.
> This is named Showguru.lha.
Thanks plenty, I'm sure it will be VERY useful.
Odd address errors, hmm, I suppose this could be pointer arithmetic problems,
but this code does very little pointer math. Are you aware of any problems of
this type caused or contributed by the AZTEC C compiler. I remember
considerable discussions several years ago re "pure 32 bit code"
– thanks again, ken
Stephen:
> I have uploaded a very good GURU lister into library system utilities, in
Amigatech. > This is named Showguru.lha
Sorry to bother you, but:
I Could not find any showguru.lha or any files in system utilities dated after
2/15/95
– maybe just my ignorance, I will try again later
– thanks again, ken
Ken,
I could not find it either…Don't know why. I have uploaded it again into
Amigatech lib. system utilities and also Amigauser, other utils.
Maybe this time it will be there. Sorry for the mixup. I don't know what
happend.
—Stephen—
===Cruisin' on Auto Pilot 1.77–From Kansas to OZ===
Stephen:
Am I daft, Its now 01:00 am on 2/23, only 8 hours after you uploaded
your file, but I cant find a trace in either amigatech.anywhere or
amigauser.anywhere
Thanks for the effort, sounds like a great util…… 🙁
-ken
There are other guru utils about, it takes a while, sometimes, for the
sysops to get files from UL to LIB, and an odd address error may easily
come from using data as an address, i.e. you forgot an & or added a *
where you shouldn't. I strongly recommend using the following tools (also
here) Enforcer, Segtracker/Findhit, and Mungwall.
Thanks arnie
I'm afraid I've been out of the Amiga Development arena for quite awhile, and
it may take some time for me to get back up to speed to solve this annoying
problem.
Most likely, you are correct regarding the pointer arithmetic, we do quite a
bit of casting….
-thanks, ken
Don't you get odd addressing errors on 68000-based Amigas when you try to read
a 16-bit word or a 32-bit word on non-even addresses? But that same code works
on an '020, right? My brain is getting hazy about the 68000, too.
Right, John. The 68000 assumes that if you go for a word, you want it in one
chunk; and that means the address must be EVEN so that the two bytes can be
accessed in one dip from memory.
The 68020 and up will work if you give an odd address, but it will slow the
operation, since two memory dips (and a little bit-juggling) are called for;
eventually, the sixteen bits (or 32 if you're doing longword) starting from the
specified odd address will be delivered. So you won't get a GURU #3 from a
68020 and up.
However, due to the loss of speed, it's a heckuva good idea to try to code
your word (and longer) accesses to work on even boundaries. Might even be an
idea, where practical, to run a test phase with a 68000 just to check that's
so.
By the time you get into 32-bit memory architecture, some programmers are
anxious to make sure that longword accesses are always made with addresses that
divide evenly by 4 (quad boundaries? don't know the term for sure). This
sounds like a straightforward objective, but there's a curve they have to watch
for if they are serious: they have to try to make sure that the stack pointer,
too, notches along in multiples of four so that you don't lose extra clock
cycles with interrupts, subroutine calls, and whatever.
If you're not a CCC (clock cycle counter), you can ignore most of this. But
it doesn't hurt to be sure word/doubleword values are indeed on even
boundaries. It will work better on the 68000, and you'll get faster operation
on other machines.
–Jim
Ken,
When files are uploaded here, they go into a 'holding area' until the sysops
can download and check them out – make sure they are free of viruses, that they
work, that the description fits, etc. And after they have been checked and
approved for the libraries, they still wait for a pre-set time when CIS
releases them to the libraries. So, it usually takes around 24 hours from
upload time until they actually become available for download.
—Betty
Betty,
I din not know that they did it that way. Now i understand that it was'nt a
problem with my uploading. Thank's for the clarification.
—Stephen—
===Cruisin' on Auto Pilot 1.77–From Kansas to OZ===
Thanks for the clarification on the time frame.
1. Is 24 hours std, what is typically the MAX?
2. Extensions like .lha … are these zipped, or compressed in some fashion.
If yes,
are there utils to unpack them as well available…?
<talk about revealing <G>>
ok, so I'm mostly a PC developer….
We try very hard to get the programs out within the 24 hours, but occasionally
it takes longer. If one of us has problems with a program, others will try it,
for example, and that takes longer. Or if some of us lack the hardware needed
to do certain programs (not all of us have AGA machines, for example), then the
programs must wait for a sysop who can handle it. But 24 hours or less is the
norm.
Nearly everything in the libraries is compressed, and almost all of them are
either .LHA or .LZH files. Both of these formats can be unpacked with
LHA138.RUN from Library 14 of AmigaUser. LHA138.RUN is a self-dissolving
archive. Just type its name, and it unpacks into the current directory. You
get LHA, a doc file, and I think something else. Copy LHA to your c: or Tools:
directory, so it will always be ready for use. The doc file will tell you how
to use it. We do have versions of ZIP and some other archivers, but nearly
everything for the past two or three years has been packed with LHA.
—Betty
Ken,
the official documentation for "guru meditation" numbers is in the RKM
includes and autodocs, "exec/alerts.h" or "exec/alerts.i".
But in this file, only system alerts are documented.
Processor alerts, which will be in the range from 00000002.XXXXXXXX to
0000003F.XXXXXXXX, you have to look up in the Motorola documentation for
the 680XX CPU which is in use.
I think there are some files in the librarys here which will help you
interpreting and/or catching alerts. Just do a search for the Keyword
GURU.
– wkc – … via AP from Hamburg, Germany