The wave-particle duality is common logic (proof)

As a physicist, I'm also interested in physics topics. And I recently had a small chat where I convinced the Perplexity AI that the wave-particle duality is not weird but a simple consequence of the classic logic.
Of course, current AIs still don't have great logic and thus it's too easy to convince them for anything (frankly speaking, they are stupid and emotional yet), but it seem that it got this idea with an ease and supported it with enthusiasm. I hope you enjoy the conservation and find the core idea useful too as an insight of common logic in the 'weird' quantum world.

You can find the chat at the Perplexity AI (or here as pdf)
I also posted the same idea at Quora.

ICU64 for Frodo Redpill v0.1.8 - Released

Download the new version here.
(also download the latest update 2022.01.08)

New features of Frodo Redpill:
- Multiple independent instances
- Preferences > Redpill > 'Extra Shared RAM' option
- CPU boost
- .hack file format (for data injection and boost control)
- drag'n'drop files: .fpr .hack
- improved REU emulation
- Window/Display management:
  - [F11] toggle window frame
  - [Ctrl+RMB+drag] move window
  - [RMB+drag] move all windows of all instances
  - [Alt+arrows/Home] control screen offset in smaller viewports

New features of ICU64:
- Multiple independent instances
- memory view:
  - view [6] : Changed values
  - view [7]/[Ctrl+F] : Find values (in current map layout)
  - extras [F4] : added REU view (if enabled)
  - Extra Shared RAM @ DE00..DEFF of MMIO (if enabled)
  - selection [LMB+drag] > [Ctrl+C/V] : copy/paste via clipboard
  - status bar [F10] : added current cell coordinates
- code painter:
  - [New]&[Clear] (to reduce close & reopen of this tool)
- instruction logger:
  - [Break New]&[PC only] (to locate easier first time executed code)
- .NET API:
  - peek/poke renamed as Peek/Poke
 

  

Multiple Instances

You can start multiple -independent- instances of ICU64 & Frodo Redpill that are totally isolated. However, to utilize some parallelism, you can optionally enable the 'Extra Shared RAM' (in Frodo > Preferences > Redpill) that provides 256 bytes of extra RAM (at DE00..DEFF in MMIO). This RAM is common among all the Frodo instances that have this option enabled. Be aware that this shared pipeline has max bandwidth only 256 bytes/frame = 12.5KB/s and latency = ±1 frame (I'm working to improve these...). The previous 'unlocked' instances (where the whole RAM and COLORRAM both shared) is still available; just start the emulator holding the [SHIFT] key.

 
CPU Boost

The 'CPU Boost' feature is a clock multiplier (a turbo) for the CPU of the C64. The rest of the chips (VIC,SID,CIAs) operate in the original speed and preserve the real-time features of the system. It is similar to the turbo switch of the SuperCPU for the real hardware, but in Frodo Redpill boost is controlled automatically by a .hack file. For example, say you have a 3D game that calls its -slow- rendering routine with an instruction like:
      1204 JSR 3120
    1207 ...
If you create a .hack file that contains:
    +1204    ; enable boost when 1204 is executed
    -1207    ; disable boost when 1207 is executed
and drop this file inside the emulator, then the routine at 3120 will be executed 63 times faster! I think you get the idea...

Note that every time you apply a .hack file, the boost map of the emulator resets. You can use this to turn off the boost feature without restarting the emulator or editing your .hack file; just keep an empty 'foo.hack' file around and drop it to the emulator anytime you want to turn off boost globally.

The .hack file format

A .hack file is a text file with a simple syntax, that simplifies the application of patches to a running C64 software, and also controls the boost of the C64 CPU. A command in a .hack file starts with a single symbol:
    #    comment
    ;    comment too
    :    poke
    +    boost on
    -    boost off
After a poke or boost command follows a hex address, and in the case of poke it follows an array of hex byte values that can expand in multiple lines. Some examples:

    # this is a comment  ; this is a comment too
    :400 08 05 0c 0c 0f  ; poke some bytes at $0400 $0401 ...
    :2d020 00            ; make border black (MMIO @ 2xxxx)
    +1800                ; turn on boost at $1800 (x63)
    -1860                ; turn off boost at $1860 (x1)


.NET API

To avoid some issues, the peek[]/poke[] functions renamed as Peek[]/Poke[], and the sample code for the Mathematica has updated too.

 
Enjoy!

ICU64 for VICE 3.x v0.1.3 - Released

A long awaited update of the ICU64 for the VICE 3 emulator is ready for download. While I'm still working for the v0.2, the new features of this release are trying to reduce the gap from the more feature rich ICU64 for Frodo. Among the unique features of this version, the new .icu file format, is more generic and can be used with bigger success with other emulators also. Please, read carefully the new instructions about how to install and run, and thank Sebastian who pushed me for this release. For any bug/issue/question post a comment or send me an email.

Update 2023.07.27: Download support for VICE 3.7 

Known issues

• symptom: memory view '1' (cpu events) shows no events (all cells are black)
  cause: icu64 failed to connect to the emulator automatically when it started
  fix: press ALT+F5 in icu64 to connect to the emulator manually
  

ICU64 for Frodo Redpill v0.1.7 Released

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

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 a 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 every time it opens.The disassembly of the code starts from a user specified 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 (most interrupts), and NMI (RESTORE key and CIA2 interrupts). 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.

ICU64 for Frodo Redpill v0.1.6 - Released

The creation of memory maps gets easier with this release.

New features in the memory view:

BASIC program layout
Load or type a BASIC program and hit ctrl-L in the memory view to watch the memory map of its code. After RUN, you have to press ctrl-L periodically to update that map, because a running BASIC program updates the layout of the data area (which is located after the code area) as it meets new variables for the first time. Enable the text view (ctrl-A) to get a more meaningful view (or type LIST in the emulator but this is like cheating!)

Data Classification (Order In Chaos)
The data classification view colorize the memory in a chaotic still consistent way. And using only your pattern recognition abilities you can organize the data even if you don't understand their meaning!
So far, watching the internals of the C64 in action may was something, yet you may have this feeling: "wow! I see everything :) but still I understand almost nothing :(". Well, the new feature lets the CPU to interpret  to us the meaning of the data using a color language. And no, you don't have to learn another color code, since these colors are meaningless this time (it's just a meaningless 'alphabet'). What's important is their patterns (i.e. the 'words' and 'phrases' that they form). These patterns are not the usual data patterns (as in the grayscale view), they are event patterns arranged in space that highlight the internal structure of the data as being used by the code (who always knows their meaning, and this is where we rely).
More particular, this visualization is based on 'what code access what data', and actually it's a simple hash function of the "last access" address that located in the upper left corner of every cell (visible in deep zoom). So, actually, this information was always there in a numerical/textual form, proper only for serial/boring reading. By translating this information into colors, patterns emerge (from chaos!) that can be recognized immediately by the human brain in parallel way, and organized manually. This view is especially useful to find large internal structures like arrays or lists of data, and analyze their entries down to their most individual parts.

