Conference hydra::amiga_v1

I too am looking for 

WDB.2.ALL & WDB.1.ALL

 mark

    Any interest in getting these and putting them on the net - apparently
    they are PD.
    
    Regards (and I would like a copy of them as well)
    	Kevin
    
           <<< FRSOLD::IS$NOTES:[NOTES$LIBRARY]AMIGA_SYS_1.NOTE;1 >>>
                            comp.sys.amiga - postings
================================================================================
Note 5401.0                    WorldDataBank files                    No replies
FRSOLD::ZIMMERMANN "polyslo!nschultz"                35 lines  30-JAN-1990 23:00
--------------------------------------------------------------------------------

Path: shlump.nac.dec.com!decwrl!polyslo!nschultz
From: [email protected] (Ned W. Schultz)
Newsgroups: comp.sys.amiga
Subject: WorldDataBank files
Message-ID: <[email protected]>
Date: 30 Jan 90 00:41:57 GMT
Reply-To: [email protected] (Ned W Schultz)
Organization: Cal Poly State University -- San Luis Obispo
Lines: 25
 
 
 
If you have seen WorldDataBank from Fish Disk 262 you are probably interested
in the higher magnification files, wdb.2.all and wdb.1.all.  Here is how I
obtained them.  I *think* you could get them the same way, but I can' t say
for sure.
 
I sent 2 disks along with a return mailer *and* the appropriate postage to:
 
Bob Dufford/A.U.O.H.
Box 1432 DTS
Omaha, NE  68101-1432
 
The files come lharc'd.  You must have a hard disk to use them, as they are
1068408 and 524088 bytes respectively.
 
The increased resolution is quite interesting.  I think I spoteted my 
house (I live on the coast!).  No inland details, other than borders.
And no Golden Gate Bridge...
 
If you are affiliated with a users group you might mention that and send
a copy of your newsletter.  They sent me one of theirs and it is very
nice.  
 
Ned Schultz    [email protected]
    

    I have been unable to get the WDB program to display on my 2000. It is
    a new one with 1 Meg (Chip) RAM. Do I need more memory to display these
    maps? I saw nothing in the docs about more than 1 meg.
    
    Boy do I want more memory...

I followed the instructions in .2, and the floppies came back this Saturday
(took about a month). This included not only wdb.[12].all, but the other
data bases (wdb.[345].all), a binary, and source to the program.

Since the source & two large databases are >90% of the entire thing, I
put it all together as wdb.arc. Arc so those who are wish can de-arc it before
downloading it.

For now, you ought to be able to copy it from DECWSE::/usr/tmp/wdb.arc. If
someone can provide the name of a "correct" place - or better yet, a listing
(or pointer thereto) of the Amiga archives on EASYNET - I'll copy it over
later today. Send pointers by mail for quickest response.

	<mike

    Mike,
    
    You should be able to copy the wdb.arc to TAPE::USER2:[upload]wdb.arc
    
    regards
    kevin

It's also on WJG::AMIGA: now.

in TAPE::USER2:[upload]wdb.arc

	<mike

    I have just copied over wdb.arc (from both wjg and tape). I have tried
    VMS  arc and VMSsweep on both copies but keep getting corrupt file
    headers. (My Ami is on holiday and I want to know that what I can
    extract from the archive before I copy it down)
    
    Anybody else managed to extract on the VAX?? Is it ok on the Ami??
    
    Thanks and regards
    Kevin

look for notes on cvtarc - better yet,

copy wjg::amiga:cvtarc.exe

to your system and make a foreign command:

$ cvtarc :== $disk:[directory]cvtarc

(replace disk and [directory] with where you put cvtarc.exe and leave in the
 leading '$')

then:

$ cvtarc v wdb.arc

john

    I have tried cvtarc with both the u and the v qualifiers and nogo
    either way. With the v qual I get bad headers and with the u qual I
    get a "cannot create file" (message 000002).
    
    I'm stonkered either way.
    
    anymore ideas? Can someone put please it in a .zoo or .lzh file??
    
    regards
    kevin

Re: last few

It's all very simple _why_ VMS ARC chokes on that archive:

The files in question all contain more than one dot...

like wdb.1.all.

