intfiction.org

Hello everyone!

Tonight I have uploaded my new Z-Machine implementation to Parchment. I would appreciate your help in testing it. To switch to ZVM, just add &vm=zvm to the end of a normal Parchment URL (ex: http://iplayif.com/?story=stories/troll.z5&vm=zvm). Once I've fixed a few minor things, and fix any bugs you help find, then I plan to make ZVM the default Z-Machine implementation in Parchment, and Gnusto will be used only as a backup (for version 3 etc.)

Some things aren't supported yet:
- Colours/styles in the status window
- A few rarely used opcodes (one of which has never been supported by Gnusto): @catch, @throw, @get_cursor
- Z-machine versions other than 5 and 8 (I have no plans for the other versions, sorry, but I do have plans for Glulx! )
- Quotation boxes won't be displayed
- The main window's width is too wide

I also have some questions for the experts among you:
- What do the operands of @throw mean?
- The monospace header bit is clearly independent of other UI stuff. Are @set_text_style and @set_font also independent? Or, would @set_text_style 8 then make @set_font return 4?

Hi Danii,

I have problems getting your example running on Chrome 15 (Uncaught Error: INDEX_SIZE_ERR: DOM Exception 1 in /?story=stories/troll.z5&vm=zvm:13)

as for @throw:

As I understand it, you store the value of your current stack frame in the @catch instruction. That value is then given to you in the @throw instruction as the second parameter, together with a routine return value in the first, which is used when you return from the state after unwinding the stack up to the saved state.
(this is how I implemented it in ZMPP).

Hope that was not too confusing of a sentence ,

Wei-ju

_________________
Wei-ju Wu - ZMPP@github Blog Twitter

Very cool. What are the benefits compared to Gnusto?

To augment Wei-ju's response: if you implement Quetzal, @catch is required to return the number of frames on the call stack (it uses the phrase “system stack”, but it seems obvious that the call stack is meant). So @catch in Main() returns 1; if you call another function, @catch in that function returns 2, etc. See §6.2 of Quetzal 1.4.


I see nothing in the standard linking text styles and fonts, and I did not implement it that way. More importantly, the gold standard—Windows Frotz—does not appear to link them, which is as close to a de jure answer as you can get if there is nothing in the standard.

Thanks for your comments everyone. I thought @throw worked that way. Gnusto has implemented it wrongly.

I've now more thoroughly tested it in Chrome and have pushed an update so that it works in Chrome, FF and IE. However I haven't tested every file in existence, and the test suites aren't comprehensive enough yet, so, if you use Parchment, I would appreciate you trying ZVM next time you use it.

Juhana, ifvms.js is a new way of writing JIT VMs, by using Abstract Syntax Trees. My plan is that there will be a common core, which ZVM and a future VM for Glulx and maybe even one for TADS would be built on top of. The big advantage is that an AST is much more manipulatable than the JIT systems of Gnusto and Quixe are, which just write out code to run. Instructions can easily be reordered, and structures like loops can be identified and converted into real JS loops, rather than a series of branches and jumps. Previously if you had a loop the JITer would have to stop before and after it, so that you would have three code sections. ifvms.js can compile a loop in place, with the code before and after it, and a JS loop in the middle which will run itself, rather than the VM framework telling it to run multiple times.

Here's an example of the code it generates, which has a while loop inside a block if statement. This would be close to impossible under Gnusto. It's not pretty code, but it's fast.
(But not fast enough. The .incdec() function needs to be inlined, and the push/pop can be optimised too.)

Dannii, apologies if this is off-topic, but the other day I was showing someone an IF ("Cold Iron," FWIW) on the iPad and it froze up on a "press any key to continue" event. Apparently on the iPad's browser, you bring up the keyboard by clicking in a text field, and since there's no text field in a "press any key to continue" event, there was no way to bring up the keyboard and press a key without losing focus -- at least not one we could think of.

Do you know a way around this?

(I was actually a little surprised that we got as far as we did on the iPad's browser, because I'd been under the impression that it just didn't play nice with Parchment at all.)

Turns out there's an invisible text entry field, either right at the last character printed in the status window, or at the bottom edge of the story window. If you feel around you can find it.

(I've done this with http://eblong.com/zarf/zweb/huntdark/ . I haven't tested it with Cold Iron.)

Hm. May I suggest that it might be a little more user-friendly to make the field less invisible, or to provide some other workaround? I guess that the workaround would show up whenever anyone uses Parchment, even if they don't need it, but what with iThings being all the rave now it seems like it might be worth it for outreach's sake.

(I don't have an iPad so I can't look for the text field myself.)

(Definitely OT, but I was impressed at how much of my friend's totally naive input Cold Iron understood. Some of it was built-in I7 parsing, like "pick up the book," but I didn't have to say "No, the game won't understand you unless you say this exactly" as much as I expected.)

Making it mobile friendly is something I'm planning, but I've been waiting to get the new VM to the working stage first. I have an Android phone, but they're similar enough that I expect fixing it for Android will fix it for Apple devices too.

Cool, thanks.