Thanks, Steve. Let me double-check that I understand. You are saying that the memory-mapped registers appear

• anytime A15-A0 equal $0000 or $0001
• the four-bit bank-select address is irrelevant, and
• it is irrelevant whether the $0000 or $0001 on A15-A0 was generated by (Ind),Y address mode or by some other address mode

If you can confirm this or else offer clarification I'd appreciate it. Also, what about Zero Page and the Stack? Do they change banks when the Code Bank changes, or does the 6509 always divert Z-Pg and Stack references to Bank 0?

cheers,

Jeff

Interesting stuff! I find two likely-looking articles in transactor by Jim Butterfield:
The C128 - You can bank on it July 86, Vol7, issue 1, p34 (pdf) also here on scribd
The Commodore 128 - Banking on the Turns Jan 87, vol 7, Issue 4 (pdf) also here on scribd
(Edit: wrong articles, wrong machine - see downthread.)

My guess would be that the on-chip registers would appear in all banks and both 'modes'. Note that the banks as known to the OS on the C128 are mapped by the MMU, so they are complex memory maps which do seem to carry the zero page and stack with them into every bank, as well as the MMU itself. The CPU only knows about the four extra pins P0..P3.

I agree with Jeff, that Toshi is right to suggest the '816 for a quick self-contained way to exceed the 64k limit, but for an interesting project making a 6509 workalike is promising. There's no need to limit to 4 bits of bank address either. You do need to count from the SYNC to the final cycle of the two affected opcodes though, discounting RDY stalls, so it isn't trivial.

What I like about the 6509 approach is that it's minimal. It doesn't introduce 3-byte pointers and it could leave most existing code unchanged running in a single 64k bank. Only long-distance data accesses need be affected, which is ideal for an interpreted language or for data storage/retrieval (like photoframes.)

(Let's not forget Acorn's in-house Turbo machine, which did use 3-byte pointers, placing the high byte in page 03. This was built using discrete components around an existing CPU, so could be done again.)

Cheers
Ed

(Yup, the '816 looks more straightforward, and also easier, to design around so it can be run at up to its max. clock speed; "hacking" an '02 with external logic would likely impose limits on performance.)

And another possible solution might be to use one of the FPGA-type 6502 cores, adding the extra logic in at that stage; this way, it should be easier to "tap into" the internal control signals, making the decoding more straightforward.