Since Mike lives in U*x land, where (like the Amiga) such is perfectly legal,
the archive will unpack quite nicely on his machine. Unfortunately the size
of this archive prevents downloading it to a floppy, so a ZOO or LHARC archive
would be very appreciated...

Regards,

<CB>

What version of ARC are you using?

The WDB.ARC and ARC.EXE on WJG::AMIGA: seem to work together just fine.

john

I downloaded the file to my Amiga (1'50'' at 2400 & JRcomm) and un-arc'd it.

It is pretty nice, overall, but I wish there was a major cities database
for it. I am sure they would not be difficult to include in the drawn pictures.

I got the source to compile last night and am fairly sure the code included
could not be the same as used for the executable. For instance, the color
map  table was declared as an array, but was passed to LoadRGB with a 
preceeding "&". LoadRGB expect the address of a vector of color values.
As supplied the code gave one too many levels of indirection!

There were other things the Manx 5.0a compiler picked up. These were 
type mis-declarations or a routine that was called with one too many 
arguments (don't recall the name). All relatively harmless.

	Thanks,
		-SES

> I got the source to compile last night and am fairly sure the code included
> could not be the same as used for the executable. For instance, the color
> map  table was declared as an array, but was passed to LoadRGB with a 
> preceeding "&". LoadRGB expect the address of a vector of color values.
> As supplied the code gave one too many levels of indirection!


SHORT CTable[] = {,,,};		/* real values in here */


(with VAX C)  CTable and &CTable are one in the same. In fact you'll get
a warning that '&' was ignored.

Not sure what Lattice will do...

john

RE:.14

>  SHORT CTable[] = {,,,};		/* real values in here */
>
>  (with VAX C)  CTable and &CTable are one in the same. In fact you'll get
>  a warning that '&' was ignored.

Sheesh! C is such a crock language {imho}.

	Thanks
		-SES

I wonder what ANSI C says about address of an array name?

Randy?

john

re .11

Actually, the files in wdb.arc never were on Unix land. They went from floppies
in the mail to my hard disk to the arc on same to the arc on Unix. I confess
to not considering that VMS users would have trouble extracting them when I
built the arc file instead of an lzh file. On the other hand, you can't use the
large databases unless you've got a hard disk anyway, so...

re .ANSI questions...

ANSI says that &Array and Array are the same thing. Array is a pointer to
a chunk of memory, except that the pointer doesn't really exist. Hence
&Array is logically an invalid construct. Some pre-ANSI compilers enforce
that, but not all of them do. Since &Array is unambiguous and makes the
logic of & slightly more consistent, it was left in. Doing it that way
also broke zero C programs, whereas doing it the other way would break
some.

For a real nasty, the pre-v7 C compilers automatically turned
	struct x y ; func(y) ;
into
	struct x y ; func(&y) ;

since you couldn't pass a structure by value. Worked much like functions
do today.

	<mike

Re: &array

Taking the address of an array has had three different interpretations
over time:

In K&R, &array was illegal.  The rationale was that & could not be used
to take the address of a constant, and an array name was a constant
representing the address of the first element of the array.

When pcc (the "portable C compiler," which is the C compiler supplied
with most UNIX systems in the world) came along, &array was allowed.
What pcc did was just ignore the attempt to use &.  Thus, "&array"
was the same as "array" was the same as "&array[0]"; namely, all
three expressions were the address of the first element of the
array.  The value, and the type, was the same for all three
expressions.  In particular, for "int array[10];", the type of
&array was pointer to int.  (VAX C implemented the extension in
order to be pcc-compatible.)

ANSI C noticed that the pcc's extension to K&R was not very natural.
When you take the address of something, you expect the type to be
pointer to the type of that something.  For example, the more consistent
interpretation of "int a[10]; &a;" would be for the type of &a to
be "pointer to array of 10 ints" and not "pointer to int." 

ANSI decided to go with the more consistent interpretation.  The new
ANSI interpretation didn't have much of an effect on programs that
used the old pcc interpretation.  The value of &array stays the same:
the address of an entire array is equal to the address of the first
element of the array.  The interpretations only differed on the type
of the result (pointer to the array versus pointer to the type of the
element of the array).  In most contexts, the type of &array would
only cause a warning to be issued by the compiler.  The two common
cases being:

	extern int f(int *);
	int *p, a[10];

	p = &a;		/* warning: ptr to array assigned to ptr to int */
	p = a;		/* ok */
	f(&a);		/* warning: ptr to array passed to ptr to int */
	f(a);		/* ok */

I both cases, the program would work if you ignore the warnings.

The only time the different types matter is when pointer arithmetic
is done.  Remember, when you add or subtract an integer and a pointer,
the integer is scaled by the size of the object being pointed to:

	short *ps;	/* pointer to short */

	ps = ps + 1;

The compiler automatically multiplies the 1 in the above expression
by sizeof (short).  Assuming that sizeof (short) is 2, then this means
that 2 is added to the value of ps, because the next short is two bytes
away from the current one.

	short (*pa)[10];  /* pointer to an array of 10 shorts */

	pa = pa + 1;

Here the object being pointed to by pa is an array of ten shorts.
Thus, the 1 is multiplied sizeof (short [10]), which is the value 20.
We want to add twenty because the next array is twenty bytes following
the current one.

So, ANSI's new interpretation can cause a radical change in a
program that does something like this:

	short *ps, a[10];

	ps = &a + 1;

Under pcc, 2 gets added to &a.  Under ANSI C, 20 gets added.  However,
ANSI (wisely) decided this was no problem because:

	1.  Not many programs embed &array in a pointer arithmetic
	    expression.

	2.  In most cases (like the above example), the compiler would
	    issue a warning that the expression had the wrong type.

I think ANSI's treatment of &array is cleaner and more consistent than
pcc's.  I have seen programs that used very complicated data structures
like pointer to array, and they depended on ANSI treatment of &array.

    thanks <cb> - i never thort to look at the validity of the file names
    from a vms standpoint!!! (mutter  mutter     mutter....) 
    
    Ed, arc.exe is v1.0 - same as the one on wjg. 
    
    Will get it onto the ami and have a look at it real soon.
    
    regards and thanks 
    	kevin
    

    I have a 1Meg 2000 (all chip memory) and the WDB program doesn't run. I
    looked at the C source and it looks like the program specifically
    requests FAST ram for its buffers. HAs anyone modified it to run on an
    all CHIP RAM system? It's supposed to work on 1 Meg systems according
    to the docs. Must have been thinking of a 1Meg 500 when they were
    written.
    
    I don't own a compiler so if anyone has could you copy the new
    executable to the archives on TAPE. Thanks.
    
    John

    
    
    
    	Thanks for the Upload....
    
    
    		- Pete -
    
    

re .17

>On the other hand, you can't use the
>large databases unless you've got a hard disk anyway, so...

Oh, I got plenty of HD space... at home.
In the office it's just a meager 1MB A500 with one floppy, so the problem is 
getting the archive on one of those 3.5" thingies. ;-)

<CB>

    re .22
    
    me too.
    
    I need a more compressed version on a 770K-floppy. 
    (VAX->PCSA->PC->Dos2Dos->AMIGA)
    But wdb.1.all is too large.
    
    Are there .lzh or .zoo versions ???
    
    thanks
    gerald

I tried to recompile it with the "requesting FAST RAM" feature fixed, but it
seems there is a missing include file (functions.h).

Is this a Manx thing?

john

    re .24
    Yes, <functions.h> is MANX only.
    This files defines system functions to long etc.
    
    If You are a Lattice user -> delete this line.
    

    Am I missing something here? I loaded these "maps" up, and basically
    they are just outlines of states and countries sans any detail.
    Ever do a 40x magnification on the State of Maine ... blank screen,
    no rivers, lakes, towns, etc. Perhaps I am missing some key files?
    Otherwise these maps appear to have little value. 

re .-1

I got the same impression. Not much detail.

john

    re. .26
    
    Most people from 'away' usually think that Maine is off the edge of the
    world anyway.  That might explain the lack of any map details ;').
    
                               Bob

Re: .25

>    Yes, <functions.h> is MANX only.
>    If You are a Lattice user -> delete this line.

I don't remember off the top of my head, but I think Lattice may
have a similar header file.  It think it is <proto/all.h>.
It causes prototypes to be included for all Amiga system functions.
Look at the files in include:proto and see if something appears
to be there.