Jump to content
IGNORED

New Infocom style adventure - The Locked Room


Shift838

Recommended Posts

Very odd boot information - I have a couple (3?) vintage Infocom games from BITD on original media, two I've had since the 80's (Zork I and HHGTTG), and one I picked up in a big random eBay purchase about 20 years ago now (Leather Goddesses of Phobos). All three require BASIC to be removed (on an 800) or with OPTION held to suppress it, and all three autoboot. 

Link to comment
Share on other sites

9 hours ago, EdwardianDuck said:

I guess my understanding of how this works is wrong. Sorry about that, I wasn't intending to spread confusion and misinformation. I won't post on this subject again.

my understand was off too.  We both learned something so that's good.  

Link to comment
Share on other sites

8 hours ago, DrVenkman said:

Very odd boot information - I have a couple (3?) vintage Infocom games from BITD on original media, two I've had since the 80's (Zork I and HHGTTG), and one I picked up in a big random eBay purchase about 20 years ago now (Leather Goddesses of Phobos). All three require BASIC to be removed (on an 800) or with OPTION held to suppress it, and all three autoboot. 

From my understanding it is also dependent on which Infocom Interpreter was used.  From my research (asking a lot of questions!) I have been told there are 3 different ones.

 

 

Link to comment
Share on other sites

8 hours ago, Shift838 said:

From my understanding it is also dependent on which Infocom Interpreter was used.  From my research (asking a lot of questions!) I have been told there are 3 different ones.

 

 

Besides the 3 vintage original disks I own, I’ve played a bunch of others over the years via emulation, usually using ATR files from either DJayBee’s cracks thread or ATX files from the A8 Preservation Initiative archive. They all auto-boot and require BASIC carts to be removed when using OSb or to boot with OPTION held to suppress it on an XL/XE operating system. Typing “DOS” from BASIC is just not something you have to do with vintage Infocom original titles.

  • Like 1
Link to comment
Share on other sites

This almost seems like the Commodore quirk of having to load everything from the BASIC interpreter prompt, very strange indeed. It's just not the way to get all available memory out of the Atari.

Edited by _The Doctor__
Link to comment
Share on other sites

13 hours ago, Shift838 said:

From my understanding it is also dependent on which Infocom Interpreter was used.  From my research (asking a lot of questions!) I have been told there are 3 different ones.

 

 

It depends what you mean by that.  There are at least 8 official Infocom z-machine versions.  The Atari only used Z3, although there was discussion that Z4 and Z5 could be done:  

 

As for typing DOS to run the game, it just sounds like the game is being jacked into the DUP init vectors instead of doing it "properly" with its own boot code.

 

But I haven't looked.... I'm just speculating :)

 

  • Like 1
Link to comment
Share on other sites

5 hours ago, kheller2 said:

As for typing DOS to run the game, it just sounds like the game is being jacked into the DUP init vectors instead of doing it "properly" with its own boot code.

Yeah.

 

Clearly at one stage the build tools used to create the atr did things this odd way- the documentation of the build tools author's magnum opus 'Hibernated 1- the Director's Cut' instructs Atari users to enable/insert BASIC then type DOS at the READY prompt.

 

But (as others have noted) the current version of the build tools on GitHub (Ver 1.5, Apr 3 2022) produce an auto-booting atr for which BASIC is not required.

  • Like 3
Link to comment
Share on other sites

10 minutes ago, drpeter said:

the documentation of the build tools author's magnum opus 'Hibernated 1- the Director's Cut' instructs Atari users to enable/insert BASIC then type DOS at the READY prompt.

That's funny because I actually have Hibernated 1 and it boots right up without BASIC. 

  • Like 1
Link to comment
Share on other sites

By default, the a8bit.sh build script bundles the early interpreter but you can invoke it with flag -2 to create a two disk distribution using the final Atari 8-bit interpreter Infocom released, which is version G. The Atari build script has a disk creator utility embedded, which takes care of patching your story file, splitting it at the defined offset and then creating the two disks which allow you to play the game. In the build directory, fire the script like this a8bit.sh -2 and the magic will happen. You may also want to change all.sh by adding the -2 flag and please consider editing bundle.sh so that you make sure it will zip both disk files.

 

If you edited everything and it still makes a disk that requires BASIC and then typing DOS... then you may have to fix the disk manually as has been noted in this thread.

 

I seems the early interpreter is rather limited all thing considered and it's best to run with the last one as you won't run out of space as you expand your and edit your adventures

 

Hybernated -1 Directors cut...

Atari 8-bit:
Insert game disk 1, the game will auto-boot
When prompted insert game disk 2

 

that's a clue.

Edited by _The Doctor__
Link to comment
Share on other sites

5 hours ago, Shift838 said:

This is the same version of build tools I am using.

Yeah, after a little experimentation it seems that a single-disk build will only successfully auto-boot without BASIC for a very minimal PunyInform game.

A two-disk build auto-boots without BASIC fine.

 

It also seems that even with a minimal PunyInform game the single-disk build is very slow to repond to commands without some sort of disk acceleration, on account of excessive disk churning- far more than happens with the early single-disk Infocom games like Zork I.  Presumably this is due to differences in how on-disk Z-machine static/dynamic memory is cached/swapped to and from Atari RAM.  With disk acceleration, it's fine apart from the BASIC/DOS thing- if you want the convenience of not having to swap disks during boot-up and/or to have that authentic early Infocom interpreter experience.