Map Editing
Some new functions that will help you with your memory maps:
    Enter / Shift-Enter                  : Split / Join line
    Backspace / Shift-Backspace    : Move line Left / Right
(the above operations never overwrite non empty cells)
    Delete / Shift-Delete                : Delete cell / line
    right click / Insert*                  : Pick cell / Put cell++ 
    F2*                                       : Rename cell (change address)
Note that the editing functions are minimal yet, and they are line oriented. If you want to move blocks around you must export the map and use some spreadsheet application.
 * edit: bugs found on these operations that may mess your map, so avoid them (fixed in version 0.1.7)

Drag 'n' Drop
If you drop a .txt file in the memory view, it will open as a memory map. Any other file will be imported as a .prg file (i.e. will be loaded in the RAM at the location that the first two bytes specify). BTW, the Frodo Redpill window accepts .fss files (Frodo snapshots).

Press F1 on every window (even in the main menu) to see more functions.

You can also download some generic memory maps that may help you. Especially the RAM only map, it's a good start point to create the map of a game.


How to create a memory map, in practice:
- start a game in the emulator and wait until it gets into its main loop
- from the memory view of icu64, import (ctrl-i or drag'n'drop) the RAM only map (so you don't mess with the ROM and the MMIO while editing the map)
- press shift-ctrl-X to clear the colors and thus start a new log (do this at any time)
- (optional) switch to view '1' or '3' (cpu events) and play with the game for a while until you locate its code areas to remove them (since the data classification is meaningless with the code parts). Use 'shift-delete' to delete entire lines.
- switch to view '2' (vic events) to find the bitmaps, text screens, charsets, and sprites, all of which have 'standard' layouts usually (the graphics view will help you with this).
- switch to view '4' (data classification) and play with the game as much as possible, so the code to exploit  much (if not all) of its data. As you start seeing similar patterns in the memory view,  hit 'enter' over the beginning of each pattern to send it to a new line. The goal is to align the similar patterns vertically. To join two lines, hit 'shift-enter' on the first line.
- if some colors are very similar, hit '0' to get a different set of colors
- note that even with an incomplete map, you can probably locate lists of pointers/offsets (they have very characteristic patterns) to the patterns you have found so far, and this way you can find ALL the addresses of the entries in a list/table/etc.
- to tidy up the map export it (ctrl-O) as a text file, open it with Notepad, and copy everything or a part. Start a new sheet on Excel, select all of its cells and mark them as 'Text' (ctrl-A > right click > Format cells > Text). Paste the map to the sheet and do your edits (e.g. move blocks around). Finally, copy & paste everything  back to Notepad, save the map, and import it again to icu64. (edit: in v0.1.7 you can move blocks around, so there is no need for external tools)
- enjoy the new view!

ICU64 for VICE 2.3 v0.1.2 - Released

An update of the ICU64 for the VICE emulator is available for download (you also need the VICE 2.3 emulator). There are no new features, only better functionality. My goal is to inject the REDPILL into the VICE, so more features could be supported in the future. I'm working on it...
(see the included readme file for instructions)

Note for programmers:
This time I modified the VICE source code to fix the bank issues of the memmap feature (the mod is here).

EDIT: I forgot to fix the zoom-out crash bug that occurs in the 64-bit versions of Windows. A patch is available in the download page.

ICU64 for Frodo Redpill v0.1.5 - Released

Eventually, after 3 years, a new version of ICU64 is ready for download. Several bugs and issues have fixed, additional functionality and features have added. Note however, that this version is not the one that I was working on the last years (i.e. v0.2). This is only an update of the initial release, where I have paste as much code as I could from v0.2 without corrupting the functionality. My goal is to make the raster view equally significant with the memory (matrix) view, so the development is being continued...

Report any bug/issue/request in the comments or via e-mail.

Good hack!