[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: RGB card

mdj wrote:

On Nov 15, 3:59 pm, "Michael J. Mahon" <mjma...@aol.com> 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."