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

View unanswered posts | View active topics


Board index » 6502.org Users Forum » Hardware

All times are UTC




Post new topic Reply to topic  Page 1 of 1
  [ 11 posts ] 
  Previous topic | Next topic 
Author Message
Ruud
 Post subject: 65816 vs. 6502 + MMU
PostPosted: Wed Sep 16, 2020 5:18 pm 
Offline
User avatar

Joined: Fri Dec 12, 2003 7:22 am
Posts: 259
Location: Heerlen, NL
Goal: I want to build a 65xxx equipped computer on an ATX board (so it fits in a PC case) including some ISA slots so I can use various PC cards. But what 65xxx to use?

The first thought was to use the 65816 because it can handle up 16 MB of memory range, the same amount that can be handled by a 16-bits ISA slot as it has 24 address lines (forget the data lines D8..15). The 6502 cannot do that. Or can it?

In 1989 I created a small interface for my Commodore 64 to handle 8-bits ISA cards. The C64 has 512 free bytes available at its expansion port; I used "256" bytes to access a 6526 (the C64 version of the 6522) plus a mini interrupt controller and I used 256 bytes as window for the ISA cards. Address lines A0..A7 were driven by the C64. 12 I/O bits of 6526 drove the address lines A8..19. One bit told the ISA cards whether it was an I/O or memory operation. And the whole was quite fast. Copying a block of data using LDA ($aa),Y and STA ($bb),Y was hardly slower. If $aa/$aa+1 was the source in the C64 then after 256 bytes this vector had to be increased = increasing a zero page byte, a two-bytes instruction. Increasing the target address was increasing one port of the 6526, a three-bytes instruction.

Using a MMU like the 74612 made things many times more flexible: I could replace any chunk of 4 KB within 1 MB range (*) with another chunk of 4 KB. I could start up from 64 KB of ROM where writing to the ROM was writing to the I/O range and the first thing I did was rearranging things so that RAM and I/O were visible in a more normal way.
(*) with a trick I could even handle 16 MB but IMHO it was not worth the extra trouble.

The 65816 can address up to 16 MB. Nice. It can access data over the 64 KB barrier and it can perform long jumps and long subroutines. The advantage it has over the MMU: when copying data to another 64 KB segment I don't have to swap a chunk of memory inside the original 64 KB. The disadvantage: I'm stuck to a fixed I/O, RAM and ROM area. OK, the ROM can be swapped for RAM but the extra I/O and glue log is needed. And how am I going to split 4 KB off from 128 KB EPROM? Yes, a GAL does wonders in this case but still.

OK, the 65816 has more and better instructions. No problem, I could combine the 65816 (without latch) with a MMU; some advantages gained

And a little devil just told me to profit from both worlds using 74257 to combine a MMU with 65816 + latch. Being a lost soul anyway this sounds good and not that many extra parts needed.

Yet I like to hear your opinions, maybe you have other or better ideas. Many thanks in advance!

_________________
Code:
    ___
   / __|__
  / /  |_/     Groetjes, Ruud
  \ \__|_\
   \___|       URL: www.baltissen.org



Last edited by Ruud on Wed Sep 16, 2020 7:39 pm, edited 1 time in total.

Top
 Profile  
Reply with quote  
GARTHWILSON
 Post subject: Re: 65816 vs. 6502 + MMU
