mdj wrote:
> On Nov 15, 3:59 pm, "Michael J. Mahon"  wrote:
>> mdj wrote:
> 
>>> It's an excellent design. I never did figure out if the IIc versions
>>> could interpolate the switching protocol somehow from the expansion
>>> connector. One of these days I'll have to grab such an adapter and
>>> test it out.
>>> I always thought it a shame that the IIgs didn't support this. It did
>>> provide a way to do colour/mono selection, but it was rare that I
>>> found a mono-dhr application that didn't require me to activate
>>> monochrome in the control panel.
>> Apple had a very mixed record on "adopting" _de facto_
standards created
>> by third parties, even when they were well thought out.
>>
>> The ThunderClock comes to mind as a winner, though its lack of a
"year"
>> register led to the 5/6-year rollover in the year table in ProDOS--not
>> a very clean clock, actually.
>>
>> The Zip Chip was adopted in the IIc+, though it is so invisible to
>> software that only its control was an extension to the architecture,
>> and even then, it wasn't carried forward to the IIgs.
> 
> And IIRC, the Zip Chip debuted after the release of the IIgs...

...and "carrying backward" is so difficult!  ;-)  (I was never part
of the IIgs universe, so I never considered that obvious problem!  ;-)

>> The "standard" of slot 3 for an 80-column card was, I
think, a third-
>> party creation.
> 
> I could be wrong, but I think that standard was created by Apple
> Pascal which scanned slot 3 for an external terminal. At the time,
> this would have been a dumb terminal or modem connected via a Serial
> Communications Card. I pretty sure the firmware ID bytes and protocol
> for communications cards and terminal adapters is a 'Pascal' standard.

That's true, but I thought that there were 80-column cards prior
to the introduction of Pascal--maybe I'm wrong.

>> It always struck me as peculiar that Apple never directly supported
>> the usual AUX slot bank-switching memory expansion scheme, even though
>> it was "market standardized" by AE and adopted by many
others, with
>> pretty wide software support.
> 
> 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.  Since 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.  It
always seemed peculiar to me that the //e was escaping a 64KB "prison"
only to enter a 128KB prison!  A 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!

>> 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.  I 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.  For 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.

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

-michael

******** Note new website URL ********

NadaNet and AppleCrate II for Apple II parallel computing!
Home page:  http://home.comcast.net/~mjmahon/

"The wastebasket is our most important design
tool--and it's seriously underused."
--- SBBSecho 2.12-Win32