WDC 65C832 design in today's world

[Anthony Ortiz]

I'm itching to build an emulator on the ARM but would love to expand what we have rather than rehash what's already here. I'm thinking perhaps the 65C832 would be nice, offering 32-bitness and full backwards compatibility, but glancing through the specs I find it somewhat limiting given today's resources. I don't like that it's program counter is 16-bit, only allows for 24-bit addressing, and still relies on banking memory. It's also added a lot of addressing modes that compilers don't usually take advantage of but I'd love to hear what the community has to say about it. Is there anything you'd change on it, and if so, what would you rather see?

[Antoine Vignau]

I'd like MUL, DIV, LSL, and ASR

[Anthony Ortiz]

Yes, MUL we get for free from ARM A32 instruction set, but DIV exists in signed and unsigned versions, take your pick (or perhaps both?) :P ASR and LSL are also free. Out of curiosity, what made you pick these shift operators?

At some point I'd like to compile our ideas into a document of the 65C832 in its original form and the modernized version.

[Antoine Vignau]

Why? Because they are missing in the 65816
av

[David Schmenk]

On Friday, 1 September 2017 11:14:21 UTC-7, Anthony Ortiz wrote:
> I'm itching to build an emulator on the ARM but would love to expand what we have rather than rehash what's already here. I'm thinking perhaps the 65C832 would be nice, offering 32-bitness and full backwards compatibility, but glancing through the specs I find it somewhat limiting given today's resources. I don't like that it's program counter is 16-bit, only allows for 24-bit addressing, and still relies on banking memory. It's also added a lot of addressing modes that compilers don't usually take advantage of but I'd love to hear what the community has to say about it. Is there anything you'd change on it, and if so, what would you rather see?

Why not skip the 65832 and just go with ARM32? Then you get what you want, the tools are already available and it would run native speed. Just a thought.

Dave...

[Michael J. Mahon]

Exactly. Best go with a processor that was *designed* to be 33-bit, with
some inspiration from the 6502, without having the tail wag the dog...

(Of course, if you connect it with an Apple II, then look at that dog wag!)

--
-michael - NadaNet 3.1 and AppleCrate II: http://michaeljmahon.com

[Anthony Ortiz]

I plan on having it work full Arm mode of course, but I would like a mode that extends the Apple II as we know it

[Jorge]

On Saturday, September 2, 2017 at 10:05:41 PM UTC+2, Anthony Ortiz wrote:
> I plan on having it work full Arm mode of course, but I would like a mode that extends the Apple II as we know it

Many things are missing in the 6502, more registers, 16 bit registers, deeper stack, relative jmp, ability to write relocatable code, all these things and moar were already in Sophie Wilson's mind when she designed the ARM, so... what others have said already.

--
Jorge.

[Anthony Ortiz]

Well, I guess we should just all stop using or developing anything other than the arm and rename this news group... sheesh

[David Schmenk]

On Saturday, 2 September 2017 14:02:01 UTC-7, Anthony Ortiz wrote:
> Well, I guess we should just all stop using or developing anything other than the arm and rename this news group... sheesh

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?

[Michael J. Mahon]

