Re: IIc Memory..

[DaveSchmenk <dschmenk@gmail.com>]

On Feb 5, 6:50 pm, mdj <mdj....@gmail.com> wrote:
> On Feb 4, 5:01 pm, "Michael J. Mahon" <mjma...@aol.com> wrote:
>
>
>
>
>
> > mdj wrote:
> > > On Feb 4, 5:00 am, "Michael J. Mahon" <mjma...@aol.com> wrote:
>
> > >>The Slinky design only provides efficient sequential access to the
> > >>expansion memory, and is therefore best suited for RAM disks and
> > >>certain "swapping"-style memory managers, like Appleworks uses.
>
> > >>In fact, I've always theorized that the Slinky design was inspired
> > >>by Appleworks, which was the premier Apple II app that could benefit
> > >>from memory expansion.
>
> > > It was also released early enough that there were a lot of ][/+
> > > machines still in service, and without motherboard modification bank-
> > > switched designs are limited to the language card area, not to mention
> > > the complications with cooperating with existing slot-0 language
> > > cards.
>
> > Good point.
>
> > But even bank switching a meg in 16KB banks would be just as fast and
> > as easy as the Slinky architecture for sequential accesses, and it would
> > be more versatile--just an extension of the Saturn scheme.
>
> > But there wasn't much of a market for >128KB memory expansion pre-//e,
> > because Appleworks was the primary "consumer" of expansion memory.
>
> > Certainly there were some Pascal users who would have wanted a larger
> > RAM disk, but they must have been a miniscule number compared to the
> > Appleworks armies who craved a larger desktop.
>
> > (I was one of those who might have been interested, since I used the
> > Plusworks patches to run Appleworks on my ][+.  ;-)
>
> > It's actually quite disappointing how little real use there is for
> > expansion memory--another chicken and egg problem in the marketplace.
>
> > And if today is any indication, there were a lot more third party
> > RAMworks-style cards in use than Slinky-style expansions.
>
> Well it was so simple - take the existing scheme and add a bank select
> register :-)
>
> > If there had been a new version of ProDOS that loved memory expansion,
> > and tools to make it easy for applications to use, memory expansion
> > might have been more useful and more popular.  Of course, a single
> > architecture would also have helped.  ;-)
>
> It is a pity - I guess by the time there was market demand for such a
> thing there was also the Apple IIgs, and Apple seemed reticent to
> provide genuine enhancements to ProDOS after the IIgs was released. I
> suppose that's fair enough; at that point there were three Apple II
> platforms to support + Mac so the commercial imperative would have
> been to encourage obsolescence of the lower end.
>
> > I'd vote for bank switching over Slinky in an instant.  For sequential
> > block access, the bank-switched architecture is nearly as fast as the
> > Slinky architecture, and bank switching also supports code execution
> > and fast random accesses within a bank, which Slinky does not.
>
> Absolutely! With clever application design you can exceed the
> performance of Slinky cards by a considerable margin, since bank
> switch replaces swapping, although you have to be a bit wasteful with
> the memory to do so, but I can live with that. The tying together of
> the LC and ZP areas in the IIe's bank switch architecture always
> seemed like a painful compromise, and it's very difficult to use the
> extra AUX language cards. That said, 700k of memory makes for a
> *very* capacious 8 bit machine.
>
> Matt

I actually wish they had done something like the Apple III.  24 bit
pointers *and* bank switching.

Tying the LC and ZP together certainly make for some programming
challenges - especially when working with interrupts.  Leave them
disabled for too long and some hardware (*cough* mousecard *cough*)
stop interrupting.

Dave...