[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: 65832 Manual Is Found!



Exegete <millers@noneofyourbusiness.com> wrote:

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