It seems cen64 is gonna be a compiler an operating system and at a some point in an undisclosed future also an emulator
At the moment it is in its first stage -- a compiler. If you want to see something from the current cen64 then you should cmake it with the debug flag in order to get some verbose outputs on exec. Binary .z64 files aren't valid inputs for the parser. At the moment you should try with text files. MarathonMan posted a couple of working demos time ago. It is an impressive work he has put himself into. It has been without a doubt done so far at the highest professional level possible. It is a giant project by itself - being a spare time project these are the things you know when you begin them and cannot know when they'll be over ... if ever No wonder cen64.exe pifdata.bin game.z64 doesn't work. Yet i wonder Windows does

8d0e7bb627b91f4d592ebd2a7e3d87cf580cdb32
pi: add support for IS Viewer 64
When -is-viewer is passed on the command line, create an IS Viewer
object that intercepts writes at 0x13FF0000. This is used by Ocarina of
Time Master Quest Debug to log debug messages.
The messages are encoded in EUC-JP, so we bring in iconv to convert that
to UTF-8 so the messages can be printed to modern consoles.
Props to jrra (@jkbenaim) and spinout for reverse engineering the
interface and documenting it: http://wiki.spinout182.com/w/IS64

In Windows you could avoid to create a new dependency on iconv for the old cen64 (also the call to iconv_close is nowhere to be seen). It is easier to add an exception... include windows.h, add a few #ifdef _WIN32 and just call MultiByteToWideChar to make the conversion. It is straightforward after having read the docs and found out the proper "code page identifier" -- i see in the list two identifiers for EUC-JP. The WinAPI-function will write the output to an array of WideChars. They should be an alias for wchar_t* and were basically plain UCS-2 characters, then turned into stricter UTF-16 characters after the standardization process. If you really need a new UTF-8 string then you should also call WideCharToMultiByte to convert it back to utf or anything. If you only need to print the string (it seems so) it is much easier to call printf with the proper identifier for wide strings printf("%S", L"widechar"), printf("%ls", L"longchar") or whatever the used libc wants. So that a second conversion won't be needed. Now somebody knows how to fix it.