Re: Problems with moving VIC-20 sources

From: Spiro Trikaliotis <ml-cbmhackers_at_trikaliotis.net>
Date: Sat, 6 Jul 2013 23:00:13 +0200
Message-ID: <20130706210013.GC6067@hermes.local.trikaliotis.net>
Hello Ruud,

* On Sat, Jul 06, 2013 at 10:22:15PM +0200 Ruud@Baltissen.org wrote:
 
> Some time ago I mentioned having problems when moving routines of 
> the VIC-20. Today I got them as well. In this case VICE came with 
> the message the the VIC crashed at $FE45. This is ROM area. But 
> checking that address and bytes around it, I noticed that bytes had 
> been changed. The file 'kernal' that I created was OK. So something 
> must have changed the bytes at some moment. But how can if it is 
> 'ROM' ??? The only one that can change that is, IMHO, a buggy 
> WinVICE.

You do not happen to have "virtual device traps" (VDT) enabled?

Background: VDT tries to recognize some "common" functions of the
machine and do not emulate it. Instead, it is run on the host.

For this functionality to work, VDT has to know the memory addresses of
the KERNAL functions that are virtualised. These addresses are then
trapped. If the machine wants to xecute code from there, VICE stops the
machine, does the execution itself and puts the PC at the pre-known
address where the function ends.

Because of this, VICE has a list of known addresses to trap and
addresses where to continue work, for every machine.

In older versions (I do not know if this is correct anymore), VICE
replaced the memory area where the traps were installed with another
byte (00, BRK, IIRC). This might be the reason why you see ROM addresses
changed.

Now, if you move around memory areas, these addresses ("traps") might
not be correct anymore. In this case, VDT will not work and might send
your machine into nirvana.

So, the bottom line: Switch off "VDT" and try it again.

Regards,
Spiro.

-- 
Spiro R. Trikaliotis
http://www.trikaliotis.net/

       Message was sent through the cbm-hackers mailing list
Received on 2013-07-06 21:01:53

Archive generated by hypermail 2.2.0.