stepping machanism of Apple Disk ][ drive (was Re: Heatkit 51/4 floppies)

From: Richard Erlacher <edick_at_idcomm.com>
Date: Sat Apr 10 16:13:23 1999

I knew somebody woudl come up with a good example. That 6809 code is
probably the closest thing I've seen in a micro. The 8051 uses a similar
approach, pointing to the table with the datapointer and uses the
accumulator as an offset. It does make it a bit awkward passing a parameter
in the accumulator, though. In this case, the accumulator is occupied by
what's really the only value you'd want to pass anyway under the
circumstances.

 They (DEC) did make the uVax-II as a chipset for interfacing to their
BI-bus, I believe, so that might qualify as well. The DEC chipset probably
didn't sell for what a 6809 costs, even the faster part, and certainly not
the $0.86 I last saw on the 4MHz Rockwell 65C02.

The 6502 and its scions save a clock tick every time they loaded an address
because the indexing or whatever arithmetic could be done on the low byte
while the high byte was being fetched, leaving the carry set or cleared as
was required, for the arithmetic on the next byte as was appropriate. Note
that the carry was generally irrelevant, as most instructions requiring
indexing simply wrapped the PC, but not in all cases. I thing indexed mode
addressing was a case where an index could cross a page boundary. The MOT
processors could often do the same thing, but they needed to add a clock
tick to order the bytes and another to propagate the carry if appropriate (I
think). It wasn't that sort of hair-splitting I was after, but rather, a
contrast between the simple, elegant instruction set of one processor,
versus the not-so elegant instruction set of "the other" meaning the
intel/zilog clan.

I'm not surprised that it was in the 6809 that this instruction came up.
The 6809 showed lots of promise at first, but once it was in hand, one
clearly could see that it would be MUCH easier going with the MC68008 if one
had to use an 8-bit bus. I never had the opportunity to write in a
high-level language for the 6809, but I was told it should have been quite
easy to write a high-quality efficient compiler for it because of its
repertioire of instructions and addressing modes. I turned out literally
tens of thousands of lines of assembler code for it and never used this
feature, though. It's likely most of my code would have run on a 6802 or
6803 just as easily.

Dick

-----Original Message-----
From: Sean 'Captain Napalm' Conner <spc_at_armigeron.com>
To: Discussion re-collecting of classic computers
<classiccmp_at_u.washington.edu>
Date: Saturday, April 10, 1999 1:27 PM
Subject: Re: stepping machanism of Apple Disk ][ drive (was Re: Heatkit 51/4
floppies)


>It was thus said that the Great Richard Erlacher once stated:
>>
>> At the risk of becoming the resident infidel . . .
>>
>> The 6502, particularly in its later incarnation by Rockwell embodied the
>> cleverness fostered by its earlier versions and the non-Intel family of
>> processors. How the elegance of their instruction set became lost is a
>> mystery to me.
>
> I've never been a real fan of the 6502, it seemingly geared more towards
>embedded systems than for a general purpose computer. But that's just me
>8-)
>
>> On a 65C02 from Rockwell (making the distinction because there were
several
>> CMOS 6502's, all slightly different) you load the input value into an
index
>> register and then jump, indexed indirect, to the routine which is
>> appropriate for that pattern of inputs. This requires, then, that you
have
>> a table with 256 bytes, more correctly 128 words, with each word the
>> address of the routine which is used to process the left-justified ASCII
>> data.
>>
>> This is tremendously fast! It requires no STACK, and it requires only
two
>> instructions. Another way of doing this involves building a stack frame
and
>> loading the return address with a value looked up in a table, then
executing
>> a return. This can be done with any number of processors. On a Z-80 you
>> can jmp HL, and I'm sure there are other neat ways of doing this simple
>> thing. I've never seen anything more elegant than that simplistic
sequence
>> on the 65C02. How the MOTOROLA people let this go by the wayside in the
>> design of their 6809, 6801, 68K family, and countless others puzzles me.
>> I've not made an extensive study of other processors, but I have looked
at a
>> few. The only processor I've used which has a similar mechanism at its
>> disposal is the 8051 core. It has a data register which can be used as
an
>> offset for a jump instruction.
>
> If I understand the problem correctly, then what you want can be done on
>the 6809 as two instructions as well (okay, three, but the first one is
only
>there for setup):
>
> LDX #JMPTAB
> MAIN: LDA UART
> JMP [A,X]
>
>
> As long as X is unchanged, your overhead is two instructions. Also, if
>you want to use X for something else, you still have Y or U for use as well
>(okay, you can use S, but then it gets a bit harder 8-)
>
> But if you want elegance, go with the VAX---one statement:
>
> caseb uart,0,255
> jmptab: .word c00 - jmptab
> .word c01 - jmptab
>
> ; ...
>
> .word cff - jmptab
>
> And with this, you don't even have to jury rig a special UART.
>
> In fact, the VAX is about as elegant as they come---you have 16 general
>purpose registers and the PC is one of them (R15). Not only that, but all
>addressing modes work on all instructions---it's very regular and with some
>practice you can probably end up reading hex dumps directly. It's a very
>nice assembly language.
>
>> Now, I doubt that anything that simple can be used to discriminate
between
>> what's "best" and what's not, but it's for certain that it's a nice
feature
>> not available on the 6809. I used the 6809 extensively while I was in
the
>> aerospace industry, and found it fairly friendly. BUT, it still is
>> relatively slow, as compared with processors of the same generation from
>> sources clever enough to arrange the bytes the other way around in memory
so
>> you didn't have to fetch and the discard a high byte when there wasn't
one.
>> Fortunately, many tasks don't require a really fast processor.
>
> I don't follow. You either care about a 16-bit quantity, or you don't,
>but I may be biased---my first CPU was a 6809 and when I switched to the
>Intel x86 architecture, I didn't like the little endianess of it at all,
but
>I never found the bigendianess to be a real problem.
>
> -spc (Then there's the ARM ... )
>
>
Received on Sat Apr 10 1999 - 16:13:23 BST