6502.org Forum  Projects  Code  Documents  Tools  Forum
It is currently Tue Nov 12, 2024 3:52 am

All times are UTC




Post new topic Reply to topic  [ 29 posts ]  Go to page Previous  1, 2
Author Message
 Post subject: Re: 65C816 - Why?
PostPosted: Thu Nov 08, 2018 5:37 am 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8482
Location: Midwestern USA
BitWise wrote:
It might be worth checking out these people. Allegedly they have thousands in their warehouse on your side of the pond. Search for W65C802.

http://www.greenlightelectronics.com/electronic-part-search

They list the manufacturer as "Western Digital." :D

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!


Top
 Profile  
Reply with quote  
 Post subject: Re: 65C816 - Why?
PostPosted: Thu Nov 08, 2018 5:43 am 
Offline

Joined: Tue Jul 24, 2012 2:27 am
Posts: 679
scotws wrote:
Here is something that I think would be fun on a 65816: Scheme or Lisp. If i understand the internal structure, you need two pointers and a bunch of type bits in each cell -- not something you want to do on a 6502. With 16 bit, you could probably get away with it. Think of all the stuff you would have to figure out, GC, interpreter, compiler ... basically, the whole Structure and Interpretation of Computer Programs. That's pretty much enough stuff to last a lifetime.


There are tons of ways to represent Lisp internal objects, even when just sticking to cons cells. I've done a ton of pondering & taken plenty of notes in the past on exploring this space. Plus, I've been giving attention to AcheronVM trying to get the overhaul of it published, on top of which I certainly want to build GC, typed memory objects, and such.

What I would opt to do is have pages of homogeneous types, so you could check the first bytes of the page, or look up the pointer's high byte(s) in a table, to check the type of a pointer without making individual objects more complicated. At least from a 6502 perspective, there's tons of fun puzzles to solve in this space, and I think it's possible to have these sorts of features running "at scale". The '816 might just be cheating in comparison. ;)

_________________
WFDis Interactive 6502 Disassembler
AcheronVM: A Reconfigurable 16-bit Virtual CPU for the 6502 Microprocessor


Top
 Profile  
Reply with quote  
 Post subject: Re: 65C816 - Why?
PostPosted: Thu Nov 08, 2018 6:42 am 
Online
User avatar

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8539
Location: Southern California
BitWise wrote:
I could but with International shipping a single chip would be rather expensive. It might be worth checking out these people. Allegedly they have thousands in their warehouse on your side of the pond. Search for W65C802.

http://www.greenlightelectronics.com/electronic-part-search

Thankyou, Andrew! I put it in the 65xx parts sources sticky topic head post.

The "quantity available" line indicates there are thousands, but it seems to be an item number instead. (The number is 2547 through 2551, consecutive, for the five speeds.)

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?


Top
 Profile  
Reply with quote  
 Post subject: Re: 65C816 - Why?
PostPosted: Sat Nov 10, 2018 1:22 am 
Offline

Joined: Mon May 21, 2018 8:09 pm
Posts: 1462
I may use a 65C816 in my desk calculator, not because it *needs* one - I'm currently intending to only use 65C02 instructions - but because that makes it easier to reuse the design (and maybe spare PCBs) for something that requires more RAM later, and the price seems to be very similar.

The behaviour of VDA/VPA also seems cleaner to me than the "every cycle is an access" behaviour of the pure '02 bus, and opens the possibility of implementing a low-priority DMA system if I feel like a challenge.

The extended instruction set, though, is an absolute horror.


Top
 Profile  
Reply with quote  
 Post subject: Re: 65C816 - Why?
PostPosted: Sat Nov 10, 2018 2:48 am 
Online
User avatar

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8539
Location: Southern California
Chromatix wrote:
The extended instruction set, though, is an absolute horror.

My only use of it has been with the C32 assembler, and I've liked it a lot; but after seeing how other assemblers deal with it, I can see why people might not like it.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?


Top
 Profile  
Reply with quote  
 Post subject: Re: 65C816 - Why?
PostPosted: Sat Nov 10, 2018 5:14 am 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8482
Location: Midwestern USA
Chromatix wrote:
The extended instruction set, though, is an absolute horror.

Please explain.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!


Top
 Profile  
Reply with quote  
 Post subject: Re: 65C816 - Why?
PostPosted: Sat Nov 10, 2018 6:56 am 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10977
Location: England
BigDumbDinosaur wrote:
Chromatix wrote:
The extended instruction set, though, is an absolute horror.

