[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: ProDOS Plus
On Jul 1, 6:33 pm, BluPhoenyx <bluphoe...@earthlink.net> wrote:
> > The established protocol is this: If at application initialisation
> > time /RAM is connected, you are free to use the whole Aux memory area,
> > sans a small block in Aux. Language card bank 2 which is used by third
> > party drivers. Fortunately, I found that applications tend to respect
> > this barrier, so there's a whole 4K of useable RAM there.
>
> What about the 2c which uses some low areas in the auxiliary 64k bank? I
> understood that this part of ram is also reserved.
The IIc firmware uses parts of auxiliary page 2, auxiliary zero page
and the auxiliary "Screen Holes". How much of it is actually used
depends on what features you've got turned on, for instance keyboard
buffering, the mouse, and serial port buffering are the primary (and
rarely invoked) culprits.
> As a mention, I think the Apex 128k developer might fail your tests.
> IIRC, it uses some aux ram while /ram is still connected. Granted, I
> never had any problems with the system and I think the /ram blocks are
> marked but I could never get Don (at microgram) to use the Apple method.
If it leaves /RAM connected it definitely fails. Applications that
wish to use Aux memory have to disconnect it, then reconnect it on
exit. If it's disconnected on launch, you have to stay out of the
Auxiliary Language card region as well.
Any application that leaves /RAM intact and uses 'some' areas is
probably doing so to suppory double hires graphics.
> > If /RAM is disconnected, you are theoretically not allowed to use the
> > Language card at all. Anecdotal testing reveals most of the
> > 'interesting' applications will either refuse to start, ask for
> > permission to start, or ignore this recommendation.
>
> Does this imply that the 16k language card affects the 16k memory area
> in aux64?
The 16k area in Aux memory behaves exactly the same as the language
card area in main memory. Of course when it's switched in, the Aux
Zero Page and Stack are also switched in.
> > It really *is* a no-go zone. At a minimum, depending on this area will
> > make it impossible to run AppleWorks or Merlin 8. Since these are holy
> > applications to either the Apple II user community, developer
> > community or both, it's a non-starter.
>
> > I really feel it's a non sequitur to imagine a "turbo ProDOS 8" that
> > really only power users are going to be interested in, and then set
> > the hardware requirements to that of a stock Apple II. I would think
> > that anyone interested in this project is going to have a RamWorks or
> > similar card, or at the least, be prepared to source one in order to
> > be involved.
>
> Initially, I was thinking along the same lines. During discussions with
> Michael Mahon, his ideas offer other possibilities. I suppose in the end
> it would really be up to the person or persons who develop such a system.
As is the case with anything software. Of course we could consider the
readers of c.s.a2 the marketing department, and whoever puts up a hand
to write this thing an unfortunate IT employee of the same fictitious
organisation, but unfortunately the things we do for money are not the
same as the things we do for love ;-)
> > ProDOS 8 does a pretty good job of exploiting the 128k Apple II
> > platform, and there's little functionality you can practically add to
> > it within those constraints, with the exception of a couple of small
> > behavioral mods to remove some limitations.
>
> So your suggesting something which will take advantage of multiple
> memory banks? I don't have much experience with 'Slinky' ram cards so I
> don't know specifically how those work but I think the more banks you
> use, the more complex the system becomes. You quickly lose compatibility
> with existing programs. You could still maintain file compatibility though.
In terms of adding extending ProDOS, they're quite useful, since you
can expand it as much as you like into the extended memory card and
keep the memory footprint of "standard RAM" identical. As long as you
don't compromise the functionality of the ProDOS MLI, your
compatibility is ~100%.
The only thing that needs to be considered are applications that use
RamWorks style memory. The only ones I've really considered important
are AppleWorks and RAM Disk drivers, and both of those provide ways to
flag banks as reserved. I imagine the other applications do as well.
Slinky memory cards are really just RAM disks. In the context of this,
they would be usable as a "fast swapping" setup, but that's about it.
Matt