Re: What is the quintessential Apple II?

["mdj" <mdj.mdj@gmail.com>]

Michael J. Mahon wrote:

> I coudn't agree more.  I was amazed at the //c joystick/mouse interface.
> About the only thing that //c pushbutton inputs are compatible with is
> pushbuttons!  ;-)  (Of course, it also has some more exotic modes, but
> you can't get compatible pushbuttons.)

I suppose we should concede in its defense that it allowed adding mouse
capability to the IIc without adding the 6800 uC that the card version
employs, which would have been a board real estate issue.

But yes, it was wierd.

> Yes--that's what a good standard bank-switching protocol would have
> fixed, but Apple never did it.  In several other cases, they "anointed"
> an existing player as the "standard" and supported it in system code.
> (Taxan RGB adapter and ThunderClock come to mind.)

And the Video7 RGB adapter for the IIe/IIc. The AUXMOVE/XFER routines
never got improved, but then, it's difficult to do control transfer to
AUX language bank RAM from ROM ;-) Such routines would have had to have
been squeezed into the slot-overlay ROM bank, and space was pretty
tight there.

> > I really like the fact that the mini-assembler came back - it's very
> > handy. The only 'missing' in the IIe firmware that the IIc had is that
> > the monitor L command disassembles 65C02, but I guess given how much
> > smaller the IIe ROM space is, they did a fine job squeezing in
> > everything they did :-)
>
> True, space is a real constraint.  The disassembly list function of
> the Monitor is alread crammed in pretty tightly, even using data
> compression.
>
> What the List command does is intimately related to the function and
> capability of the mini-assembler.  The mini-assembler is another fine
> hack, in which the opcode byte is incremented successively, with the
> result of dissassembling it being compared to the input line.  When
> the disassembly matches the input, the correct opcode is found!

:-)

When I first got my Apple II I neither had, nor could I afford an
assembler, so I wrote a simple Applesoft program than would read my
'assembly' listings, and calculate label offsets. It handled EQUates as
well. It did one pass through the listing using trivial 'guess' like
code to determine the number of bytes per instruction, then a second
pass which substituted labels for actual values, writing it to a second
text file. The end result could then be EXEC'd, invoking the
mini-assembler to do the hard work, then BSAVE'ing the result.
Chronically slow (due to naive searches through Applesoft arrays), and
you had to hold your hand over ctrl-S waiting for an error, but it
worked ;-)

I called this thing MAE, or mini-assembler-extender. Later it was
extended with a DS directive, and "did the job" until I started using
the UCSD p-System in preference to BASIC.

I imagine many others did similar things, but at the time I was quite
young and felt a real sense of Woznian achievement at the results.
Perhaps this explains my distaste for the unenhanced firmware, where my
hack would only work if you were in DOS 3.3 and had Integer BASIC
loaded. I never cared much for DOS 3.3 either :-)

Matt