6502.org Forum  Projects  Code  Documents  Tools  Forum
It is currently Fri Nov 22, 2024 12:13 pm

All times are UTC




Post new topic Reply to topic  [ 84 posts ]  Go to page 1, 2, 3, 4, 5, 6  Next
Author Message
PostPosted: Sat Feb 09, 2013 8:51 am 
Offline

Joined: Mon Jan 07, 2013 2:42 pm
Posts: 576
Location: Just outside Berlin, Germany
Again, a question that came up while reading through old forum posts. When I first found out about the 65816, I was really, really excited. A 16-bit version of the 6502 with up to 16 Mb of RAM? Awesome! However, it seems that there is not much love for the CPU. Obviously, there is BigDumbDinosaur's POC V1.1 (http://sbc.bcstechnology.net/), and Daryl's SBC-4P (http://sbc.rictor.org/pinfo4.html), for example. But there are fewer projects, assemblers, and simulators than I would have expected. What gives?

So far, I would guess that there are three reasons:

1. The 65816 is not a true 16-bit processor, but a 8/16-bit hybrid (which is what WDC says on their website). As such, it suffers from the worst of both worlds: Segmented memory (some commands wrap to the beginning of their banks), but with important stuff limited to Bank 0 (zero pages, boot vectors, stacks). Even if you tried to use the chip for a bunch of virtual 6502s, the "ZP in Bank 0" situation would prevent ever using the full 16 Mb (max of 256 instances of 64 Kb each with 256 byte ZP would eat up the complete Bank 0, if my math is correct).

2. The 16-bit code seems bolted on. Whereas the 6502 instruction set is elegant, parts of the 65816 feel like, well, downright hacks. Switching from 8-bit to 16-bit mode requires two instructions and manipulating the carry bit, and you have to keep telling the assembler what mode you are in (LONGI ON). REP and SEP makes your head hurt because you have to remember which bits to set. Nothing that a bunch of assembler macros couldn't make easier to tolerate, but not exactly pretty, either.

3. The memory addressing is harder for the hobbyist to handle, mostly because data and bank lines are shared. I see the data sheet for the 65816 has some special glue logic they recommend for this. After reading about BigDumbDinosaur's problems with a hardware bug ("Unlike the 65C02, the 65C816 can generate false address bus states during the intermediate steps of processing certain instructions."), my enthusiasm is dampened as well.

Now, am I being unfair to the 65816 and missing something? Or is this just a chip that could have been designed a whole lot better? And while we are at it, it doesn't seem that there is a good 16-bit CPU out there for hobbyists at all, at least for assembly programming fun.

Thanks,
Y, Scot


Top
 Profile  
Reply with quote  
PostPosted: Sat Feb 09, 2013 9:39 am 
Offline
User avatar

Joined: Tue Nov 16, 2010 8:00 am
Posts: 2353
Location: Gouda, The Netherlands
For me, the 65816 holds no nostalgic value, unlike the 6502. My first two computers were based on a 6502, and that's where I learned programming. Many popular computers from that time were based on a 6502, while the 65816 was not nearly as popular.

For modern day stuff, I see no reason to use a 65816 or any other 16 bit controller. I'd rather use a modern ARM Cortex. These are cheap, come in hundreds of different packages and configurations, including tons of peripherals, can be programmed in C with free compilers, and are much more powerful than the 65816.


Top
 Profile  
Reply with quote  
PostPosted: Sat Feb 09, 2013 10:26 am 
Offline
User avatar

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8543
Location: Southern California
scotws wrote:
What gives?

I think it's that it looks more mysterious, so people shy away from it.  Part of the 6502's attraction is the simplicity.

Quote:
So far, I would guess that there are three reasons:

1. The 65816 is not a true 16-bit processor, but a 8/16-bit hybrid (which is what WDC says on their website). As such, it suffers from the worst of both worlds: Segmented memory (some commands wrap to the beginning of their banks),

As kc5tja (a forum member who is a professional programmer but inactive here at the moment) said, the trick is to make banking work for you, not against you.  Even if the data bus were 16-bit, it would slow things down if you always had to fetch a 24-bit address.  Hence the absolute and long addressing modes.

Quote:
but with important stuff limited to Bank 0 (zero pages, boot vectors, stacks). Even if you tried to use the chip for a bunch of virtual 6502s, the "ZP in Bank 0" situation would prevent ever using the full 16 Mb (max of 256 instances of 64 Kb each with 256 byte ZP would eat up the complete Bank 0, if my math is correct).

The direct page doesn't have to be on a page boundary; so since few applications would need an entire page for it, you can fit more in than you might have thought.  The same goes for the stack.

Quote:
2. The 16-bit code seems bolted on. Whereas the 6502 instruction set is elegant, parts of the 65816 feel like, well, downright hacks. Switching from 8-bit to 16-bit mode requires two instructions and manipulating the carry bit

The XCE instruction is only for getting in and out of 6502-emulation mode.  If you're really after an '816, you'll put it in native mode in the reset routine and never touch the E bit again.  Once in native mode, the C and E bits are not involved with switching the accumulator or the index registers from 8- to 16-bit mode or vice-versa.  It can have either (or both) of those in 8-bit mode even in native mode.

Quote:
and you have to keep telling the assembler what mode you are in (LONGI ON). REP and SEP makes your head hurt because you have to remember which bits to set. Nothing that a bunch of assembler macros couldn't make easier to tolerate, but not exactly pretty, either.

For 8- versus 16-bit A and index registers, it only makes sense to make macros that are far more clear than REP and SEP.  I called mine ACCUM_8, ACCUM_16, INDEX_8, and INDEX_16, which are far more clear and assemble the appropriate REP or SEP instruction.  I think BDD called his LONG_A, etc..  When I wrote my '816 Forth kernel, I left the processor almost full time in ACCUM_16 and INDEX_8, and seldom had to change it.  I use the Cross-32 (C32) assembler, and instead of having to tell it LONGI ON etc., it just gives 16-bit unless you preface the operand with "<", like LDX #<$20 which lays down A2 20, not A2 20 00.

Quote:
3. The memory addressing is harder for the hobbyist to handle, mostly because data and bank lines are shared. I see the data sheet for the 65816 has some special glue logic they recommend for this. After reading about BigDumbDinosaur's problems with a hardware bug ("Unlike the 65C02, the 65C816 can generate false address bus states during the intermediate steps of processing certain instructions."), my enthusiasm is dampened as well.

It would have been nice if they just put 8 more pins on it to avoid that; but keep in mind that the '816 offers a lot of advantages even if you never stray from bank 0, which is what the 65802 was about-- an '816 that could go into a 6502 socket.  You don't have to latch, decode, or use the bank byte to reap a lot of benefits.  In situations where you're constantly dealing with 16-bit values, I find the '816 much easier to program than the 6502.  Really.  And since it takes so few instruction to get the job done compared to the 6502, my '816 Forth runs two to three times as fast as my 6502 Forth does at a given clock speed.

Quote:
Now, am I being unfair to the 65816 and missing something? Or is this just a chip that could have been designed a whole lot better? And while we are at it, it doesn't seem that there is a good 16-bit CPU out there for hobbyists at all, at least for assembly programming fun.

Anytime they try to preserve an investment (like making an Apple IIGS that could also run legacy Apple II code), they will fail to make all the gains they could have made in performance when upscaling the processor.  The '816 does however still run the Sieve of Eratosthenes benchmark faster than the 68000 did, even though the 68000 had more and wider registers.  And the interrupt performance is no comparison.  The '816 is 10-20 times as fast there.

I would really like to have what we called the 65Org32 in our discussion of a hypothetical processor at viewtopic.php?f=1&t=1419 which would have the bank, direct-page, and stack-pointer registers like the '816 but no boundaries since everything is 32-bit, including the data bus, so there are no bank or page boundaries.  It would be kind of like everything being in zero page, because ZP is the entire gigaword address space.  These registers would just be used as offsets, making it better suited for multitasking with any size of programs and data.  It would be just a much more powerful 6502.

Edit, eight years later:  I posted an article, "The 65816 microprocessor: Common Misunderstandings, Plus Attractions" which covers these things and more.

_________________
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  
PostPosted: Sat Feb 09, 2013 12:59 pm 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10985
Location: England
Hi scottw
I went through the same reactions: the 816 seemed like a great step forward to someone rooted in 6502 systems. With richarde doing most of the work, we made an 816 upgrade for the beeb, which we also tried on the oric (with less success.) See https://sites.google.com/site/beeb816/

But it does seem - to me - much less attractive to program. Perhaps it's just too big, perhaps it seems untidy. From a commercial and implementation perspective, it's a good idea, no doubt about that: compatibility and low pin count are both valuable.

I'd urge you to ignore BDD's hardware bug, or if not, then understand exactly what happened. It was a real bug, but he was interfacing to an unpleasant chip and happened to use a troublesome addressing mode. I'm sure it was frustrating and of course it had to be fixed, but I think he over-reacted.

As Garth says, there have been several efforts here (and probably elsewhere) to dream up a better CPU. Sometimes they even get implemented. The 65Org16 has run successfully on FPGA, including with external memory - which is not so easy, because single-cycle asynchronous SRAM isn't normally what you have. The 65org32 remains unimplemented - it does have the advantages Garth spells out, and the 65Org16 has a subset of those advantages. You might be interested to look through the summary of threads at viewtopic.php?f=1&t=1982

Cheers
Ed


Top
 Profile  
Reply with quote  
PostPosted: Sat Feb 09, 2013 4:14 pm 
Offline

Joined: Tue Jul 24, 2012 2:27 am
Posts: 679
The biggest issue is what Arlet brought up. It didn't have big commercial success in home computers, like the 6502, Z80, 68k, and x86 did. The only real presence there was was the Apple IIgs, which wasn't that much of a hit as 68k home computers were already on the market at that time. Of course, it was in the wildly popular SNES, but that's not user-programmable on its own.

So it didn't entrench itself with the hobbyists, and in shopping for features it makes more sense to get a "real" 16-bit or larger processor when you need oomph beyond the basic 8-bit. I think it has very little to do with the programming model.

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


Top
 Profile  
Reply with quote  
PostPosted: Sat Feb 09, 2013 4:42 pm 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10985
Location: England
There's a fair amount of interest and activity still in SNES land - as you say, it's not a computer you program, but then cross-development is common anyway now that we all have bigger faster computers to work on.

The other point in favour of '816 is that there are not a lot of attractive alternatives at 16bit: x86... and arguably 68k, although that's somewhat like a 32bit system with a 16bit bus.


Top
 Profile  
Reply with quote  
PostPosted: Sat Feb 09, 2013 7:25 pm 
Offline
User avatar

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8543
Location: Southern California
There was a political factor in the Apple IIGS's lack of success, which was that Steve Jobs [Edit: no, I think Jobs was gone from Apple by that time] didn't want it to outperform the new McIntosh and make it look bad, so the IIgs's clock speed was held down to 2.8MHz.  The C64's SuperCPU add-on module with an '816 however operated at 20MHz.  I don't know anything about the design, but the clock speed itself was over seven times as fast as the IIgs's.

And maybe someone else has more history on this (Ed is good at finding and posting this kind of thing)— Commodore designed the 65CE02 which came out in the late 1980's and was an upgrade to the 6502 featuring:
  • 10MHz clock speed
  • most dead bus cycles eliminated, and more than 30 of the op codes took only one clock, ie, 100ns @ 10MHz
  • 16-bit stack pointer
  • base page register allows relocating "zero" page
  • additional index register Z
  • 24 new instructions and 46 new op codes (in addition to the Rockwell 65c02 ones), filling out the op-code table

So what happened to it?  I suspect it was a story similar to that of Apple's, and Commodore wanted to put the emphasis on the Amiga.  I think Commodore was starting to have their financial problems then too.

_________________
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  
PostPosted: Sat Feb 09, 2013 8:10 pm 
Offline

Joined: Tue Jul 24, 2012 2:27 am
Posts: 679
The 65CE02 went into the never-released Commodore 65, of which there are a few (very pricey) prototypes floating around, but those were only clocked at 3.54MHz. And yeah, it was a "Let's not compete with the Amiga" sort of thing, and C= going to Bermuda instead of caring about finishing & marketing tech.

I do have a SuperCPU, but I don't know all too many technical details about it. It's got a CPLD on board as well to handle all the glue to the C64's bus.

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


Top
 Profile  
Reply with quote  
PostPosted: Sat Feb 09, 2013 8:18 pm 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10985
Location: England
White Flame, if you could take some photos of the SuperCPU circuit board I'd love to see them! Especially if we can make out the component numbers.
Cheers
Ed


Top
 Profile  
Reply with quote  
PostPosted: Sun Feb 10, 2013 5:42 am 
Offline

Joined: Tue Jul 24, 2012 2:27 am
Posts: 679
It's unfortunately packed away right now, but GIS seems to know about it:

Image

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


Top
 Profile  
Reply with quote  
PostPosted: Sun Feb 10, 2013 6:35 am 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8505
Location: Midwestern USA
White Flame wrote:
It's unfortunately packed away right now, but GIS seems to know about it:

Image

If one looks carefully at the picture a 40 MHz clock generator can be seen (a flop somewhere is dividing that to produce a Ø2 clock), but the 65C816 itself is a -14, meaning 14 MHz. I'm not familiar with the SuperCPU's design but do know that it did run reliably at 20 MHz. The performance speedup on a C-64 bordered on the ridiculous. Using a FOR-NEXT loop in BASIC as a time delay device was an exercise in futility. :lol:

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


Top
 Profile  
Reply with quote  
PostPosted: Sun Feb 10, 2013 7:11 am 
Offline

Joined: Sat Oct 20, 2012 8:41 pm
Posts: 87
Location: San Diego
scotws wrote:
Now, am I being unfair to the 65816 and missing something? Or is this just a chip that could have been designed a whole lot better? And while we are at it, it doesn't seem that there is a good 16-bit CPU out there for hobbyists at all, at least for assembly programming fun.


All processors could be designed better. :wink:

The 65816 was of course designed to stay close to the 6502 in hardware and software. I like having the 16 bit instructions when needed but I wouldn't want to be in 16 bit mode all the time. ARM has thumb instructions as well.

It just takes a little time to get used to the 816, macros make 8bit-16bit switching a non-issue.


Top
 Profile  
Reply with quote  
PostPosted: Sun Feb 10, 2013 7:36 am 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8505
Location: Midwestern USA
scotws wrote:
Again, a question that came up while reading through old forum posts. When I first found out about the 65816, I was really, really excited. A 16-bit version of the 6502 with up to 16 Mb of RAM? Awesome! However, it seems that there is not much love for the CPU. Obviously, there is BigDumbDinosaur's POC V1.1 (http://sbc.bcstechnology.net/), and Daryl's SBC-4P (http://sbc.rictor.org/pinfo4.html), for example. But there are fewer projects, assemblers, and simulators than I would have expected. What gives?

So far, I would guess that there are three reasons:

1. The 65816 is not a true 16-bit processor, but a 8/16-bit hybrid (which is what WDC says on their website)...

Garth replied to this, but I'll toss in my two cents just for grins.

The '816 is a true 16 bit processor with selectable register widths. The ALU is 16 bits, the all-important stack pointer is 16 bits and the direct page register is also 16 bits. WDC chose to stay with an 8 bit data bus to make the MPU more acceptable to designers already invested in the 65C02. Incidentally, even when the accumulator is set to 8 bits it's still a 16 bit register. The MSB is accessible by using the XBA instruction to swap the MSB with the LSB (real handy, by the way, for changing the endianess of words).

Quote:
...As such, it suffers from the worst of both worlds: Segmented memory (some commands wrap to the beginning of their banks), but with important stuff limited to Bank 0 (zero pages, boot vectors, stacks). Even if you tried to use the chip for a bunch of virtual 6502s, the "ZP in Bank 0" situation would prevent ever using the full 16 Mb (max of 256 instances of 64 Kb each with 256 byte ZP would eat up the complete Bank 0, if my math is correct).

The bank zero limitations of direct and stack pages (also the hardware vectors) is not as limiting as one may think, especially when programmable logic gets into the picture to manage memory. It's not a big stretch to arrange memory management to cause direct page and stack accesses to occur in other banks. It just takes some imagination and adroit programming.

Quote:
2. The 16-bit code seems bolted on. Whereas the 6502 instruction set is elegant, parts of the 65816 feel like, well, downright hacks...

I'm not sure that you fully understand the '816's 16 bit capabilities. The code isn't "bolted on." The MPU has dual sized registers. The same load-store instructions are used whether a register is 8 or 16 bits wide. The program flow is actually quite easy to envision after you've worked with the '816 for a while.

Quote:
Switching from 8-bit to 16-bit mode requires two instructions and manipulating the carry bit...

Not true, as Garth pointed out. What you are referring to is the CLC-XCE sequence that places the '816 into native mode. In a native mode system (e.g., my POC unit), that happens early in the reset handler, after which the '816 stays in native mode until a hard reset occurs.

Quote:
...and you have to keep telling the assembler what mode you are in (LONGI ON). REP and SEP makes your head hurt because you have to remember which bits to set. Nothing that a bunch of assembler macros couldn't make easier to tolerate, but not exactly pretty, either.

I bury the register width changes in macros (LONGA, LONGX, SHORTA, SHORTX, LONGR and SHORTR, the latter two flipping all registers to 16 or 8 bits, respectively). It's no big deal once accustomed to it. As for whether said code is "pretty" or not, assembly language is somewhat like spoken German (apologies to André): neither is pretty, but both are efficient and succinct.

Quote:
3. The memory addressing is harder for the hobbyist to handle, mostly because data and bank lines are shared. I see the data sheet for the 65816 has some special glue logic they recommend for this.

I agree that the MUXing of A16-A23 onto the data bus (which occurs during Ø2 low, giving rise to some interesting timing matters) is a nuisance. It would have been nice for those to be brought out on separate pins. That design characteristic is a result of the desire by Apple to stay with a DIP-40 package in their hardware.

The data sheet bank latching example will work effectively with 74ABT discrete logic (which has single digit prop times). Alternatively, it can be done with a CPLD or even a couple of GALs for those who like a challenge. I've done some timing analysis of the discrete logic method and have concluded that 74AC is fast enough to support at least 15 MHz operation, faster if a two-phase clock is generated. The circuit is not at all complicated for the hobbyist to handle; just a couple of extra chips.

Quote:
After reading about BigDumbDinosaur's problems with a hardware bug ("Unlike the 65C02, the 65C816 can generate false address bus states during the intermediate steps of processing certain instructions."), my enthusiasm is dampened as well.

Why would your enthusiasm be dampened because of this? The fix was easy to implement and didn't even require adding any hardware to the board.

BigEd wrote:
I'd urge you to ignore BDD's hardware bug, or if not, then understand exactly what happened. It was a real bug, but he was interfacing to an unpleasant chip and happened to use a troublesome addressing mode. I'm sure it was frustrating and of course it had to be fixed, but I think he over-reacted.

It was a design bug on my part, not a failing of the '816. Nor did I "over-react" to it, and I'm not quite ready to characterize the 2692 DUART as "unpleasant" (it wasn't designed to work with a 6502-type bus—I expected that my adaptation would run into problems, but this particular problem was one that I wasn't expecting). I merely identified and fixed the problem, and thoroughly documented it for the edification of others who might choose to use the '816 in a new design (the '816 has two outputs that tell you when the MPU is emitting a valid address—ignore them at your own peril). The issue of false address bus states is not unique to the '816, nor is anomalous behavior solely an '816 matter. The NMOS 6502 will generate double writes on R-M-W cycles that are potentially much more difficult to deal with, especially if applied to hardware registers.

Quote:
Now, am I being unfair to the 65816 and missing something? Or is this just a chip that could have been designed a whole lot better? And while we are at it, it doesn't seem that there is a good 16-bit CPU out there for hobbyists at all, at least for assembly programming fun.

Programming the '816 is fun. As Garth pointed out, the ability to perform 16 bit operations greatly increases performance, all the while reducing total code. The machine code monitor in my POC's firmware makes extensive use of 16 bit operations, and also uses the very handy MVN and MVP instructions for memory copies and fills. The stack addressing instructions proved to be indispensable in the low-level SCSI driver code—the IRQ handler can easily vector the driver's foreground code according to the bus state by simple read/write operations to the stack. Sure I could have done it on a 65C02, but the result would have been bigger and substantially slower code.

I currently am not implementing the bank address function, so my design is limited to a 64K address space. That is the only '816 feature that I haven't taken advantage of.

BTW, my SBC website is not complete, so there is some information that you may not yet know. I've been very busy with revenue work the last several months and haven't had much time to fool around with my toys. POC V1.1 is running on my desk, periodically doing read-write ops to the hard drive and just marking time. Current uptime is $0065083D (6,621,245) seconds, or 76 days, 15 hours, 13 minutes and 58.08 seconds (timekeeping has a 10 millisecond resolution).

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


Last edited by BigDumbDinosaur on Thu Apr 15, 2021 8:26 am, edited 1 time in total.

Top
 Profile  
Reply with quote  
PostPosted: Sun Feb 10, 2013 7:40 am 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10985
Location: England
Thanks for the photo WF!
It led me to some info: I've started this new thread.
Cheers
Ed


Top
 Profile  
Reply with quote  
PostPosted: Sun Feb 10, 2013 9:34 am 
Offline
User avatar

Joined: Fri Dec 11, 2009 3:50 pm
Posts: 3367
Location: Ontario, Canada
scotws wrote:
The memory addressing is harder for the hobbyist to handle[/b], mostly because data and bank lines are shared. I see the data sheet for the 65816 has some special glue logic they recommend for this.
The shared data and bank address lines now have a thread of their own, here.

Quote:
After reading about BigDumbDinosaur's problems with a hardware bug ("Unlike the 65C02, the 65C816 can generate false address bus states during the intermediate steps of processing certain instructions."), my enthusiasm is dampened as well.
Yes, the 65C816 can generate false addresses. That's a problem that existed on the NMOS '02 and was fixed on the 'C02. I guess maybe it's easy to get blind-sided by this, but the fix on the '816 takes a different form, namely the VDA signal (which is unique to the '816). The data sheet states,
Quote:
2.26 Valid Data Address (VDA) and Valid Program Address (VPA)
The Valid Data Address and Valid Program Address output signals indicate valid memory addresses when high and are used for memory or I/O address qualification.
So they do tell ya, but you really need to use your eagle eyes when reading the doc! So it's good to mention this issue. But, as BDD says,
Quote:
Why would your enthusiasm be dampened because of this? The fix was easy to implement and didn't even require adding any hardware to the board.

cheers.
Jeff
ps- thanks, White Flame, for posting the SuperCPU photo!

_________________
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  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 84 posts ]  Go to page 1, 2, 3, 4, 5, 6  Next

All times are UTC


Who is online

Users browsing this forum: No registered users and 12 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: