Re: Auxilary Ram card programming info..

[Phoenyx <quazar@dcnet2000.com>]

Hi Matt,

Some other things to consider. The arrangement of aux memory allows for the execution of subroutines but it would be
very
difficult to execute a large program this way. Not only do you
have to worry about the interrupts, you also need to be absolutely
certain of the memory configuration and how any changes in the
program or system will affect things. Many of the 'standard' tips
and tricks used in programming other systems will not apply to
the Apple II.

The 8 bit Apples break aux ram into several chunks. You have the
ZP + BSR, lower 48k, video ram. If I understand the manuals, you
can swap the video ram without affecting the lower 48k and
possibly the 48k without messing up video ram. I never got that
far into it because of the variety of ram cards and the amount of
code required to support this variety as compared to using the
Prodos routines and MLI.

I have seen a few attempts to make the best use of aux ram. Zbasic
uses it for internal subroutines and user program code as well as
editor routines during program editing. Apex128k also uses it for
program subroutines and font and data storage. Of course, this is
simply the aux bank zero (motherboard ram) but if you swap in
another bank from the card, it replaces the aux bank zero (or what
ever bank was active).

One thing I would love to see is an aux based memory manager that
could be used with Merlin or other assembler. Due to the methods
used by Apple in the design of aux ram, they memory is not contiguous. Each 64k bank will loose some memory for other
tasks.
For instance, the 2c uses a buffer in aux ram for serial I/O.

To make a program usable by the majority of Apple II 128k+ systems
I still suggest using Prodos and a ramdisk. Primarily because it
would allow for use of the GS memory, AE style cards as well as
the Apple slinky ram cards with a limited amount of trouble. This
may also help Apple II systems with a variety of sizes to operate
in a similar manner. It would even be possible to create virtual
memory by expanding this technique to access a disk file. It could
be fairly easy to implement and except for the file buffer you
use, it would be pretty invisible to the end user. If you use the
Prodos MLI you can easily load 'blocks' of data as well as loading
data directly into main ram addresses. For most functions you only
need on file buffer. Actually, if the code was written correctly
it could easily be adapted to handle other P8 functions necessary
to the program.

Alternately, if you only use the aux ram for subroutines with
hooks from main ram, you would gain a few advantages. First, you
have defined a set of routine hooks (addresses) for the user
programs to call. Trust me, this is very handy and anyone who
may program with your system will appreciate this. Second, with
proper coding, you can put most of your routines in aux memory
without worrying about interrupts as long as it is in the lower
48k. Troubles arise when you try and use the ZP+aux stack and/or
BSR ram.

Of course, aux ram works very well for data storage. As long as
you don't try to load data directly to or from the memory from a
AE style ramdisk. For this you would have to buffer the data in
main ram.

Surprisingly, most of the bank switch logic is already built in
to the Apple. AE just took advantage of the existing hardware and
added the bank select register, well basically. There is other
hardware to keep it all working right. As I mentioned in the last
message, the AE cards use a one byte 'register' ($c073) to
identify which bank to use. This register is connected to the
paddle strobe. For the 2c, this was probably the simplest method.
As the cards grew in functionality, they also grew in complexity.
For example, the last Zram came with a clock, Z80 cpu and could
handle a 65816 which I can't remember if it was stock. The Zram,
and probably the IIe ram cards do not keep track of the contents
of the bank select register, this is up to the programmer. Since
it is tied to the system, it can change values. I recommend that
the computer is set back to the zero aux bank (motherboard) after
each use, especially those programs that access the paddles.

Your OS sounds like a neat idea, but some things to keep in mind.
Redirecting I/O will slow the program down, sometimes quite a bit.
If you then add the overhead of swapping or fetching data from the
aux bank(s) you lose even more time. I was discussing this a while
back with Teodor, the author of Apple Oasis. He had created a neat
OS shell which had some of the things you mention as well as the
ability to run many Dos 3.3 programs. Some things worked great,
but most of the I/O was pretty slow.

I'm not saying this can't be done. I'm just saying it will take
some careful planning. Part of the OS will need to run in main
ram, primarily hooks for the system routines or stubs for those
routines you want to add at a later time. I think most of the
subroutines should run from aux ram at least those of a reasonable
size. This has some definite possibilities.

In answer to your questions on David's reply. If you plan on
running anything in the aux ram you will probably have to deal
with the interrupts. Plus, not all machines handle interrupts the
in same although Prodos helps with handling interrupts. With this
in mind, you will have to either deal with the interrupts (a whole
other topic :) ) or disable them while the code is executing. If
you disable them, you should make sure that no running programs or
devices need them.

As for the aux ram ZP and Stack, it is up to the programmer to
keep track of this. The routines supplied by Apple do not use
this aux memory.

As mentioned, aux ram coding can be very difficult, but this
difficulty makes the results more rewarding for many. Caution is
advised. Save often and be ready with the off switch.

I hope I haven't confused you more with this message. My intention
was to expand the answers given. Keep us informed and if you need
more help, please ask. Also, I would be willing to beta test if
and when you need it.

My apologies to the group for the length of this message. I just
hope it helps.

-- 

Cheers and best wishes,
Phoenyx

Have you fed your Apple today?

Phoenyx's Pages are back online...

It seems the ZIP.TO link was down for a while.
It is now working again. This is the preferred
link to my site. You may also use the direct link.

http://zip.to/Phoenyx_A2
http://www.tinyangeldesigns.com/Apple2