Please explain.

Do we have a thread, or a reference, explaining the facilities and benefits of the '816 already? I feel we must have gone over this question quite a few times...

... certainly for me, my first reaction on learning of the '816 was joy, that here was a 16 bit extension to my my favourite micro. My second reaction was that the four-mode design makes things rather less accessible than I'd hoped. My third position was that all is well provided you set out to choose a mode and stick with it most of the time - different applications and different people will have different preferences as to how to set the M and X bits for 8 or 16 bit operations and 8 or 16 bit indexing. In any case, some specific routines might change modes to do some work: in a 16/16 setup, one might find string-handling routines switch to 16/8 mode.

The important thing with the 816 is surely the compatibility mode, and the familiar programming model. That is, compare it with the 6502 and it comes up looking pretty good. If instead you look at all the CPU architectures out there for your comparison, the 816 might come off as a bit clunky - that's the cost of the backward compatibility and the incremental design.

So, comparisons with 68000 or with ARM or any recent architecture are likely to come to unfavourable conclusions, especially if they disregard the other aspects of a system design, like memory width or glue complexity, or if they emphasise programming in a compiled high level language.

The basic ability to hook up lots of memory and use three-byte pointers is great. The moveable stack and direct page are very handy. The 16 bit operations are handy. Slightly less obvious, the stack-relative addressing can be handy. And so on.


Top
 Profile  
Reply with quote  
 Post subject: Re: 65C816 - Why?
PostPosted: Sat Nov 10, 2018 7:37 am 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8482
Location: Midwestern USA
BigEd wrote:
Do we have a thread, or a reference, explaining the facilities and benefits of the '816 already? I feel we must have gone over this question quite a few times...

Yep! It's deja vu all over again. :shock:

Quote:
The important thing with the 816 is surely the compatibility mode, and the familiar programming model. That is, compare it with the 6502 and it comes up looking pretty good. If instead you look at all the CPU architectures out there for your comparison, the 816 might come off as a bit clunky - that's the cost of the backward compatibility and the incremental design.

Exactly. One needs only to look at the x86 architecture and the baggage it drags around so some old 8086 programs can be run on x86-64 MPUs (if anyone is still running 1980s code on a contemporary PC). I still get headaches think about that segment:offset nonsense.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!


Top
 Profile  
Reply with quote  
 Post subject: Re: 65C816 - Why?
PostPosted: Sat Nov 10, 2018 7:54 am 
Offline

Joined: Mon May 21, 2018 8:09 pm
Posts: 1462
My principal objections to the '816 instruction set are the mode flags (which can affect instruction length as well as the amount of data accessed), and the fact that the address space is not *quite* linear in ways that are inconsistent across addressing modes. These warts increase the cognitive load of dealing with the extra capabilities, on a CPU family where getting useful work done efficiently already involves a lot of careful juggling.

By comparison the 65C02 is reasonably orthogonal and flat in its addressing, with the easily-remembered exceptions of the stack and zero-page. Granted, the '816's discontinuities occur at 64K boundaries, so some of the headaches basically go away if you ignore the extra address space, but…


Top
 Profile  
Reply with quote  
 Post subject: Re: 65C816 - Why?
PostPosted: Sat Nov 10, 2018 8:44 am 
Online
User avatar

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8539
Location: Southern California
We've had various topics on the '816, but here's something I don't remember any of them having addressed. Someone said they wished that instead of the M and X flags, it had separate op codes for 8- versus 16-bit operations, but IIRC, only mentioned loads and stores. That by itself would already require two-byte op codes since the table is full as it is; but the fact is that you'd have to have separate op codes also for any register or memory operation that affects the C, N, or V flags. ROR A for example, even though it does not involve memory, still needs to know whether to rotate the C flag into bit 7 or bit 15, also which bit to reflect in the N flag. INA and DEA, even though they do not involve memory, still need to know whether to operate on 8 or 16 bits, because if the accumulator is in 8-bit mode, it's actually two 8-bit registers, A and B, and you might be expecting data in B to be left undisturbed. PHA, PLA, PHX, PLX, PHY, and PLY (a different kind of load and store) could be made to always be 16 bits, but that would be more wasteful of memory and execution time.

There's more, but these should make the point. I have wished sometimes that Bill Mensch hadn't been required to make it backward compatible with the '02; but I think he did a great job given Apple's requirements.

