So I figured who better than the C=128's "daddy" to figure this out.
"Hi Betatesters, Peter and I have done more thinking on the C128 possibilities, and after trying out a special core that Peter has made for me to try and measure, I checked all documents that I have about the C128. While browsing through my literature, I found the Commodore service manual for the C128 (dated november 1987, PN-314001-08), which already gives some answers on the very first pages titled "Theory": On page 4 unter "The Translated Address Bus", you can read: "During a VIC cycle or a DMA, the MMU pulls TA12-TA15 high, while TA8-TA11 are tri-stated. This allows the VIC chip to drive TA8-TA11 as VIC addresses VA8-VA11." Essentially, the MMU does the "almost" equivalent of the C64 part RP4, a resistor pack that pulls address lines A12 to A15 high during a VIC cycle. The "almost" part is the difference: While the lines remain tri-stated in a C64 and you can pull low on these four address lines during a VIC cycle, this is not valid in a C128, because the lines are not tri-stated. Why is this so important? To understand a little more about the C64 PLA, please download my PLA analyzer program - the latest version contains an important addition to what I've published a few years ago: http://icomp.de/products/SuperPLA/pla_analyzer.zip Start the program by changing to the directory in a commandline (DosBox) and enter "pla". The program will display the standard C64 memory map. Now press the 5 key - this simulates pulling the GAME line low, doing a massive change to the memory map: The CPU only sees 4k of memory, lots of "blanks" and the $01 address is completely inoperable. This is the famous Ultimax mode. Now comes the previously undocumented part: Press 0 to simulate pulling low on A15 during a VIC cycle. What you see is a previously undocumented feature of the Ultimax mode, and that's removing all memory from the VIC address space. This is the special mode that lets Chameleon feed the VIC with external data. This is the mode that will allow our accelerator to write to video-displayable memory without slowing down to 1MHz. This will bump turbo performance big time. However, not on a C128. While the C64 uses pull-up resistors on the upper four address lines, the C128 will push these lines up almost "hard-wired" with the MMU. On top of that, the C128 expansion port is wired differently from the C64 expansion port: The upper eight address lines are the MMU-translated address lines TA8-TA15 instead of the CPU address lines A8-A15. As we've read before on page 4 of the service manual, these lines are *controlled* by the MMU, but they are not translated back to the CPU address bus. This kills the required path to the PLA of the C128, which does not know about the translated address bus. It gets the non-translated address bus of the CPU, so even if we yank low on the upper address lines on our external cartrigde, the C128 PLA will never know about this. On an electrical level, this means that the current cores of Chameleon cause bus contention on a C128. I therefore recommend not to try it on the C128 any more. Since we have reliable means to identify that we're plugged to the C128, I'll submit a set of suggestions to Peter, so we can find a compromise for C128 owners. More on that later. ciao, Jens
... Jens Schoenfeld Message 8 of 8 , Mar 3, 2011 At 12:01 03.03.2011 +0000, Alex wrote: >Do I understand you correctly if you say that there is currently no (obvious) way to gain access to the real memory inside the C128 because the MMU doesnt allow you to set your own address on the cartridge connector in Ultimax mode? Not entirely correct. There is a way to access memory, otherwise things like the real REU would not work on the C128. If it's pure CPU cycles, then the C128 is still a beast to taim, but it's possible, as we have shown with the MMC Replay. However, VIC access is a different story. Remember that all C64 memory is shared memory, where CPU and video chip can both access the data. If you are creating an accelerator, the main thing you create is fast memory access for your CPU. However, if your CPU wants to access the slow hardware on the 1MHz side of things (such as registers), then you need to clock down your CPU to 1MHz to make this access happen. That means: Even the 20MHz SuperCPU has to slow down to 1MHz for every single write access to memory and to registers. This is a considerable loss of time, because even if only one out of 20 cycles is a write cycle, then your total performance goes down to an average of under 11MHz, despite the max frequency of 20MHz for the CPU. To get around this bottleneck, we're turning things around with Chameleon: We do not use the slow memory of the C64 at all. If you want to try, you can even operate the C64 without the memory chips if Chemeleon is attached. Chameleon only uses the fast external memory. This way, we don't have to slow down the CPU if we write to memory. We only need to slow down for register/IO access such as VIC, SID, CIAs and colour ram. All other writes to memory are fast - even writes to an active video bank. Even if our performance may never be as high as SuperCPU, I'm confident that we'll get close enough to be an adequate competitor. ciao, Jens"
My first thought is why can't they use something like the Commodore 8726 REC Chip to DMA the data into the C=128. Unless there is a non-intrusive solution getting around the MMU.
Tue, 2016-04-12 08:39#1
Turbo Chameleon 64 doesn't like the C128.
Edited by: Ratteler on 2016-04-12 08:44