So far I’ve encountered the following issues with interpreters running Dialog:
Special characters used in languages other than English seem to cause problems in some cases, in combination with Dialog Files compiled to z-code.
On OSX
Fizmo crashed with message to use an alternative interpreter (Dialog compiler) and I think this is true für both, english and non-english stories
Yazmin doesnt recognize input commands with non-ANSII charaters (Dialog compiler), only non-english stories
On IOS
Iphone Frotz crashes when typing “erz” (Dialog compiler), you have to type this in non-capital letters and the crahs occurs when typing “z”; I didn’t find yet other combinations of charaters that cause the system to crash
On OSX (Catalina), Lectrote seems to work fine with the Dialog component.
I think this might affect not all other foreign languages which use non-ASCII character sets.
I just wanted to report this and would be glad if the maintainers of the interpreters could work on a fix.
There is currently limited support for input of international characters when compiling to the Z-machine. It’s on my todo-list. Anything in the default extended charset of the Z-machine (see Table 1) should work for both input and output, and all other characters should work for output.
I have to correct myself: the problem with Iphone Frotz seems to have something to do with umlauts in source code though the command line itself with three letters “erz” (all non-capital) which causes the crash has no umlauts in it. Very strange. An english story file does not crash.
Do you care that the C64 interpreter fails on xscpu64 or for that matter if true drive emulation is off? (freezes just after the “Loading interpreter” display starts)
I assume we are discussing the Å-machine interpreter now. Yes I care, to a degree. Ideally the 6502 engine should be ported to as many platforms as possible. A C64 with SuperCPU is different from a normal C64, so it would take a bit of work. I don’t think a new frontend is necessary, but certainly a bit of work.
I ran a quick check, and it looks like the program gets stuck in the fastloader routines, which is kind of obvious in hindsight: That code is highly optimized and relies on the precise timing of individual instructions. If you swap in a faster CPU, the computer will expect data from the disk drive to arrive earlier, relative to the program.
The bulk of the interpreter, the actual Å-machine engine, is implemented in a more restrained, platform-independent way. But the frontend (especially the loader) needs to be as fast as possible.
I personally know very little about SuperCPU coding, and I’m not really motivated to put in the hours at this point. But anybody should feel welcome to try—the code is open source. As for turning off true drive emulation, well, that kind of misses the point of emulation, doesn’t it? On days when you value speed over authenticity, why not play the games in a native interpreter on a modern computer?
and having a speed-optimized and a compatibility-optimized loader. But I understand that may not be a priority.
FWIW as a non-programmer but SCPU-user: I would expect (from general experience) that a text-based engine “should” work on SCPU, when disk turbo tricks are not in play. Unless you’re doing really heavy optimizing apart from disk access, it seems like the kind of thing that should just-work on the 65816. (Notably, C64 Infocom interpreters are fine on SCPU. Ozmoo is also fine, although there’s an REU interaction issue I’ll be tracking down eventually…)
Yes, that’s a different matter. You would like to run the game on a physical C64 with a physical storage medium, which happens to be modern. Fair enough!
What I’m having trouble with is the scenario where somebody goes through the trouble of emulating a C64 in order to play a text game in a virtual machine, while at the same time modifying the emulation in ways that would not be possible on the real thing, just to make the game run faster. It makes sense if you want to play something like Thing On A Spring, which needs a C64 to run at all. But for a text game, you’d just be putting a virtual machine inside a virtual machine for no particular reason. A fun thing to try, perhaps, but not when speed is an issue.
The VICE team refuses to implement SD2IEC peripheral emulation for (whatever their reason is), but I’ve observed that “VICE TDE off/virtual device traps on” is a pretty good proxy for “will this work on SD2IEC?”
I’m happy to escalate to real hardware if you consider this a problem worth contemplating.
