On 12/30/2016 12:40 AM, silverdr@wfmh.org.pl wrote: >> On 2016-12-29, at 21:06, Jim Brain <brain@jbrain.com> wrote: >> >> On 12/29/2016 12:28 PM, Michał Pleban wrote: >>> Hello! >>> >>> silverdr@wfmh.org.pl wrote: >>> >>>> If we want to keep compatibility - I am afraid the answer is "yes". A simple example: a program uses the RAM area under KERNAL as a temporary storage and reads from the consecutive addresses there. I know for a fact that such programs exist. So you would need to monitor the configuration bits or the _CS or ... The next example is copying KERNAL from ROM to RAM - lots of programs to this in order to modify a few things in the KERNAL. Here monitoring the _CS won't help as the program reads from ROM locations and you know what happens when you don't differentiate between the _RST induced reads and the same done by the program. >>> This is a valid point. As Gerrit said, you cannot distinguish the CPU >>> reading the reset vector during the RESET, and the CPU reading the reset >>> vector as a part of some user code. >> I submit that things copying ROM to RAM are a rare occurrence nowadays. >> >> However, I concede the point. >> >> Still, the goal is no wires, > If you want to be able to switch the ROMs on-the-fly (without reset - which I understand is the main difference between what you are trying to achieve and what I do) and want no extra wires (as I do ;-) then I believe the magic sequence is the most viable option. Choosing a long enough random sequence should cover the bum well enough. Switching the initial ROM is pretty easy, no magic sequence needed. But yes, switching to a different ROM would require a magic sequence. I already do one on UltiMem, so it's not a big deal. JIm Message was sent through the cbm-hackers mailing listReceived on 2016-12-31 05:00:02
Archive generated by hypermail 2.2.0.