Re: 8-bit unzip utility

[mdj <mdj.mdj@gmail.com>]

On Jun 20, 5:12 pm, pau...@saaf.se (Paul Schlyter) wrote:
> In article <1182319202.810467.211...@q19g2000prn.googlegroups.com>,
>
> mdj  <mdj....@gmail.com> wrote:
> > On Jun 20, 7:12 am, pau...@saaf.se (Paul Schlyter) wrote:
>
> >> and compile it on any platform of one's choice, provided a suitable C
> >> compiler is available for that platform.  With e.g. Aztec C, one ought
> >> to be able to produce executable files also for the 8-bit Apple II.
>
> > You might have more luck cross-compiling it with cc65, since none of
> > the native 8-bit C compilers are ANSI level, and even then it might be
> > tricky since not even cc65 is a full implementation
>
> I just glanced through the C sources of unzip:
>
> > (no floating point,
>
> No problem - unzip doesn't use floating point.  Did you really believe it did?
>
> > bit fields,
>
> unzip doesn't use bit fields either....
>
> > or passing structs as arguments to functions).
>
> I didn't find any structs passed by value in the unzip C sources either....
>
> unzip does however use "new style" function headers here and there, so these
> headers might have to be rewritten in K&R style.  It'll take maybe 15 minutes
> or so to do that.

A quick attempt to compile it resulted in cc65 not being able to
correctly parse one of the main header files in the source. Probably
easily fixed, perhaps not.

> > Then there's the hassle that there's no command line interpreter on
> > the Apple II,
>
> REALLY?   So you mean I cannot type e.g.
>
>     BRUN UNZIP
>
> on the Apple II ?????   <g>
>
> There is a command line on the Apple II, but it doesn't take arbitrary
> arguments.  Any argument which doesn't follow the prescribed syntax
> are treated as syntax errors - and those arguments which do follow the
> prescribed syntax aren't passed by the program, but are consumed by
> the "shell" (i.e. DOS 3.x or ProDOS).
>
> But something like:
>
>     BRUN MYPROGRAM,S5,D2,A$5000
>
> *is* a command line, and it's interpreted by DOS 3.x.  Or do you think
> it's a GUI?  <evil grin>

I'm sorry, I had assumed the readers of c.s.a2 would understand my
meaning, which was that the standard interpreter extension to BASIC
does not support a DOS/CPM/Unix style environment, and thus the tool
would either have to provide its own, or be compatible with one of the
many 'shell' environments available for ProDOS 8. Unfortunately for
user of !x, it's likely to be compatible with x :-)

Clearly BRUN UNZIP ZIPFILE.ZIP will issue a syntax error under ProDOS
or DOS 3.3. I assumed everyone here knew what I meant. Obviously I was
mistaken ;-P

> Apple DOS 3.x contains three parts:
>
> 1. The command-line interpreter
> 2. The File Manager
> 3. RWTS
>
> > so you'd need to construct some sort of wrapper program
> > that handled argument passing, etc.
>
> That ought to be included in cc65 already -- how else can the runtime
> library of cc65 manage to fill the argv[] array with proper contents?
> Quite naturally, unzip uses argc/argv to fetch its input arguments.
>
> (I'm here making the optimistic assumption that cc65 will produce
> executable binaries for the Apple II, but maybe that assumption is false).

I assume it treats the declaration as int main(void) on the Apple II,
which is perfectly acceptable under the C standard(s). I'm sure it
could be modified *easily* to supply such parameters should the
environment actually support it.

> > More luck may be had with the WDC's 65xx toolchain, which is
> > supposedly an ANSI C implementation, but it more than likely produces
> > 65C02 code, and quite possibly uses the Rockwell/WDC extensions as
> > well.
>
> That should be runnable on the IIe, which also is an 8-bit computer.

IIe's and IIc's generally shipped with NCR 65C02's, which won't
support the BBR/BBS instructions, and those should be considered
vetoed on the Apple II.

> Also: if WDC's 65xx toolchain is any good, it ought to have some
> compiler switch which makes it generate working code also for the
> original 6502.  But maybe WDC's 65xx toolchain isn't any good?

Dunno. I'd not be surprised if it was designed specifically for CMOS
generation 6502s, considering how much simpler the 'C02 instructions
and addressing modes make the compiler writers life, and considering
it's offered as a toolchain to support current generation WDC
products.

Of course, this doesn't address the fact that you'll need further code
to translate files that most likely contain ASCII text into TXT files
on the Apple II. Since there is already available tools to do this
job, the "port Unzip" option is a pretty poor one.

Matt