Maybe address space randomization makes it either crash or not? For me on NetBSD I have tried it a bunch of time and Vice started up correctly every time. But I did get the impression that the actual contents of the file name after -config were not even read. I even specified some file that wasn't a config file at all, and Vice still started up and had the settings from my default vicerc. Maybe running it with valgrind could give a hint.
I committed more or less the above patch and the issue should be fixed in r46149 or later. @rice123 please test (I gave it a quick test only and a run of the testbench).
...and this file too.
Side-effect free looking at VIA I/O ports.
yeah I caught the TABs. for reading the joysticks (vic20via1.c and vic20via2.c) it was calling more code than I was willing to look at that time, including via function pointers like return joyport_device[id].read_digital(port); so I was playing it safe. We can assume for now it's safe. It's easy to change again later if it's not (for whatever reason). I also noticed that many of the readprb functions do something like byte = (parallel_bus & ~(via_context->via[VIA_DDRB])) | (via_context->via[VIA_PRB]...
I prepared a patch using the second approach: the unified read / peek function. For various cases, the read function is quite complicated and the things that a peek should do different are somewhere in the middle (sometimes even in multiple places in the middle). Having this as two different functions seems too annoying. Here is what I have so far. I think I found all the things you can call safely for the peek function but do have a look. (edit: updated diff, I missed some files)
I prepared a patch using the second approach: the unified read / peek function. For various cases, the read function is quite complicated and the things that a peek should do different are somewhere in the middle (sometimes even in multiple places in the middle). Having this as two different functions seems too annoying. Here is what I have so far. I think I found all the things you can call safely for the peek function but do have a look.
I prepared a patch using the first approach: the unified read / peek function. For various cases, the read function is quite complicated and the things that a peek should do different are somewhere in the middle (sometimes even in multiple places in the middle). Having this as two different functions seems too annoying. Here is what I have so far. I think I found all the things you can call safely for the peek function but do have a look.