Edited by drpeter
Link to comment
Share on other sites

The very short story files will drive the interpret crazy. (from memory) there is some kind of disk caching to prevent re-reading the same sectors, but very short files + lots of free ram = very long cache -> signed byte overflow -> craziness.

Link to comment
Share on other sites

24 minutes ago, jindroush said:

The very short story files will drive the interpret crazy. (from memory) there is some kind of disk caching to prevent re-reading the same sectors, but very short files + lots of free ram = very long cache -> signed byte overflow -> craziness.

Interesting... will see how a medium-sized story file (i.e. one that only just fits onto one disk along with the interpreter) behaves...

Link to comment
Share on other sites

15 minutes ago, drpeter said:

Interesting... will see how a medium-sized story file (i.e. one that only just fits onto one disk along with the interpreter) behaves...

I know I said I would stop posting here, but here's a worked example (still a beta) https://forums.atariage.com/topic/332183-duck-me-an-old-fashioned-1980s-style-text-adventure/#comment-5176022 which is ~90K on a single bootable disk.

 

Warning, it's a terrible game.

Edited by EdwardianDuck
Link to comment
Share on other sites

58 minutes ago, jindroush said:

The very short story files will drive the interpret crazy. (from memory) there is some kind of disk caching to prevent re-reading the same sectors, but very short files + lots of free ram = very long cache -> signed byte overflow -> craziness.

From what I remember the interpreter uses a flag in the z-file header to determine if the title is 2-sided or not and then there is a 'resident' portion size too.

The interpreter is less than 8K in size, I reworked it to run titles from cartridge. 

Link to comment
Share on other sites

2 hours ago, EdwardianDuck said:

I know I said I would stop posting here, but here's a worked example (still a beta) https://forums.atariage.com/topic/332183-duck-me-an-old-fashioned-1980s-style-text-adventure/#comment-5176022 which is ~90K on a single bootable disk.

 

Warning, it's a terrible game.

I haven't gone far enough to comment on the game, but can confirm that the experience feels a lot more like the original Zork I disk.

 

So previous disk-churning observations do perhaps seem to be an issue related to minimal story size.

 

From what you say, this compiles to a single disk with the Puddle Build tools without the need for BASIC on boot?  Again, perhaps a function of story size?

Link to comment
Share on other sites

2 hours ago, Wrathchild said:

I reworked it to run titles from cartridge.

That sounds nifty.

 

Were the story files loaded from disk with the cartridge inserted?  Or everything held on cartridge?  Which story files did it run with- Inform-compiled-to-z3 or Infocom .dat or both?

Link to comment
Share on other sites

Just now, drpeter said:

Were the story files loaded from disk with the cartridge inserted?  Or everything held on cartridge?  Which story files did it run with- Inform-compiled-to-z3 or Infocom .dat or both?

All from cartridge, eliminating the swap-side activity. Compilations made with the original game titles but could also be done with any z3.

 

 

Link to comment
Share on other sites

21 minutes ago, drpeter said:

I haven't gone far enough to comment on the game, but can confirm that the experience feels a lot more like the original Zork I disk.

 

So previous disk-churning observations do perhaps seem to be an issue related to minimal story size.

 

From what you say, this compiles to a single disk with the Puddle Build tools without the need for BASIC on boot?  Again, perhaps a function of story size?

Effectively yes. I fiddled about with the A8 script from the Puddle Build tools because they don't seem to work on macOS out of the box (or possibly they do and I don't know how to run them on macOS), but the actual process is the same.

Link to comment
Share on other sites

3 hours ago, Wrathchild said:

From what I remember the interpreter uses a flag in the z-file header to determine if the title is 2-sided or not and then there is a 'resident' portion size too.

The interpreter is less than 8K in size, I reworked it to run titles from cartridge. 

Yep. But there is a computation of cache size. Cached sector numbers are stored in $600-$67F (low) and $680-$6FF (high). $80 is maximum number, but this is computed as a number of pages between end of resident part and memtop page. And that could overflow for short stories, as there is no test. Cache size is stored to $BD in Zork 1 interpreter. This is subsequently used in ZBYTE reads, which reads from cached sectors - this is so called 'high' memory - see the table at the end of this link https://www.inform-fiction.org/zmachine/standards/z1point0/sect01.html

Edited by jindroush
  • Like 1
Link to comment
Share on other sites

1 minute ago, drpeter said:

but could also be done with any z3

I don't suppose you still have the details of the build process?

 

EDIT:  I guess for modern tastes, the ability to build large (>130K) bootable single-z3 ATRs without the swap-process might be of particular interest...

Edited by drpeter
Link to comment
Share on other sites

4 minutes ago, drpeter said:

EDIT:  I guess for modern tastes, the ability to build large (>130K) bootable single-z3 ATRs without the swap-process might be of particular interest...

I’m sure I don’t have the latest version (haven’t downloaded an update), but my ATR for Hibernated-1 is exactly that: a 130K bootable ATR that doesn’t require swapping. There might be a later updated version that changes this but I don’t know offhand. 

Link to comment
Share on other sites

Now what do you mean by 'swapping'? The side/disk swapping is needed only once per game, right? Or you mean story loading while playing? Because that's a must, because most stories are longer than 40KBs, which is about maximum for 64KB Atari (could be computed more precisely, but it would be somewhere around 40KB).

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...