Adventure

Post Reply
dave
Site Admin
Posts: 710
Joined: Tue Sep 09, 2008 5:24 am

Adventure

Post by dave »

I saw Tom's offer of working disk images, and did a double take when I saw Adventure in the list. I didn't even realize there was an Adventure port. I found a copy on Mark's site and tried it out in an emulator, and was amazed to see that it's the real thing! Incredibly slow, though.

Does anyone have any information on this implementation at all? How could it have stayed under the radar all this time? Did everyone know about it but me? IMO, any computer should have an implementation of original Adventure or Zork available, so this is important to me :-)

Does anyone have any information on who created this, when it was published, who sold it, how it was implemented, etc.? Is there any documentation for this version?

Thanks,

Dave
lowrybt1
Posts: 212
Joined: Sun Mar 08, 2015 3:42 pm
Location: New York State

Re: Adventure

Post by lowrybt1 »

I can’t say for certain but I think this is an implementation by Aurora Software Associates. Here’s an excerpt from the Aurora catalog sometime in 1981:

KEYBOARD CONTROLLED GAMES
ADVENTURE (32K or 48K non-graphic) - For the first time, you can now have ADVENTURE on your OSI without requiring a CP/M ooeratino system! ! ! Explore the COLLOSSAL CAVE with its 100 rooms. This is an OSI version of the original ADVENTURE. ADVENTURE is for all OSI systems with at least 32K and a 5%" or 8" disk drive.
AD-32K .................................................$19.95 (includes disk) AD-48K runs faster than the 32K version ............ ·...............$19.95 (includes disk)

I wish I had the 48K version because the 32K version is quite slow. That said, I am having a blast with this. I’m currently reading Ready Player One at my daughter’s suggestion and Adventure is featured prominently in the storyline. All-in-all, this is a very good implementation, albeit slow. So much fun to relive this!!
C8PDF w. 48K, 2x 520 24K RAM boards and Glitchworks 64K board
OSI 567 Telephony board
Spare 8" drives
Klyball D-13
dave
Site Admin
Posts: 710
Joined: Tue Sep 09, 2008 5:24 am

Re: Adventure

Post by dave »

Well, I took a peek at the 32K adventure disk, and found out why it's so slow. It's not really because it's written in BASIC, which can be fast enough. The problem is with the database of strings such as room descriptions, responses, etc. on disk. It's stored on disk as a serial file containing pairs of <numeric key , string>. The program logic can print a string by calling a subroutine with the key in a register variable (Z9). The problem is how the key->string mapping is done:

Code: Select all

OPEN the serial file on track 13
REPEAT
   Read String
   Convert the key to a numeric (floating point) value.
UNTIL value matches the key
REPEAT
    READ a string
    Convert the string to a numeric (floating point) value. 
    PRINT string if the value is zero (not the next key)
UNTIL value is non-zero (reached next key) 

So, for the gameplay instructions (key 403) the entire serial file must be read from disk. Since the database is about 41K, pretty much everything you do requires reading half the disk to generate a response.

There is no compression. Each string is terminated by a ^M, so it can be read with an INPUT command. If you see how slowly the lines of the instructions are printed (compared to printing strings from an array, for example), you can get an idea how long it takes to read through the entire database to get to strings at the end.

The string database looks to be about 41K, so I suspect the 48K version is caching portions of the string database in a string array. I suppose it could get more granular by storing the <key,string> pairs and maybe even some kind of LRU ranking. It could be further speeded up keeping a full map of keys and file offsets and use a random file instead of a serial file.

It looks like the BASIC on the adventure disk is crippled to inhibit LISTing, and perhaps in other ways. You can list the program by booting to OS65D, switching to the adventure disk, and DISK!"LO 31". You can view the database by simply opening the disk image in an editor.

A few thoughts on porting to C1 -- The database has hard code line breaks, which will be ugly on a C1.
There is some gratuitous direct keyboard polling, to check a spacebar hit. That could be replaced with an "input" statement.
Otherwise, this should fit on a C1. Since C1's usually run with a max of 32K, they would benefit from some optimization. I think a C1 can have 40K, which would be better.

Dave
dave
Site Admin
Posts: 710
Joined: Tue Sep 09, 2008 5:24 am

Re: Adventure

Post by dave »

Quickly glancing at just the top of the listing, which parses commands, the BASIC code is very inefficient. Certainly lots of opportunities for speedups.

I've attached the listing if anyone's interested, or link here.
Attachments
advent.bas
(19.92 KiB) Downloaded 569 times
dave
Site Admin
Posts: 710
Joined: Tue Sep 09, 2008 5:24 am

Re: Adventure

Post by dave »

dave wrote: Tue Aug 08, 2017 6:01 am So, for the gameplay instructions (key 403) the entire serial file must be read from disk. Since the database is about 41K, pretty much everything you do requires reading half the disk to generate a response.
I added a speedup for the description printing code, by adding in a small map pairing each track with the first description number on the track. That means at most one track needs to be loaded and searched, rather than 11 tracks. This helps somewhat, but responses were still very slow. Some simple profiling showed that the word lookup takes a very long time. About 200-300 strings must be read and compared against each word, with some additional string manupulation. It takes several seconds for each word. The movement lookup is only taking a second or so, but I've only tested in the early part of the game, so for larger room numbers, presumably, this will be worse as well.

BASIC does not have good data structure support, and the program is already pushing the size limits for 32K, so the easiest optimization is to read in the strings into an array, sort the array, and add a lookup table of array offsets for starting the string search based on the first letter. It won't be optimal, but can speed up the average search by a constant factor of 10 or 20. Right now, the string->object mapping is stored in DATA statements, so moving this to disk, if possible, could free up some RAM for the arrays.

For the movement database, since there's a good local correlation between the rooms, a hybrid approach might be to store 10 or 20 rooms of movement data in an array that serves as a cache, and read in a new track to the cache if the target room is not loaded.

I suspect the 48K version just loads much more into RAM. I wonder what other optimizations it uses, if any.

As I have time (I don't have much), I'll see if I can make the 32K version usable, and also see what can be done to further improve usability when more RAM is available.

Unfortunately, BASIC, lacking symbolic variable nams, variable scoping, real functions, or data structures, and with its numbered lines, makes it tedious to unravel the program logic, and difficult to change highly interdependent code. This is an example of software that would have been better developed in assembly--even tedious 6502 assembly--than in BASIC. It definitely would be smaller and faster, and could store more data in place of the BASIC interpreter.
lowrybt1
Posts: 212
Joined: Sun Mar 08, 2015 3:42 pm
Location: New York State

Re: Adventure

Post by lowrybt1 »

I'm blown away!
C8PDF w. 48K, 2x 520 24K RAM boards and Glitchworks 64K board
OSI 567 Telephony board
Spare 8" drives
Klyball D-13
Post Reply