Discussion:
WDC 65C832 design in today's world
(too old to reply)
Anthony Ortiz
2017-09-01 18:14:19 UTC
Permalink
Raw Message
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
2017-09-01 20:12:08 UTC
Permalink
Raw Message
I'd like MUL, DIV, LSL, and ASR
Anthony Ortiz
2017-09-01 21:23:17 UTC
Permalink
Raw Message
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
2017-09-01 22:27:59 UTC
Permalink
Raw Message
Why? Because they are missing in the 65816
av
barrym95838
2017-09-03 06:39:33 UTC
Permalink
Raw Message
Post by Antoine Vignau
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.
Scott Hemphill
2017-09-06 17:02:10 UTC
Permalink
Raw Message
Post by barrym95838
Post by Antoine Vignau
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 ***@alumni.caltech.edu
"This isn't flying. This is falling, with style." -- Buzz Lightyear
Anthony Ortiz
2017-09-06 18:13:10 UTC
Permalink
Raw Message
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
2017-09-06 22:58:53 UTC
Permalink
Raw Message
Post by 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.
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
2017-09-07 06:08:43 UTC
Permalink
Raw Message
Post by 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.
Also doesn't a lot of Z80 stuff do similar?

-uso.

Brian Patrie
2017-09-03 12:20:39 UTC
Permalink
Raw Message
Post by Antoine Vignau
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
2017-09-04 00:16:21 UTC
Permalink
Raw Message
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.
Post by Brian Patrie
Post by Antoine Vignau
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?
-------
ProLine: ***@pro-kegs
barrym95838
2017-09-03 19:59:50 UTC
Permalink
Raw Message
Post by 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)
cmp #$80
ror
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 <****************************>
-------
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
2017-09-04 02:00:20 UTC
Permalink
Raw Message
Post by 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)
cmp #$80
ror
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.
Post by Brian Patrie
Post by Antoine Vignau
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?
-------
It also has something to do with the carry flag and/or twos-compliment arithmetic, doesn't it?
Michael J. Mahon
2017-09-04 04:04:41 UTC
Permalink
Raw Message
Post by Kelvin Sherlock
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.
--
-michael - NadaNet 3.1 and AppleCrate II: http://michaeljmahon.com
James Davis
2017-09-04 01:56:25 UTC
Permalink
Raw Message
Post by Brian Patrie
Post by Antoine Vignau
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?
Rodnay Zaks explains it in his book, "Programming the 6502," in the chapter/section about "6502 Addressing Modes."
David Schmenk
2017-09-02 16:43:11 UTC
Permalink
Raw Message
Post by 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?
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
2017-09-02 17:50:23 UTC
Permalink
Raw Message
Post by David Schmenk
Post by 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?
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...
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
2017-09-02 20:05:39 UTC
Permalink
Raw Message
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
2017-09-02 20:49:25 UTC
Permalink
Raw Message
Post by 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
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
2017-09-02 21:02:00 UTC
Permalink
Raw Message
Well, I guess we should just all stop using or developing anything other than the arm and rename this news group... sheesh
David Schmenk
2017-09-02 21:43:17 UTC
Permalink
Raw Message
Post by Anthony Ortiz
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
2017-09-02 22:19:26 UTC
Permalink
Raw Message
Post by Michael J. Mahon
Post by David Schmenk
Post by 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?
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...
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!)
*32-bit* of course... ;-(

Fat finger!
--
-michael - NadaNet 3.1 and AppleCrate II: http://michaeljmahon.com
Loading...