65832 Manual Is Found!
Bryan Parkoff
Go to http://www.apple2.org.za/gswv/A2.LOST.N.FOUND.CLASSICS/CPU.65832/
--
Yours Truly,
Bryan Parkoff
BPar...@satx.rr.com
David Empson
> 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.
--
David Empson
dem...@actrix.gen.nz
David Empson
> Bryan Parkoff <BPar...@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
dem...@actrix.gen.nz
Exegete
David Empson wrote:
> David Empson <dem...@actrix.gen.nz> wrote:
>
>
>>Bryan Parkoff <BPar...@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).
So it couldn't run GS software then, could it?
A can be
> 32-bit, 16-bit or 8-bit (controlled by 'M' and 'E8' flags).
What sense is there in a 16 bit A if X and Y can only be 8 or 32 bit?
Roy
David Empson
> David Empson wrote:
>
> > 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).
>
> So it couldn't run GS software then, could it?
Yes it could, by setting the CPU to operate in 65816 emulation mode.
The E16 flag used to switch between 32-bit native mode and 16-bit
emulation mode is invisible to 65816 and 6502/65C02 software unless it
makes use of the XFE instruction, in the same manner as the E flag of
the 65816 is invisible to 6502/65C02 software unless it uses the XCE
instruction.
Both the 65816 and 65832 start up in 8-bit emulation mode at reset, so
the 65832 would work perfectly in a IIgs (assuming there was a version
of the chip in the same package), as it would happily operate in 8-bit
emulation mode and 16-bit emulation mode.
Software which was aware of the 65832 could switch to 32-bit native
mode, but it would be necessary to operate with interrupts disabled,
because the native interrupt vectors would not be implemented. It would
also be necessary to switch back to 16-bit or 8-bit emulation mode to
call any existing code.
If the IIgs had been further developed by Apple and had made use of the
65832 in a later model, then Apple would have upgraded the firmware to
add support for 32-bit native mode in the appropriate places. The
interrupt handler would have gained another set of entry points, and the
toolbox and GS/OS would have to deal with the CPU running in either
32-bit native or 16-bit emulation mode (depending on the application),
or require that the application switched to 16-bit emulation mode prior
to calling the appropriate entry point.
> > A can be 32-bit, 16-bit or 8-bit (controlled by 'M' and 'E8' flags).
>
> What sense is there in a 16 bit A if X and Y can only be 8 or 32 bit?
X and Y can be used as pointers while A is used to perform calculations.
I can easily envisage applications where you want 8-bit offsets in the
index registers while doing 16-bit calculations, or storing a complete
memory address in one or both index registers while doing 16-bit
calculations.
Note that the XBA instruction would probably swap 16-bit values between
A and B (the hidden top half of A) while in this mode, and transferring
data between X/Y and A (or vice versa) would also transfer the contents
of B.
I didn't read the data in enough detail to see what XBA would do while
the A register was set to 8 bits in 32-bit native mode. I expect it
suppresses the high order 16 bits of the accumulator, effectively
behaving like the 65816 native mode with the accumulator set to 8 bits.
--
David Empson
dem...@actrix.gen.nz
Rubywand
Wish I had noticed this thread and your answer before sailing off to dig
around on Tom's site!
Anyway, the stuff is now in GS WorldView's archive ...
http://www.apple2.org.za/gswv/a2zine/Sel/index.html click on "Docs".
(Have put a redirect msg at the old location.)
Rubywand
Peter Watson
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" <dem...@actrix.gen.nz> wrote in message
news:1faenwe.cj7cgubl3okaN%dem...@actrix.gen.nz...
Michael J. Mahon
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: mjm...@aol.com
Home page: http://members.aol.com/MJMahon/