On 10/16/2019 7:50 AM, Zoran Davidovac wrote: > Hi Jim, > > How about a different idea for MMU? > > My idea is to page both RAM and ROM and I would preferred that if you > are creating MMU, > you create a MMU board that will replace not just ROM and RAM but also > to replace failing PLAs, > it will lower power consumption on every c64, repair it and give it > longer life. > > Tech Details: > > In stock c64 kernal is on $E000 $FFFF (last 8K) while c64 can access > to Kernel ROM and execute it, > VIC can access only to RAM under kernel even with KERNAL ROM turned on. > Writing to KERNAL ROM space actually write to RAM under. > > So you could page not only RAM under $E000-$FFFF ie graphic for > VIC,but also replace KERNAL ROM in same $E000-$FFFF code for CPU > > That would give us two types of pagging: > > -8K in another words you can swap 8k at the time $E000-$FFFF RAM, so > you can also change every 8K block to fill all the data RAM and > potential ROM (every second 8K RAM) > > -16K as 8k at the time $E000-$FFFF RAM and 8k at the time $E000-$FFFF > ROM read only. > > this give us to data as 8K graphic and 8K code or 2x8K code if you are > turning of ROM on/off The traffic here is a bit low at present, but I did post on some of the other forums. Maybe post there and see if there is more widespread interest. I can create a PLA (I did, but have not debugged it), but as you note, that starts to drive costs up, and people will be less likely to unsolder a PLA on a board with one soldered in, at least until it dies. I'm not sure how much the additional 8kB slot that VIC does not see helps (I know it helps, just not sure how much it does with all of the existing MMU features in use. There might be an easier way to handle this as well. If I tap the specific line of the PLA with a flying lead that handles knowing when the VIC-II is accessing data, I can remap that way, no additional PLA needed. It also would give me a way to always map VIC-II accesses out of the regular memory map, if the user desired. JimReceived on 2020-05-29 23:11:04
Archive generated by hypermail 2.3.0.