Hi

I am looking into using the 6509 and its built-in 4-bit MMU for some experimental work. I have made a 65C02 expansion with paging, but the direct way of changing SRAM memory bank represent a problem in moving memory. Let me explain:

Standard 6502 with 64KB:

$0000-$FFFF SRAM or ROM or a combination of both. All programs and chipset addressing runs within this area. Easy access for the MPU. No pages so PC remains were it should.


"My" 65C02 implementation (with 6502 multiplexed as a dual-processor system):

page 1: $0000-$FFFF SRAM or ROM for the 6502 and 65C02. ROM is only viewable for the 6502, full SRAM area for the 65C02.
page 2: $10000-$1FFFF SRAM for both 6502 and 65C02
and so on..

Paging is done with a 74133 NAND, 74138 mux and 7474 flip-flop. STA or LDA to $FFEx will change pages (databus not involved). It means that the MPU suddenly finds itself within a different SRAM page and that both code and data must be there. The PC will remain.
I also looked at the single-cycle implementation here which was impressive. Might use that in the future.


6509 paging

Same as above, but $0000 and $0001 are used to set the 4-bit paging address lines (first 4 bits). Up to 16 pages of 64KB for a total of 1MB. Register $0000 is the code page (the page at which the code is located) and the $0001 register is the data page (from which page the data is manipulated). That works, but it means that one needs to write to $0000 and $0001.


"My" page solution obviously wont work with a single MPU since there is no way to move data over pages without having code there in the start. A quick solution would be to reserve a small area that is non-paged for pointers and data. E.g.:

$0000-$00FF Non-paged SRAM, $0100-$FFFF Paged SRAM

In such a case, moving data between pages can be done by a small code segment in Zero page (even with the single-cycle solution).


Now, the 6509 way of doing things is a little more sexy since one can have code running in one page and access memory in another page. I was thinking that this might be possible to do on a 65C02 as well. My question is whether anyone here has looked into that before. I am thinking that maybe it could even be combined with a single-cycle NOP ($x3) to get both code and data access?

(From a previous discussion, a clarification (for those not already familiar with 6509):

So, if only two opcodes are affected, the code/data distinction is not quite what one might have thought - it's not a matter of distinguishing fetches from other accesses, for example.
)

Interesting! I missed the fact that there were only two instructions affected by the data register which is a limitation. I still don't understand how you are supposed to get data into another zero-page to use those instructions thus (since they are indirect LDA/STA and you basically need to store the zp pointer there before you can use them). Anyway it probably makes for fetching data from other pages/banks more straight-forward.

As I only have a handful of 6509 (and unlikely to find more) I also want to look into a 65C02 page/bank implementation on the longer term. I like the $x3 NOP single-cycle bank switch, which can be used in a number of ways. I was thinking of using a $x3 to JMP replacement scheme (e.g. intercept the $x3 and put a $4c there, with two cycles of bank-switch delay). But compared to the 6509 that is only going to give me a way of doing direct jump to any page. But it would make for a better scheme than only using $x3 to switch banks since the PC would require a program to be at the exact same place once the flipflot switches to another SRAM bank.

Another more 6509-like way would be to use $x3 as a pre-opcode bank switch. For example:



Would mean that bank/page $1 should be used for LDA and page/bank $2 for STA. E.g. for a 20-bit address:


Without the $x3 precode it would run as usual, so full backward compability. For a permanent bank/page switch I would have used JMP (as explained above) with $x3 as precode.

Or maybe there is a better way which is less complicated..

I think you may have missed something: the 6509's two special opcodes will only use the 'data' bank for the single final access - so the zero page pointer remains in the 'code' bank. So there's no problem updating it.

Here's are some general points I wrote a while ago:


So, it might be worth sketching out how you might use the large amounts of memory you want to make available - where code goes, where data goes, and so on.

But then, yes, some simple hardware which does the job using an off-the-shelf '02, that does seem an attractive project. (I wrote some thoughts down here - earlier this year, but not necessarily reflecting what I'd say today!)

Thank you for pointing that out! It certainly makes more sense with only one place for zeropage for the 6509.

Using prefetch NOP codes to expand the dataspace also enables larger program space, but even more important it enables multiple stacks.

We have seen a Minix 2 implementation on the 6502, but to make one that is efficient (at multitasking) you need to expand the register space. That is were multiple stacks come into play. Thus, jumping from one bank/page into another would give you a new stack space which means that multiple processes can efficiently run on a single 6502. With 16 pages/banks one can run 16 processes efficiently!

Another implementation (of paging) would be to only set page/bank with the $x3 opcodes and let all consequent instructions use that page/bank. That might be an even better solution since one would save bytes compared to the above solution (and you could still use $x3 opcodes in front of every instruction if you want to).

