Re: 65832 Manual Is Found!

["Peter Watson" <paw77@NOhotmailSPAM.com>]

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).
>
> --
> David Empson
> dempson@actrix.gen.nz