To be honest, a 65832 has no more in common with the Apple II than an ARM. And having to bastardize the (poorly designed) 65832 just to make it somewhat useful leaves a lot of questions as to what you're really trying to do and how you'll do it. Not

saying you shouldn't, but you're suggesting a path that requires much magic to happen vs taking the spiritual successor to the 6502 and making a pretty cool environment. 32 bit GS/OS apps running at 1 GHz, anyone?

David, I know this reply is years late but better late than never! :P

Regarding your opposition to a 65832 implementation but liking the idea of 32-bit GS/OS apps (I like this too! :), what exactly do you have in mind when you say "taking the spiritual successor to the 6502 and making a pretty cool environment. 32 bit GS/
OS apps" given that the GS is a 16-bit platform? What kind of enhancements would you make to the 65C816 to make that possible, and wouldn't the 65832 cover that base already or do I completely misunderstand?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

So, if I understand correctly, the suggestion was to use an ARM processor (cheap and readily available) to support a 32 bit GS/OS , rather than build a further extension to the 6502 family, incurring development costs (both hardware and software) and then either remaining content with low volumes (and high prices) or engaging in a battle to push into a space already occupied by the x86 and ARM ‘gorillas’. Even the ARM processors available
back when this discussion was conducted had enough power to emulate a 6502 and maybe even a 65816, but one could also have a system with both, similar to those machines with Z80 cards.

WDC seem to do sufficiently well continuing to sell 6502 and 65816 chips
and cores for embedded systems that they haven’t seen the benefit in pursuing the 65832 concept.

Okay, so assuming we're talking about an ARM emulating a 6502, which is something that has been done and I've done myself, then nothing prevents us from emulating the 65C816, and if we can do that then we can emulate the 65832, or create a true 32-bit
version of the 65C816. This is what I'm thinking to do with my little Raspberry Pi project, I'm using my Raspberry Pi as an accelerator ( ie. a turbo version of the Transwarp) hence all my questions here about bus timings, but I'd also like to make it so
you can choose the chip to emulate and add a 32-bit mode either by emulating the 65832 or creating a 32-bit version of the 65C816.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Anthony Ortiz <[email protected]> wrote:

To be honest, a 65832 has no more in common with the Apple II than an
ARM. And having to bastardize the (poorly designed) 65832 just to make
it somewhat useful leaves a lot of questions as to what you're really
trying to do and how you'll do it. Not saying you shouldn't, but you're
suggesting a path that requires much magic to happen vs taking the
spiritual successor to the 6502 and making a pretty cool environment. 32
bit GS/OS apps running at 1 GHz, anyone?

David, I know this reply is years late but better late than never! :P

Regarding your opposition to a 65832 implementation but liking the idea
of 32-bit GS/OS apps (I like this too! :), what exactly do you have in
mind when you say "taking the spiritual successor to the 6502 and making
a pretty cool environment. 32 bit GS/OS apps" given that the GS is a
16-bit platform? What kind of enhancements would you make to the 65C816
to make that possible, and wouldn't the 65832 cover that base already or
do I completely misunderstand?

What you might be missing is that the original ARM processor was produced
to replace the 6502 in BBC Micros. It has been described as the spiritual successor to the 6502. The 65816 is the actual successor.

So, if I understand correctly, the suggestion was to use an ARM processor (cheap and readily available) to support a 32 bit GS/OS , rather than build
a further extension to the 6502 family, incurring development costs (both hardware and software) and then either remaining content with low volumes
(and high prices) or engaging in a battle to push into a space already
occupied by the x86 and ARM ‘gorillas’. Even the ARM processors available back when this discussion was conducted had enough power to emulate a 6502
and maybe even a 65816, but one could also have a system with both, similar
to those machines with Z80 cards.

WDC seem to do sufficiently well continuing to sell 6502 and 65816 chips
and cores for embedded systems that they haven’t seen the benefit in
pursuing the 65832 concept.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Anthony Ortiz <[email protected]> wrote:

So, if I understand correctly, the suggestion was to use an ARM processor
(cheap and readily available) to support a 32 bit GS/OS , rather than build >> a further extension to the 6502 family, incurring development costs (both
hardware and software) and then either remaining content with low volumes
(and high prices) or engaging in a battle to push into a space already
occupied by the x86 and ARM ‘gorillas’. Even the ARM processors available
back when this discussion was conducted had enough power to emulate a 6502 >> and maybe even a 65816, but one could also have a system with both, similar >> to those machines with Z80 cards.

WDC seem to do sufficiently well continuing to sell 6502 and 65816 chips
and cores for embedded systems that they haven’t seen the benefit in
pursuing the 65832 concept.

