Nov 1, 2018

ICU64 / Frodo Redpill v0.1.7 Released

Download the new version here.
(and also the patch, last update 2019.01.10)

New features

 In ICU64:
- bug fixes
- block edits 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 in alternation and absolute synchronization at rate of 50Hz. They run like sharing a single thread on the host CPU (which needs more GHz in this mode, not 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 may not worth to enable this mode!). So the steps are:
- Turn your monitor at 50Hz (most display 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 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, as there is no limit to the number of instances you can start in parallel.
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 top level RTS/RTI, a BRK, a loop, or a 'JAM'. 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
- return addresses on the stack
- the code itself (in case of self-modifying code)
Neither fully 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'. After LOAD & RUN, its code occupies a single continuous region in memory and is mainly 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 disassemble 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, if you copy the ROM into the RAM, you can disassembly there the KERNAL and the BASIC.

.NET Interface (for programmers)
This is another way to control the C64 virtual machine via an easy to use API. Currently allows you only to peek & poke the RAM, ROM, and MMIO of the C64 using any .NET 2.0 compliant language. You can peek & poke single bytes or multiple bytes at a time.
Here is some sample code in Mathematica. Start Frodo Redpill (without the ICU64), open the sample code, correct the path to ICU64.EXE, and run the examples.

(Note: Don't confuse this .NET interface which exposed by ICU64 with the more powerful -and undocumented yet- 'redpill interface' which exposed by Frodo Redpill itself)

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.