My project with a w65c265s MCU.

[BigDumbDinosaur]

tokafondo wrote:

But that cross banking issue should not be a proble with a 16 bit addressing space, should it? The MCU just write bytes to an memory address and that is... "linear address space" should stand for that: no banking at all.

It's that, or I just don't have any clue of how the '816 memory model works?

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.

[tokafondo]

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.

Code: Select all

CSEL  MEM RANGE  MCU LINES:  A18 A17 A16 A15 A14 A13
====  =========  ===================================
RAM1    000000                0   0   0   0   0   0
       -00DFFF                0   0   0   1   1   0

ROM     00E000                0   0   0   1   1   1
       -02DFFF                0   1   0   1   1   0

FRAM    02E000                0   1   0   1   1   1
       -04DFFF                1   0   0   1   1   0

RAM1    04E000                1   0   0   1   1   1
       -05FFFF                1   0   1   1   1   1

RAM2    060000                1   1   0   0   0   0
       -07FFFF                1   1   1   1   1   1

[GARTHWILSON]

tokafondo wrote:

But that cross banking issue should not be a proble with a 16 bit addressing space, should it? The MCU just write bytes to an memory address and that is... "linear address space" should stand for that: no banking at all.

Long addressing (that is, when you use a three-byte address) has no regard for bank boundaries or bank registers. However, addressing that is neither long, nor stack, nor direct-page, works in the previously selected bank, pointed to by the appropriate bank (data or program) register. If everything required long addressing, code size would become larger and performance would be degraded somewhat. It would also reduce the flexibility of loading various programs into whatever bank(s) are available at load time. It's another thing like 16-bit absolute versus zero page (or even 8-bit relative branch addresses) on the 6502, where the shorter one saves memory and execution time when it's practical to use. The secret then is to make banking to work for you rather than against you.

I might add a bit to what BDD said:

BigDumbDinosaur wrote:

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.

The MVN and MVP instructions (which can also be used to do a fill, not just a move) do up to 64KB each time one is called. There's a little overhead to set it up which takes a minor amount of execution time compared to the time to move thousands of bytes. If you need to move a section that spans bank boundaries, you just do it in pieces, which again presents only minor additional overhead. You could instead set up a loop that increments 24-bit pointers in direct page, and it might appear simpler, but it would not execute as fast.

If I'm forgetting something, BDD, Dr Jefyll, or someone else who has used or studied the '816 more than I can correct me.

[BigDumbDinosaur]

GARTHWILSON wrote:

If I'm forgetting something, BDD, Dr Jefyll, or someone else who has used or studied the '816 more than I can correct me.

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.

[barrym95838]

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.

[drogon]

tokafondo wrote:

drogon wrote:

Here is something to think about... If your screen memory needs 120,000 bytes, then the fastest you can clear it in software would be to use the block move instruction (ie. MVN). This moves one byte every 7 cycles. 120,000 * 7 = 840000 cycles, at 8Mhz is about 1/10th of a second. So that's a baseline for clearing the screen or software scrolling. A slight thorn in the side is that 120KB of RAM will span 2 x 64KB banks in the '816/'265 address space, so drawing a line from one corner to the other will cross a bank - as will moving a sprite. I think at that point things would get complex enough for me to simply give-up and move to a plan B for video. (which I have done)

.

But that cross banking issue should not be a proble with a 16 bit addressing space, should it? The MCU just write bytes to an memory address and that is... "linear address space" should stand for that: no banking at all.

It's that, or I just don't have any clue of how the '816 memory model works?

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

[BitWise]

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.

[BigDumbDinosaur]

drogon wrote:

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.

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.

[tokafondo]

BitWise wrote:

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

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

[floobydust]

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.

[BitWise]

floobydust wrote:

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.

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.

[tokafondo]

BitWise wrote:

floobydust wrote:

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.

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.

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:

Code: Select all

The “XBus816” is a 50-pinmale connector with the following signals:
- 8 DataBus lines (D0-D7)
- 24 AddressBus lines (A0-A15; 64 Kbyte space)
- 3 External Chip Select Lines for expansion (XCS0B-XCS2B)
- 9 Control lines (PHI2, RWB, BE, VDA, VPA, MLB, RESB, NMIB, IRQB, VPB)
- 4 Power and Ground - 2xVSS(Pins 2 and 49) and 2x VDD (Pins 1 and 50)

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

[Chromatix]

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.

[floobydust]

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.

[tokafondo]

floobydust wrote:

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.

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?