uuencoded files....
Mike (Don't have strength to leave) Meyer
I finally broke down and tried to download some of the uuencoded
things that have been posted recently. They don't want to run.
Download path is either via kermit and the Wecker VT100, or tar/xmodem
(VT100 again)/tarsplit. In either case, the object on the Amiga is
one byte smaller than the file on the Unix end. The complaint from
AmigaDOS is "file is not an ojbect module". Fixobj doesn't find
anything wrong with it.
So what am I missing?
Thanx,
<mike
m...@berkeley.edu, ucbvax!mwm
Howard Hull
I just got through trying to compile iffdump.c and iffencode.c
using Lattice C 3.03 and got a couple of undefined link tags for
my trouble :-) I can't find checkbreak() or resetbreak() anywhere
in lib/include/ and they evidently are not in my.lib, amiga.lib or
lc.lib, either. There is a reference to them in Shell 2.01 "help".
Are these things in Lattice 3.04 (Arrrgh?).
I also checked both 3.20a Manx disks, but since my.lib (which has always
before been referenced by Matt with respect to the Lattice compiler) was
mentioned, I didn't think it would be in the Manx stuff.
I did get the iffencode.uue and iffdump.uue decoded and downloaded with
Kermit using Wecker's Wonder VT100 (Thanks, Dave - VT100 is the best little
piece of software in *or* out of Texas!). However, I was curious about the
missing routines. Another (probably related) difficulty is that the
sources distributed on the the net for my.lib seem to compile to a
different byte count than the uudecoded my.lib included in the package.
The compiled library is 11680 bytes, whereas the decoded library is
12052 bytes. I have done the compile twice (all day job, guys), and
finally even made a somewhat awkward monster lmk makefile to assure
that I didn't leave something out, and to assure that the process
would be not only repeatable, but subsequently easier.
Shell V2.01, when compiled with the shorter library, just hangs with the
disk drive light on when I try to do a cat of a text file. It works
ok with the longer library. Curiously enough, the working shell is 26864
bytes, whereas the one that hangs is 26860 bytes (both were generated on
the Amiga). So you are wondering, since I have a copy of shell that works,
what am I complaining about? Well, if I want to learn by tinkering with the
code, I can't do so well with the one for which I have the source, since
from the start, it doesn't work.
Annnyway, as an additional matter, if someone would be kind enough, I'd
appreciate an e-mail copy of the Thomas Spencer et. al. btoa.c SOURCE from
the compress directory on Fred Fish #6. Only one of the machines I work with
here has Kermit, and Xmodem pads downloaded binaries so that they can't
be recognized by the Amiga loader. I don't have fixobj from Fish Disk #10
with which to clean up the ends. According to Mike (I'll be mellow when
I'm dead && Don't have the strength to leave) Meyer, it may not work anyway.
He states that his binary downloads have a difference of only 1 byte by count
from the decoded ones, yet they won't load. They don't seem to respond after
treatment by fixobj, either. If he hadn't gotten this problem consistently
through both Xmodem and Kermit, I would have sworn that the transfer program
was dropping an entire block out of the start or the middle, then padding
the end with the dreaded dinosaur CP/M CR/LF+7E^Z's.
With btoa.c, I could compile on the Integrated Solutions machine
and download the binaries from any machine on which I might generate them.
(I already have the Amiga executables for atob and btoa that a friend got
for me from Fish Disk #6, and I got the atob.c source from the Usenet
distribution of Toebes' Hack. Too bad he didn't throw in btoa.c, too,
but probably excluded it because it wasn't necessary and might have confused
someone).
Thanks in advance for any help...
Howard Hull
[If yet unproven concepts are outlawed in the range of discussion...
...Then only the deranged will discuss yet unproven concepts]
{ucbvax!hplabs | decvax!noao | mcvax!seismo | ihnp4!seismo} !hao!hull
Fred Fish
>one byte smaller than the file on the Unix end. The complaint from
>
>So what am I missing?
How about one byte? :-) :-) :-)
--
===========================================================================
Fred Fish Motorola Computer Division, 3013 S 52nd St, Tempe, Az 85282 USA
{mcdsun,well}!fnf (602) 438-5976
===========================================================================
Howard Hull
Today I came across the missing binary libraries for checkbreak and
resetbreak; they were in a very recent net article:
Message-ID: <861107082...@cory.Berkeley.EDU>
Date: 7 Nov 86 08:26:56 GMT
a uuencoded update for my.lib by Matt Dillon. Thanks, Matt - I'm having
tons of fun with all the interesting stuff you've been putting on the net
for some time now...
For anyone else who may have responded to my questions, thanks to you as
well. (I haven't gotten anything yet, but the Dillon update helps quite
a bit.) Of course, I still don't have btoa.c, and I have no idea what the
code for checkbreak and resetbreak look like, but shucks; - people in hell
want ice water. I was able to compile the IFF dump and encode programs
with the new my.lib using Lattice 3.03, however I would like to report
that the sizes of the executables I got were consistently larger. I know
about the -s and -v flags for LC2, and I even snapped all the intermediate
files to Ram: like a good boy would have done. So the difference must be
that Matt is using v1.2 and/or a slightly later version of Lattice C than
I am using. For general information, here is what I have so far:
my.lib (compiled w/lc3.03 and is missing something(s)) 11670
my.lib (from .uu) Ref below to this is "a" 12032
my.lib (new .uu) Ref below to this is "b" 12676
iffencode (from .uu) 9776
iffdump (from .uu) 8508
iffencode (compiled w/lc3.03, my.lib b) 10376
iffdump (compiled w/lc3.03), my.lib b) 8752
setfont (from .uu) 4900
setfont (compiled w/lc3.03, my.lib a) 4940
setfont (compiled w/lc3.03, my.lib b) see note 5492
shell 2.01 (compiled w/lc3.03, my.lib a) 26864
shell 2.03 (from .uu) 31092
note: This is the latest version of setfont, the "too powerful" version :-)
Also, note that there is a reference in the file "dotty" to a font
"2", though it is not included in the uuencoded fonts ("1", also
referenced in "dotty" is included.)
I have not as yet ascertained that all the above mentioned executables,
compiled or otherwise, are without bugs; but they do all load without
summoning the Guru.
Typical compilation I used is of the form:
LC1 -i:include/ -oRam:filename.q filename
LC2 -s -v -oRam:filename.o Ram:filename
Alink FROM :lib/AStartup.obj+filename.o LIB :lib/my.lib+:lib/amiga.lib+:lib/lc.lib TO a.out
Delete Ram:filename.o
Some who are wiser (and evidently less patient) than I have advised that it
is better (especially when working your own code) to have something in
s/Startup-Sequence that loads all of the libraries (and the includes as well,
if you have more than 512K) into Ram: and uses commands like the ones above,
except with SYS: assigned to Ram: where the object of the game is to hope
that only one disk file (for reading or writing, as appropriate) is open for
any given command line.