Speculation: Wither Super Banking?

[richardc64]

Some documentation refers to bits 6/7 of the relevant MMU registers as extended addresses A16 and A17 for 256K of memory, rather than as "Block Selects" for RAM0 & 1 and the non-existent RAM 2 & 3. Had a C256 been built a new  MMU would've possibly outputted a multiplexed 9th address bit for 256K DRAMS, instead of four /CASs for four groups of 64K.

The matter of 8502 memory addressing versus VIC addressing (not to mention how the Z80 affects matters,) is somewhat complex, so I might be a bit off the mark in the preceeding paragraph. But from a software standpoint, nothing much would change regarding banking, and from a hardware standpoint, this hypothetical new MMU wouldn't need any more pins than the old one did, but it would not, however, be a "drop-in" replacement.

But what of "Super Banking"?

I've seen bits 4/5 of the RCR -- the supposed Super Bank bits -- referred to as addresses A18 and A19 for a total of 1Megabyte. Setting aside the hardware implications of that pie-in-the-sky idea, we can only speculate as to how Super Banks would've functioned in a C1024. With sixteen 64K blocks of RAM available, would Common Memory always be in RAM0, no matter which Super Bank was selected, or would there be three more Common areas in RAM 4, 8 and 12, depending on which SB was selected? Or would there have been an option to have it either way? The same goes for relocated Zero Page and Stack: two more bits would be needed in the block pointer registers to specify where ZP and Stack were to be moved to. And then there's the VIC. Would its screen memory be restricted to the first 256K, or would screen be limited to one of the 4 blocks of whichever SuperBank was in effect, or would two more bits -- somewhere! --  determine which of 16 blocks to use? And if the latter were the case, would the MMU or other circuitry have to generate more Translated Address bits?

Trying to accommodate these indeterminate possibilities, or variations thereof, with standard, common logic ICs would be impractical, to put it mildly.  A CPLD or FPGA, as a sort of "Super MMU", or perhaps a "co-MMU" might be a viable solution, but I suspect such an undertaking would be daunting even to an experienced designer of such things. Is anyone willing to step up and make me eat those words?

Does anyone else have any thoughts on how Super Banking ought to have behaved?

[Hydrophilic]

I like your idea of a multiplexed 9th bit to keep the pin count the same on a "256" MMU.  I remember reading somewhere that Bill Herd had 256K capability built into (or rather snuck into) the MMU but management made him remove it when they found out.  I'm wondering how that worked, or if it had more pins?  I don't think it would have more pins, the MMU is already a 48-pin as I recall... really big for a DIP.

As far as the super MMU of 1024K, I believe it would have common memory in Bank 0 also.  Just a guess, but as a programmer, I would prefer it.

If you've ever programmed the page 0 / 1 redirection registers, you've probably noticed that the high byte (bank byte) holds a 4 bit address, of course only 1 bit works in the real 128K MMU.  If all four bits worked, you could relocate to any page in 1024K RAM.

The VIC/DMA access would need some extra registers / bits somewhere... it wouldn't be very nice to have your REU access only the first 2 (or 4) banks instead of all 16 banks... (the restriction wouldn't be a serious problem for the VIC).

The translated address bus is used for accessing the ROMs and relocating page 0 / 1.  So if you want all 16 banks for relocation you would need a wider trans adrs bus.

Sorry I don't know anything about programming FPGAs... I'll be doing good to reprogram the Atmega1281 in my uIEC...

But if somebody is going to design a super MMU, please, please, PLEASE fix the common memory bug!  Because it is documented, some might call it a 'feature' but it sucks!  I'm referring to common memory over-riding page redirection.  Because of this bug, you can't relocate page 0 or 1 to into bank 1 with the standard MMU setup which has common RAM at the bottom of RAM... it works fine with no common RAM or top common RAM, but the KERNAL won't run that way.

[Diddl]

A CPLD or FPGA, as a sort of "Super MMU", or perhaps a "co-MMU" might be a viable solution, but I suspect such an undertaking would be daunting even to an experienced designer of such things. Is anyone willing to step up and make me eat those words?

I am NOT really experienced designer of CPLD, but I have done succesful work with Atmel ATF1504 CPLD in a VC-20 project: Final Expansion 3

FE3 has 512KB SRAM and 512KB flash for my VIC-20 and two software register to configure it (all open source).

If you has question about ATF-1504 I will answer it if I can.

[airship]

The manual for the never-produced C128-40 (which was to be the low end 'personal' model in the B series), says "128K RAM expands to 256K internally, 704K externally, totaling 960K."

I don't know if the thinking on the early C128 design was similar or not.

[richardc64]

I like your idea of a multiplexed 9th bit to keep the pin count the same on a "256" MMU.  I remember reading somewhere that Bill Herd had 256K capability built into (or rather snuck into) the MMU but management made him remove it when they found out.  I'm wondering how that worked, or if it had more pins?  I don't think it would have more pins, the MMU is already a 48-pin as I recall... really big for a DIP.

A "1024" MMU could create a 10th multiplexed address bit and the pin count would remain at
48. However, VIC and the existing circuits generate only 8 row bits, which is enough for refreshing 64Kx1 or x4 DRAMs and 256Kx1s, but larger capacities need more bits during refresh. Some complicated stuff would be needed to insert a 9th and 10th bit at the right time.

As far as the super MMU of 1024K, I believe it would have common memory in Bank 0
also.  Just a guess, but as a programmer, I would prefer it.

Yeah, that makes sense, but imagine the possibilities -- or complications! -- if each 256K
group could have its own Common Memory including ZP and Stack.

The translated address bus is used for accessing the ROMs and relocating page 0 /
1.  So if you want all 16 banks for relocation you would need a wider trans adrs
bus.

That's what I thought for a long time, but now I don't think so. The 8-bit TA bus only moves things around within 64K. When ROMs, relocated or
not,  appear in different banks, the bank only refers to the RAM -- including page 0 and 1 -- in the 64K space with them, and that's handled by the /CASs or the hypothetical 9th and 10th Address bits. There are no actual banks for ROM: they're either present or not.

The VIC/DMA access would need some extra registers / bits somewhere... it wouldn't be very
nice to have your REU access only the first 2 (or 4) banks instead of all 16 banks... (the
restriction wouldn't be a serious problem for the VIC).

This, to me, is the worst of it. Although there are many unused bits in the "128" MMU registers, none are in the RCR where the 2 bits for VIC/DMA access are located. That means, for a future MMU, changing VIC/DMA access would have to be a 2-register operation, which would be clumsy at best. Not only that: it might have to be that changing  VIC/DMA banks would have to be like changing page 0/1 banks -- that is, the low bits wouldn't have any affect until the high bits were changed. Ugh.

...you can't
relocate page 0 or 1 to into bank 1 with the standard MMU setup which has common RAM at
the bottom of RAM... it works fine with no common RAM or top common RAM, but the KERNAL
won't run that way.

Ah. So THAT'S what's wrong with! Makes me wonder why anyone would ever use that feature at all.

[richardc64]

I am NOT really experienced designer of CPLD, but I have done succesful work with Atmel ATF1504 CPLD in a VC-20 project: Final Expansion 3

FE3 has 512KB SRAM and 512KB flash for my VIC-20 and two software register to configure it (all open source).

If you has question about ATF-1504 I will answer it if I can.

That's a pretty impressive accomplishment for someone "...NOT really experienced." I salute you.

My only question -- which isn't specific to the ATF -- is why do I have to create a circuit using equations? If I could just draw a schematic and click "Make It", that would be ideal.