🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Thread View: net.micro.amiga
3 messages
3 total messages Started by Mike (Don't have strength to lea... Fri, 31 Oct 1986 07:11
uuencoded files....
#5200
Author: Mike (Don't have strength to lea...
Date: Fri, 31 Oct 1986 07:11
15 lines
1118 bytes
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
	mwm@berkeley.edu, ucbvax!mwm
iffdump.c & iffencode.c - where's _checkbreak ?
#5261
Author: Howard Hull
Date: Wed, 05 Nov 1986 00:50
60 lines
4170 bytes
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
Re: uuencoded files....
#5301
Author: Fred Fish
Date: Wed, 05 Nov 1986 04:59
15 lines
1074 bytes
In article <1562@jade.BERKELEY.EDU> mwm@eris.BERKELEY.EDU (Mike (Don't have strength to leave) Meyer) writes:
>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
===========================================================================
Thread Navigation

This is a paginated view of messages in the thread with full content displayed inline.

Messages are displayed in chronological order, with the original post highlighted in green.

Use pagination controls to navigate through all messages in large threads.

Back to All Threads