Aztec C SHELLS - Unix-Like Environment for DOS 3.3 and ProDOS 8
Bill Buckels
following links:
Diskimages and text-docs only (very small)
http://www.aztecmuseum.ca/AppleShellDisks.zip
Diskimages and text-docs and fairly large 41 page scanned manual
http://www.aztecmuseum.ca/AppleShell.zip
Note: You do not need Aztec C to use these. And when you download these also
included is a DOS 3.3 stripped-down version of Aztec C for compiling TINY
Aztec C programs that run the DOS 3.3 SHELL.
Please see the ReadMe below and the Docs in the ZIP file for additional
details. The SHELL commands for the ProDOS version are also described at the
following link:
http://www.aztecmuseum.ca/cat2.htm
See the Shell Commands sections.
This was not a solo effort by any means. Phoenyx and Rubywand and Paul R.
Santa-Maria provided most of the pieces of this perfectly enjoyable puzzle.
If you have not yet experienced just how well-done James Goodnow's efforts
in making the Apple II into a unix-like environment were back-in the day,
you really must play with this surprisingly functional little disk set. Even
if you are not a programmer.
ReadMe.txt for
AppleShell.zip
By Bill Buckels Aug 2008
This ZIP file contains diskimages and documentation for 2 versions of the
Aztec C SHELL for the Apple II; a ProDOS 8 Version and a DOS 3.3 version.
Some additional utilities are included with both versions and an Aztec C
native mode compiler environment is included on the diskimages for the DOS
3.3 version.
I am not going into exhaustive detail about the use of the SHELL. For the
DOS 3.3 version; see the text file D33Shell.txt and for the ProDOS version
see SHELL65A.PDF also in this ZIP file.
I have written and compiled a couple of filter programs and a "hello world"
program for use with each shell. The source code is identical, however the
executables are targeted at their particular SHELL. The programs targeted at
the DOS 3.3 shell are very tiny. Neither the ProDOS nor the DOS 3.3 sample
programs will run properly outside their intended SHELL since both
environments are SHELL version and OS version specific and all accept commad
line arguments. The filter programs will also accept redirected input and
output and do file input.
These sample programs are compiled to PCODE (pseudo-code) and run somewhat
slower than native code, but with the availbility of emulators and
accelerators that increase execution speed over what was then available,
their performance is passingly acceptable.
The ProDOS samples were compiled in the CG65 cross-development environment,
and the DOS 3.3 samples were compiled on the diskimage provided in this ZIP
file using the native mode compiler also provided on the diskimage in this
ZIP file. To my knowledge, no cross-development environment exists for the
DOS 3.3 Aztec C SHELL.
These diskimages and the other contents of this ZIP file were produced as a
mini-project of sorts to explore the use of both SHELL programs which
provide a decidedly unix-like flavour to the Apple II.
Not only are many of the unix commands supported, but also each SHELL has
its own unique strengths, a couple which I will mention now.
The ProDOS SHELL.SYSTEM uses paths to navigate, and further the SHELL has a
resident and transient portion that is similar to what one would have
expected back in the MS-DOS days of TSR programs. If you don't know about
those, suffice to say that the ProDOS SHELL unloads itself to run external
programs and relaods itself when done (in most cases). Another important
feature of the ProDOS SHELL.SYSTEM is that since it can be copied to the RAM
disk on an Apple //e it will load itself back-in from RAM leaving the 2 disk
drives open for program and data disks.
The DOS 3.3 shell tackles efficient use of the limited resources on an Apple
II by supporting very tiny PCODE programs.
I have configured both SHELL programs to run in 80 column mode.
Please read each's respective documentation for additional details.
And please remember that like unix, these SHELL programs are case- sensitive
and expect lower-case for their internal commands. SHELL scipting is also
supported in both and a surpring myriad of additional features considering
the relative size of these and the small memory footprint of the Apple II.
End of Document
Bill Buckels
SHELL programs. As you will see when you download and try these, the
redirection works as expected.
These were adapted from my Commandline Commando Windows Utilities which were
written-up in ITPRO in their "Real-World Scripting" article back in 2001:
http://windowsitpro.com/article/articleid/21277/real-world-scripting-scripting-tools-on-the-web.html
and that package is here:
ftp://ftp.arnes.si/software/simtelnet/win95/txtutl/clcom10.zip
Anyway, the porting of these would not necessarily be considered
interoperability, because of the K&R syntax on these, but that's minor in
the overall grand scheme of not reinventing well-oiled working wheels...
x--- snip ---x
/* -------------------------------------------------------------------
System : ProDOS 8 or DOS 3.3
Environment : Aztec C Shell
Program : lcase.c
Description : Uppercase to Lowercase filter.
This program is a filter that translates all uppercase
characters to lowercase. It will optionally accept a
filename to read input from. All output goes to the
standard output device unless redirected.
Examples:
Lcase abc.txt
read input from abc.txt,
output goes to screen.
Lcase abc.txt >abcnew.txt
read input from abc.txt,
output goes to abcnew.txt.
Lcase <abc.txt >abcnew.txt
same as previous example
Written by : Bill Buckels
Based On : lower.asm
used with permission
Date Written : Aug 2008
Revision : 3.0 Third Release
------------------------------------------------------------------ */
#include <stdio.h>
main(argc, argv)
int argc;
char **argv;
{
int c;
FILE *fp = NULL;
if (argc > 1)
fp = fopen(argv[1], "r");
for (;;) {
if (NULL == fp)
c = getchar();
else
c = fgetc(fp);
if (c==EOF)break;
if(c>64 && c<91)c+=32;
putchar(c);
}
if (NULL != fp) {
fclose(fp);
exit(0);
}
}
x--- snip ---x
/* -------------------------------------------------------------------
System : ProDOS 8 or DOS 3.3
Environment : Aztec C Shell
Program : ucase.c
Description : Lowercase to Uppercase filter.
This program is a filter that translates all lowercase
characters to uppercase. It will optionally accept a
filename to read input from. All output goes to the
standard output device unless redirected.
Examples:
Ucase abc.txt
read input from abc.txt,
output goes to screen.
Ucase abc.txt >abcnew.txt
read input from abc.txt,
output goes to abcnew.txt.
Ucase <abc.txt >abcnew.txt
same as previous example
Written by : Bill Buckels
Based On : upper.asm
used with permission
Date Written : Aug 2008
Revision : 3.0 Third Release
------------------------------------------------------------------ */
#include <stdio.h>
main(argc, argv)
int argc;
char **argv;
{
int c;
FILE *fp = NULL;
if (argc > 1)
fp = fopen(argv[1], "r");
for (;;) {
if (NULL == fp)
c = getchar();
else
c = fgetc(fp);
if (c==EOF)break;
if(c>96 && c<123)c-=32;
putchar(c);
}
if (NULL != fp) {
fclose(fp);
exit(0);
}
}
Bill Buckels
news:Y4Qqk.346$Rs1...@newsfe08.iad...
>Neither the ProDOS nor the DOS 3.3 sample programs will run properly
>outside their intended SHELL since both environments are SHELL version and
>OS version specific and all accept commad line arguments.
I should note that DOS 3.3 programs compiled using the CG65 cross-compiler
and the DOS interpreted library (DI) run fine in the DOS 3.3 shell except
that they don't accept args in the same manner, which to me is not
acceptable, and they are bulky like their ProDOS counterparts although
smaller than native code The native mode compiler that I included is the
best bet and makes really tiny programs.
>To my knowledge, no cross-development environment exists for the DOS 3.3
>Aztec C SHELL.
See above. I probably should have been clearer and said that the existing
cross-development environments that I have aren't recognized as interpreted
SHELL programs under DOS 3.3 in the same way that the native mode programs
are. However, I have a real Apple //e and may have an Aztec C DOS 3.3 disk
kicking-around that may eventually make a liar out of me:)
I should also note that for those who don't read manuals:) these SHELLS run
compiled Aztec C PCODE or INTerpreted C programs respectively in ProDOS 8 or
DOS 3.3 but also run BIN and in the case of ProDOS, SYS programs. On the
ProDOS side the SHELL's environment pages can be overwritten by another
Aztec C program and lots is written in the Manual about all this.
One of the strongest features is the support for different standard hardware
of the day as well.
Anyways, I have gone on-and-on but really had a good time with this. I hope
you'll enjoy it as well.
Have Fun,
Bill
mdj
> The Aztec C Shells for DOS 3.3 and ProDOS are now up for download from the
> following links:
She sells C Shells ...
Oh, right, that was yesterday. Sorry :-)
Bill Buckels
"mdj" <mdj...@gmail.com> wrote in message
news:ab482032-aa72-475c...@w24g2000prd.googlegroups.com...
>She sells C Shells ...
>Oh, right, that was yesterday. Sorry :-)
C shills you say<g>
I am not sure about the gender implications... but more fundamentally (or
irreverrenly or atheistically as your preference may be:) yesterday WAS a
long time ago if you consider 1983 as yesterday but then so was the Apple II
yesterday... Hmmm! O well, like McCartney I believe in yesterday.
Perhaps I will next write a version of AppleSoft BASIC that runs in GWBASIC
under Ubuntu in DOSEmu... but I think not! Not today anyway.
For I have promises to keep, and lines to code before I sleep.
Bill
A2Pro
The "ReadMe.txt" file in the archive "AppleShellDisks.zip" states
that the archive contains a file named "SHELL65A.PDF". It does not.
Willi
Bill Buckels
news:40dbc97a-e68f-47a3...@k7g2000hsd.googlegroups.com...
>The "ReadMe.txt" file in the archive "AppleShellDisks.zip" states that the
>archive contains a file named "SHELL65A.PDF". It does not.
Hi Willi,
The release notes are as follows (previously posted):
The Aztec C Shells for DOS 3.3 and ProDOS are now up for download from the
following links:
Diskimages and text-docs only (very small)
http://www.aztecmuseum.ca/AppleShellDisks.zip
Diskimages and text-docs and fairly large 41 page scanned manual
http://www.aztecmuseum.ca/AppleShell.zip
The rationale here is that given a choice between downloading 274K and 4.39
MB for the same zip file including the scanned pdf manual I considered that
I would also make a light version. However, I intend to add to this
collection and categorically refuse to maintain 2 ReadMe's for a WIP (Work
In Progress).
Was there something you liked about this or are you just being helpful?:)
The alternative of course is to remove the small file and leave the ReadMe
as is in the large file (just kidding), but since the links were offered
with the release notes above and haven't been posted without them, I think
you might be pulling my leg and letting me know that someone is actually
spotting my deliberate error.
Anyway, I have a number of filters to complete before I call it day on this
one, and one in particular is a variation of Soundex and Metaphone which was
born in the International C Echo from Fido in one of its latest incarnations
back at the turn of the Millenia, with help from the late Charles Angelich
(Ghost in the Machine).
When you see this addition completed, you will forgive me for making the zip
you downloaded too small. Either that or you can jump right in and help me
expand the documentation on this. I would really like to split the shell
commands for ProDOS from Phoenyx's Phade Software manpages into a standalone
shell command reference and also reformat these so they don't need to be
magnified in a browser to be read by old eyes. A Pdf version might be nice
but HTML is still the smallest method of dealing with a manual outside of
plain text or manpages.
Did you try the native mode compiler for the shell? I put a shell script in
place that takes command line arguments and will build the filters and the
example programs.
Another cool thing that I want to do with the native mode ProDOS compiler
which I didn't bother with this go-around is to make a distribution that
loads the essential tools into the RAM disk for building SHELL programs.
My use of the CG65 compiler from here (the gmail version) was to see what
its differences are from the version that I based AppleX on. I have yet to
try this with a C64 but it has some intructions on how to modify zero page
settings for that platform as well. For ROMable code I doubt if I will do
much but someone building a 6502 based device-thingy of some kind might want
to give this a whirl for a ROM based controller.
When I talked to Harry Suckow about a big japanese company who shall for the
time being go nameless, they redistributed the ROM compiler with their
embedded systems to countless developers after only purchasing 2 licences.
Harry didn't have the ways and means to stop the Kamikaze Kompilers. I
suspect this might be the same compiler and I will be asking Harry the next
time we talk.
Anyway, again thanks for taking the time to actually read the docs.
Going now,
Bill
magnusfalkirk
> "A2Pro" <a...@wilserv.com> wrote in message
>
> news:40dbc97a-e68f-47a3...@k7g2000hsd.googlegroups.com...
>
> >The "ReadMe.txt" file in the archive "AppleShellDisks.zip" states that the
> >archive contains a file named "SHELL65A.PDF". It does not.
>
> Hi Willi,
>
> The release notes are as follows (previously posted):
>
> Bill
Bill, what Willi said, and you ignored, is that the README.TXT for the
AppleShellDisks.zip file says there is supposed to be a PDF file
called Shell65A.PDF in the Zip file and it isn't there. I can verify
that what he says id true because I downloaded and unzipped that file
and there is NO PDF file in there. In the AztecShell.zip there is a
PDF named SHELLC65A.PDF but I'd imagine these aren't the same files.
Dean
Bill Buckels
news:9c5ceda5-e312-4c81...@l42g2000hsc.googlegroups.com...
On Aug 22, 9:01 pm, "Bill Buckels" <bbuck...@mts.net> wrote:
>Bill, what Willi said, and you ignored, is that the README.TXT for the
>AppleShellDisks.zip file says there is supposed to be a PDF file
>called Shell65A.PDF in the Zip file and it isn't there.
First off, thanks for reporting the spelling mistake. Probably best done by
private mail in the future or use the following link:
http://www.teacherschoice.ca/bugs/index.htm
Now that we've had some fun:) The first 2 lines in the ReadMe.txt in the
AppleShellDisks.zip are::
>ReadMe.txt for
>AppleShell.zip
As you can see (on line 2) the file is for the larger zip. I have removed
this file from the AppleShellDisks.zip and put the updated zip file on the
Aztec C website which now joins so many other zip files on the Internet that
have no documentation, for the time being at least.
I am sorry that you think I ignored Willi. Try reading my reply to him again
after I give you some background and I hope you'll realize that it is a
serious reply for the most part and not a flame. Willi is 10 years older
than I am and I respect him on that point alone because I am getting close
to 60 and sometimes wonder why nobody has shot me dead yet:)
It might have been better in retrospect if Willi and I both sent our last 2
posts to private mail as well as we have done in the past.
I just checked my inbox and I have 7 private emails from Willi who by the
way is "...an advocate for ProDOS shells. The KIX shell, specifically. Only
way to go..." and says of the Aztec C site "OUTSTANDING! AMAZING!! If I
ever get off my duff and get my site populated I'll model it after yours." I
also have 6 replies back to Willi but after my last absense from this group
for our last commercial fishing season I never got back in touch and for
that I am to blame.
I probably should have included a port of CFX in both DOS3.3 and ProDOS
format for the Aztec C Shell but I am still secretly hoping he will do that
for me and send me the source with his modifications.
The reference in my post to Willi about the C64 is an acknowledgement of
sorts that he is a cbm guy (Amiga) as well as a ProDOS and Mac guy, and I
still have some of his work that I was going to put up on the Aztec C site
when I got a case of round tuits. He has also provided me with help for
another Amiga guy for which we are all truly thankful:)
> I can verify that what he says id true
No need. I would never question the honesty of anyone in here. Not even me:)
>In the AztecShell.zip there is a PDF named SHELLC65A.PDF but I'd imagine
>these aren't the same files.
Hey Dean, as I said before thanks for reporting the spelling mistake. The
ReadMe says "...see SHELL65A.PDF also in this ZIP file." and should have
said "SHELLC65A.PDF".
Now while we are on it, this PDF was a HUGE disappointment to me and I mean
HUGE which is what caused me to make a smaller zip and in turn this
kafuffle. The entire PDF of the Aztec C manual that this is from is almost
the same size as the one I created. I used VeryPDF to convert the shell
chapter to MSWORD and then OPENOFFICEORG to convert it back again. I don't
have Acrobat so can't manipulate these directly. My first thought was to not
bother including it but then came-up with the dumb idea of making 2 zip
files. Perhaps it would have been best just to put the whole manual up on
the Aztec C Website in a separate zip and perhaps that is the route I SHELL
take.
See I didn't ignore you either:)
Bill
magnusfalkirk
> Now while we are on it, this PDF was a HUGE disappointment to me and I mean
> HUGE which is what caused me to make a smaller zip and in turn this
> kafuffle. The entire PDF of the Aztec C manual that this is from is almost
> the same size as the one I created. I used VeryPDF to convert the shell
> chapter to MSWORD and then OPENOFFICEORG to convert it back again. I don't
> have Acrobat so can't manipulate these directly. My first thought was to not
> bother including it but then came-up with the dumb idea of making 2 zip
> files. Perhaps it would have been best just to put the whole manual up on
> the Aztec C Website in a separate zip and perhaps that is the route I SHELL
> take.
>
> See I didn't ignore you either:)
>
> Bill
Bill,
I didn't take your reply to Willi as a flame, from what you wrote at
the start of it it looked, to me at least, like you were simply
repeating your previous post rather than answering his comment. If
you'd like help with creating PDF's I have a copy of Adobe Acrobat on
my Mac and would be willing to see what I could do for you, all you'd
need to do is send me the file in a form I can access i.e. Word or a
PDF you'd like me to try and downsize, if possible.
Dean
Bill Buckels
>I didn't take your reply to Willi as a flame, from what you wrote at
the start of it it looked, to me at least, like you were simply
repeating your previous post rather than answering his comment.
Well, I had a long day yesterday so the coffee hadn't quite kicked in:) And
I was a little wordy even for me so I wasn't sure but hoped not. I didn't
spot the spelling error until you made me take another look.
>If you'd like help with creating PDF's I have a copy of Adobe Acrobat on my
>Mac and would be willing to see what I could do for you, all you'd need to
>do is send me the file in a form I can access i.e. Word or a PDF you'd like
>me to try and downsize, if possible.
Thanks Dean. I would like that very much, but the file is pretty large... if
that's ok I will place it on the website a little later. My wife's
grandfather is 107 years old tomorrow and we are just heading for the
Birthday Party right now. This man is lucid and much nicer than I:)
Anyway I would like just the shell chapter chunked-out but was unable to do
this in a reasonable way because of the inefficiency of my converter. My
hopes are that this chapter will remain tiny if Acrobat is used.
Bill
Michael J. Mahon
> "A2Pro" <a...@wilserv.com> wrote in message
> news:40dbc97a-e68f-47a3...@k7g2000hsd.googlegroups.com...
>
>> The "ReadMe.txt" file in the archive "AppleShellDisks.zip" states that the
>> archive contains a file named "SHELL65A.PDF". It does not.
>
> Hi Willi,
>
> The release notes are as follows (previously posted):
>
> The Aztec C Shells for DOS 3.3 and ProDOS are now up for download from the
> following links:
>
> Diskimages and text-docs only (very small)
>
> http://www.aztecmuseum.ca/AppleShellDisks.zip
>
> Diskimages and text-docs and fairly large 41 page scanned manual
>
> http://www.aztecmuseum.ca/AppleShell.zip
>
> The rationale here is that given a choice between downloading 274K and 4.39
> MB for the same zip file including the scanned pdf manual I considered that
> I would also make a light version. However, I intend to add to this
> collection and categorically refuse to maintain 2 ReadMe's for a WIP (Work
> In Progress).
I understand exactly what you did and why you did it that way. ;-)
But another alternative that satisfies everyone ;-) is to make the
single README describe both files, by having it note that the large
file contains the .pdf and the small file doesn't.
Then the README is precisely true for each file, contains a pointer
to the "other" file for those who may find just one, and remains
a single file for your convenience. ;-)
-michael
AppleCrate II: An Apple II "blade server"!
Home page: http://members.aol.com/MJMahon/
"The wastebasket is our most important design
tool--and it's seriously underused."
Bill Buckels
news:bfmdndKTBsT8Mi3V...@comcast.com...
>But another alternative that satisfies everyone ;-) is to make the single
>README describe both files, by having it note that the large file contains
>the .pdf and the small file doesn't.
But Michael that is exactly what I started doing this AM before I needed to
pressure wash the doogie off my 800 sq. ft. patio in anticipation of a visit
from our grandson... "You can't please everyone but you've got to please
yourself.... I went to a garden party."
Where do the days go:)
>Then the README is precisely true for each file, contains a pointer to the
>"other" file for those who may find just one, and remains a single file for
>your convenience. ;-)
You are too smart for your own good. And rumour has it you invented the
wastebasket. If Dean can give me a small PDF I would rather use your
wastebasket for both files and redo from start. I already emailed Dean the
link so who knows how lucky I will get.
I'd best get the source for CFX and see if it will compile because I need a
little break from documentation. I spent yesterday writing release docs and
change control forms for an ASP.NET order entry system, and some IT
procedures for setting-up IIS with with a virtual SMTP interface to an
EXCHANGE server and other cr*p like that. It's hammer time:)
Bill
Bill Buckels
provides a qsort both in the shell library and outside of the shell. For
sure a variation of this will work in DOS 3.3 outside of the SHELL but I
will work with this some more to see what I can do about plain redirection
in DOS 3.3 inside the shell.
Not being overly concerned about interoperability, I may not get this
working to the same level as in Unix, Windows, and ProDOS but I am pretty
confident the code you see below will be pretty much doable under DOS 3.3.
You will probably note that blank lines are skipped, and I am using variable
size dynamically allocated memory buffers in the interests of maintaining a
modicum of civilized efficiency, but I have stayed with a limit of a maximum
of 2048 elements for my sort array and a maximum element length of 80
characters and would argue that most text files that one would want to sort
will have smaller elements or fewer lines. I hope so because the potential
here is about 4 times or so more than what an Apple II has, and I wanted to
stay out of auxilliary memory in case the RAM disk is in use which it is in
the ProDOS SHELL. For the occasion where this runs out of memory the test
for mallocation is my sanity check.
Anyway, here's the code. If anyone has written a sort filter in some other C
on the Apple II feel free to critique this. For one thing, I wonder how
quickly your redirection would have compared between a native mode and shell
version using your chosen compiler.
I am working on a bunch of other shell utilities like filters for converting
Apple II text to IBM-PC text etc. but I will definitely bundle all this when
done into a new and much improved version of this happy little zip. In the
meantime this code can be added to your Aztec C FoodChain.
Have Fun!
Bill
x--- snip ---x
/* -------------------------------------------------------------------
System : ProDOS 8
Environment : Aztec C Shell
Program : sort.c
Description : Sort filter.
This program is a sort filter. It optionally accepts
a filename to read input from. All output goes to the
standard output device unless redirected.
Examples:
Sort abc.txt
read input from abc.txt,
output goes to screen.
Sort abc.txt >abcnew.txt
read input from abc.txt,
output goes to abcnew.txt.
Sort <abc.txt >abcnew.txt
same as previous example
Written by : Bill Buckels
Date Written : Aug 2008
Revision : 1.0 First Release
------------------------------------------------------------------ */
#include <stdio.h>
char *malloc();
char *gets();
int cmp();
#define MAXLINE 80
#define FEEDTEST 78
#define MAXLINES 2048
FILE *fp = NULL;
char *lines[MAXLINES];
char buf[MAXLINE+1];
main(argc, argv)
int argc;
char **argv;
{
int idx, c, len=0, numlines = 0;
char *ptr;
if (argc > 1)
fp = fopen(argv[1], "r");
for (;;)
{
if (NULL == fp)
c = getchar();
else
c = fgetc(fp);
/* nobody should be sorting text lines longer than 80 */
/* what would be the point? */
if (c == '\n' || c == '\r' || len > FEEDTEST || c == EOF) {
if (c != EOF && c != '\n' && c!='\r') {
buf[len] = c;
len++;
}
/* terminate the buffer */
if (len != 0) {
buf[len] = 0;
len++;
/* transfer the line into storage */
ptr = malloc (len);
if (NULL == ptr)break;
lines[numlines] = ptr;
strcpy (lines[numlines], buf);
numlines++;
len = 0;
}
if (numlines == MAXLINES || c == EOF) {
break;
}
}
else {
buf[len] = c;
len++;
}
}
if (numlines > 1)
qsort (lines, numlines, 2, cmp);
for (idx=0; idx<numlines; idx++) printf ("%s\n", lines[idx]);
if (numlines == 0)putchar('\n');
if (NULL != fp) {
fclose(fp);
exit(0);
}
}
cmp (a, b)
char **a, **b;
{
return strcmp (*a, *b);
}
Bill Buckels
is the SHELL script that I put on the compiler disk:
x--- snip ---x
set -x -a
loop
# Now Building $%
cci $%.c
ln $%.INT SHINT.LIB
rm $%.INT
loop
x--- snip ---x
This script is called MAKEFILE and it is used to compile any old thing by
using the basename of the C program as an argument. This is what we wrapped
our stuff with back in my AIX days (whatever that is:) not that it came from
there. It is pretty much right out of the Aztec C manual.
Here's part of what I say in the new and as yet unpublished ReadMe for all
this:
Building Shell Programs for DOS 3.3 in the Aztec C Shell
----------------------------------------------------------
There are 3 DOS 3.3 diskimages in this ZIP file:
D33Shell.dsk
D33Compiler.dsk
D33Filters.dsk
To build DOS 3.3 programs that will run in the Aztec C DOS 3.3 Shell, boot
with the D33Shell.dsk in drive 1 then put the D33Filters.dsk in drive 2
and the D33Compiler.dsk in drive 1.
Type "cd d2" to change to drive 2.
Then type "ls" and press [RETURN] to list the directory. A number of C
source files are listed.
Type "MAKEFILE exmpl" and press [RETURN] to build the EXMPL program.
Repeat as necessary.
x--- snip ---x
It took 11 seconds to build EXMPL from exmpl.c in its entirety in the
AppleWin emulator on my Windows box under DOS 3.3.
OP's with overweeningly more capable machines (if they exist) may get faster
results:) Interoperability may actually be an illusion propagated by
promises and propaganda but a pleasant one I suppose...
For the rest of us there is always the tried and true, and you may note that
while the ProDOS Shell uses proper pathing with PREFIXs the DOS 3.3 Shell
just uses d1 and d2 as its PATH. When in Rome?
I prefer the Land of the Sirens:)
Bill
Bill Buckels
DOS 3.3 so maybe it's more.
Remembering that interoperability is somewhat of an illusion I go directly
to the keyboard memory so as not to disrupt the console redirection and
stdio etc.
Like in MS-DOS where getch was born of bioskey or in my C64 Aztec C code, I
keep the getch out of the I/O channel. It does not belong there and is not
part of a tty or anything like that either. It is quite operable except in
unises where it exists not but surely an equivalent like bioskey must. Alas
it has been years since I wrote in curses so I can't remember. And I would
have to look at my Z80 and CP/M 86 stuff to see what exists there. Int 16h
function 0 on Intel I think.
This too will be included in the revised SHELL zip with more goodies.
Have Fun,
Bill
x--- snip ---x
/* -------------------------------------------------------------------
System : ProDOS 8 or DOS 3.3
Environment : Aztec C Shell
Program : more.c
Description : paged or line oriented text file viewer
This program is a filter that displays a text file
either page by page if the spacebar is pressed
or line by line if enter is pressed.
If the [ESCAPE] key or the letter 'Q' is pressed
the program ends.
It will optionally accept a filename to read input
from. All output is to the standard output device
unless redirected.
This does a better job displaying text files like
readme files than the built-in shell command cat,
but is nonetheless primitive.
It is oriented to the 80 column x 24 row display.
Example:
more abc.txt
read input from abc.txt,
output goes to screen.
more <abc.txt
same as previous example
Written by : Bill Buckels
Date Written : Aug 2008
Revision : 1.0 First Release
------------------------------------------------------------------ */
#include <stdio.h>
main(argc, argv)
int argc;
char **argv;
{
int c, d,ctr = 0;
FILE *fp = NULL;
if (argc > 1)
fp = fopen(argv[1], "r");
for (;;) {
if (NULL == fp)
c = getchar();
else
c = fgetc(fp);
if (c==EOF)break;
putchar(c);
if(c == 13 || c==10) {
ctr++;
if (ctr > 22) {
d = getch();
if (d == 27 || d=='q' || d == 'Q')break;
else if (d == 32)ctr = 0;
else if (d == 13)ctr = 22;
}
}
}
if (NULL != fp) {
fclose(fp);
exit(0);
}
}
getch()
{
/* return the last key press */
char *key_press = (char*)0xC000;
/* clear the last key press */
char *key_clear = (char*)0xC010;
char c;
/* clear stragglers from the keyboard buffer */
while((c=key_press[0]) > 127)key_clear[0]=0;
/* read the keyboard buffer */
/* and return the character */
do{
c = key_press[0];
}while(c < 128);
c-=128;
key_clear[0]=0;
return (int )c;
}
Bill Buckels
http://www.aztecmuseum.ca/AppleShell.zip
Thanks to Dean Phares and his mastery in reducing the size of the ProDOS
SHELL documentation there is now only one zip and a new improved ReadMe with
hopefully no errors. This concludes my foray into the SHELLs of the Ancient
Aztecs and I now return to normal programming... leaving you with SORT and
MORE
ReadMe.txt for
AppleShell.zip
By Bill Buckels September 2008
This ZIP file contains diskimages and documentation for 2 versions of
the Aztec C SHELL for the Apple II; a ProDOS 8 Version and a DOS 3.3
version. I have configured both SHELL programs to run in 80 column
mode. One of the strongest features of these is the support for
different standard hardware of the day as well.
These diskimages and the other contents of this ZIP file were produced
as a mini-project of sorts to explore the use of both SHELL programs
which provide a decidedly unix-like flavour to the Apple II.
Not only are many of the unix commands supported, but also each SHELL
has its own unique strengths, some which I will mention now.
The ProDOS SHELL.SYSTEM uses paths to navigate, and further the SHELL
has a resident and transient portion that is similar to what one would
have expected back in the MS-DOS days of TSR programs. If you don't
know about those, suffice to say that the ProDOS SHELL unloads itself
to run external programs and reloads itself when done (in most cases).
Another important feature of the ProDOS SHELL.SYSTEM is that since it
can be copied to the RAM disk on an Apple //e it will load itself back-
in from RAM leaving the 2 disk drives open for program and data disks.
The DOS 3.3 shell tackles efficient use of the limited resources on an
Apple II by supporting very tiny PCODE programs.
Please read each's respective documentation for additional details. I
am not going into exhaustive detail about the use of the SHELL. For the
DOS 3.3 version; see the text file D33Shell.txt and for the ProDOS
version see SHELLC65A.PDF. The sample program source code can also be
reviewed for additional details.
And please remember that like unix, these SHELL programs are case-
sensitive and expect lower-case for their internal commands. SHELL
scripting is also supported in both and a surprising myriad of
additional features considering the relative size of these and the
small memory footprint of the Apple II.
ProDOS Diskimages
-----------------
ProShellA.dsk /SYSTEM:
debwr SYS (2000) 25600 Jun 18 00:00 filer
debwr SYS (2000) 14848 Jun 10 12:37 prodos
debwr TXT (0000) 153 Aug 17 10:19 profile
debwr SYS (2000) 27044 Jun 27 15:42 shell.system
ProShellB.dsk /UTIL:
debwr PRG (0800) 20236 Nov 13 20:15 diff
debwr PRG (0800) 10440 Aug 19 01:18 exmpl
debwr TXT (0000) 177 Aug 19 02:31 exmpl.c
debwr PRG (0800) 19336 Sat 0 00:00 grep
debwr PRG (0800) 11130 Aug 19 21:04 lcase
debwr TXT (0000) 1467 Aug 19 23:21 lcase.c
debwr PRG (0800) 11242 Aug 26 22:03 more
debwr TXT (0000) 2297 Aug 31 06:48 more.c
debwr PRG (0800) 12426 Aug 24 22:58 sort
debwr TXT (0000) 2200 Aug 31 06:48 sort.c
debwr PRG (0800) 11130 Aug 19 19:41 ucase
debwr TXT (0000) 1468 Aug 19 23:25 ucase.c
To navigate the ProDOS shell put the SYSTEM disk in drive 1 and the
UTIL disk in drive 2. Boot the SYSTEM disk. Make sure your CAPS lock is
off. To change to drive 2 type "cd /UTIL" and press [RETURN]. To change
to the RAM disk, type "cd /RAM" and press [RETURN].
DOS 3.3 Diskimages
------------------
D33Shell.dsk
D33Compiler.dsk
D33Filters.dsk
To navigate the DOS 3.3 shell put the D33Shell disk in drive 1 and the
D33Filters disk in drive 2. Boot the D33Shell disk. Make sure your CAPS lock
is
off. To change to drive 2 type "cd d2" and press [RETURN]. To change
back to drive 1, type "cd d1" and press [RETURN]. To get a directory
listing type "ls" and press [RETURN].
Note that while the ProDOS Shell uses proper pathing with PREFIXs the
DOS 3.3 Shell just uses d1 and d2 as its PATH.
What's Included
---------------
Some additional utilities are included with both versions and an Aztec
C native mode compiler environment is included on the diskimages for
the DOS 3.3 version.
I have written and compiled several filter programs and a "hello world"
program for use with each shell. The source code is identical, however
the executables are targeted at their particular SHELL. The programs
targeted at the DOS 3.3 shell are very tiny. Neither the ProDOS nor the
DOS 3.3 sample programs will run properly outside their intended SHELL
since both environments are SHELL version and OS version specific and
all accept command line arguments. The filter programs will also accept
redirected input and output and file input.
These sample programs are compiled to PCODE (pseudo-code) and run
somewhat slower than native code, but with the availbility of
emulators, CF drives and accelerators that increase execution speed
over what was then available, their performance is quite acceptable.
The ProDOS samples were compiled in the CG65 cross-development
environment available for download from the Aztec C website at:
http://www.aztecmuseum.ca/AZCG65.zip
The DOS 3.3 samples were compiled on the diskimage provided in this ZIP
file using the native mode compiler also provided on the diskimage in
this ZIP file. To my knowledge, no cross-development environment exists
for the DOS 3.3 Aztec C SHELL.
Building Shell Programs for DOS 3.3 in the Aztec C Shell
--------------------------------------------------------
There are 3 DOS 3.3 diskimages in this ZIP file:
D33Shell.dsk
D33Compiler.dsk
D33Filters.dsk
To build DOS 3.3 programs that will run in the Aztec C DOS 3.3 Shell,
boot with the D33Shell.dsk in drive 1 then put the D33Filters.dsk in
drive 2 and the D33Compiler.dsk in drive 1.
Type "cd d2" and press [RETURN] to change to drive 2.
Then type "ls" and press [RETURN] to list the directory. A number of
C source files are listed.
Type "MAKEFILE exmpl" and press [RETURN] to build the EXMPL program.
Repeat as necessary.
It took 11 seconds to build EXMPL from exmpl.c in its entirety under
DOS 3.3. in the AppleWin emulator on my AMD DX2/3000 Windows XP
machine. More capable machines may get faster results.
MAKEFILE
--------
MAKEFILE is a SHELL script on the DOS 3.3 compiler disk:
x--- snip ---x
set -x -a
loop
# Now Building $%
cci $%.c
ln $%.INT SHINT.LIB
rm $%.INT
loop
x--- snip ---x
It is used to compile any old thing by using the basename of the C
program as an argument. It is pretty much right out of the Aztec C
manual.
Acknowledgements
----------------
Thanks to Rubywand (Jeff Hurlbert) for his work in organizing the DOS
3.3 AztecC_minimanual.txt from which D33Shell.txt (the DOS 3.3 Shell
Documentation) is excerpted.
Thanks to Paul Santa Maria for making the PDF manual MAXC65A.pdf
available for download from sys.apple2 from which the ProDOS SHELL
documentation is excerpted from. Thanks to Dean Phares for splitting
the SHELL chapter out of the PDF and keeping it small.
Thanks also to Paul Santa Maria for making the CG65 compiler and its
docs available.
And thanks to the other folks on comp.sys.apple2 and
comp.sys.apple2.programmer for the good discussions that have provided
the details I needed and the other bits and pieces to pull this Aztec C
Stuff and this little SHELL project together.
Bill Buckels
September 1988.
End of Document
Bill Buckels
When I post an Aztec C Installation whether compiler or project it is
complete. If I repost it just got better but you don't need to download the
latest and greatest every time.
To install any of my distributions into Windows XP or on an MS-DOS-type
environment just unzip the distribution zip onto the root of your C: drive
with directories intact.
In Windows XP click-on the shortcuts from Windows Explorer. In DOS just run
Aztec bat.
Aztec C will run in Ubuntu Linux (and others) under DOSEmu and will also run
under DOSBox and I have tested in both. It is 100% portable in this respect.
Have Fun,
Bill
Bill Buckels
For those serious-minded individuals who dare to tread on the metal.
The pdf manual for the ProDOS SHELL describes the SHELL's file system
showing the hierarchy beginning with the "root" directory. The "root"
directory is specified with a slash (a forward slash like in unix pathnames,
and not a backslash like in MS-DOS and Windows Network pathnames).
Therefore to change directory to the root, type "cd /" and press [RETURN].
In the ReadMe I state "To navigate the ProDOS shell put the SYSTEM disk in
drive 1 and the UTIL disk in drive 2. Boot the SYSTEM disk. Make sure your
CAPS lock is off. To change to drive 2 type "cd /UTIL" and press [RETURN].
To change to the RAM disk, type "cd /RAM" and press [RETURN]."
You need some way of knowing the PREFIX when you put a new disk in the drive
so you can change to it using the SHELL's directory metaphor. The manual is
not clear on this. When you type "ls /SYSTEM" and press [RETURN] all the
files (and sub-directories if any) on the disk with the SYSTEM volume label
are listed (sub-directories if any are preceded with a dash). However when
you type "ls /" or when you type "ls" when in the virtual "root" directory,
nothing is listed.
What do you do now? Keep in mind that you are in "SHELL HELL" and you can't
TAB around like you can in the ProDOS finder. You may as well be in linux:)
without the KDE or X of any kind. Shades of the PDP-11!!! But this is as
Goodnow intended I am sure.
The manual also discusses the use of wildcards (the asterisk) and the use of
the ls internal SHELL command, but one important and very significant detail
has been missed... probably because Jim Goodnow II and Thomas Fenwick are in
the rocket-scientist IQ ratio and didn't anticipate that mere mortals like
the rest of us would have a problem making a logical connective. Read-on.
To list all volumes simply type "ls /*" and press [RETURN].
Beauty eh?
Another tip: Removing a sub-directory:
To make a sub-directory on the current volume, as expected, "mkdir myfolder"
and press [RETURN]. To change to the new directory the cd command works.
There is no rmdir command to remove a sub-directory. Just use the rm
command.
Hope this helps (assuming you care about such minutae as navigating this
shell course:). I also certainly understand why some people prefer a GUI
for navigation and sudoku for puzzles. Those same people may even say that
what I have described is cryptic. I have heard that said about this shell by
those new to shells before. But I hope I am clear and I am in the process of
adding this to the ReadMe without most of the editorializing.
Pathname qualifiers and other related info can be a topic for another day.
Before I go, want to see what's on path (this is set set in your profile):
echo $PATH
But you knew that:)
Bill
Bill Buckels
>MAKEFILE is a SHELL script on the DOS 3.3 compiler disk:
>x--- snip ---x
>set -x -a
>loop
># Now Building $%
>cci $%.c
>ln $%.INT SHINT.LIB
>rm $%.INT
>loop
>x--- snip ---x
Errata: The above was not fully functional due to an irregularity in the
expected format of text files used as shell scripts. It worked fine for one
program but the loop sandwich was disabled because the text file terminated
without a $D.
Don't go shooting the SHELL though. It is in good company. GWBASIC on the PC
has this same sort of problem dealing with programs in ASCII format. It
needs that EOL ($D$A) and would like at least one $1A as well because on a
clear disk you can seek forever.
Anyway the zip on the website has been updated and the ReadMe as well.
See below.
x--- snip ---x
MAKEFILE
--------
MAKEFILE is a SHELL script on the DOS 3.3 compiler disk:
x--- snip ---x
set -x -a
loop
# Now Building $%
cci $%.c
ln $%.INT SHINT.LIB
rm $%.INT
loop
x--- snip ---x
It is used to build any old thing by using the basename of the C program as
an argument. It is pretty much right out of the Aztec C manual.
It can also be used to build multiple files.
For example:
MAKEFILE exmpl ucase lcase
will build all 3 programs. The loop keywords in the DOS 3.3 shell script
which enclose the build sequence will shift up to 9 source filenames named
on the command line and compile each in succession.
x--- snip ---x
Note also the loop command in the ProDOS shell is structured differently
than the DOS 3.3 shell in that it sports an eloop for the same reason that
you can't have one without the other. Or for some of you who don't remember
the words to Love and Marriage, for every if there is a fi is better
understood by.
Bye.
Blackbeard