(FPGA'ing a CBM-II might be an idea for a project, especially as similar projects are underway for the PET and BBC Micro.)

--Martin

_________________
Martin Penny

.sig in beta - full release to follow.

This is from memory, so hopefully I remember...

There is no separate MMU chip in the CBM-II machines. All this is handled in the 6509 CPU. Any write, no matter how to $00 and $01 affect the CPU registers, from any write instruction, from any bank. These registers are 4 bits each for 16 banks or 1MB address space. Think of the 16 banks of 64K stacked on top of each other. On reset both $00 and $01 are set to $FF (well, $0F since there are only 4 bits). Register $00 is the "execution" register. This is the bank that is running the code. Any write to $00 immediately changes the BANK, but not the address counter, so code execution just keeps going but in a different bank, which means code must be syncronized. The $01 register is the "indirect" register, which determines which bank is used for memory reads and writes using the 'indirect indexed' instructions. Each bank (with memory in it) has it's own zero page and stack. There are special "transfer" routines in the kernal for calling BANK 15 Kernal routines from another bank.

Jim B's article "B500 Machine Language Transfer Sequences" can be found in Transactor, July 1983. If requested I can make this available on my CBM-II page.

Steve

Disclaimer: I haven't programmed in 6509 code for many years.

PS: Count me in for a CBM-II emulator in FPGA!!!!

Ah, thanks for the correction (I had the wrong machine and so found the wrong articles)

The right article then is on page 60 of the pdf found here.

Cheers
Ed

Thanks, Steve. I think this reveals the 6509 is not a specially designed CPU -- instead it's just a sidecar hung on the 6502 (sort of like the 2A03, which uses a stock 6502 mask but with a bit of extra logic added around the perimeter). Here is my version of add-on logic for a 6509 look-alike. If my understanding of the 6509 is correct, then this circuit, connected to a 6502, should reproduce 6509 behavior. [Edit: confirmed -- see subsequent posts.]



I drew this with 6502 in mind but offhand see no reason it wouldn't be OK for the 'C02 or even the '816. The circuit detects the opcode fetch of the two modified 6509 instructions, STA (Ind),Y and LDA (Ind),Y (op-codes $91 and $B1). The data access occurs later -- either during in cycle 5 or 6. It'll be cycle 5 only if the access is a read and no page crossing occurs, as per normal 6502 behavior. During cycle 5 (and cycle 6, if it's present) the Indirect memory bank is selected by the 74_157 mux. If it's a read with no page crossing, cycle 6 will be absent, as per normal 6502 behavior. In that case the circuit uses SYNC to ensure it'll be the Execution bank that's selected for the opcode fetch in the cycle which follows cycle 5.
Note:

• I haven't bothered to draw the output port logic that provides the two bank addresses.
• the '377 is an octal, edge-triggered register similar to '374 or '574, but clocking with /EN high ignores the new input data on D and reloads the data already on Q. IE: the output remains unchanged.
• The XOR gate protects against the false opcode fetch that occurs whenever an interrupt is recognized. There's a risk that a $91 or $B1 opcode will get fetched but not executed. If this happens the circuit mustn't respond. To recognize the beginning of the cpu's interrupt sequence we look for the unique circumstance of the address bus failing to increment in the cycle following an opcode fetch. No increment means the least-significant address line, A0, will fail to toggle. The output of the XOR gate will be low, thus inhibiting the circuit.
• To simplify the circuit D1 could be ignored (like D5). This would render the circuit susceptible to triggering from opcodes $93 and $B3, but these are undefined op's anyway.

Right, Martin -- certainly that's a legitimate concern for this circuit (in its present form). For example in some situations there'll be no valid bank address until SYNC has had time to propagate into the mux. At NMOS CPU speeds that's a fairly trivial delay, but for a modern 'C02 running at, say, 14 MHz, it's much more of an issue. Hmmm.... For the '816 you could make use of VPA and VDA signals, which would inform you in cycle 5 whether there's a page crossing. Having that advance notice means you could use fully synchronous logic and eliminate the performance limit. IOW you could 6509-ify an '816 and run it at the full 14 Mhz.

The FPGA approach is attractive too, of course. (I mean with the cpu core implemented on FPGA.) The add-on approach could be abandoned for something more elegant and resource-efficient!

Since the goal seems to be to run pre-existing CBM-II code, the question arises whether the FPGA core would have to accurately reproduce undefined 6502 op's. Do CBM-II applications use illegal instructions?! (This issue would also affect the 'C02 and '816 add-on look-alikes.)

-- Jeff

Edits: Fix typo. Improve clarity. Fix booboo: '377 register, not '273.
Edit (2018): Improve clarity. Fix booboo: the Enable on a '377 is active low, not active high. The updated diagram reflects this. Also, the original logic (shown below) unnecessarily imposed two gate delays between SYNC and the mux.

Excellent! About the speed concern: wrapping all this glue, including the two ports, into a CPLD, is a possible answer. I haven't counted up the required pins though. An off the shelf CPU plus a CPLD is a useful step, short of going for a custom CPU on an FPGA. And for this level of complexity it's natural to design with schematics, so no particular need to learn an HDL.

That said, the same design could readily be combined with an existing 6502 core in an FPGA.

Cheers
Ed

Excellent work indeed!



That was my initial concern but you have handled that as well! Great work! Only one question: Have you run that through visual 6502 that there is a cycle where PC is not incremented before the IRQ handling starts? Otherwise assume the opcode is on an odd address, the IRQ kicks in, and then what happens in the two "internal operations" cycle, maybe it does actually increase PC? I couldn't find this on a quick search...

André

Right, then! If that goofy kludge makes sense to you guys then I know I'm not completely crazy! (Or, if I am, at least I have some company.)

Quite right. Our add-on logic needn't be limited to 1 MB (4 extra address bits). We can easily go as high as 16MB (8 extra bits) -- or even higher if we find a way to map in wider ports.

Actually I'm disappointed to learn that the 6509 is so primitive. On the one hand it is better than conventional mapping schemes that deal in, say, 8K or 16K chunks. (These clever but constricting schemes seem to be by far the most widely adopted means of beating the 64K barrier.)

On the other hand, the 6509 falls short of what it could have been. Because it maps the ports to $0000 and $0001 of every bank, the 6509 is incapable of hosting an array or other object greater than 64K-2 in size. IMO this limits you to small-computer goals, in contrast to the '816 and and my Kimklone which let you accommodate and linearly address any object that'll fit in memory.


The lack of PC incrementing during interrupt recognition is documented on page A-11, Table A. 5.4 of the MOS Hardware Manual and in Table 5-7 of the '816 Data Sheet. There's an old and somewhat fragmented 6502.org discussion of the topic here. See also the visual6502.org/wiki/ page here.

cheers,

Jeff
[edited to include Ed's comment and the link to the visual6502.org wiki page]

Nice! 6509's are in very short supply... Anyone willing to build and test?!

Steve

Still curious about this point. If we don't need to preserve the illegal op's then the '816 may be better than an '02 in regard to creating a 6509 substitute using add-on logic.

Steve, is your Rogers email working properly? I haven't heard back from a msg I sent you on Friday. Maybe you're just enjoying the holiday...

Jeff

Holidays have been crazy... Sorry, I seemed to have missed your email.
Things have settled down now, thankfully.

Btw, I'd be surprised if any cbmii software used illegal opcodes, simply because there's so little software for the machines.

Steve

Sorry for resurrecting a long ago thread, but I created a PCB for a 6509 Replacement:




I am considering building a few test boards, if someone is interested in testing.

Jim

I can't read what is in your images.

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

Thanks Jim, that's a very interesting development!