Okay, so assuming we're talking about an ARM emulating a 6502, which is something that has been done and I've done myself, then nothing prevents
us from emulating the 65C816, and if we can do that then we can emulate
the 65832, or create a true 32-bit version of the 65C816. This is what
I'm thinking to do with my little Raspberry Pi project, I'm using my Raspberry Pi as an accelerator ( ie. a turbo version of the Transwarp)
hence all my questions here about bus timings, but I'd also like to make
it so you can choose the chip to emulate and add a 32-bit mode either by emulating the 65832 or creating a 32-bit version of the 65C816.

The 65C832 as proposed is basically a 32 bit version of the 65C816. In
order to implement it you’ll need to make some decisions that WDC never got around to:
* opcode and byte count for XFE to switch between bit modes;
* how to handle XBA in 32 bit mode (swap the top and bottom 16 bit groups,
or bytes 1 and 0 like in 16 bit mode)
* whether to clear or preserve the top 16 bits of the A, X, and Y
registers when switching between 32 bit and 16 bit modes;
* register transfer ops in 32 bit mode (TDC, TSC, TXA, TYA clear top 16
bits of C?); and
* probably other things I haven’t thought of.


In choosing to emulate a 65C832 you limit yourself to
* 8 bit data bus (4 memory cycles to load a 32 bit register)
* 24 bit program address space (16Mb limit)
* 24 bit data address space (unless you pretend it is an ASIC version with
32 bit data address space)

You’ll also need to develop a new software development tool chain for this ‘preliminary’ processor.

By comparison, if you chose an ARM coprocessor you’d have the 32 bit
address space and tool chain ready to go.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

The 65C832 as proposed is basically a 32 bit version of the 65C816. In
order to implement it you’ll need to make some decisions that WDC never got
around to:
* opcode and byte count for XFE to switch between bit modes;
* how to handle XBA in 32 bit mode (swap the top and bottom 16 bit groups, or bytes 1 and 0 like in 16 bit mode)
* whether to clear or preserve the top 16 bits of the A, X, and Y
registers when switching between 32 bit and 16 bit modes;
* register transfer ops in 32 bit mode (TDC, TSC, TXA, TYA clear top 16
bits of C?); and
* probably other things I haven’t thought of.

In choosing to emulate a 65C832 you limit yourself to
* 8 bit data bus (4 memory cycles to load a 32 bit register)
* 24 bit program address space (16Mb limit)
* 24 bit data address space (unless you pretend it is an ASIC version with 32 bit data address space)

You’ll also need to develop a new software development tool chain for this ‘preliminary’ processor.

By comparison, if you chose an ARM coprocessor you’d have the 32 bit address space and tool chain ready to go.

This is what I don't understand... I'm talking about a spiritual successor to the 65C816 that looks like a duck, walks like a duck, and quacks like a duck... unlike what the 65C832 would be to the 65C816 as that is to the 65C02 as that is to the 6502,
the ARM has no resemblance whatsoever to the 6502 line despite it having been the inspiration for the ARM; you might as well put an Intel inside and program a new GS/OS in x86 and run it and claim it's an Apple IIgs, but it's not, you can't leverage any
existing software, not even a single instruction, so it doesn't make any sense in an Apple II. With the 65C832 you'd be able to leverage what's already out there, and any assemblers and compilers would simply need to be extended, not replaced. What I'm
saying is that I think we're at the point where we can create a much faster Apple II accelerator (via FPGA or emulation as I'm doing on my Pi) so we can achieve that 1ghz GS/OS , and while we're at it maybe we can add some things that we've always wanted
in the process, like 32-bitness or some badly-needed instructions.

Also I'm not stuck on the 65C832, right now this is all just talk, just trying to see what the veterans here think the successor should look like if one had been made for the 32-bit world, just a bunch of locker-room talk for now. I'll be happy just to
get this 1ghz 6502 going, lol!

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <[email protected]>,
Anthony Ortiz <[email protected]> wrote:

The 65C832 as proposed is basically a 32 bit version of the 65C816. In
order to implement it you’ll need to make some decisions that WDC never got
around to:
* opcode and byte count for XFE to switch between bit modes;
* how to handle XBA in 32 bit mode (swap the top and bottom 16 bit groups, >> or bytes 1 and 0 like in 16 bit mode)
* whether to clear or preserve the top 16 bits of the A, X, and Y
registers when switching between 32 bit and 16 bit modes;
* register transfer ops in 32 bit mode (TDC, TSC, TXA, TYA clear top 16
bits of C?); and
* probably other things I haven’t thought of.


In choosing to emulate a 65C832 you limit yourself to
* 8 bit data bus (4 memory cycles to load a 32 bit register)
* 24 bit program address space (16Mb limit)
* 24 bit data address space (unless you pretend it is an ASIC version with >> 32 bit data address space)

You’ll also need to develop a new software development tool chain for this >> ‘preliminary’ processor.

By comparison, if you chose an ARM coprocessor you’d have the 32 bit
address space and tool chain ready to go.

