Re: Auxilary Ram card programming info..

[Matt Jenkins <mdj@pacific.net.au>]

Phoenyx wrote:
> 
> 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.

Absolutely, but this is why it's fun to do - if it were simple
programiing
there'd by no point to it.

> 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'm aware of all the details, although interrupt programming is
something
I'm new at since I don't (yet) have a mouse card installed in my //e.
I could drag out the //c to do this, but it's miles away and doesn't
have a Z-Ram board installed.
 
> 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).

There are dozens of ways to make use of it; I'm just trying to explore
another one. I haven't had this much fun programming in years!
 
> 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.

That'd be cool. Is Merlin available for free to download now? I'm stuck
for a decent assembler to use.

To be honest, I don't really care about compatibility with other
ram expansions - the AE approach interests me, since it's the 
most flexible. If someone *really* wants to play with what I come 
up with, then a RamWorks/Z-Ram or compatible board shouldn't be
that hard to find.
 
> 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.

The interrupts aren't that tricky, all you have to do is provide
a handler. Interrupt-driven devices are actually pretty rare in
the Apple II; apart from the mouse card, there isn't much else
that actually generates an interrupt, and since I plan to utilize
the mouse's interrupt generator I'm trapping it anyway, and it's
fairly simple to trap in aux. memory and use a handler to communicate
the as yet unclaimed interrupt back to ProDOS (which no doubt, will
have no handler for it and bring the system to a halt :\))
 
> 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.

Heh, I used Apple Pascal for years - that was the definition of slow I/O
 
> 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.

I think only what has to run in main memory will run there. Sometimes
it will be more efficient to run things in Aux. bank 0, since there's
only a single SS to hit to switch it in, whereas there'd be a minimum
3 to get back to main ram. Also, there's much efficiency to be gained
from the fact that clever organisation can allow the OS 'kernel' to
read things directly from the process's memory, by having the main
shunt mechanism in the $200-$BFFF range of main memory.

It would be great if you could beta test, presuming you've got the
hardware.

Cheers,

Matt