Some time ago I started writing a C64 emulator from scratch for Android.

Recently I came to the point where I need to implement the C64 bank switching within the emulator.

This exercise tickled the following within me: Does anybody have some interesting articles on why designers decided to implement bank switching in the way they did?

Bank switching is implemented using the lower three bits of memory location 1. However, very weird combinations of these three bits are used for enabling the various blocks. So much so that the C64 designers had to design a custom chip for these combinations.

Is there any reason why they did it this way instead of just dedicating a bit per block?

If I remember it right, this

http://skoe.de/docs/c64-dissected/pla/c64_pla_dissected_a4ss.pdf

explains how the PLA works and by this gives a clue why it was done like it's done. (Ability to plug in modules,...)

Thanks for the link. Very informative article

To be pedantic about it (something for which I'm infamous), what is going on is not "bank switching."

In the eight bit world, especially that of the 6502 family, the term "bank" generally refers to large extents of RAM (or, less so, ROM) that lie beyond the normal 6502 addressing range of $0000-$FFFF. For example, in the Commodore C-128, which really does have 128KB of RAM (lots of DRAMs in there), there are two banks, numbered $0 and $1. That was also true of the Commodore B-128, whose MPU, the 6509, did indeed do banking, albeit in a weird fashion.

Even the 65C816, which can directly address 16 MB, refers to each 64KB piece of that 16 MB space as a "bank"—there are potentially 256 of them. My POC V2 unit has 1 MB of RAM, which means it has 16 banks, addressable from $00xxxx-$0Fxxxx. The register that tells the '816 from which bank to retrieve program code is PB, the program bank register. The content of PB is concatenated to the program counter (PC) during an opcode or operand fetch, forming a full 24 bit address. So if PB contains $0C and PC contains $1234, and the '816 is getting ready to fetch an opcode, the opcode will come from $0C1234.

Something similar happens with DB, the 65C816's data bank register. If the address operand for a load/store instruction is 16 bits, as in LDA $1234, the content of DB is concatenated to the $1234 address to form a 24 bit address from which the data will be loaded. So if DB contains $56 and the 16 bit address is $1234, the data will come from $561234.

In both cases, what is happening is banking. The '816 selects a particular memory bank—a 64KB range—and then reads or writes on a particular address within that range.

What is going on in the C-64 is "memory mapping," which makes RAM, ROM or I/O appear at the same address in a mutual exclusive fashion. For example, one can make the BASIC ROM appear at $A000-$BFFF, the power-on default, or RAM. A similar thing can be done with the E-ROM, which contains the final extent of BASIC, as well as the kernel ("Kernal"). Plugging in a cartridge may cause /GAME and/or /EXROM to be asserted, causing the cartridge to replace RAM at $8000 or $E000 with cartridge RAM or ROM (the technique used in the Xetec Lt. Kernal hard drive subsystem's host adapter to make the DOS run in the same address space as user programs). It's just memory mapping, not bank switching, even though Commodore themselves occasionally referred to "banking in" or "banking out" different things within the 64KB address space when they should have said "mapped in" or "mapped out."

Incidentally, the PLA that was used in the C-64 to carry out the memory mapping features was an off-the-shelf part, not anything special. All Commodore did was program it to suit their requirements. A number of replacements schemes for this PLA have been devised in order to revive dead C-64s. This PLA has a 20 year data retention life, which means it was possible that it would simply forget what was burned into it, causing the computer to cease operation—a common occurrence with the C-64.

Almost anything programmable is potentially subject to the same failure, including modern E(E)PROMs, CPLDs and GALs. For example, Atmel's data sheet for the ATF150x series of CPLDs says these parts have a guaranteed 20 year data retention capability. That means that 19 years from now I had better refresh the code in the ATF1504AS in my POC V2 unit, as well as in the EPROM. I'll be sure to do that if I'm still around at that time and playing with this stuff—I'll be 90 by then.

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

It's not a bit per block, because as mentioned above, there's more than 1 thing going on per memory region. Some of the modes even un-map memory, to emulate smaller gaming configurations.

The C64's PLA still allows you to write RAM underneath ROM while the ROM is mapped in, which true banking would prevent. This arrangement is useful for write-only graphics areas, and decompression/initialization.

I don't recall if the VIC-II depends on the PLA to address the bus (I know the CIA controls the 16KB (true) bank switching), but that offers another parallel view of the memory configuration that needs to be maintained in combination with the CPU's view.

(Also of note is the fact that the C= engineers didn't really believe the mess that was being built would ever work. It was a quickly and cheaply built patchwork of electronics with no elegant overall design.)

_________________
WFDis Interactive 6502 Disassembler
AcheronVM: A Reconfigurable 16-bit Virtual CPU for the 6502 Microprocessor

VIC-II can adress 16kb of memory, the upper address bits VA14/15 provided by the CIA. They are routed through PLA. As far as I recall if video memory is set to an even address ($0000-3fff or $8000-bffff) PLA maps the character ROM into VIC adress space.

And I'm not sure, if PLA does more fancy things for VIC-II when game/UltiMax/... cartridges are plugged in.

Thanks for everyone's input.

Sounds like the C64 had indeed some complex memory mapping requirements.

Looks like the goal to have 64KB accessible memory an 8-bit machine cuased quite number of headaches for the Commodore Engineers at that time.

@BDD, I learned more from that than I have from just about anything else that deals with "bank switching" and the 65C816. I've been put off of the '816 because I was confused on how the bank switching worked.

You cleared up a bunch of stuff for me.

Thanks!

_________________
Cat; the other white meat.

You're welcome.

BTW, the '816 itself doesn't switch banks except under very specific circumstances, e.g., handling an interrupt. Programs cannot span banks, as PC wraps at the 64K boundary, but PB doesn't increment when PC wraps. On the other hand, indexed addressing modes smoothly span banks, allowing an arbitrary amount of memory to be treated as flat space for data purposes.

Direct page and stack accesses are automatically directed to bank $00. It's not complicated.

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

It must be worth noting that the '816 does support extended 24 bit addresses - both as long absolute addresses and as three-byte indirect addresses fetched from the direct page. Also, in indexed addressing modes it's capable of computing an address which is based in one bank and indexes into the next.

When using those ideas, it might be easier to think of it as a 24 bit addressed machine rather than as a 16 bit addressed machine with a banking mechanism.

The other machines mentioned don't do this, I think - they really do have a 16 bit address space with a preselected configuration to use one bank or another.

In all these cases the implementation is messy enough that you have to understand what's going on - there's no clean abstraction.

That's correct. For all intents and purposes, data load/store operations in the '816 can be treated as working on a 24 bit flat space. Using the "long" indirect addressing modes, e.g., LDA [<dp>],Y, the full range of available RAM can be readily touched when the index registers are set to 16 bits.

That said, 24 bit addressing in any form is somewhat slower than 16 bit addressing. There are operations in which the little bit of overhead required to set and restore DB is minuscule compared to the improvement in execution speed achieved with 16 bit addressing. In my 65C816 interrupts article, I discuss this:

Any 24 bit access, such as LDA $AB1234,X, will incur a one clock cycle penalty as compared to the same instruction using a 16 bit access, such as LDA $1234,X. If it is necessary to perform multiple successive "long" operations, a performance gain can usually be realized by temporarily setting DB to the target bank, using 16 bit accesses on the target locations and then restoring DB. For example, consider code that increments five bytes in bank $AB. The first routine uses 24 bit loads and stores:


Code:
             sep #%00100000        ;8 bit accumulator
             ldx #4                ;modifying 5 locations
    ;
    loop     lda $ab1234,x         ;load
             inc a                 ;increment
             sta $ab1234,x         ;store
             dex
             bpl loop              ;next
    ;
             ...program continues...

Performance suffers where performance matters the most: in the read-modify-write loop. Two 24 bit accesses plus the INC A instruction are required to make up for the lack of an equivalent 24 bit read-modify-write operation—unfortunately, INC $AB1234,X isn't in the 65C816's instruction set.

Now consider the following code, which temporarily changes DB to accomplish the same task:


Code:
             phb                   ;save current data bank
             sep #%00110000        ;8 bit registers
             lda #$ab              ;target bank
             pha                   ;push it to the stack & pull it...
             plb                   ;into DB, making it the default bank
             ldx #4                ;modifying 5 locations
    ;
    loop     inc $1234,x           ;effectively INC $AB1234,X
             dex
             bpl loop              ;next
    ;
             plb                   ;restore previous bank
;
             ...program continues...

Although the above version looks larger and slower than the previous version, it is slightly smaller and substantially faster in the loop because a single R-M-W instruction with 16 bit addressing accomplishes what three separate instructions accomplish with 24 bit addressing in the first version. Consider that the extra clock cycle penalty of a 24 bit access is avoided twice per loop iteration. Even though some additional instructions are needed to change and restore DB, overall execution time is significantly shorter.

It all comes down to a judgment call on the part of the programmer.

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

Where is this article? This is some good stuff!

_________________
Cat; the other white meat.

This one, I think:
http://www.6502.org/tutorials/65c816interrupts.html

Edit: You might also find Bruce's '816 tutorial useful:
http://www.6502.org/tutorials/65c816opcodes.html

Awesome. Thanks!

_________________
Cat; the other white meat.

This version is more up-to-date than the version posted here.

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