This is what I don't understand... I'm talking about a spiritual
successor to the 65C816 that looks like a duck, walks like a duck, and
quacks like a duck... unlike what the 65C832 would be to the 65C816 as
that is to the 65C02 as that is to the 6502, the ARM has no resemblance >whatsoever to the 6502 line despite it having been the inspiration for
the ARM; you might as well put an Intel inside and program a new GS/OS
in x86 and run it and claim it's an Apple IIgs, but it's not, you can't >leverage any existing software, not even a single instruction, so it
doesn't make any sense in an Apple II. With the 65C832 you'd be able to >leverage what's already out there, and any assemblers and compilers
would simply need to be extended, not replaced. What I'm saying is that
I think we're at the point where we can create a much faster Apple II >accelerator (via FPGA or emulation as I'm doing on my Pi) so we can
achieve that 1ghz GS/OS , and while we're at it maybe we can add some
things that we've always wanted in the process, like 32-bitness or some >badly-needed instructions.

Also I'm not stuck on the 65C832, right now this is all just talk, just >trying to see what the veterans here think the successor should look
like if one had been made for the 32-bit world, just a bunch of
locker-room talk for now. I'll be happy just to get this 1ghz 6502
going, lol!

As for what to shoot for: it will not be easy to make an FPGA processor
which is faster than software emulation. Software can emulate a 65816
at an effective speed of 1GHz already, which is actually much faster
than the speed of a real 65816 running at 1GHz. This works out to about
300 million instructions per second (since 65816 instruction average a
little over 3 clocks each). FPGAs at reasonable prices are basically
limited to around 300-350MHz clock speeds. A complex FPGA design which executed one 65816 instruction every clock cycle would just about match
the speed of emulation on today's CPUs. But since accessing all memory couldn't sustain that 350MHz speed, it's effective rate will be lower
(think caches and cache misses).

So if not the fastest experience, what do you want?

Theorizing about CPU designs can be fun, but a 65832 has a lot of
headwinds against it. A lot of software is needed to get anywhere
(assemblers, compilers, disassemblers, etc. etc.). There are many ways
to add 32-bit support, so there are a lot of choices to be made, where
easy would be in direct violation of making it run fast. To have any
kind of speed, it will need to run one instruction per cycle (or more!),
which means a new mode (since 6502/65816 compatibility needs to keep the
byte fetches). One approach is WDM is a prefix for existing
instructions, and changes how they work--WDM STA could always write 32
bits, for example, and WDM BNE could use 32-bit (or 16-bit)
displacements. But what should WDM CLC do? This is where new
operations can be added. The 65816 makes some mistakes (like SEP #$20;
STA; REP #$30 to do a store of one byte), which would be nice to fix in
some way. Another approach is WDM REP #$30 enters 32-bit mode, and then
you just widen all the existing instructions to work on 32-bit data.
But this can be harder to make fast. So, if you create a new
instruction set, then you've got write a lot of software to support this (compilers, assemblers), plus then write software which takes advantage
of it. I think that's what the previous poster was saying: if WDM was a
switch to an ARM instruction set, then you get a whole lot of support
for the software needed.

Kent

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2022-08-19 10:48 a.m., Anthony Ortiz wrote:

Also I'm not stuck on the 65C832, right now this is all just talk,
just trying to see what the veterans here think the successor should
look like if one had been made for the 32-bit world, just a bunch of locker-room talk for now. I'll be happy just to get this 1ghz 6502
going, lol!

Back when the 65832 was first being discussed I was really wanting to
see it come into being but today, I don't think it will add a whole lot
to the Apple II experience. It would add a little bit but it wouldn't
add the modern things that people would really like to see today. Even
back then, when I saw the preliminary documentation for it, it was
lacking things that would have been needed. It is probably possible to
come up with a 65832 design that is backwards compatible to the 65816
and has modern capabilities but it would be a lot of work and take quite
some time to work out all the bugs.

Using an ARM right now, you could write firmware that would allow you to
run older 8 and 16 bit applications using an emulated 65816 but would
give you all the capabilities of the ARM for creating a new version of
GS/OS that could even be made multi threaded. A 65832 that allows multi threading and possibly other modern processor capabilities would be
almost as different from a 65816 as an ARM would be anyway. There are
already cross compilers for ARM processors so development could start immediately without the need to "extend" existing compilers but it would
be more of a rewrite to add the new capabilities anyway.

I think the majority of the IIgs experience comes from the user
interface which is not dependent on what processor it is running on.
This is why I consider a IIgs emulator a IIgs even though I run it on a
Ryzen 7 processor under Windows. Keeping the FST system and other parts
that make it unique and useful is more a priority for me. I think the
one thing I would like to see changed, especially if we can get higher a resolution desktop, is to lose the menu bar locked at the top of the
screen and have them at the top of the windows instead.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)