Re: 65832 Manual Is Found!

[mjmahon@aol.com (Michael J. Mahon)]

Peter Watson wrote:

>A long time ago I had a copy of the (or a possible??) 65832 data sheet. (I
>probably still have it buried underneath one of the piles of computer debris
>I have accumulated.)
>
>The one enduring memory I have is that it was supposed to have some type of
>inbuilt floating point support, from memory using one of the existing
>"instructions" (maybe WDM??) as a lead-in byte. (And no, it wasn't COP with
>a numeric co-processor!)
>
>At the time I first saw it I got all excited until someone reminded me about
>how "useful" 32-bit floating point was likely to be in the real world...
>:-(
>
>[Pause while Peter rummages in the debris piles...]
>
>OK, maybe I don't have a 65832 data sheet (although I have seen one). As I
>was searching however, I remembered that the Apple IIgs Hardware Reference
>has a Western Design Centre 65C816 data sheet (dated Nov 1986) which
>mentions the 65C832. The COP instruction explanation mentions that
>"Signatures 00-7F may be user defined, while signatures 80-FF are reserved
>for instructions on future microprocessors (i.e., W65C832)."
>
>And here is the explanation for the WDM Opcode:
>
>WDM Opcode Use
>The WDM opcode will be used on future microprocessors. For example, the new
>W65C832 uses this opcode to provide 32-bit floating-point and other 32-bit
>math and data operations. Note that the W65C832 will be a plug-to-plug
>replacement for the W65C816, and can be used where high-speed, 32-bit math
>processing is required. The W65C832 will be available in the near future.
>
>[...I think that should have been "...in the Near Future", as in "Real Soon
>Now"! It's only been 15 years or so - it must be getting close now!]
>
>BTW, David, I had a look at the online data sheets. While there is a
>reference to the XFE instruction on P.30, I can't see any reference to it in
>the opcode tables on P.32 and P.33. Which all just adds to the mystery.
>
>--
>Peter Watson
>-- Write to MSDOS disks on the Apple IIgs?
>-- Impossible!  ;-)
>
>"David Empson" <dempson@actrix.gen.nz> wrote in message
>1faenwe.cj7cgubl3okaN%dempson@actrix.gen.nz">news:1faenwe.cj7cgubl3okaN%dempson@actrix.gen.nz...
>> David Empson <dempson@actrix.gen.nz> wrote:
>>
>> > Bryan Parkoff <BParkoff@satx.rr.com> wrote:
>> >
>> > > 65832 Manual Is Found!
>> > >
>> > > Go to
>http://www.apple2.org.za/gswv/A2.LOST.N.FOUND.CLASSICS/CPU.65832/
>> >
>> > Thanks for the pointer.
>> >
>> > It is in a rather awful format (separate GIF document for each page,
>> > with no HTML index), so it will take me a little while to absorb its
>> > contents.
>>
>> Well that was a non-event.
>>
>> If this document is accurate, then the only differences between the
>> 65832 and 65816 would have been:
>>
>> - Three layers of emulation mode (65832 native, 65816 emulation and
>> 65C02 emulation).  The existing 'E' flag bit is renamed 'E8' and a
>> second 'E16' flag is added.  The new XFE instruction toggles the E16 and
>> E8 flags with the V and C flags respectively.
>>
>> - 32-bit A, X and Y registers available in 65832 native mode.  X and Y
>> can be either 32-bit or 8-bit (controlled by 'X' flag).  A can be
>> 32-bit, 16-bit or 8-bit (controlled by 'M' and 'E8' flags).
>>
>> - Yet another set of interrupt vectors in 00FFD0-00FFDF for use in
>> 32-bit native mode.
>>
>> That's it.  No new instructions (apart from XFE) or addressing modes.
>> No improvements to the placement of the stack or direct page.
>>
>> It theoretically supports a 32-bit address space, but there is no way to
>> access more than 16 MB outside of the chip.  The rest of the 4 GB
>> address space would only be available in an ASIC which incorporated the
>> 65832 as a CPU module, and appears to have very limited addressing
>> options.
>>
>> The second half of the document is basically identical to the 65816 data
>> sheet.
>>
>> I couldn't see any evidence that an opcode had been allocated for the
>> new XFE instruction.  Since the 65816 uses all but one of the possible
>> opcodes, and the last one was reserved as a pre-byte, the XFE would
>> require a two byte opcode, probably WDM (0x42) followed by an
>> unspecified second byte (with the XCE opcode being a likely candidate).

All of this is completely consistent with the 65832 existing only as an
idea or specification for a design, not a full design.

It is common to float such proposals to assess interest which would
justify carrying the design on to more detail.  This often means that
the "preliminary spec" is just a cut-and-paste job on the previous product,
with the general idea for extensions roughed in--often without a very well
thought-out plan for whether or how they would be implemented.

Evidently, the 65832 "proposal" did not generate enough interest to
warrant going any further.  And I agree with David (and Peter WRT
floating-point) that the proposal is not particularly interesting as a
microprocessor.  The only justification for doing it would be to carry
forward a large and valuable body of 65816 software.

Ironically, as with the 65816 (for which there was indeed a good case
for compatiblity with the 6502), the kludgy compromises required to
achieve good compatibility were the impediments to designing a
really capable state-of-the-art microprocessor.

-michael

 Email:  mjmahon@aol.com
 Home page:  http://members.aol.com/MJMahon/