Regarding the not-quite-linear address space, Samuel Falvo (forum name kc5tja), professional programmer, said the key is to make the banking work for you, not against you. Now that memory (even SRAM) is super cheap compared to what it cost back when the Apple IIGS was introduced, one could extend the 65816 design with 32-bit buses and all 32-bit registers (except maybe the status register which probably doesn't have any use for 32 bits); and then the program and data bank registers and direct-page register simply become offsets into the entire 4-gigaword address space, à la 65org32. :D If any of the 32-bit 65-family processor designs ever become reality, I expect Michael Barry's (forum name barrym95838) 65m32 might be the closest to it. His scheme is more efficient than the 65org32's but has less of the familiar 65 flavor.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?


Top
 Profile  
Reply with quote  
 Post subject: Re: 65C816 - Why?
PostPosted: Sat Nov 10, 2018 3:14 pm 
Offline
User avatar

Joined: Fri Dec 11, 2009 3:50 pm
Posts: 3367
Location: Ontario, Canada
Chromatix wrote:
Granted, the '816's discontinuities occur at 64K boundaries, so some of the headaches basically go away if you ignore the extra address space, but…
Not sure I follow what you're saying here. I agree there's discontinuity in terms of code space. For example, when PC reaches $FFFF it wraps around to 0 without PBR getting incremented. That's disappointing, but only a minor downside, IMO.

On the upside we have the shining glory of the '816 -- specifically, that the data space is continuous! Those 3-byte pointers really work -- even with indexing applied. Example: using [d],y address mode, adding y to the 24-bit base address may result in a bank crossing. This event will execute successfully and transparently. The same is true with al,x mode (where the three-byte address is part of the instruction).

Unlike most schemes that "break the 64K barrier," the 816's three-byte pointers make it easy for the programmer to store and manipulate objects which...
  • straddle bank boundaries and/or
  • exceed 64K in size

-- Jeff

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html


Top
 Profile  
Reply with quote  
 Post subject: Re: 65C816 - Why?
PostPosted: Sat Nov 10, 2018 7:50 pm 
Offline

Joined: Mon May 21, 2018 8:09 pm
Posts: 1462
Looking into it, there *are* some limitations on '816 data addressing:

1: Stack relative addressing wraps around at 64K; the bank address generated is always zero. This effectively means you can't move the stack into high memory.

2: Direct Page register is 16 bits wide but aligned low, and the bank address generated is always zero (*not* taken from the DBR!) in direct or direct-indexed addressing modes, so it also wraps around at 64K and you can't use it as a fast shortcut into high memory.

3: The index registers are also only 16 bits wide, so you can't use them as fast universal address registers.

4: In Emulation mode there appear to be some odd behaviours if the DBR, PBR and/or DPR are non-zero. This is really just a warning to zero them before returning to Emulation mode.

This imposes some requirements on the hardware which could be considered inconvenient in some cases: you need ROM at $00FFxx for the reset vector, *and* RAM elsewhere in $00xxxx to use the stack and direct-page. Granted, there are ways to shadow a small ROM with a monolithic 16MB RAM.


Top
 Profile  
Reply with quote  
 Post subject: Re: 65C816 - Why?
PostPosted: Sat Nov 10, 2018 7:58 pm 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10977
Location: England
Right, Bank 0 is a bit special for the '816 - some things live there. It's a kind of generalisation of the way Page 0 is special for the '02. If you want acres of unrestricted RAM, start looking at Bank 1 and onwards.


Top
 Profile  
Reply with quote  
 Post subject: Re: 65C816 - Why?
PostPosted: Wed Nov 14, 2018 9:36 pm 
Offline

Joined: Sat Feb 10, 2018 10:13 pm
Posts: 10
I picked up a couple of 65816s recently. I don't have a specific project in mind yet, but I'm toying with either taking the SBC I've been working on and hacking the 816 in, or designing a whole new board around them. The main things I'm interested in are the larger address space, the 16 bit index registers, and the stack relative address mode.

One of the software projects I've been playing with is a 6502 version of a (very simple) LISP interpreter. I can get it working on a 6502... it's actually very close now, but the code has to do so much work to follow all the references. Another language I think would be interesting to try to implement is Smalltalk, but I don't even want to think about trying to implement it in 8-bits.


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 29 posts ]  Go to page Previous  1, 2

All times are UTC


Who is online

Users browsing this forum: Google [Bot] and 5 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to: