Although the 65C816 can easily cross banks by using long indirect addressing ([<dp>],Y), the most that can be indexed at a time is 64KB. This is a limit established by the 16-bit width of the index registers. If the operation has to touch more than 64K then each time .Y rolls over the most significant byte of the 24-bit direct page address must be incremented.

The MVN and MVP instructions cannot increment the bank if indexing takes the source or destination to a bank boundary. For copies that span banks you have to do it "manually" with load/store instructions.

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

WIP: Considering the Amtel/Microchip ATF750C-7PX CPLD as the Address decoder.

This is the logic I've setup, I think could reduce the basic memory setup to just four chips: RAM1, EEPROM, FASTRAM and RAM2. I would use two 128Kx8 chips for the whole RAM.

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

You pretty much covered it.

[<dp>],Y takes 6 cycles if the accumulator is set to 8 bits or 7 cycles if set to 16 bits. Since a load followed by a store would have to be used, the execution time is either 12 or 14 cycles per byte, plus the loop overhead. Disregarding the setup preamble for MVN and MVP, those instructions copy data at more than twice the speed of conventional load/store copying, even if the loads and stores are with 16-bit addresses. If copying is really time-critical, IRQs can be disabled, which helps with MVN and MVP, as both instructions are interruptible.

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

I'll start off by saying that I'm not a big fan of the '816 engine, but you needn't be too discouraged by some of its inherent "bankiness". You can take a minor but noticeable speed- and code- penalty and use 24-bit addressing for your screen buffer activities (long-absolute and long-indirect) instead of trying to trick the faster 16-bit address modes and instructions into doing what you want ... many of the 8-bit index register idioms to deal with a 16-bit address space should still be applicable when you have 16-bit index registers and are dealing with a 24-bit address space. I think I would end up with a migraine trying to do so, but I'm not you, so it would be foolish of me to attempt to discourage you.

I wish you the best of luck, and would enjoy hearing of your progress in the software/firmware area, after you get the hardware up and running.

_________________
Got a kilobyte lying fallow in your 65xx's memory map? Sprinkle some VTL02C on it and see how it grows on you!

Mike B. (about me) (learning how to github)

You may need to do more reading about the '816.

The memory is 8 bits wide and the address bus is (effectively) 24 bits wide and it is linear however it's split from the CPU side into banks of 64KB each.

The index registers are 16 bits wide and there are separate data and program bank registers. There are instructions that let you do a direct 24-bit load/store and jump, but unless you use self-modifying code, you can't index with them. You might typically load the data bank register, then do the load/store, then more load/stores until you reach the next bank, then update the data bank register, reset the index register(s) and carry on. It's only "easy" when you stick to one bank.

Your video-generator side doesn't need to see this though - you can give it a 17-bit wide address register, it's just the '816 code that needs to be aware of it, but go back to the timings - you have a retro CPU in terms of ability and clock speed and you're trying to make it manipulate a quantity of memory that's far more than we ever dreamed of in the late 70's/early 80's. When we did progress to more colours and higher resolutions, we also had faster and more capable CPUs and hardware assist ('blitter' and the like) started to be a thing.

If you could keep to one bank, then your resolution or number of colours becomes reduced - 8 bits per pixel would limit you to about 320*200 pixel resolution which is usable - to give 40x25 characters. you could increase that to get to 320*240 if you went to 4 bits per pixel, but then your code needs to do read/modify/write for ever pixel written. It's always a compromise somewhere...

Cheers,

-Gordon


-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

If you haven't worked with a '816 processor before then I'd recommend getting a W65C265SXB board from WDC via Tindie and having a play.

https://www.tindie.com/products/wdc/w65c265sxb/

The board breaks out all the I/O pins to port connectors and the 50 pin XBUS connector gives you the address & data busses, chip selects and required control signals to drive external memory. If you fit a flash EEPROM you can write a replacement boot ROM.

Its well worth the current (as of April 2020) $48.16 price tag -- half what I paid for mine a couple of years ago.

_________________
Andrew Jacobs
6502 & PIC Stuff - http://www.obelisk.me.uk/
Cross-Platform 6502/65C02/65816 Macro Assembler - http://www.obelisk.me.uk/dev65/
Open Source Projects - https://github.com/andrew-jacobs

Just to clarify:

• The registers can be 8- or 16-bits wide. Use of 16-bit index registers allows a program to perform loads and stores on a maximum of 64KB via the indexed addressing modes without having to alter the base address. Indexing can cross bank boundaries, which means loads and stores can treat the 16MB address space as linear. For example, LDA $BBFFFF,X will load from $BC0000 if .X is $01.
  
  
• A load or store can touch anywhere in the 16MB address space by either explicitly setting DB (data bank register) to any desired bank and using a 16-bit address (with optional indexing) or by ignoring DB and using a 24-bit address (with optional indexing). The choice depends on how random accesses will be. If most will be in a single bank, the former method will produce somewhat faster code.
  
  
• The direct page indirect long, [<dp>], and direct page indirect long postindexed, [<dp>],Y, addressing modes give load/store access to the entire 16MB address space. No self-modifying code is required, only a 24-bit address on direct page, which, of course, can be computed at run-time. If .Y rolls over you merely increment the most significant byte of the address at location <dp> and keep going. It's actually quite easy.

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

I almost did it but with a QBX aka Mensch microcomputer. But I didn't like the <4mhz clock in both designs, but I liked the 265 MCU because of having more things included than the bare 816, even with more exposed address pins.

So I cancelled the WDC order and got a bare 265 MCU from Coltek.

https://twitter.com/dandolavara/status/ ... 2905060358

Perhaps purchasing the WDC W65C816SXB would be a better option. It's now priced at $68.16. The core chips are all socketed, which are 2- W65C22, 1- W65C21, 1-W65C51, 1- W65C816 and the SST 128KB EEPROM. These chips alone would cost about $45 plus shipping. Once you spend some time with the SBC, you can then pull the chips and build what you want at a reduced cost.

Up front, you have a fully functional to get started with running at 8MHz.

_________________
Regards, KM
https://github.com/floobydust

Yes, its faster and you could extend it using the XBUS connector BUT at least initially you have to work with the WDC tools to download code into it and you are stuck with less than 32K of RAM in the first bank.

In my experience its harder to work with than the W65C265SXB.

_________________
Andrew Jacobs
6502 & PIC Stuff - http://www.obelisk.me.uk/
Cross-Platform 6502/65C02/65816 Macro Assembler - http://www.obelisk.me.uk/dev65/
Open Source Projects - https://github.com/andrew-jacobs

I actually studied all the datasheets and found in the 816SXB's a contradiction: the 50 pin connector has lines A17-A23 connected to... ???

Because the specs are:



"24 AddressBus lines (A0-A15; 64 Kbyte space)" ??? So... 16MB not possible?

It wouldn't be the first time a WDC datasheet had a careless error in it. I'd hazard a guess that if A16..23 are present, they will carry the corresponding address signals.

Well, looking at the (W65C816SXB) schematic confirms that all 24 address lines are available on the bus connector pins 11 thru 34. When in doubt, check the schematic. In some cases, WDC documentation is shared, meaning, they likely started with the 65C02 based SXB and modified it for the 65C816 SXB. At one point, they had some pin designations showing on the wrong connector.... I think Bitwise found this one initially.

_________________
Regards, KM
https://github.com/floobydust

Yes I found that, but as the schematic itself refers to the w65c816 MPU itself, and it does not have the full 24 bits of address bus exposed, then I should believe then that addressing external memory in the '816SXB board should include a demultiplexer along with the rest of the memory itseld, shouldn't it?