richardc64
Windows User
No longer a Guest
Posts: 5
|
Post by richardc64 on Mar 24, 2019 19:08:44 GMT
Why? The specs are no different from those of the flat '128 that we've come to know and somewhat love.
I don't see the "dream" aspects.
|
|
richardc64
Windows User
No longer a Guest
Posts: 5
|
Post by richardc64 on Apr 21, 2018 13:17:40 GMT
Hmm...this part seems familiar: "The Color Ram is actually 4-bit in size and the VIC chip can only address 4-bit, there are only the other 4-bit for the CPU free, so you have seen another "bank". So does this increase the number of colors that can be output? Nope. It only gives you 4 more bits as a "buffer" and could thus swap between the upper and lower "bank". So are there any compatibility issues? Should not really, but nothing is 100%, if one modifies. (the upper bank is always set to signal high in the original)" I'm sure I've seen something like that before. www.sdiy.org/richardc64/color/byte.html
|
|
richardc64
Windows User
No longer a Guest
Posts: 5
|
Post by richardc64 on Nov 7, 2017 0:10:11 GMT
The big drawback for most of these you have to convert the digital RGBI into analogue RGB first which makes it even more of a complex board. It does? I seem to remember a circuit in this forum that was just resistors and diodes, and a refinement adding one IC for the "brown fix." Am I mistaken? Also, what about all the CGA/EGA/RGB -to- VGA/HDMI converters showing up on eBay?
|
|
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.
|
|
richardc64
Windows User
No longer a Guest
Posts: 5
|
Post by richardc64 on Dec 4, 2014 12:36:01 GMT
Yeah it is strange that full (8-bit-wide) RAM chip was used but only the low 4-bits are connected. Surely this was for C64 compatibility, because they had to actually add 4 resistors to stabilize the unused bits! Those four resistors were just a few cents, but when you multiply that by millions of units, that is tens of thousands of dollars that CBM 'invested'... or as some may say 'wasted'. Umm, actually they didn't waste the money, they passed the cost to the consumer I think wasting half a 2Kx8 RAM was the most cost-effective way to provide two color banks. It's a shame the VIC wasn't made to utilize the upper 4 bits, but that probably would've created problems in 64 mode. I'm probably the only person who ever did this mod. I only used the extra memory (when in 80 columns) as an "alternative" common memory to do bank switching when normal common memory wasn't present.
|
|