Subject: Re: Phoenyx's AmperDos
Message-ID: <396E30A7.150DF035@dcnet2000.com>
From: Phoenyx <quazar@dcnet2000.com>
X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.2.15-4mdk i586)
X-Accept-Language: en
MIME-Version: 1.0
Newsgroups: comp.sys.apple2.programmer
References: <8kjjfs$nu2$1@nnrp1.deja.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Lines: 142
Date: Thu, 13 Jul 2000 16:12:07 -0500
NNTP-Posting-Host: 204.2.54.204
NNTP-Posting-Date: Thu, 13 Jul 2000 21:08:33 GMT
Organization: Verio



Hi Bob,

> What is the reason for using the "& hook" for Prodos commands?

There is not a simple answer here. Mostly this is due to how
Applesoft was written. It was created before disk drives and
thus, has no code for dealing with disks or files on them. In
fact, most versions still have the original tape drive code. To
allow Applesoft to deal with disks, Apple had to use another
method. For them, the I/O hooks seemed to be the answer. I guess
it would have caused to many problems to change the ROM when the
boot code was added.

Anyhow, Apple used the same basic technique in both Dos 3 and
ProDos. When the interpreter starts up, it ties into the I/O
hooks and controls the I/O flow of the system. ProDos already
has control of these hooks to some degree for other purposes,
which is a whole different topic. Basically, a bit of scanner
code processes I/O and waits for the correct control code for
a DOS command. When received, DOS (or Basic.System) takes
control and processes the string data following the control
code. Anyone who has programmed in Applesoft, knows what I'm
talking about.

This process takes up extra time and slows down Applesoft a
little. It it also (IMHO) an ugly way of accessing DOS in a
program. Well, Amperdos may not be prettier, but it is a little
easier for me to read. I can tell easily where a DOS function
is located. However, it must be said, Apple's technique offers
some possibilities which an ampersand interpreter cannot match.
For an example, see the assembler and article released in the
Nibble magazine.

It is very easy to write a simple interpreter for the Ampersand
hook and you now have some control over the routines you use
for DOS access. The Prodos MLI offers a great variety of useful
functions which can be incorporated. This allows for more ram
as well as control over DOS capability. This technique allows
for better memory control too. For example, you could use the
area from $800-$1fff for the DOS routines and have most of the
area below $bf00 for Applesoft. Allowing of course for any
file buffers you need. If you have a graphics oriented game and
need both screens, you still have from $6000 to $beff to work
with. You also can add routines to himem by simply adjusting
himem yourself, similar to Dos 3.3.

I guess the main answer is control. One of my original ideas was
to create a loadable DOS module which could be attached to a
BASIC program and run from anywhere. I had planned to make a
compiler which used a higher level of BASIC and convert it to a
highly tuned Applesoft module. This module would be attached to
the Amperdos module as a standalone SYS program.

I suppose Amperdos was more of a test for a variety of ideas
which turned out to be usable enough to release by itself. Some
of the other ideas may not be viable until I can gather more
info on Extra Vars. I have always wanted an Applesoft system
which can use 128k. I have Zbasic and it can be set to simulate
Applesoft, but it's not the same.

Also, an interesting side effect in Amperdos, the original IN#
and PR# work for slot control without disabling DOS as they do
in the standard system.

> I checked out AmperDos and it sure does leave alot of room for
> programs and variables.

This was an original requirement for Atree II. I wanted to store
directory info for several possible levels. Unfortunately, I'm
still having problems here. I have a partially developed idea
of using stub basic routines for passing variables to Extra Vars
using a technique similar to ProBasic.

I really want to fix it right and I suppose I need to get back
to it. Part of my problem, I use and like ZBasic compiler so I
tend to resort to it more often. The released version of Atree
II was a combination of Zbasic and assembly. Zbasic's biggest
drawback, it always includes the whole system, graphics and all
whether you use them or not. Modular compilers just weren't in
vogue I guess.

> Did you program the text window-draw and restore subroutines?

I borrowed it from ProBasic and made it work. It was an extra
assembly code module from disk 2. This is why it's rather
limited. It was only supposed to be temporary, then I decided it
would be useful as a separate error handler or such.

I was at the burn out point here. I knew things wouldn't work
for what I wanted, but I hated to give it up. I figured the
simple window routine would prompt me to later add better ones.

> I was able to run the program with AppleWin, but not Oasis.

Which version of Oasis. It had a problem with earlier ones due
to a bug in my code regarding clocks. Actually, the code made no
allowance for a clock. The older clock hardware made use of the
input buffer @ $200 without saving it, when P8 made a call, it
always called the clock code which ended up trashing the buffer
data. What a pain in the *ss. This was fixed by adding a buffer
backup/restore routine and calling it at certain points.

I just tested it with the latest Oasis. I downloaded the archive
and made a fresh disk with shrinkit. It works fine on Oasis,
Kegs and ApplePC. By default, the disk boots and exits to the
P8 quit code and you need to launch Amperdos from here. I have
forgotten why I made the disk like this, but I will probably
leave it. I have not decided how I want to release the freeware
source versions. I like the examples being there and the auto
run demo features when Amperdos executed.

The code was formatted for Merlin 2.54 P8 assembler. I used
Merlin for the code for a couple of reasons. Availability of
the assembler for one. It was the most common for 8 bit systems.
Plus the assembler has a built in full screen editor which the
Editor/Assembler from Apple Inc. lacked. The code is also
compatible with the assembler program released in a later Nibble
magazine. I felt this would allow for more people to update the
code. It will also assemble in Merlin 16 I think.

Ok, you may have sparked my interest in returning to the project
for a bit. I suppose I need some more input on what/how to
improve it. Also, any info on Extra Variables would help. Guess
I'll break out my notes on Kegs debugger and see if I can figure
things out.

BTW, I first tried the newer NULIB2 to extract the disk. For
some reason, NULIB2 didn't make a useable disk image. It worked
fine when extracted through KEGS via GSHK.

-- 

Thank you for your time and interest. I hope it was helpful
or at least interesting.

Phoenyx,

Apple2 user since March 1984

Links to Phoenyx's pages:
preferred..... http://zip.to/Phoenyx_A2
alternate..... http://www.tinyangeldesigns.com/Apple2