dropping to I6 properly

So I’m writing my own interpreter, and I can make I6 code run it it, but I need to initialize my subsystem with a few custom glk opcodes. I can compile and run I6 to do it, but having a probelm getting it to go in I7. Here my code in I6

Release 1;

Global mainwin = 0;
Constant MAINWIN_ROCK 100;

[ Main;
  @setiosys 2 0; ! select Glk I/O system
  mainwin = glk($0023, 0, 0, 0, 3, MAINWIN_ROCK); ! glk_window_open
  glk($002F, mainwin); ! glk_set_window
  glk($2000); ! initalize graphics lib
  glk($2001); ! initialize display
  print "This is a terminal test.日本語";
];

and here is what I’m trying to do in I7

[code]“temlab” by Halkun

a cube is a room

when play begins:
(- @glk(2000); @glk(2001); -);
say “This is a terminal test.日本語”;
[/code]

It’s saying You wrote '(- @glk(2000); @glk(2001); ’ : but this is a phrase which I don’t recognise, possibly because it is one you meant to define but never got round to, or because the wording is wrong (see the Phrasebook section of the Index to check). Alternatively, it may be that the text immediately previous to this was a definition whose ending, normally a full stop, is missing?

Did I mess the punctuation up?

Now, I know that those two opcodes don’t exist in a “normal” Glk terp. They do in mine though :slight_smile:

You (unfortunately) can’t just include I6 in I7 like that. You have to define a phrase first, and use that in the rule:

[code]
To start glk: (- @glk(2000); @glk(2001); -).

when play begins:
start glk;
say “This is a terminal test.日本語”;[/code]

Have you contacted Zarf to reserve a block of Glk selectors?

It’s not like we get a lot of people wanting to customize this stuff. :slight_smile:

You want to use $1300 to $13FF? That would fit in neatly with what’s already listed.

thanks!

Naaa, My interpreter isn’t compatible with “normal” glulxe games. and the I7 code I’m writing isn’t going to work in “normal” interpreters The blorb file going to be compiled into the executable, and my I/O is wildly different. I’m just taking advantage of the @glk opcode so I didn’t have to write a whole new VM. I’ll be moving my I7 code into Notepad++ (Syntax highlighting FTW) and build the whole C + I6 project via the command line scripts and Code::Blocks. The dispatcher isn’t really that recognizable anymore. I’m only using 4 or 5 of the original glk opcodes (and it’s statically linked to the game anyway). It’s actually quite an elaborate hack. More of a hack and slash really.

Most of the graphics system is going to be hard-coded to my particular game, however, when I’m done. I can actually write a “proper” dispatcher that is a wrapper for the allegro library, which will give inform a “real” graphics system as opposed to what glk has now. I’ll release that if it comes to it.

That’s a project for another time.

I don’t think it matters how compatible it is with a normal interpreter, you should still register your use of glk selectors, and you should probably use gestalt selectors too. Then you could show an error message in a regular interpreter saying that it needs your custom interpreter.

Or, if you’re really replacing glk entirely, then just add a new IO system, like FyreVM did. (But again, ask for a Glulx opcode range.)

Here’s the problem…
You see, I’m not very good at programming. I’m actually shocked I have my own interpreter running. It’s actually Zarf’s+CheapGLK that I got somehow compiled under windows. It took me a day and a half to figure out how to even load a blorb file into it. (I hard-coded it, don’t ask me how the blorb stream thing works. I sort of guessed by context.) I just, finally, understood how a pointers worked about two weeks ago. Well, kind of, anyway. I’m still throwing unsigned chars into functions that require cont *char using ampersands and ignoring the warnings. I have no idea what an “opaque object” is, even though I’m evidently using them.

Because Zarf is awesome at documenting, I was able to to take control of the dispatcher… kind of… I can pass types back and forth, but mostly use it to call void functions that return nothing. That’s all I’m doing. My functions being dispatched are things like draw_an_x() and draw_her_here(). I’m not even loading my graphic files from the blorb because I have no idea how to use it. Though I know it’s some kind of archive file(?) I’m using allegro functions to load my graphics and have my resources in a different folder. As long as it can read my blorb, and as long as I can inline glk functions I’m happy. If I can’t do something on the inform side, I’ll just hardcode the function in C on the other side of the dispatcher.

That’s why assigning or registering glk opcodes are irrelevant. I don’t want to pollute Zarf’s code with my nonsense. I’m just forking it, and making my own mess. It’s also why I want it to be incompatible with everything else, so that no one can run it in another interpreter. I’m actively trying to keep that from happening.

One day I might learn how to return ALLEGRO BITMAP *mybitmap; into the VM so it can can use the library proper. Until then I’m happy punching out chunks of the dispatcher like the Incredible Hulk, and stepping over gestalts, rocks, and other bit of technology I don’t understand.

