|
Post by robertb on Jul 22, 2015 6:13:48 GMT
At last weekend's CommVEx, I was able to briefly show the following C128 internal memory expansion schematics to Bil Herd -- www.sdiy.org/richardc64/c128/new256k/c256v2prelim.htmlFor a long time, I wondered if this was doable, even though it was questionable what C= software could access that extra memory. Bil looked at it and immediately found flaws in the design. From what I remember, he didn't like the added components which put extra timing delays in the board and the added components which drew more power. Because it was at the end of the show, he told me to send him the links to the pages, and I did that last night, including the link to the previous version of the design at www.sdiy.org/richardc64/c128/index.htmlI hope he will give a more detailed analyses of the design(s), and I hope he will even suggest improvements so that such an internal expansion can work. Still in Las Vegas after CommVEx, Robert Bernardo Fresno Commodore User Group www.dickestel.com/fcug.htm
|
|
richardc64
Windows User
No longer a Guest
Posts: 5
|
Post by richardc64 on Jul 22, 2015 10:55:38 GMT
I am the author/perpetrator of that particular memory expansion.
In the 1990s I performed the original modification (for a modest fee,) on several C-128s besides my own. The only complaint I was ever made aware of was that it didn't work with any software that relocated Zero page and/or the stack. The so-far-untested c256v2 design theoretically corrects that limitation.
I demonstrated the 512K modification at a Bronx, New York User Group, running the Spinning Globe demo with the pictures residing in internal memory, instead of in an REU. (I no longer think 512K was a Good Idea.)
The only point where I thought delays might pose a problem was where I replaced U9, a quad OR gate that sorts out /CAS0 and /CAS1 from the MMU, /CASENB from the PLA, and /CAS from the VIC with a 74LS138 1-of-8 decoder. 74LS_ worked in MY '128 -- even at 2MHz -- but when modifying other's computers I used a 74F_ part, just to be safe.
OF course no C= software accesses the extra memory: it's not supposed to exist. But Basic and the Kernal assume Blocks 2 and 3 are real, and a User with the chops can access them easily using only standard Basic commands and Kernal calls.
The heaviest hit power-wise is the second MMU. (150mA, max.) I made sure to use CMOS DRAMs for the added RAM, and only four of them, as 64Kx4s. I optimistically (or naively,) assumed that the PSUs for both the low profile '128 and '128D had sufficient current capacity. I never experienced any power problems.
I don't know how well or poorly my expansion worked in CP/M. At the time, I didn't care, and still don't.
|
|
|
Post by robertb on Jul 22, 2015 12:07:00 GMT
Good to hear from you! If Bil Herd elaborates any more on your design, I will post it here. Leaving Las Vegas today, Robert Bernardo Fresno Commodore User Group www.dickestel.com/fcug.htm
|
|
|
Post by robertb on Sept 4, 2021 21:29:49 GMT
|
|
|
Post by eslapion on Sept 5, 2021 16:31:44 GMT
I am the author/perpetrator of that particular memory expansion. ... The heaviest hit power-wise is the second MMU. (150mA, max.) I made sure to use CMOS DRAMs for the added RAM, and only four of them, as 64Kx4s. I optimistically (or naively,) assumed that the PSUs for both the low profile '128 and '128D had sufficient current capacity. I never experienced any power problems. ... Since a Saruman-128 replaces all 16 4164 DRAM of a C128 and consumes about 10mA of power (on the 5Vdc) I suspect using four Saruman-128 would provide the 512k of your memory expansion AND result in lower power consumption at the same time. I would gladly send you 4 samples of that module if you were to publish a building manual that uses these instead of DRAM.
|
|