PostPosted: Wed Sep 16, 2020 5:59 pm 
Offline
User avatar

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8540
Location: Southern California
If you can work yourself up to the '816 I would definitely go for it. It's not just the greater address range, 16-bit data-handling capability, and improved instruction set, but also the fact that it is far better suited to relocatable code, multitasking, large stack frames, multithreading, multiprocessing, DMA, cache, and virtual memory (although I've thought very little about how a few of these might work in a system). In many situations, the code can be denser and perform much faster at a given clock rate.

_________________
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  
Ruud
 Post subject: Re: 65816 vs. 6502 + MMU
PostPosted: Wed Sep 16, 2020 7:27 pm 
Offline
User avatar

Joined: Fri Dec 12, 2003 7:22 am
Posts: 259
Location: Heerlen, NL
That's why I will listen to the little devil :)

_________________
Code:
    ___
   / __|__
  / /  |_/     Groetjes, Ruud
  \ \__|_\
   \___|       URL: www.baltissen.org
Top
 Profile  
Reply with quote  
BigDumbDinosaur
 Post subject: Re: 65816 vs. 6502 + MMU
PostPosted: Thu Sep 17, 2020 8:51 am 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8483
Location: Midwestern USA
GARTHWILSON wrote:
In many situations, the code can be denser and perform much faster at a given clock rate.

In fact, multibyte arithmetic on the 65C816, using 16-bit registers, can run as much as 60 percent faster than on the 65C02 at the same clock rate. Memory copies and fills with the '816 are as much as three times faster than on a 'C02 at the same speed if one uses the MVN and MVP block copy instructions.

From a hardware standpoint, using the 65C816 to address a large memory space will be much easier than with a 65C02 and unlike the hardware "windowing" method that has to be used with the 'C02, the '816 can touch the entire 16MB space with nothing more than indirect addressing that uses a 24-bit direct page (zero page) pointer.

The $000000-$00FFFF addressing range (referred to as bank $00) is used for direct page and stacks, and also is where the 65C816's hardware vectors are located. Hence some ROM has to always be present in that range. That also means an interrupt will ultimately result in the '816 going back to bank $00 looking for code to execute. However, in native mode there is nothing to prevent an interrupt service routine (ISR) from jumping from bank $00 to some other bank. Once in the other bank, the ISR can stay there, as a final RTI will put the '816 back into the bank in which it was executing code when the interrupt occurred.

Direct page and stack accesses are always directed to bank $00. A program can run in any bank—branches and 16-bit JMPs and JSRs cannot leave that bank. The JML and JSL (long jump and long subroutine call) instructions can go to any bank. Certain vectors have to be in bank $00. Beyond that, all fetches and stores can treat the memory space as linear.

All-in-all, the 65C816 is far more flexible than the 65C02, much faster at performing many types of operations and better at using the stack as more than just a place to put return addresses and temporarily store registers. Give it a try.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!
Top
 Profile  
Reply with quote  
GARTHWILSON
 Post subject: Re: 65816 vs. 6502 + MMU
PostPosted: Thu Sep 17, 2020 9:13 am 
Offline
User avatar

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8540
Location: Southern California
BigDumbDinosaur wrote:
In fact, multibyte arithmetic on the 65C816, using 16-bit registers, can run as much as 60 percent faster than on the 65C02 at the same clock rate.

I might go further than that. My '816 Forth runs two to three times as fast as my '02 Forth at the same clock rate. I suspect the same would be true for a lot of other high-level languages as well, as long as the '816 version is really written to take advantage of the 816's extra capabilities (rather than just running '02 code). I give an example of why at viewtopic.php?p=9705#p9705, and I could (and should) add a lot more examples there. In the 6502 stacks treatise's chapter about the 65816's added instructions and capabilities relevant to stacks, at http://wilsonminesco.com/stacks/816newinst.html, I show what code would be needed to partially synthesize some of them on a 6502. The difference in efficiency is huge. Comparisons like that could be made in many other areas, but that particular page in confined to the context of stacks.

_________________
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  
Druzyek
 Post subject: Re: 65816 vs. 6502 + MMU
PostPosted: Thu Sep 17, 2020 1:55 pm 
Offline
User avatar

Joined: Mon May 12, 2014 6:18 pm
Posts: 365
Is it easy to assign IO and ROM to bank 0 or do you still have a hole in the address space in other banks?
Top
 Profile  
Reply with quote  
BigDumbDinosaur
 Post subject: Re: 65816 vs. 6502 + MMU
PostPosted: Thu Sep 17, 2020 3:54 pm 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8483
Location: Midwestern USA
Druzyek wrote:
Is it easy to assign IO and ROM to bank 0 or do you still have a hole in the address space in other banks?

What happens in bank $00 stays in bank $00. :D

Jocosity aside, the 65C816's address space in native mode is $000000-$FFFFFF. There are no memory map "holes" unless you choose to create them in your glue logic. If, for example, you place I/O at $00C000-$00CFFF and your glue logic recognizes when the address is in bank $00, I/O will not be seen in other banks. In other words, your glue logic makes that distinction, not the '816. The address space is linear, with some exceptions.

You can make ROM and I/O appear in any bank you want, but practically speaking, some ROM needs to appear in bank $00 to provide a place for the '816 to go at reset and when an interrupt hits. As I said in an earlier reply, the interrupt service handler (ISR) doesn't have to be entirely in bank $00—a long jump into a different bank can be made. Hence other than a tiny bit of front-end code in bank $00, your ISR can be in any other bank.

Having extensively programmed the '816, I've concluded it's best to make I/O appear in bank $00. Obviously, you can make I/O appear in any bank, but the fact that direct page and the stack are "hardwired" to bank $00 means I/O will be most efficient if the hardware, drivers, buffers, queues and associated pointers are all in the same bank. If I/O hardware and data structures are scattered about in different banks then you will have to use long indirect addressing, which will be relatively slow compared to absolute or "short" (16-bit) indirect addressing, as I do in my POC units—I extensively use (<dp>,X) to access hardware registers.

In passing, I should note that while a reasonably capable '816 system with extended memory can be built using only discrete logic, programmable logic definitely makes it easier.

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


Last edited by BigDumbDinosaur on Thu Sep 17, 2020 7:21 pm, edited 1 time in total.

Top
 Profile  
Reply with quote  
BigEd
 Post subject: Re: 65816 vs. 6502 + MMU
PostPosted: Thu Sep 17, 2020 4:18 pm 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10977
Location: England
Good joke BDD! Indeed, as you must have ROM in bank 00 (at least temporarily, it seems reasonable to put all necessary ROM there. If you want acres of uninterrupted RAM to allocate freely, then use consecutive banks above 00. As noted, you do also need RAM in bank 00, but keep that for one-off usage like OS or global libraries or frame buffers. Bank 00 is special, not unlike page 0... which is slightly less special in the 816 model.

It might be an interesting idea (for a new thread) to make the minimal discrete-logic-only large-RAM '816 machine. Lazy decoding can get you quite a distance... here's a new thread.
Top
 Profile  
Reply with quote  
GARTHWILSON
 Post subject: Re: 65816 vs. 6502 + MMU
PostPosted: Thu Sep 17, 2020 7:22 pm 
Offline
User avatar

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8540
Location: Southern California
To add again to what BDD said: My interest is the larger memory is for data, and the '816 lets you have contiguous arrays as big as you want, up to the 255-bank limit (256 banks, ie, 16MB, minus bank 0 which you'll use for the direct pages, stack, vectors, ISR and system code, and probably some ROM and I/O). So if you wanted to have a contiguous array of, say, 11.6MB, you can, assuming you have enough memory installed. Indexing into an array of over 64KB has a little more software overhead, because the index registers max out out 16 bits, not 24, so it would be analogous to indexing into an array of, say 2KB on the 6502 which only has 8-bit index registers; but you can do 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  
BigDumbDinosaur
 Post subject: Re: 65816 vs. 6502 + MMU
PostPosted: Thu Sep 17, 2020 7:36 pm 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8483
Location: Midwestern USA
GARTHWILSON wrote:
Indexing into an array of over 64KB has a little more software overhead, because the index registers max out out 16 bits, not 24, so it would be analogous to indexing into an array of, say 2KB on the 6502 which only has 8-bit index registers; but you can do it.

If you use [<dp>,Y] addressing with the index registers set to 16 bits, all you have to do when .Y rolls over is to increment <dp>+2 and keep going. It's quite efficient.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!
Top
 Profile  
Reply with quote  
GARTHWILSON
 Post subject: Re: 65816 vs. 6502 + MMU
PostPosted: Thu Sep 17, 2020 7:45 pm 
Offline
User avatar

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8540
Location: Southern California
If it's in a loop of consecutive accesses, yes; but if you have to jump around, it involves slightly 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  
Display posts from previous:  Sort by  
Post new topic Reply to topic  Page 1 of 1
  [ 11 posts ] 

Board index » 6502.org Users Forum » Hardware

All times are UTC


Who is online

Users browsing this forum: No registered users and 4 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:  
6502.org is an ongoing project by Mike Naberezny and contributors.