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, so I think the best option is a jumper on the board and a spot to solder a wire. In one config, accesses to reset vector are trigger. In the other config, only powerup and falling signal on user supplied reset pigtail. That should cover all of the situations of interest. Jim Message was sent through the cbm-hackers mailing listReceived on 2016-12-29 21:00:26
Archive generated by hypermail 2.2.0.