d/loadICU64 / Frodo Redpill v0.1.7
New features
In ICU64:
- bug fixes
- block selection in memory view
- static code analyzer tool
- sync mode option
- 'peek & poke' via .NET interface
In Frodo Redpill:
- bug fixes
- drag'n'drop .d64, .t64, .prg, and .fss
- SID Voice 3 mute works
- REU support increased up to 16MB
- ROM files embedded to the .exe file
- multiple instances unlocked
Sync Mode
In sync mode, Frodo Redpill and ICU64 operate alternative in absolute synchronization at rate of 50Hz each. They run like sharing a single thread on your CPU (which needs more GHz in this mode, not more cores). Most of the time you should use the asynchronous mode (since it is lighter), but the sync mode is a lot more visually pleasing, as far as you can turn your monitor at 50Hz (otherwise not worth to enable this mode!). So the steps are:
- Turn your monitor at 50Hz (nVidia drivers have user settings for that)
- Press ALT+F5 in ICU64 to switch to sync mode (watch the indication on the main title)
- Enjoy the absolute smooth motion and perfect sync on both programs.
Multiple Instances (experimental)
Multiple instances combined with memory sharing is the long name of parallelism. And this feature is all about parallelism. You can now run multiple instances of Frodo Redpill that share some of their parts. And even if the control of sharing is minimal yet, is enough to start dealing with the problems and the benefits of parallelism.
So, try to start a second instance of Frodo Redpill and you will see three options:
The first option is to press 'Cancel' and quit, to avoid any change to the state of the first instance (choose this if accidentally you started a new instance).
The second option is to press 'No' and you will have a minimal sharing between two (or more) C64s. Then you can start, for example, different games in parallel and watch them fighting for their colors.
The third option is 'Yes' and is mainly for 6502 programmers, as the first thing will happen is to crash both C64s (not the external apps, only the internal virtual machines). To start without crash is a challenge; first you must realize the problem and then you'll have to write some code (ask me for help if you want). After you find a way, you may start exploit the benefits of multiple CPUs on C64 writing custom programs.
A host CPU with multiple cores is beneficial with this feature (the GHz not matter), as there is no limit to the number of instances you can start in parallel (but watch out the complexity).
Note that this feature is experimental; done by minimal modifications in the emulator side only. ICU64 is ignorant of the secondary instances (those having an asterisk '*' on their title). So you'll not helped much. Though you can watch all memory accesses from all instances, in some views (like the raster view) all these events interfere and get messy.
Note also that if you close or crash the primary instance, then any new instance will be secondary. And the only way to receive a primary instance again, is to close them all, and start new ones.
Code Painter
The 'Code Painter' in the misc tools of ICU64, is a static code analyzer. It works on a snapshot of the RAM that takes when first opens.The disassembly of the code starts from a user specific address, and it follows the flow of execution until to reach a loop, an error, or the command 'BRK'. As a basic rule it never disassembles the same address twice.
Theoretically, if you specify the entry point of a program, it should disassembly the whole code. But the CPU of the C64 has 3 threads: RESET (the main thread), IRQ (all the interrupts), and NMI (the RESTORE key). Also, because the analyzer is 'static', it can't deal with dynamic changes in places like:
- IRQ vector ($fffe..$ffff)
- NMI vector ($fffa..$fffb)
- memory banking ($00..$01) (bank switching)
- destination address of the 'jmp $(xxxx)' instruction
- a return address on the stack
- the code itself (in case of self-modifying code)
Neither supports the undocumented instructions of 6502. Indeed, there are many restrictions. A dynamic code analyzer that will bypass any restriction, will be one of the main features in the future. For now, though 'static' is still useful.
As an example, check the game 'Barbarian'. Its code occupies a single continuous region in memory and is completely static. The only 'dynamic' part is the destination address of a 'jmp $(xxxx)' instruction, and all its destinations (10 in total) located in a array of pointers (that's easy to find). So, if you disassembly the main thread (hint: barbarian stays resident after reset), and also the IRQ, the NMI, and the 10 destinations of the 'jmp$()' instruction, then you will get a nicely structured form of the whole code!
Also, even if the Code Painter can't read any ROM, you can copy the ROM into the RAM and disassembly there the KERNAL and the BASIC.
(More info pending...)
Known issues
issue: In some rare cases, Frodo Redpill crash very often by just clicking or dragging few times the window title.
cause: The bug is related to the sound system.
fix: option 1: Change the DirectSound option in Preferences > WIN32.
option 2: If the above fail, restart the Windows.
option 3: If all fail, disable the SID Emulation in Preferences > Standard.
issue: The primary instance of Frodo Redpill does not initialize the RAM during startup, as it should.
cause: A silly bug.
fix: Use a hex editor to patch the 'frodorp.exe' file:
file offset: 29D2F
old values: B0 CE 44 00 75
new values: B1 CE 44 00 74
ICU64 / Frodo Redpill v0.1.7Προέλευση
http://icu64.blogspot.com/2018/11/icu64 ... eased.html