> On 2016-12-29, at 21:06, Jim Brain <firstname.lastname@example.org> wrote: > > On 12/29/2016 12:28 PM, MichaÅ‚ Pleban wrote: >> Hello! >> >> email@example.com 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. -- SD! Message was sent through the cbm-hackers mailing listReceived on 2016-12-30 07:00:02
Archive generated by hypermail 2.2.0.