*32-bit* of course... ;-(

Fat finger!

[barrym95838]

On Friday, September 1, 2017 at 3:28:00 PM UTC-7, Antoine Vignau wrote:
> Why? Because they are missing in the 65816
> av

There's no more op-code space, so you would have to start using $42
as a prefix byte to maintain any claim of backward compatibility.

Doable, but inelegant, IMO.

A kinky alternative would be a 9-bit byte version, but backward
compatibility is instantly lost, along with most of your fair-
weather friends.

Mike B.

[Brian Patrie]

On 2017-09-01 15:12, Antoine Vignau wrote:
> I'd like MUL, DIV, LSL, and ASR

I've long wondered why the 6502 has LSR and ASL instead of both one or
the other. What are the (dis)advantages of an arithmetic shift versus a
logical shift, anyway?

[Kelvin Sherlock]

Arithmetic vs logical is really signed vs unsigned.

For left shifting, arithmetic and logical are identical.
For right shifting, arithmetic preserves the high bit which is the
sign bit.

$ff lsr -> $7f (127)
$ff asr -> $ff (-1)

arithmetic shift right can be emulated with a compare and rotate:

cmp #$80
ror

I guess you could emulate logical shift right as well:
asr
and #$7f

The 6800 has arithmetic shift left (asl), arithmetic shift right (asr),
and logical shift right (lsr), so maybe that's why the 6502 ended up
with the asl mnemonic instead of lsl.
In <oogs2n$1eqg$1...@gioia.aioe.org>

-------
ProLine: kelvin@pro-kegs

[barrym95838]

On Sunday, September 3, 2017 at 12:20:09 PM UTC-7, Kelvin Sherlock wrote:
> Arithmetic vs logical is really signed vs unsigned.
>
> For left shifting, arithmetic and logical are identical.
> For right shifting, arithmetic preserves the high bit which is the
> sign bit.
>
> $ff lsr -> $7f (127)
> $ff asr -> $ff (-1)
>
> arithmetic shift right can be emulated with a compare and rotate:
>
> cmp #$80
> ror
>
> I guess you could emulate logical shift right as well:
> asr
> and #$7f
>
> The 6800 has arithmetic shift left (asl), arithmetic shift right (asr),
> and logical shift right (lsr), so maybe that's why the 6502 ended up
> with the asl mnemonic instead of lsl.

> In <****************************>
> Brian Patrie <********************************> writes:
>
>
> -------
> ProLine: kelvin@pro-kegs

Agreed. There is limited opcode space, so it makes sense (at least to me)
to implement one type of operation with lots of nice addressing modes and
leave the ability to emulate a similar operation with just one additional
machine instruction, as you aptly noted. This is exemplified best by the
absence of the ADD and SUB instructions, which would have gobbled up far
too much opcode space to be of overall benefit.

Mike B.

[James Davis]

Rodnay Zaks explains it in his book, "Programming the 6502," in the chapter/section about "6502 Addressing Modes."

[James Davis]

On Sunday, September 3, 2017 at 12:20:09 PM UTC-7, Kelvin Sherlock wrote:

It also has something to do with the carry flag and/or twos-compliment arithmetic, doesn't it?

[Michael J. Mahon]

Kelvin Sherlock <kel...@pro-kegs.uucp> wrote:
> Arithmetic vs logical is really signed vs unsigned.
>
> For left shifting, arithmetic and logical are identical.

Except that the Overflow flag should be set if an arithmetic shift results
in a sign change.

[Scott Hemphill]

barrym95838 <barry...@yahoo.com> writes:

> On Friday, September 1, 2017 at 3:28:00 PM UTC-7, Antoine Vignau wrote:
>> Why? Because they are missing in the 65816
>> av
>
> There's no more op-code space, so you would have to start using $42
> as a prefix byte to maintain any claim of backward compatibility.

An idea I had was to have a shadow memory for storing the upper two
bytes of 32-bit addresses. As long as the shadow memory is all zero,
then 8-bit code will function normally. But every instruction which
uses a two-byte address would also fetch two more bytes from the shadow
memory, constructing a four-byte address. JSR would push the upper two
bytes of the return address to the shadow stack, and RTS would fetch
them.

You could have a status bit which you turn on/off to switch between
8-bit and 32-bit access, so that you can use regular 8-bit code in
ROMs. You would need to be able to manipulate the shadow memory when
you load 32-bit code. One way would be to have a mode where memory
reads come from the first 64k of regular memory, but writes go to the
first 64k of shadow memory. After you set up the first 64k of shadow
memory (or as much of it as you need) you can turn on 32-bit mode and
JMP to it (or RET, or simply fall through to inline code) to bootstrap
program loading.

The nice thing about this scheme is the lack of bank registers and full
access to the 32-bit address space. But you don't get any 16-bit
registers or any additional functionality.

Scott
--
Scott Hemphill hemp...@alumni.caltech.edu
"This isn't flying. This is falling, with style." -- Buzz Lightyear

[Anthony Ortiz]

Why would using WDM ($42) be inelegant? It was meant for this exact scenario. From an assembler perspective we can use other mnemonics and it will assemble to WDM based instructions so it's hidden from you.

[barrym95838]

It's not inelegant from an assembler perspective, just from a raw binary
perspective. I'm one of those weirdos who thinks that way, I guess ...

It didn't stop the 6809 and the Z80 and the 8086, and it seems to work
fine for them, but that doesn't mean I have to like it.

Mike B.

[Steve Nickolas]

Also doesn't a lot of Z80 stuff do similar?

-uso.

[Anthony Ortiz]

> 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?

[Anthony Lawther]

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.

[Anthony Ortiz]

> 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.

[Anthony Lawther]

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.

[Anthony Ortiz]

> 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!

[Kent Dickey]

In article <6d32f8c2-9de2-49f2...@googlegroups.com>,

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

[Jeff Blakeney]

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.