The only argument against this implementation would be the limitation of 4bits for pages/banks. But the $xB opcodes can be used to extend that to 7 bits (excluding STP and WAI opcodes). That would give us 64*128=8192KB of memory space. Not too bad!

By the way: I am also looking for a spare case/cabinet for a Commodore B700 mainboard. I have a spare 6509 (never used it and looks new) if someone wants to trade.

I wouldn't design anything round the 6509. Yours may be the only one in the world for sale/trade.

Someone at vcfed.org was looking for one, I think.

Thank you for the lead! I have posted on vcfed and hopefully there is a non-working PET-II out there that needs a new board.

Well, I must admit that having a few 6509 for experimental work is one thing and using them for a product another.. The B256-80/B700 board I have is a good one for experimenting with the 6509, but then one only learns that much from a finished product.

As a first step, reconstructing the 6509 logic for the paging external to a 6502 would be interesting to a lot of CBM-II owners (that can't find a 6509 once it fails). Then finding a better logic for 6502 paging is very important to get improved memory control & expansion capabilities for 8-bit systems. Especially if you want to implement tables for integer math which requires more memory. I also like working on the 6502 and want to experiment with it.

There may be a lot of money to be made if you can build a 6509 replacement board. Or not, we're all pretty cheap!

It's one of those things I'd like to tackle if I had time. That and a 65c10, which would actually be fairly simple.

Alot of money or not, it would still be interesting to get something that is 6509-like. Maybe even replicate the whole B256-80 board with newer components and a HDMI port.

Better to build a C65 replica, maybe.

I don't recall why I didn't mention this earlier, maybe you already addressed this: A real easy way round your initial problem is to address decode out one page of RAM, which never changes. You could put a lot of context switching code in one page. I had thought about doing that once, and I planned to make zero page constant, as much as I hate putting code in zero page.

Or use page one? Thinking out loud here:

Decoding code fetches from page 1 should be relatively easy: P1_FLAG=SYNC AND ( [A8-A15]=01 ). Connect this signal to logic that forces the bank bits to be all zeroes (or all ones). You could then have small utility routines there, that are always executing out of the same bank. Other accesses to the stack that are not code execution would be unaffected.

For moving data between banks, I'm thinking there could be a bit that sets P1_FLAG high for all accesses to page 1, not just code fetches; then the same addressing logic could be used to let a utility routine could move data using LDA/PHA from source bank; PLA/STA to destination. (Just be careful not to overwrite the code.)

Qualify accesses to the flag bit, and the banking registers, with the P1_FLAG signal, and they are invisible to user code and take up no space in the memory map.


With this arrangement, you still have multiple stacks, and multiple zero pages for variable storage too. And if you have a 6509- (or KimKlone)-like mechanism that supplies the missing address bits for specifically loads/stores, they still see a linear address space, with no holes for bank switching code, ZP, or special registers.


Anything obviously wrong with this idea?

It's my opinion that putting code in page one is more problematic than page zero. Now, I understand that I don't ever really watch the stack pointer, so I probably don't use as much stack as I think I do, and I've read others claiming stack usage much less than the whole page.

But having thought about this some more, now I think page $FF would be most appropriate. Presumably the uP vectors need to be constant anyway, and putting the context switching code there would make even more sense if it happens to be interrupt-driven.

This makes for moderately easy decoding, and allows for both multiple stacks, and multiple zero pages, without complicating interrupt handling. Ideally I might complicate things and make half of $FF page RAM, to speed up context switching. Maybe...

What do you think?

The reason for using page one is precisely because that's where the stack normally lives. If the CPU is acting weird, executing code out of there, that's a fairly unique signal that can be used to control banking on a cycle-by-cycle basis without interfering with anything else. Regular stack accesses would not assert SYNC, so they'd just go to the currently active bank.

So no need to watch your stack use and reserve space for code, you still get a place to put cross-bank code without having to eat into page zero, one, or any other part of memory.


Being able to use interrupts is a good point, that would make things more difficult unless using page FF. Putting special code there would also not fragment memory further, just reserve one more page. You could use VPB on a WDC part to signal that memory accesses should go to the special bank, not sure about the details there though.


Edit: I just realized things might be a bit more difficult than I had thought. SYNC is only asserted during the first fetch, the one that grabs the opcode. That means it won't be for the other words that make up code, like immediate values, addresses, or branch offsets, so that makes the whole scheme much more complicated, or less useful. Doh!

Maybe it's possible to save the idea by latching the signal or with unimplemented opcodes.

I like using page 1 for (small amounts of) code - it's always there, always writeable, and by reading the stack pointer you can have an idea of how much is free. That it gives an extra special indication because it's so rare to fetch instructions from there is a bonus!