Yes

http://www.csbruce.com/~csbruce/cbm/transactor/v9/i3/p028.html   "FarSYS"

Quote from: Diddl on January 06, 2010, 07:15 PM
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.

Quote from: Hydrophilic on January 06, 2010, 01:52 PM
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.

QuoteAs 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.

QuoteThe 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.

QuoteThe 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.

Quote...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.

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?

Leaving active signals on an IC that's not powered isn't a good idea. Worst case would be damage to both the unpowered chip(s) and the one supplying the signals. You'd be better off switching /CAS between the two pair of DRAMs, but why keep the 16Kx4s when you can just tell the VDC how much memory to use?

 

Mapping the C128, page 413, also goes on the say, "...the pins must be high during reset or the system will enter Commodore 64 mode."

I take this to mean that if something were to go awry while either (or both,) pins were low, so that the only recourse was to press Reset, you'd get dumped to C64 mode, with chunks of ROM missing, requiring a second hard reset to get back to 128 mode -- not that that would be so terrible, I suppose.

Google is your friend...

Craig Bruce
http://www.csbruce.com/~csbruce/cbm/zed/

I don't know if the email address there is still valid.

BTW, I found a d.i.y. RGB-to-NTSC (or PAL) converter intended for the Atari ST. I don't know how good 80-column composite color would look on a television or monitor. Frankly, it looks too simple to me, but it might be worth trying.
http://www.preromanbritain.com/gwem/martbean/ataridiy/conv.htm

Quote from: SmallCleverDinosaur on November 24, 2009, 01:11 AM
I hope you don't mind me "cleaning" the article. I haven't changed anything though I hope it will be of use to someone

Why would I mind? You did a beautiful job!

Seeing the article again, I realize I had forgotten a lot in regard to software concerns, specifically the need to initialize the IFR at $FFFA-FFFF, the fact that I had used a Load Configuration Register in an effort to slightly speed up bank switching, and, most importantly, that my mem mover routine used the stack to hold some "relay" code! Yikes!

Obviously, there's room for improvement.

Quote from: Hydrophilic on November 23, 2009, 02:41 PM
Cool article.  I remember looking up and reading that article after this thread was posted.  I like the web page too!  And those schematics look they were done in GEOS... pretty cool.

Thanks very much. Yes, the drawings were originally done in GEOS, but the graphics on the web page are scans from the TC128 article, retouched in Windows M$ Paint.

QuoteI get what you are saying about saving the system RAM on the stack and restoring it when writing your SRAM.  This could be a bit time consuming if you need to write a lot of data to the SRAM without trashing system RAM.

A little less time would be consumed if the MMU pre- and load configuration registers were used to do the bank switching, but I did not try that.

If the SRAM were written to before a Basic program or whatever was stored in system RAM then byte-by-byte bank switching would be unnecessary.

QuoteAn idea I thought of is if you had a spare page of memory, you might be able to swap page 0 under the area of SRAM.

(Shudders) I never completely understood the page 0/1 swap, so I can't say anything certain about your idea. I can only assume swapping affects only system memory, and it shouldn't matter if the pages are under any ROM, but I don't know for sure.

Quote...in any case my idea (if it works) would result in writes to SRAM trashing the real zero page but for "normal" operation, zero page would be redirected to the spare page of memory.

Wouldn't it be better to trash the substitute zero page , then restore the normal ZP? (Actually, I'm not comfortable with idea of "trashing" either the "real" or substitute ZP, but better programmers than I ever was might be able to pull it off -- IF no ZP locations are used as address pointers for memory moves, which is kinda impractical.)

All these complications are why I considered my SRAM as primarily a substitute for EPROM, containing utilities and such, and not for any rapid, and/or frequent writing.

QuoteI noticed there is an unused pin (it's grounded) on the inputs to the 74HC138.  You also say you can have 4 devices controlled by connecting it's Pin 2 (B) to a control line like on the cassette port.

I was thinking there are two very often unused outputs of the C128 that are available: the /GAME and /XROM lines of the MMU.  ... you could have two lines going to the 74HC138: the one you indicated, Pin 2 (B) and the other unused (grounded) Pin 3 (C).  Wouldn't this allow you to control 8 devices?

Then you could have an extra 8x32k = extra 256k of RAM?  That sound's too good to be true!  Is my logic failing me?

Yeah, just a little. All 8 'HC138 outputs would be available if all three Select inputs (A, B, C,) were available, but in this incarnation, A (pin 1) detects when MS1=1, which in combination with MS0=0 indicates an Internal Function ROM access. For this reason, only 4 of the 'HC138 were usable, depending on the states of inputs B and C. If MS1 were inverted and applied to Enable pin /E2 (pin 5 -- some data sheets label these enables "G",) then 8 x 32k could be selected. At the time I did not want to add another IC just to get an inverter, but now I realize a single npn transistor would've done the job. D4mn hindsight.

/GAME and /XROM as outputs is a good idea, as long a user didn't plug in anything that also wanted to use them as such, in which case some mechanism for disabling the SRAM would be needed. The only thing available for that would be the afore-mentioned /E2 input.

Sorry to be so long-winded on such an ancient topic; I just want to make sure there's no misunderstanding of how this thing works and what it's good for.

I have registered so I could bump this aged thread because the TwinCities128 Internal Function RAM project was devised and authored by ME, and I must correct a slight misinterpretation of the project's capability.

Although reading the Static RAM, via PEEK and BSAVE (or M.L. equivalents), is straightforward -- or as straightforward as any memory accessing of the '128 banks can be -- writing (POKE, BLOAD, etc.,) is a bit tricky.

As my embarassingly nostalgic web page for this project http://www.sdiy.org/richardc64/c128/ifr.html explains, my circuit bypasses the MMU and PLA logic in enabling the Function ROM area occupied by Static RAM, but those devices still select the underlying system memory, because that's what they do if a write to a location that's supposed to be ROM is attempted. In other words, for Writes, both system memory and the Internal Function RAM are writen to simultaneously. This could corrupt a Basic program in RAM0 or Basic variables in RAM1, depending on which BANK # containing the Internal ROM-now-RAM is in effect.

To get around this, the M.L. routine I provided saves the configuration, switches to a configuration containing the system RAM, reads the byte from the target address and stores it on the stack, then switches the ROM area back in and does the write to the battery-backed Static RAM and system RAM AT THE SAME TIME. Then the byte stored on the stack is restored to the location from whence it came. (whew.) I don't have the original TwinCities issue at hand to scan the assembly listing, and all my CBM stuff is moth-balled, but I'm sure the talented programmers in this forum get the gist of what needs to be done. No  precautions other than the usual ones are needed when SYSing the Static RAM, unless the code therein does writes to itself, in which case it would have to perform the steps I described above.

I'd be interested in knowing if anyone has built this, and if so, what they've done with it.

-- Richard Curcio