This is all a big project to make myself a better programmer. You have no idea how much I have learned in the last 4 months. I’m making a game I’ve always want to make, and I’m barreling down it. Yea, I make mistakes, and ho boy do I wish I had another programmer helping me. I admit I’m taking technologies and “breaking” them. But I have something cool here. Right now it looks like Legos mixed in cake batter, but I know I have something.

The core is I7 though. I need it to be. So I can write my prototype stuff in “pure” I7 and then run it in my interpreter and Spackle up the cracks. I love taking things and squishing them into someplace where it’s not supposed to go. I’m actually quite famous online for doing this.

So from time to time I’ll pop out form my lab with goggles on my forehead and as for a wrench, then go back into my workshop and use it as a hammer. I hope that when comes out id the coolest doomsday device ever made…

…or a puppy.

Puppies are cute.

======

On another note.
It seems that my code compiles in the Inform IDE, but it can’t run it (I knew this was going to happen anyway), but I didn’t expect it to just delete the .inf file when it was unsuccessful, and never make a blorb file. I take it the ni.exe file is the command-line inform compiler, is the documentation for that in Inform, or is it elsewhere?

Everything you just described that you are doing: that is what being good at programming is. It certainly isn’t about intentionally taking the long way around. 8)

Indeed so! It’s all about doing things as quickly and simply as possible.

You may find it helpful to turn off the “clean build files from project before closing” preference.

It’s not well-documented. You could download the “Command line Inform built for Linux” package, which is a Perl shell that invokes ni. Read through that and see what it does. Or you could even use it in Windows, if you replace the ni binary with the ni.exe from Windows I7.

Hmm, I decided to fight with Inform with a vengeance today to have it “accept” my “invalid” glk opcodes, and I have discovered something. It’s not failing at runtime, it’s failing at compile time…

Here is an example

"temlab" by Halkun

a cube is a room

To start glk: (- @glk(2000); @glk(2001); -).

first when play begins:
	start glk;
	say "This is a terminal test.日本語";

This is the error I’m getting.

C:\Program Files (x86)\Inform 7\Compilers\inform-632 \
    -kwSDG +include_path=..\Source,.\ auto.inf output.ulx
Inform 6.32 for Win32 (18th November 2010)
auto.inf(10287): Error:  Assembly mistake: syntax is "glk <3 operands: L1 L2 S3>"
>        @glk(2000);
auto.inf(10287): Error:  Assembly mistake: syntax is "glk <3 operands: L1 L2 S3>"
>        @glk(2000); @glk(2001);
Compiled with 2 errors and 1490 suppressed warnings (no output)

So it’ actively rejecting my @glk() opcodes… am I supposed to have them in a format that I7 is supposed to understand? Going further. It seem the inline I6 is a different language than the command-line I6. For example take the following…

"temlab" by Halkun

a cube is a room

To start glk:
	(- 
	Global mainwin = 0;
	Global result = 0;
	Constant MAINWIN_ROCK 100;
	@setiosys 2 0; ! select Glk I/O system
	mainwin = glk($0023, 0, 0, 0, 3, MAINWIN_ROCK); ! glk_window_open
	glk($002F, mainwin); ! glk_set_window
	print "Hello World!^"; 
	-)

first when play begins:
	start glk;
	say "This is a terminal test.日本語";

Here’s the errors I’m getting.

C:\Program Files (x86)\Inform 7\Compilers\inform-632 \
    -kwSDG +include_path=..\Source,.\ auto.inf output.ulx
Inform 6.32 for Win32 (18th November 2010)
auto.inf(10288): Error:  Expected assignment or statement but found Global
>  Global mainwin
auto.inf(10289): Error:  Expected assignment or statement but found Global
>  Global result
auto.inf(10290): Error:  Expected assignment or statement but found Constant
>  Constant MAINWIN_ROCK
auto.inf(10292): Error:  '=' applied to undeclared variable
>  mainwin = glk($0023, 0, 0, 0, 3,MAINWIN_ROCK);
auto.inf(10292): Error:  Expected assignment or statement but found <constant>
>  mainwin = glk($0023, 0, 0, 0, 3,MAINWIN_ROCK);
Compiled with 5 errors and 1490 suppressed warnings (no output)

So the internal I6 inline thing don’t understand the Global, constant, or assignment operators correctly. However, I know that inline I6 is good because it compiles on the command line by itself and runs fine. Is the "Internal I6 different? Where can I look to figure out how to make valid inline I6?

Globals and constants must be defined outside of functions/phrases. Also, there’s a difference between a glk() function call, and the @glk opcode.

Yea, I changed it to the glk function and now it works :slight_smile: