Z-Machine terp
Fillmore
I have some ideas of things I would like this terp to do, but I thought it
might be a nice idea to find out if there are any features that other people
on this newsgroup would like in a Z-Machine terp.
I don't mean things that actually extend the Z-Machine, like better sound
support or whatever, just nice extras, like blorb support, or optional
features that you really like, like colour, or full Unicode support, or
whatever.
Bear in mind that I absolutely do not guarantee to implement any or all
features suggested, but I probably will if I like them (and can actually
program them). This is mainly just to get an idea of what people think
are important features to have.
--
Fillmore
John E
Full screen (in windows not DOS terminal)
Full screen (in mac ;-) )
(full screen in both cases meaning NO border)
Antialiased text.
A format that looks like a book that gets writen on, then when it fills the
page will turn :-P (hey it's a WISH list)
auto detect of common phrases such as "you can't go that way", "you have
died", and other library messages that the user can assign sounds to.
example
"you can't go that way" plays "DOH!",
"you have died" plays taps.
Other than that I wish I could open a terp that would detect my story files
and present them to me with customizable images of books, where I could even
paste in images from the orginal boxes or make my own for comp games.
-John
L. Ross Raszewski
I don't want to toot my own horn too loudly, but my GLK port has lots
of features in it which I more or less added specifically because I
thought that they would be useful in an IF interpreter, You might want
to look at its readme to see the sort of features it makes available.
Here's some thoughts on what I don't like to find lacking in a
Z-terp...
Command line recall
Multiple undo
command aliasing
full color and z6 support
blorb
scrollback
user control of the behavior of the piracy opcode
A specific interpreter identification (Z-code allows a header area for
writing a number or character which uniquely identifies which
interpreter is being used, so that the game file can modify its
behavior to deal well with the particular quirks of a specific
interpreter)
The ability to override the game file's attempts at color
The ability to ignore or gracefulyl recover from Z-code errors.
An assembly level Z-code debugger :-)
John Colagioia
> So, I'm writing a Z-Machine terp. It is not done. It's getting there. Now,
> I have some ideas of things I would like this terp to do, but I thought it
> might be a nice idea to find out if there are any features that other people
> on this newsgroup would like in a Z-Machine terp.
> I don't mean things that actually extend the Z-Machine, like better sound
> support or whatever, just nice extras, like blorb support, or optional
> features that you really like, like colour, or full Unicode support, or
> whatever.
Blorb might be nice, just so I (on my PC) can finally try the example game.
Unicode, I'd consider more important, as this community is extremely
multinational.
A feature I'd really like to see, though, would be an option to let the
Z-Machine do file I/O without my intervention. That is, for me, the user, to
permit the game to access files without my being asked if the filename is
correct.
Other, more trivial features would include full, by-the-spec sound support, full
v6 implementation, user-level color configuration, and...that's probably pretty
much it.
[...]
David Given
"Fillmore" <Nos...@Hotmail.com> writes:
> So, I'm writing a Z-Machine terp. It is not done. It's getting there. Now,
> I have some ideas of things I would like this terp to do, but I thought it
> might be a nice idea to find out if there are any features that other people
> on this newsgroup would like in a Z-Machine terp.
What platform's it for?
My wish list:
Z6.
That's about it, really. I'd quite like an assembly-level debugger, but
Nitfol's got that (even if I can't get it to work). But Z6 is the thing
that will have raif denizens queuing up to kiss your feet.
--
+- David Given --------McQ-+ WARNING: THIS IS A 100% MATTER PRODUCT
| Work: d...@tao-group.com | In the unlikely event of this merchandise
| Play: d...@cowlark.com | contacting antimatter in any form, a catastrophic
+- http://www.cowlark.com -+ explosion will result.
Kevin Bracey
John Colagioia <JCola...@csi.com> wrote:
> A feature I'd really like to see, though, would be an option to let the
> Z-Machine do file I/O without my intervention. That is, for me, the user,
> to permit the game to access files without my being asked if the filename
> is correct.
That's already there in the Z-machine - the extended SAVE opcode will save
silently to the specified filename. If your interpreter's prompting, it's at
fault. The Z-spec isn't absolutely concrete on that point, but I'm sure that
was the intent. Maybe someone could double-check with an Infocom interpreter?
--
Kevin Bracey, Principal Software Engineer
Pace Micro Technology plc Tel: +44 (0) 1223 518566
645 Newmarket Road Fax: +44 (0) 1223 518526
Cambridge, CB5 8PB, United Kingdom WWW: http://www.pace.co.uk/
Fillmore
news:nfljj9...@127.0.0.1...
> What platform's it for?
At the moment, Windows. Should be *really* easy to run on other platoforms,
though. It's written in python.
> My wish list:
>
> Z6.
Hey, wow, that's on my wish list too.
> That's about it, really. I'd quite like an assembly-level debugger, but
> Nitfol's got that (even if I can't get it to work). But Z6 is the thing
> that will have raif denizens queuing up to kiss your feet.
Sounds like fun.
--
Fillmore
Fillmore
"Kevin Bracey" <kevin....@pace.co.uk> wrote in message
news:44c219f4a%kbr...@kbracey.cam.pace.co.uk...
> In message <3B5D7D1A...@csi.com>
> John Colagioia <JCola...@csi.com> wrote:
>
> > A feature I'd really like to see, though, would be an option to let the
> > Z-Machine do file I/O without my intervention. That is, for me, the
user,
> > to permit the game to access files without my being asked if the
filename
> > is correct.
>
> That's already there in the Z-machine - the extended SAVE opcode will save
> silently to the specified filename. If your interpreter's prompting, it's
at
> fault. The Z-spec isn't absolutely concrete on that point, but I'm sure
that
> was the intent. Maybe someone could double-check with an Infocom
interpreter?
Infocom DOS z6 interpreters prompt the user for the name (Infocom z5
interpreters don't actually have this feature). The spec doesn't say one
way or the other, so presumably the terp can do whichever it likes.
--
Fillmore
Andrew Hunter
>On Mon, 23 Jul 2001 23:14:53 +0100, Fillmore <Nos...@Hotmail.com> wrote:
>>So, I'm writing a Z-Machine terp. It is not done. It's getting there. Now,
>>I have some ideas of things I would like this terp to do, but I thought it
>>might be a nice idea to find out if there are any features that other people
>>on this newsgroup would like in a Z-Machine terp.
>>
>>I don't mean things that actually extend the Z-Machine, like better sound
>>support or whatever, just nice extras, like blorb support, or optional
>>features that you really like, like colour, or full Unicode support, or
>>whatever.
>>
>>Bear in mind that I absolutely do not guarantee to implement any or all
>>features suggested, but I probably will if I like them (and can actually
>>program them). This is mainly just to get an idea of what people think
>>are important features to have.
>>
>
>I don't want to toot my own horn too loudly, but my GLK port has lots
>of features in it which I more or less added specifically because I
>thought that they would be useful in an IF interpreter, You might want
>to look at its readme to see the sort of features it makes available.
>
>Here's some thoughts on what I don't like to find lacking in a
>Z-terp...
>
>Command line recall
>Multiple undo
>command aliasing
I don't know what it says about me, that I wish I had this every time I
type 'x' into an original Infocom game, and *still* haven't stuck it
into Zoom. It's not even as if it would be particularily hard work...
>full color and z6 support
>blorb
>scrollback
Unfortunately, there's no real way to implement scrollback in a proper v6
interpreter. The screen model assumes that you have exclusive access to the
screen (ie, the screen is a pixmap). It becomes somewhat... hard... to
calculate where everything should be.
Of course, it's perfectly possible with the other versions ;-) You can do
a sort-of-scrollback thing ala nitfol, but I think you'll get into trouble
when you try to draw pictures and things.
>user control of the behavior of the piracy opcode
Hmm, when is this useful? (Being a 0op and rare in Inform games, piracy
makes a natural opcode to choose to mean 'breakpoint'...)
>A specific interpreter identification (Z-code allows a header area for
>writing a number or character which uniquely identifies which
>interpreter is being used, so that the game file can modify its
>behavior to deal well with the particular quirks of a specific
>interpreter)
We'd need a registry of interpreters. And we'd have a maximum limit of 255
total :-) This was only really used by Infocom's interpreters, and for
some games (well, Beyond Zork) needs to be explicitly set to a specific
version to get desirable behaviour. A better place to put this (if at all)
would be the header extension block. And that's probably not a good idea
either. What's the point of writing a game for a portable machine if you're
going to add features that only work on specific implementations?
>The ability to override the game file's attempts at color
>The ability to ignore or gracefulyl recover from Z-code errors.
>An assembly level Z-code debugger :-)
Andrew.
--
____
\ \ \ Andrew Hunter <and...@logicalshift.demon.co.uk>
> > > http://www.logicalshift.demon.co.uk (me)
/_/_/ http://www.impulse.org.uk (impulse)
Jon Ingold
separate window. The thing I hate in games is when they have long
screens of text and you press More, and lose your place; so I'd
appreciate a scroll-bar up the side that allows me (at least to have the
option) of scrolling down with that rather than jump a screenful with
the space-bar, so I won't lose the place.
Jon
L. Ross Raszewski
<and...@logicalshift.demon.co.uk> wrote:
>
>Unfortunately, there's no real way to implement scrollback in a proper v6
>interpreter. The screen model assumes that you have exclusive access to the
>screen (ie, the screen is a pixmap). It becomes somewhat... hard... to
>calculate where everything should be.
Yeah. But this is a wish list.
>>user control of the behavior of the piracy opcode
>
>Hmm, when is this useful? (Being a 0op and rare in Inform games, piracy
>makes a natural opcode to choose to mean 'breakpoint'...)
Mostly, it's useful because if piracy is user-settable, it's a way to
pass a piece of information from the environment to the game.
>
>We'd need a registry of interpreters. And we'd have a maximum limit of 255
>total :-) This was only really used by Infocom's interpreters, and for
>some games (well, Beyond Zork) needs to be explicitly set to a specific
>version to get desirable behaviour. A better place to put this (if at all)
>would be the header extension block. And that's probably not a good idea
>either. What's the point of writing a game for a portable machine if you're
>going to add features that only work on specific implementations?
>
Well, lots of whats in the spec is left ot interpreter's
discression.
If I'm writing a v6 game, as an example, I know that Nitfol does its
darndest to make the display sane, but it's not going to be quite
right. I can check the interpreter ID in my game code, however, and
turn off the optional features which don't work well therein. (And the
stuff that's not strictly illegal, but frotz doesn't consider an
error. Even better, if I could identify Zip, I could keep it from
crashing on @set_colour 0 )
Robb Sherwin
Yes, yes, yes!
(I hate to leave a 'Pokey the Penguin' meets 'The Me-Too Guy from AOL'
kind of message, but I really have nothing to add other than complete
agreement with the above sentiment.)
Robb
Kevin Bracey
lrasz...@loyola.edu (L. Ross Raszewski) wrote:
>
> Well, lots of whats in the spec is left ot interpreter's
> discression.
>
> If I'm writing a v6 game, as an example, I know that Nitfol does its
> darndest to make the display sane, but it's not going to be quite
> right. I can check the interpreter ID in my game code, however, and
> turn off the optional features which don't work well therein. (And the
> stuff that's not strictly illegal, but frotz doesn't consider an
> error. Even better, if I could identify Zip, I could keep it from
> crashing on @set_colour 0 )
For god's sake, no. Do you know the main reason web pages don't work on my
platform? Because of broken JavaScript or server-based checks for whether the
web browser is Internet Explorer or Netscape Navigator. Oddly enough, it's
neither, and all too often the script breaks or server refuses to serve. If
the author of the page had just written well-formed HTML in the first place,
the page would have worked.
Don't take your game down that route. Release it as is, listing known
interpreter problems in the release notes. If the game is any good, someone
will fix the interpreters, or people will switch to using better ones.
And I'll gladly playtest it for you on Zip 2000.
Beyond Zork is one of the most problematic Infocom games to run successfully
precisely because of the sort of behaviour you're advocating.
Anyway, isn't there a logical hole here? If the interpreters currently can't
be identified, then they would have to be changed to give you the ID. In
which case, why not change them to fix the bugs you're trying to work
around???
Matthew Russotto
L. Ross Raszewski <lrasz...@loyola.edu> wrote:
>On Tue, 24 Jul 2001 18:03:49 +0000, Andrew Hunter
><and...@logicalshift.demon.co.uk> wrote:
>>
>>Unfortunately, there's no real way to implement scrollback in a proper v6
>>interpreter. The screen model assumes that you have exclusive access to the
>>screen (ie, the screen is a pixmap). It becomes somewhat... hard... to
>>calculate where everything should be.
>
>Yeah. But this is a wish list.
I made an attempt at scrollback in V6. It was... unsatisfactory.
Which is one reason my V6 Zip Infinity has been incomplete and
unreleased for years.
--
Matthew T. Russotto russ...@pond.com
=====
Get Caught Reading, Go To Jail!
A message from the Association of American Publishers
Free Dmitry Sklyarov! DMCA delanda est!
http://www.freedmitry.org
John Colagioia
> In message <tlrk2gt...@corp.supernews.com>
> lrasz...@loyola.edu (L. Ross Raszewski) wrote:
[...]
> > Even better, if I could identify Zip, I could keep it from
> > crashing on @set_colour 0 )
> For god's sake, no. Do you know the main reason web pages don't work on my
> platform? Because of broken JavaScript or server-based checks for whether the
> web browser is Internet Explorer or Netscape Navigator. Oddly enough, it's
> neither, and all too often the script breaks or server refuses to serve. If
> the author of the page had just written well-formed HTML in the first place,
> the page would have worked.
What people often fail to realize, however, is that this is not a fault in
JavaScript (though JavaScript has many faults), but rather the fault of the
programmers, who make basic assumptions about the way the world works, which are
patently incorrect and dangerous. Since a good programmer can make good use of
these features (for example, exploiting special features that Opera might have,
only on Opera clients, and supplying an alternative interface for anyone else),
it would be absurd to remove this possibility from the programmer's hands. It
would be much better to track down the programmers who do things like this and
smack them silly. Or maybe educate them. I'm not sure which would make me feel
better and which would be more productive...
Anders Hellerup Madsen
>
> In article <tlrk2gt...@corp.supernews.com>,
> L. Ross Raszewski <lrasz...@loyola.edu> wrote:
> >On Tue, 24 Jul 2001 18:03:49 +0000, Andrew Hunter
> ><and...@logicalshift.demon.co.uk> wrote:
> >>
> >>Unfortunately, there's no real way to implement scrollback in a proper v6
> >>interpreter. The screen model assumes that you have exclusive access to the
> >>screen (ie, the screen is a pixmap). It becomes somewhat... hard... to
> >>calculate where everything should be.
> >
> >Yeah. But this is a wish list.
>
> I made an attempt at scrollback in V6. It was... unsatisfactory.
>
> Which is one reason my V6 Zip Infinity has been incomplete and
> unreleased for years.
Now I have no knowledge at all about how the z-machine works in general
or how version 6 works for that matter. But it seems to me that nomatter
how the display is (graphical, just a bunch of pixels actually it seems)
the game has to output some text to the screen. Then it would just be a
matter of writing the text both on the screen, and in a scrollback
buffer. Then the user could press a key or a key combination to enter
scrollbackmode and the main display could be switch to the scrollback
buffer or the scrollback could be opened in a new window or whatever.
--
Anders
Andrew Plotkin
> Matthew Russotto skriver:
>>
>> I made an attempt at scrollback in V6. It was... unsatisfactory.
>>
>> Which is one reason my V6 Zip Infinity has been incomplete and
>> unreleased for years.
> Now I have no knowledge at all about how the z-machine works in general
> or how version 6 works for that matter. But it seems to me that nomatter
> how the display is (graphical, just a bunch of pixels actually it seems)
> the game has to output some text to the screen.
You might think that, until you realize that V6 used a system of
virtual windows -- it output text *with positioning information*.
(I simplify, but that happens enough that reconstructing a simple text
stream is... difficult.)
--Z
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*
* Doesn't matter who you vote for, if the Supreme Court votes for me.
L. Ross Raszewski
Yes. Butthis might not produce a very friendly scrollback; what you
coudl do is reproduce how the screen looked at some time in the past,
but what you really want is to scroll backwards through the contents
of the windows which scroll. Since windows in v6 don't "own" their
content (this is one of the things that zarf changed in glulx, and the
motivation probably included a desire to make scrollback tenable, but
it does sacrifice quite a bit of the layout flexibility v6 has), you
can't do that.
Supposing you took an image of the screen whenever input was asked for
(including [more] prompts), you could have the scrollback display
these, but it wouldn't be a scrollback that would please a lot of
people (and it'd be awfully memory intensive.) I think it would be
good enough for me, but I can sympathize with those who would find it
an awfully clutzy way to handle scrollback.
L. Ross Raszewski
Well, I think what was proposed was, essentially, takign a screenshot
at some useful interval, and havign the scrollback display these
screenshots, whcih could work, but seems awfully klutzy.
Fred the Wonder Worm
In article <3B616ECE...@csi.com>,
John Colagioia <JCola...@csi.com> wrote:
> What people often fail to realize, however, is that this is not a fault
> in JavaScript (though JavaScript has many faults), but rather the fault
> of the programmers, who make basic assumptions about the way the world
> works, which are patently incorrect and dangerous.
Like assuming that I am willing to run JavaScript in the first place. :(
Cheers,
Geoff.
-----------------------------------------------------------------------------
Geoff Bailey (Fred the Wonder Worm) | Programmer by trade --
ft...@maths.usyd.edu.au | Gameplayer by vocation.
-----------------------------------------------------------------------------
John Colagioia
[...v6 Scrollback...]
>Well, I think what was proposed was, essentially, takign a screenshot
>at some useful interval, and havign the scrollback display these
>screenshots, whcih could work, but seems awfully klutzy.
It depends how it's handled, really. For example, one could make the
"useful interval" any time that text is scrolled off the top of the screen
(since I believe it does scroll, right?), and then only save the updates.
When the scrollbar is used, instead of showing a full screenshot, instead
display a screen reconstructed from the incremental shots.
Of course, given that fonts will be likely graphically rendered, allowing
text selection and interaction with the system clipboard is "left as an
exercise for the reader"...
Alpha Particle Petrofsky
> >at some useful interval, and havign the scrollback display these
> >screenshots, whcih could work, but seems awfully klutzy.
>
> It depends how it's handled, really. For example, one could make the
"Why, it's so crazy, it JUST MIGHT WORK!!!"
-- Ancient Chinese Proverb
Below is some quickly hacked code to provide this sort of scrollback
in unix-frotz. Unix-frotz doesn't really support graphics, but it
does display outlines of where the pictures would go, so it may help
you imagine what kind of results you would get if this were
implemented in a GUI interpreter.
The algorithm used here is to save an image of the screen after each
input and each time a window scrolls. When you peruse the scrollback
with the up and down arrow keys, the images are displayed one at a
time. When you use the pageup/pagedown keys, things scroll one turn
at a time. We define a turn to be the interval between non-timed-out
full-line inputs.
This approach has the virtue that it somewhat works no matter what the
game throws at it. Interesting results are obtained with all four
infocom v6 games. You can even hold down the up arrow key after
you've played a game of FreeFall and watch all the tiles fall upwards
if you like (this ability is slightly spooky, akin to pausing live
TV).
Even when playing old version 3 games, this kind of scrollback is
interesting because it updates the status line as you scroll through
the transcript. This could make it easier to find your place. Do any
released interpreters provide synchronized scrolling like this?
To make this UI more palatable, one would need to get PageUp/PageDown
to correspond to something like pages, rather than turns. While not
completely possible in general, I think you could get pretty close
with some intelligent tracking of the data on the screen. (Dumb-frotz
does something like this, but it could be hard to adapt that to a
graphics display.)
The code as written here is extremely wasteful of memory, but I think
this could fairly easily be fixed by storing each image as some sort
of compressed diff from the previous image. This should be equally
applicable to graphical displays.
USAGE: to activate the scrollbar, type Control-V. Then use up/down
arrows and pageup/pagedown keys to scroll. To resume play, press
return.
This works quite smoothly on my 90Mhz 586 linux console. Under xterm,
I get some redisplay problems with the scrollbar itself (the last
column of the terminal), but the scrolling of the rest of the window
seems to work.
Disclaimer: This software is posted AS IS, and comes with NO WARRANTY.
Blah, blah, blah. If you've never written or hacked on a z-machine
interpreter, please don't expect this code to be in any way useful to
you.
--- unix-frotz-2.41/ux_frotz.h Tue Nov 21 22:46:07 2000
+++ unix-frotz/ux_frotz.h Mon Jul 30 01:31:29 2001
@@ -70,6 +70,9 @@
extern int current_color; /* ux_text */
extern bool color_enabled; /* ux_text */
extern bool unix_init_pictures(); /* ux_pic */
+extern void unix_init_scrollback(); /* ux_screen */
+extern void unix_save_screen(int); /* ux_screen */
+extern void unix_do_scrollback(); /* ux_screen */
extern char stripped_story_name[FILENAME_MAX+1];
extern char semi_stripped_story_name[FILENAME_MAX+1];
extern char *progname;
--- unix-frotz-2.41/ux_init.c Sun May 20 23:39:10 2001
+++ unix-frotz/ux_init.c Sun Jul 29 18:58:19 2001
@@ -383,6 +383,9 @@
if (user_screen_width != -1)
h_screen_cols = user_screen_width;
+ /* FIXME: Reserve last column for scrollbar (temporary hack). */
+ h_screen_cols--;
+
h_screen_width = h_screen_cols;
h_screen_height = h_screen_rows;
@@ -440,6 +443,8 @@
}
os_set_colour(h_default_foreground, h_default_background);
os_erase_area(1, 1, h_screen_rows, h_screen_cols);
+
+ unix_init_scrollback();
}/* os_init_screen */
/*
--- unix-frotz-2.41/ux_input.c Sat May 19 17:28:33 2001
+++ unix-frotz/ux_input.c Mon Jul 30 01:37:04 2001
@@ -150,6 +150,11 @@
case MOD_CTRL ^ 'L': case MOD_CTRL ^ 'R':
clearok( curscr, 1); refresh(); clearok( curscr, 0);
continue;
+
+ case MOD_CTRL ^ 'V':
+ unix_do_scrollback();
+ continue;
+
/* Lucian P. Smith reports KEY_ENTER on Irix 5.3. LF has never
been reported, but I'm leaving it in just in case. */
case '\n': case '\r': case KEY_ENTER: return ZC_RETURN;
@@ -535,6 +540,7 @@
confused if the cursor is not at the end of the input
line. */
move(y, x + len);
+ unix_save_screen(ch != ZC_TIME_OUT);
return ch;
}
}
@@ -559,6 +565,8 @@
c = (zchar) unix_read_char(0);
if (!cursor) curs_set(1);
+
+ unix_save_screen(0);
return c;
}/* os_read_key */
--- unix-frotz-2.41/ux_screen.c Sat Oct 28 15:50:21 2000
+++ unix-frotz/ux_screen.c Mon Jul 30 01:37:24 2001
@@ -45,6 +45,7 @@
{
int y, x, i, j;
+#ifdef NO_SCROLLBAR
/* Catch the most common situation and do things the easy way */
if ((top == 1) && (bottom == h_screen_rows) &&
(left == 1) && (right == h_screen_cols)) {
@@ -58,7 +59,9 @@
#else
erase();
#endif
- } else {
+ } else
+#endif
+ {
/* Sigh... */
int saved_style = current_text_style;
os_set_text_style(current_color);
@@ -87,6 +90,7 @@
{
top--; left--; bottom--; right--;
+ unix_save_screen(0);
if ((left == 0) && (right == h_screen_cols - 1)) {
static int old_scroll_top = 0;
static int old_scroll_bottom = 0;
@@ -127,3 +131,130 @@
else if (units < 0)
os_erase_area(top + 1, left + 1, top - units, right + 1);
}/* os_scroll_area */
+
+#define NUM_SAVED_SCREENS 100000
+static chtype *saved_screens[NUM_SAVED_SCREENS];
+static char scroll_unit[NUM_SAVED_SCREENS];
+static int next_screen_number = 0;
+
+void unix_init_scrollback(void)
+{
+ unix_save_screen(0);
+}
+
+/* Call often with unit = 0, less often with unit = 1. */
+void unix_save_screen(int unit)
+{
+ int r, c, x, y;
+ chtype *ch = malloc(h_screen_rows * h_screen_cols * sizeof(chtype));
+
+ if (!ch)
+ os_fatal("Out of memory for scrollback");
+
+ saved_screens[next_screen_number] = ch;
+ scroll_unit[next_screen_number] = unit;
+ next_screen_number++;
+ getyx(stdscr, y, x);
+ for (r = 0; r < h_screen_rows; r++)
+ for (c = 0; c < h_screen_cols; c++)
+ *ch++ = mvinch(r, c);
+ move(y, x);
+}
+
+void unix_restore_screen(int n)
+{
+ int r, c;
+ chtype *ch;
+
+ ch = saved_screens[n];
+ for (r = 0; r < h_screen_rows; r++)
+ for (c = 0; c < h_screen_cols; c++)
+ mvaddch(r, c, *ch++);
+}
+
+#define MOD_CTRL 0x40
+#define MOD_META 0x80
+
+void unix_do_scrollback(void)
+{
+ int x, y, r, c;
+ int screen_num = next_screen_number;
+
+ unix_save_screen(0);
+ getyx(stdscr, y, x);
+ attrset(0);
+ timeout(-1);
+
+ for (;;) {
+ int thumb_top, thumb_bottom;
+
+ unix_restore_screen(screen_num);
+
+ /* Draw scrollbar. */
+ /* TODO: use ACS line-drawing characters */
+ thumb_top = screen_num * h_screen_rows / next_screen_number;
+ thumb_bottom = (h_screen_rows
+ - ((next_screen_number - 1 - screen_num) * h_screen_rows
+ / next_screen_number));
+ for (r = 0; r <= h_screen_rows; r++)
+ mvaddch(r, h_screen_cols, ' ');
+ for (r = thumb_top; r < thumb_bottom; r++)
+ mvaddch(r, h_screen_cols, A_REVERSE | '|');
+ move(thumb_bottom - 1, h_screen_cols);
+
+ switch (c = getch()) {
+ case MOD_CTRL ^ 'V': case ' ': case KEY_NPAGE:
+ if (screen_num < next_screen_number - 1) {
+ do
+ screen_num++;
+ while (screen_num < next_screen_number - 1
+ && scroll_unit[screen_num] == 0);
+ }
+ continue;
+
+ case MOD_META ^ 'v': case KEY_PPAGE:
+ case KEY_BACKSPACE: case '\b': case MOD_CTRL ^ '?':
+ if (screen_num > 0) {
+ do
+ screen_num--;
+ while (screen_num > 0 && scroll_unit[screen_num] == 0);
+ }
+ continue;
+
+ case MOD_CTRL ^ 'N': case KEY_DOWN:
+ if (screen_num < next_screen_number - 1)
+ screen_num++;
+ continue;
+
+ case MOD_CTRL ^ 'P': case KEY_UP:
+ if (screen_num > 0)
+ screen_num--;
+ continue;
+
+ case MOD_META ^ '<': case KEY_HOME:
+ screen_num = 0;
+ continue;
+
+ case MOD_META ^ '>': case KEY_END:
+ screen_num = next_screen_number - 1;
+ continue;
+
+ case '\r':
+ break;
+
+ default:
+ beep();
+ break;
+ }
+ break;
+ }
+ next_screen_number--;
+ unix_restore_screen(next_screen_number);
+
+ /* Erase scrollbar. */
+ for (r = 0; r <= h_screen_rows; r++)
+ mvaddch(r, h_screen_cols, ' ');
+ /* Restore attributes. */
+ os_set_text_style(current_text_style);
+ move(y, x);
+}