On Nov 17, 11:46=A0am, "Michael J. Mahon"  wrote:

> > Absolutely. I suppose the slinky approach had the advantage of working
> > on any Apple II, but it was far less useful. I remember being very
> > surprised to discover the IIgs could not access its extended memory
> > using this scheme when in emulation mode.
>
> It would be interesting to learn the "behind the scenes" story of the
> Slinky architecture vs. simple bank-switching. =A0Since Apple had already
> embraced bank-switching in the Language Card, a straightforward
> generalization seems like an obvious next move (as it clearly was to
> Titan/Saturn).
>
> And when the //e was defined, a little planning for the future could
> have produced a much cleaner 128K+ bank-switched architecture. =A0It
> always seemed peculiar to me that the //e was escaping a 64KB "prison"
> only to enter a 128KB prison! =A0A meager factor of two is hardly worth
> the architectural work, particularly when Moore's "Law" was
so evident.
>
> Just a little more effort would have extended the (bank-switched)
> addressing by 8 bits, not just 1 bit!

I always thought that the IIe having the /INH all mod installed by
default at least indicated they were thinking about it...

I find the RamWorks invaluable. The approach is good enough from a
hardware perspective, but the lack of firmware and operating system
support does make me wish Apple had gone down that road, too. It's
great to be able to flip 4 switches and have a 'clean' 64k space to
work in; it's very frustrating to have the 80col firmware not work
properly :-(

> >> On balance, Apple acted pretty "proprietary" when
it came to others
> >> extending the _de facto_ Apple II architecture, even though they
> >> actively encouraged third party extensions...
>
> > The sad thing with RGB is that it *was* Apple supported. They supplied
> > the AppleColour RGB adapter to drive the Colour Monitor 100. The
> > design was licensed from Video 7. I suppose this was only done to help
> > clear the excess inventory after the demise of the III, and to allow
> > existing III owners to migrate to the IIe and recapture some of their
> > investment.
>
> I hadn't considered this angle, but it makes perfect sense. =A0I suppose
> that until the III went down, adding RGB support for the II would have
> been seriously discouraged inside Apple!
>
> It's a shame that letting a product "be all that it can be" is often
> seen as a problem for the company planners, even though it's great
> for the product's users...
>
> > Incidentally, the supplied software with this card contained an
> > excellent DHR Ampersand library which used the excellent REL loader
> > from Apple's EDASM package (yet another forgotten gem!).
> > Unfortunately, they didn't document the more esoteric modes offered by
> > the adapter, only the DHR colour, mixed and mono. There is an example
> > of the 16 colour text mode on the demo, but I don't recall there being
> > a documented terminal driver for it.
>
> > The software is definitely worth a look though if you've not seen it.
>
> I've seen and tried it, and I agree that it deserved wider support
> and use. =A0For a long time, though, the cost of an RGB monitor prevented
> them from becoming widespread in the user base, so software authors can
> be forgiven for not targeting them.

Yes, the price was the killer :(

> It's also a shame that Apple II libraries of relocatable software never
> became popular (though the interface problems are myriad). =A0The EDASM
> package loader was quite capable. =A0At the time, I never did any project=
s
> large enough to justify separate assemblies and linking--come to think
> of it, I still haven't! =A0;-)

I guess the fact that every assembler suite had a different linker was
a deterrent, but in the end source distribution was the easiest
solution for the assembly programmers. Not so for the BASIC crowd, who
would have benefited greatly from standardised use of RLOAD.

I've been poised on switching back to EDASM from Merlin for ages now,
if only I could find a manual for it. The ability to automate EDASM
through EXEC files and the STARTUP protocol is the really big draw
card - I'm finding the 'menu driven' interface quite tedious these
days.

Matt
--- SBBSecho 2.12-Win32