I've had a few ideas to bring more text adventure stuff onto the Beeb, if order of least craziness:

1. A quick parser to convert Speccy/Amstrad/C64 quill games to work with the Neil Fleming-Smith BBC Quill engine (not as easy as it sounds, as things have been mangled a lot on the Beeb)
2. Similarly for GAC - though we may have to miss out some of the graphics, or reserve them for the Master
3. Add graphics to the Scott Adams/Mysterious Adventures game. This is both easy and difficult, depending on the game and the engine. The hardest bit will be cutting down colours and screen resolution (as I can't use either Mode 1 or Mode 2).

I've been playing around with 'Cave' the econet based MUD. Seems to work rather nicely, certainly would be nicer with some different adventures.

I've not had much luck with GAC, doesn't like Master hardware/emulator at all.

I thought I'd do some messing around and see how much space we would have to put graphics in on Scott Adams' game. The holy grail is to be able to use mode 0, 1 or 2 and allow BBC DFS. This is very restrictive, so we have to assume the only free space is between &1900 and &3000; which is about 5.5KB.

I've been trying to squeeze out extra bits from the SAGA format; so far I've manage to reduce the size of The Golden Baton down from &1AA4 bytes (6.6KB) to &1320 bytes (4.8KB). This doesn't leave much for an interpreter.

The worst news is that TGB is a small game. The largest I've seen (Robin of Sherwood) still clocks over 5KB even when compressed...

Time to either use ROMs or to give up the mode 0/1/2 idea.

BTW does anybody have any good text compression algorithms?

The only real solution to that sort of restriction is to store all the text on the drive and only read what is needed. But I have the feeling even that isn't enough.

Take Adventurescape's file format, it allows 30 chars for object name and 100 chars for detailed description. Add to that 20 bytes for each puzzle and some tracking variables, and a room with a puzzle involving a few objects can eat up 0.5-1K.

If you restrict the graphics to Master 128 only in order to use shadow memory for video the problems disappear. The rom idea would work, easy enough to get those (unlike most 1980's chips and 5 1/4 floppies), cost is a problem unless people use SWR.

Ever seen Beneath a Steel Sky on PC ?
That sort of game graphics would work well in mode 0.

To be honest, the text wouldn't be enough, as the text in Scott Adams adventures is small. most of the space seems to be taken up by the actions, for example, here's my compression tables for TGB (in bytes):




Using the Master, or perversely, an Electron would make it easier, as they have &E00 DFS, which would give me an extra 11 pages - or about 2.75 KB which may be enough. I've already got plans to steal some of the low pages (4, 5, 6, 7, 8 and some of 9) for workspace (or I could locate my code there) as I'm not going to be using BASIC.

Interestingly enough, the Brian Howarth driver used for the TGB as originally released relocates all data to &D00 - meaning that you can't save the game to disc:

Eek; I've just my first bit of 6502 code in 20 years: I've forgotten a lot! It wasn't much, just the code to decompress the compressed text that I used; but it took some hacking around and lots of d'oh! moments.

Why do all my 6502 assembly programming books tell you that instruction x affects C, N and Z; but not how and when? I spent ages debugging something to discover, that I was checking C, not Z to see whether an INC had overflowed...

PaulA: if you fancy using text compression in your rework of Adventurescape, I've now got some 6502 decoding routines for a simple tokenisation routine...

Dave,

Just a nod that - if you're starting to mess around with new assembler - that we have a couple of tools hosted here, which are intended to make life easier for working on new 8-bit projects.

Specifically, I was just wanting to draw your attention to BeebAsm and SWIFT - they're under the Dev Tools link in the top menu bar.

You've probably already seen them, but they're worth a look over if you haven't already.

Sam.

I've started up a diary to explain my logic and stuff around it and also to show that a Dave can update the wiki occasionally

haha. cool.

If this is now a fully-fledged project, are you happy it going under the Retro Software banner? (That doesn't actually entail anything, other than you're welcome to make use of our facilities - Wiki/Forum/Bug tracker/Mercurial source code repository. We even have an RS little flashy beeb loading screen, though it's entirely up to you if you want to go that far. )

If you want, I (or you, as you're getting on so well with the wiki ) can add a SAGA Adventure Engine Graphical Rework entry on the WIP page to link to your diary.

Similarly, I can create a new forum for your project, if you want one ... ?

Sam.

Hold off on creating a whole new project for the moment... I tend to flick betwixt different projects as they hold my interest (then leave one for a year, then go back to it etc). Especially as 2 month old son means I have little computer time without the missus complaining.

For now I'll just keep up the "hidden" diary and see how it goes

Just caught up on the diary - gonna have to keep my eye on that! It's interesting reading, cheers! It made me think that trying to write compact code is a completely different art to trying to write fast code (although often it's also fast by virtue of being small!). I'd think nothing of allocating a 256-byte table to do automatic sprite masking (for example) so that it runs quickly, but I guess in text adventure world, big lookup tables like this are heresy!

re 16-bit addition and all that - unfortunately there's no better way. You might find it worthwhile moving 16-bit addition and incrementing code into subroutines if you need to keep your code small.

It looks like an interesting little project, look forward to the next installment!

(by the way, I had a few thoughts on things you might be able to do to compress the text a little more if you ever need to - if you're interested, give me a shout!)

Found an interesting post by someone here, which looks like an extension of your method, i.e. it builds tokens which represent more characters by letting tokens expand into other tokens. This, he claims, gives 50% compression!

If you were happy to go with an arbitrary bitstream rather than one char/token per byte, you could improve on this even more.

One character literal can be packed into 5 bits, by assigning values like this:

0 = space
1-26 = a-z
27 = full stop
28 = comma
29 = apostrophe
30 = question mark
31 = escape code which modifies the next character literal, like this:

0 = hyphen
1-26 = A-Z (capitals)
27 = colon
28 = semicolon
29 = quote mark
30 = exclamation mark
31 = slash (or whatever)

Then, signify either a literal or a token like this:

* read 1 bit
* if 0, read 5 bits and treat as a character literal
* if 1, read 7 bits (or 8 if you want a bigger token table) and treat as a token

Reading arbitrary numbers of bits from a bitstream is really easy in 6502; I can post some code from a decompression routine of mine if you're interested.

Like this, simple untokenised text gets compressed to 75%, and with tokens, even more.

Also, remember there are other tricks, e.g. omitting spaces after punctuation (can be inferred at the rendering stage), also omitting capitalisation at the start of the paragraph or after a full stop.

The retokenise what you've already tokenised idea is a good one. I may an arbitrary dictionary size of 127 and filled it with the top 127 digrams, though the bottom, about 64 each consist of 1 character. I may do some messing with multiple passes.

The 5 bits -> 1 character concept is an old one (used by Infocom games - this is essentially what ZSCII is). I decided against it as I wanted to minimise the amount of low level bit manipulation. Also, without tokens you're only going to get a 3:2 compression rate (3 x 5 = 15) with one left over bit to specify charset. I'm already getting this with my digram token routine!

I've been glancing over Seas of Blood - which is the most massive SAGA game around: the raw datafile is 32K, which my routines have shrunk down to about 9.8K (this is before I compressed for exits and a few ideas I have for objects). On the Spectrum version, this had compressed actions, which I'm happy to see mirror my own compression routine (i.e. have a byte with 1 nibble for number of conditions and 1 for number of actions). I can't work out how the dictionary is compress though!

For words (i.e. verbs/nouns), they're doing the inverse to me: if it's a non-synonym, then the first byte has bit 0x20 cleared (which makes it lower case). So this works out as: gO WALKgET TAKE (making GO and WALK synonyms as well as GET and TAKE). I may swap to this as it may be easier to process!

If you want to stick with byte-size chunks, you could at least subtract 32 from the ASCII code and then win yourself 32 more tokens, between 96-255. The impression I get from the other post I linked to is - the more tokens, the better!

I think the crucial part of the algorithm which creates tokens which may themselves contain tokens, is that only one is added each iteration, then the substitution is made in the source text, and then the process is repeated. It'd be interesting to know if you were to get even better compression than you already have by having multi-character tokens (and 30% (9.8k/32k) is already really good!).

You could certainly get even more compression by using variable bit-length symbols (6 bits for a literal, 8 bits for a token), but it's true - it does increase the complexity a little, particularly regarding how to choose which ASCII characters are represented (e.g. there are no digits in my suggested format above).

I tired dictionary alternatives first, and mixed (i.e. both dictionary and digrams). I found I got worst results from them, but that may have been my encoding routines. It's certainly something to look at again to squeeze those extra few bytes out so I can get to use modes 0-2 for graphics.

Having tuned my compression algorithms a bit (all the figures are for Seas of Blood - the largest SAGA game I can find) for rooms (311 extra bytes saved), actions (452 extra bytes saved) and objects (36 extra bytes saved). I've got the SoB data file down from 14715 bytes to 8893 bytes. Which means I can easily get to use mode 4/5.

Re: lack of JSR (indirect) in your last diary entry:

The lazy way is just to use self-modification, i.e.

But, yeah, the better alternative (both faster and smaller) is to create a return address on the stack; the problem is I can never remember which way round to push the MSB and LSB. I think it's push MSB first, and you have to push (return address - 1):


Gonna have to check that for sure, as I want to use it in Onslaught - I always used to do lazy self-modification, but having worked it out, I realise that this way is far better!

Uhmmm, yeah, just realised that the second method also requires the routine address to be set up each time (because we can't use JMP (ind,X) like we have on the Master) - so actually the first method is both quicker and faster. And simpler too!

Currently I'm doing it the lazy way:


And instead of doing an rts I do either a jmp condloop or a jmp condfailed, depending on whether it succeeds or fails. I have a few branches set up in the middle of the subroutines so I can save a few bytes and maximise that 127 bytes +/- on a branch!

I've got to do some better thinking though, especially around not'd conditions, for example I have the two routines:


The must be a better way to do this and reduce the 8 bytes that are (virtually) duplicated.

After getting (most of) the engine working, I thought I'd have a look at the graphics; I've placed a mode 1 mock-up screen, with graphics stolen and plotted directly from the Spectrum version on the diary.

I'm interested in any feedback.

Note, the actual game screen is unlikely to look like this in the end, unless you're on a Master, or I can work out a way of doing multi-mode screens.

Hey, dave.

If you're asking for feedback on which is better - a 1/4 screen header image, or the full 1/2 screen, I have to say I do like your screenshot mockup. One reason I've never been a big fan of adventures with graphics is that the ones I've played tended to make the text suffer as a result, both in verbosity as well as screen space. Which is kinda why I liked Level 9's The Saga of Erik the Viking's Tab-switchable approach. However, your mockup looks like a great compromise - I don't think you lose a lot by reducing it in size, but it makes a big difference to how much text you fit on screen.

Or were you asking for feedback on the more techy stuff?

Sam.