Assembly language text adventure

Discuss all aspects of programming here. From 8-bit through to modern architectures.
User avatar
lurkio
Posts: 2147
Joined: Tue Apr 09, 2013 11:30 pm
Location: Doomawangara
Contact:

Re: Assembly language text adventure

Post by lurkio » Mon May 13, 2019 10:22 pm

fuzzel wrote:
Fri May 10, 2019 4:56 pm
I still have text compression to look forward to at some point
The answer to your prayers..?:
:-k

User avatar
tautology
Posts: 389
Joined: Wed Sep 01, 2010 2:26 pm
Contact:

Re: Assembly language text adventure

Post by tautology » Mon May 13, 2019 11:48 pm

In regards to text compression, there are a number of ways, most of which depend on the source text and can vary. I sort of touched on this when I did my port of the Scott Adams engine (http://www.retrosoftware.co.uk/wiki/ind ... oming_Data).

I end up going compressing with digrams, because I couldn't customise to the messages and you can fit 127 digrams into one page; which made the dictionary small and the code very simple.

Other places have used different tactics. Midge uses a dictionary of words which are looked up, this gets good compression, but makes the rendering slower.

The Quill and Infocom, compress bits, e.g. in Infocom 5 bits are used to represent a character. This offers a guaranteed 3:2 compression, is fast to decompress, but is quite complex.

Superior's Stranded uses a half way approach: most characters are normal, but there is an option to use a dictionary word for common or long words.

fuzzel
Posts: 417
Joined: Sun Jan 02, 2005 1:16 pm
Location: Cullercoats, North Tyneside
Contact:

Re: Assembly language text adventure

Post by fuzzel » Fri May 17, 2019 12:01 pm

I'm now dabbling in text compression but have encountered a problem when trying to run a program to store the compressed location text.
What's happening is that when I try to store the compressed data at &4800 and create a lookup table to the data at &7A00 and &7B00 I'm finding that the data at &7B00 is being overwritten by text from the first game location starting at &7A9D. This shouldn't happen because the memory usage is not that great.
Here's a few details:
Program runs from &1100 to &2500. This includes data statements for all 28 locations and 28 common words which will replace equivalent words in the location text with a single character (130-).
The text array DIM LOC$(28) appears to be stored in memory from &2E10 to &3D00.
There is a gap now to the compressed text which I've stored at &4800 to &5170
Then there's another gap to &7A00 for the lookup table but at &7A9D location text for the first location appears overwriting my &7B00 onwards lookup table.
Is there a reason why a basic program would choose to use &7A9D onwards to store array text ? If so it's pretty annoying. If not noticed this before with similar basic programs I've written.

fuzzel
Posts: 417
Joined: Sun Jan 02, 2005 1:16 pm
Location: Cullercoats, North Tyneside
Contact:

Re: Assembly language text adventure

Post by fuzzel » Fri May 17, 2019 12:47 pm

I'm now dabbling in text compression but have encountered a problem when trying to run a program to store the compressed location text.
What's happening is that when I try to store the compressed data at &4800 and create a lookup table to the data at &7A00 and &7B00 I'm finding that the data at &7B00 is being overwritten by text from the first game location starting at &7A9D. This shouldn't happen because the memory usage is not that great.
Here's a few details:
Program runs from &1100 to &2500. This includes data statements for all 28 locations and 28 common words which will replace equivalent words in the location text with a single character (130-).
The text array DIM LOC$(28) appears to be stored in memory from &2E10 to &3D00.
There is a gap now to the compressed text which I've stored at &4800 to &5170
Then there's another gap to &7A00 for the lookup table but at &7A9D location text for the first location appears overwriting my &7B00 onwards lookup table.
Is there a reason why a basic program would choose to use &7A9D onwards to store array text ? If so it's pretty annoying. If not noticed this before with similar basic programs I've written.

btw - I've found a workaround by loading the program at &4000 and having the date created at a lower address but I'd still like to know what basic was doing.

User avatar
lurkio
Posts: 2147
Joined: Tue Apr 09, 2013 11:30 pm
Location: Doomawangara
Contact:

Re: Assembly language text adventure

Post by lurkio » Fri May 17, 2019 1:34 pm

fuzzel wrote:
Fri May 17, 2019 12:47 pm
I'm now dabbling in text compression but have encountered a problem when trying to run a program to store the compressed location text.
It’s hard (for me, at least) to know what’s going on without seeing the full program, but perhaps the BASIC stack is corrupting your stored data?

Have you changed the value of HIMEM? If not, then try lowering the value of HIMEM and storing your data above the new value.

E.g. try setting HIMEM to &7A00, or even to &4800, or to whatever value will create just enough room for you to squeeze your stored data into the space above the new value of HIMEM.

:?:

User avatar
dv8
Posts: 229
Joined: Mon Jun 22, 2009 9:07 pm
Contact:

Re: Assembly language text adventure

Post by dv8 » Fri May 17, 2019 1:49 pm

BASIC's stack grows downwards from HIMEM and is used for storing copies of variables during PROC and FN calls and the intermediate results of string expressions. The latter is why you are seeing string fragments just below HIMEM at &7C00.

A BASIC program has the potential to use all of the memory between PAGE and HIMEM during its run.
To prevent this from happening you need to limit the amount of memory BASIC has access to using one or more of these techniques:

* increase PAGE to use the memory between OSHWM and the new value of PAGE.
* increase LOMEM to use the memory between TOP (the end of the BASIC program) and the new value of LOMEM.
* decrease HIMEM to use the memory between the new value of HIMEM and the start of screen memory.

As lurkio suggested, putting the command HIMEM=&7A00 (immediately after changing to MODE 7) will allow you to store data at &7A00-&7C00 without it getting corrupted.

fuzzel
Posts: 417
Joined: Sun Jan 02, 2005 1:16 pm
Location: Cullercoats, North Tyneside
Contact:

Re: Assembly language text adventure

Post by fuzzel » Fri May 17, 2019 3:52 pm

That's great, thanks guys for the tips. Now to try to get the compression working in LOT Level 1........

fuzzel
Posts: 417
Joined: Sun Jan 02, 2005 1:16 pm
Location: Cullercoats, North Tyneside
Contact:

Re: Assembly language text adventure

Post by fuzzel » Sat May 18, 2019 1:18 pm

After some serious headscratching I've managed to get my text compression routine to work for my test effort, Level 1 of Lords of Time. I analysed the text from the 28 locations sorting each word by frequency to determine the savings by replacing each word with a single character. As it turns out there were only 28 words worth using for compression (the rest only appear once so I would actually lose space by using them as they'd have also taken up a couple of bytes space each in the lookup table). Even so the text reduces to 67% of it's original size, or to put it another way, I could increase the amount of text in the same memory space by 50% by using compression. It also doesn't slow down the displaying of text on screen during game play. I have a few niggles to sort out but will pop a copy of my progress so far in this forum for people to have a look at (and hopefully find any glitches).
Once happy I will then use the stripped back program as a template for developing my own adventure. I'm thinking about either a Zork conversion in Level 9's style (memory constraints will probably scupper this), a Blake's 7 adventure, Lords of Time 2, or something completely different.

User avatar
Lardo Boffin
Posts: 1612
Joined: Thu Aug 06, 2015 6:47 am
Contact:

Re: Assembly language text adventure

Post by Lardo Boffin » Sat May 18, 2019 6:38 pm

Blake’s 7 sounds cool. 8)
Atom, issue 5
BBC model B 32k issue 4, 16k sideways RAM, Watford 12 ROM board, Acorn 6502 coproc
BBC model B 32k issue 7, turboMMC, Opus Challenger 3 512k, Pi 3 coproc
USA Model B
BBC Master, Datacentre + HDD, pi co-proc, econet, NULA

fuzzel
Posts: 417
Joined: Sun Jan 02, 2005 1:16 pm
Location: Cullercoats, North Tyneside
Contact:

Re: Assembly language text adventure

Post by fuzzel » Sat May 18, 2019 8:08 pm

I wrote a Blake's 7 adventure in Basic bitd and I was quite proud of it. It's on a floppy disc in the loft somewhere but time probably hasn't been kind to the disc or to my disc drive. I discovered last year when I tried to play some old games on my beeb proper that a disc had been left in the drive for a good number of years and so had been subjected to the extremes of summer heat and winter cold. I presume neither will have benefited from this cosy long-term relationship. As I recall the game approximately covered the first four episodes of series one where the crew come together and take over the Liberator. Thinking about it, I'd love to find that disc and get the game working again. If not I can start again from scratch (I have Terry Nation's book and the dvds for inspiration).
Last edited by fuzzel on Sat May 18, 2019 8:08 pm, edited 1 time in total.

User avatar
Lardo Boffin
Posts: 1612
Joined: Thu Aug 06, 2015 6:47 am
Contact:

Re: Assembly language text adventure

Post by Lardo Boffin » Sun May 19, 2019 10:00 am

With each of the characters having a unique set of abilities it would make for an interesting multi-character adventure where you have to swap between them to solve puzzles.
Atom, issue 5
BBC model B 32k issue 4, 16k sideways RAM, Watford 12 ROM board, Acorn 6502 coproc
BBC model B 32k issue 7, turboMMC, Opus Challenger 3 512k, Pi 3 coproc
USA Model B
BBC Master, Datacentre + HDD, pi co-proc, econet, NULA

User avatar
Lardo Boffin
Posts: 1612
Joined: Thu Aug 06, 2015 6:47 am
Contact:

Re: Assembly language text adventure

Post by Lardo Boffin » Sun May 19, 2019 10:08 am

Oh and some location graphics featuring Glynis Barber. :D
Atom, issue 5
BBC model B 32k issue 4, 16k sideways RAM, Watford 12 ROM board, Acorn 6502 coproc
BBC model B 32k issue 7, turboMMC, Opus Challenger 3 512k, Pi 3 coproc
USA Model B
BBC Master, Datacentre + HDD, pi co-proc, econet, NULA

fuzzel
Posts: 417
Joined: Sun Jan 02, 2005 1:16 pm
Location: Cullercoats, North Tyneside
Contact:

Re: Assembly language text adventure

Post by fuzzel » Tue May 21, 2019 7:55 pm

Glynis Barber was series 4 which is jumping the gun a bit. Sally Knyvette, however, is a more than adequate replacement in my opinion (at least with my 1970s child's head on).
By the way, this may well come in useful...
Attachments
Blakes7tech2-4.jpg

User avatar
Lardo Boffin
Posts: 1612
Joined: Thu Aug 06, 2015 6:47 am
Contact:

Re: Assembly language text adventure

Post by Lardo Boffin » Wed May 22, 2019 6:45 am

Is that the Millennium Falcon in there?

C23FF1ED-65B8-4FF3-8782-DB2B980822D7.jpeg
Atom, issue 5
BBC model B 32k issue 4, 16k sideways RAM, Watford 12 ROM board, Acorn 6502 coproc
BBC model B 32k issue 7, turboMMC, Opus Challenger 3 512k, Pi 3 coproc
USA Model B
BBC Master, Datacentre + HDD, pi co-proc, econet, NULA

fuzzel
Posts: 417
Joined: Sun Jan 02, 2005 1:16 pm
Location: Cullercoats, North Tyneside
Contact:

Re: Assembly language text adventure

Post by fuzzel » Fri May 24, 2019 8:22 am

Does anyone know if any Blake's 7 games were released for any micros, particularly text adventures ?
I suppose Starship Command partly counts for the BBC, from memory there's a Liberator lookalike in that game.

fuzzel
Posts: 417
Joined: Sun Jan 02, 2005 1:16 pm
Location: Cullercoats, North Tyneside
Contact:

Re: Assembly language text adventure

Post by fuzzel » Sat Jun 22, 2019 1:54 pm

I'm nearly finished writing my own version of Level 9's Lords of Time level 1, just the save / restore facility to add, which looks to be straightforward using OSCLI and the X,Y registers to point to the text "*LOAD TIMEDAT" and "*SAVE TIMEDAT". However, if TIMEDAT doesn't exist, say on the first play, how do I trap the "Not found" error? I don't really want the program to crash.

Secondly, I've just been looking at an old printout of a computer program called LAND which I wrote on the DEC-10 mainframe back in my uni days and I'd like to convert it to work on the beeb but I'm probably going to need to access the four banks of SW RAM. I see by default Beebem has banks 4 to 7 allocated as free for this purpose which would give me an extra 64k to play with, could someone show me how to read / write a byte of memory from one of the ram banks please ? I presume it will involve firstly selecting the RAM bank then secondly simply LDA#1:STA&8000 for example.

SteveF
Posts: 514
Joined: Fri Aug 28, 2015 8:34 pm
Contact:

Re: Assembly language text adventure

Post by SteveF » Sun Jun 23, 2019 8:23 pm

fuzzel wrote:
Sat Jun 22, 2019 1:54 pm
I'm probably going to need to access the four banks of SW RAM. I see by default Beebem has banks 4 to 7 allocated as free for this purpose which would give me an extra 64k to play with, could someone show me how to read / write a byte of memory from one of the ram banks please ? I presume it will involve firstly selecting the RAM bank then secondly simply LDA#1:STA&8000 for example.
Yes, that's right. Something like:

Code: Select all

LDA #4
STA &F4
STA &FE30
\ bank 4 is now paged in and can be accessed via LDA/STA/etc
should work. I'd suggest you use named constants for the RAM banks to make it easier to port to another machine with different RAM banks later on; the code might need tweaking at that point, but if you can search the source code for the relevant named constants that will be easy.

If you plan to do any filing system operations, be aware that you can't pass buffers in sideways RAM to filing system calls as the filing system (e.g. DFS) will be paged in at &8000 by the OS so it can't see your buffers.

SteveF
Posts: 514
Joined: Fri Aug 28, 2015 8:34 pm
Contact:

Re: Assembly language text adventure

Post by SteveF » Sun Jun 23, 2019 8:43 pm

fuzzel wrote:
Sat Jun 22, 2019 1:54 pm
I'm nearly finished writing my own version of Level 9's Lords of Time level 1, just the save / restore facility to add, which looks to be straightforward using OSCLI and the X,Y registers to point to the text "*LOAD TIMEDAT" and "*SAVE TIMEDAT". However, if TIMEDAT doesn't exist, say on the first play, how do I trap the "Not found" error? I don't really want the program to crash.
To address that specific concern, you could try to open TIMEDAT for input using OSFIND; that will return with A=0 if TIMEDAT doesn't exist. You could then only go ahead and close the file and do the *LOAD if OSFIND returns with A<>0 .

But there are other possibilities, like a disc error occurring part way through loading TIMEDAT, and then an OS error will be generated anyway. So using OSFIND as a pre-check doesn't cover all the possible ways things could go wrong.

I think the right way to handle this is to claim BRKV; the OS will call the address stored at BRKV (&202) when an error occurs. Think of this as the assembler equivalent of BASIC's ON ERROR. I haven't tested this code, but something like this:

Code: Select all

\ Install handler - this is a bit like saying "ON ERROR JMP mybrkvhandler"
LDA #mybrkvhandler MOD 256
STA &202
LDA #mybrkvhandler DIV 256
STA &203
\ ...
.mybrkvhandler
\ An error has occurred. You get to decide what to do at this point. If you want to see what the error was:
LDY #0
LDA (&FD),Y \ get error number in A
CMP #whatever:BEQ handle_whatever
\ it wasn't whatever, it was something else
You could set a flag just before doing the *LOAD and clear it immediately after a successful load; you could then check that flag in mybrkvhandler and if it's set you know the *LOAD failed. It would be good to print the error message for the user to see, but you know the load didn't succeed without needing to check for specific error numbers and can then take the appropriate action. And depending on what your program does, you should be aware that other things might cause errors which transfer control to your BRKV handler and make sure it does something suitable in that case too.

At the risk of stating the obvious, you can't RTS from the BRKV handler to "get back to where the error was generated"; you have to go forwards, so to speak. (Just like ON ERROR in BASIC, really.)
Last edited by SteveF on Sun Jun 23, 2019 11:03 pm, edited 5 times in total.

fuzzel
Posts: 417
Joined: Sun Jan 02, 2005 1:16 pm
Location: Cullercoats, North Tyneside
Contact:

Re: Assembly language text adventure

Post by fuzzel » Mon Jun 24, 2019 4:58 pm

Many thanks for the tips SteveF, I shall try them out in the next few days and report back.

fuzzel
Posts: 417
Joined: Sun Jan 02, 2005 1:16 pm
Location: Cullercoats, North Tyneside
Contact:

Re: Assembly language text adventure

Post by fuzzel » Tue Jun 25, 2019 6:01 pm

I've just created a very small program to test whether SW Ram works. I'm using Beebem and have ticked Hardware\SW Ram Board ON.
Also Allow SW Ram Write is ticked for banks 4 to 7. When I CALL&1100 the screen clears and the top line in the attached picture shows the error.
Can anyone see what I'm doing wrong? I've just tested it btw and it appears to be line 20 when I try to STA&FE30. I presume I'm doing something obviously wrong.
Attachments
SWRAM PROG.jpg

User avatar
MartinB
Posts: 5229
Joined: Mon Mar 31, 2008 9:04 pm
Location: Obscurity
Contact:

Re: Assembly language text adventure

Post by MartinB » Tue Jun 25, 2019 6:26 pm

You don't need line 100 because once bank #5 is paged in as the current 'sideways rom', it stays selected until explicitly switched out. What you do need to do though because of the latter, is switch BASIC back in when your ditty has finished by performing similar rom switching to line 100 but just before the RTS, say as line 120. To get the slot number of BASIC for storing back into &F4 and &FE30, you should first read &F4 right at the start of your code and save it somewhere. The easiest would be say LDA&F4:PHA at line 15 with a matching PLA as part of the BASIC restore code in the new line 120 - so, PLA:STA&F4:STA&FE30


Viz (renumbered)......

ditty.jpg


.
Last edited by MartinB on Tue Jun 25, 2019 6:46 pm, edited 2 times in total.

fuzzel
Posts: 417
Joined: Sun Jan 02, 2005 1:16 pm
Location: Cullercoats, North Tyneside
Contact:

Re: Assembly language text adventure

Post by fuzzel » Tue Jun 25, 2019 7:17 pm

Thanks MartinB, that's saved me quite a bit of teeth-gnashing ! I can now use the four banks of sideways ram in my game which should be good for around 400 or so locations....

fuzzel
Posts: 417
Joined: Sun Jan 02, 2005 1:16 pm
Location: Cullercoats, North Tyneside
Contact:

Re: Assembly language text adventure

Post by fuzzel » Fri Jun 28, 2019 5:07 pm

I've now got my save, restore, ramsave and ramload commands working so it's now time to park my Lords of Time Level 1 program and commence work on a new game. What's got the old juices flowing in the last week or so is a printout retrieved from my loft of LAND, a MUD game I wrote at the University of Essex with a friend back in 1989 using Trubshaw and Bartle's MUDDL programming language. The game is actually referred to here:

https://www.linnaean.org/~lpb/muddex/mud-answers3.html

Utilising the 4 x 16k SW ram banks I think I can just about squeeze in all 300+ locations. This will be my first goal. I will then add objects and puzzles etc. The only obvious problem is that it will be more like a SUD than a MUD although I'll attempt to add some interactive characters to give it the flavour of a MUD.

I'll create a new topic for this but where to put it? Not in "programming" as most of the learning process to write the game has been covered here, and not in "adventures" because it's not a previously published game (although that's my favourite forum). I guess it will have to be in "8 bit software: new games". I'll create the new topic later on with my first thoughts. Wish me luck !

User avatar
Elminster
Posts: 3690
Joined: Wed Jun 20, 2012 8:09 am
Location: Essex, UK
Contact:

Re: Assembly language text adventure

Post by Elminster » Fri Jun 28, 2019 5:28 pm

fuzzel wrote:
Fri Jun 28, 2019 5:07 pm
I've now got my save, restore, ramsave and ramload commands working so it's now time to park my Lords of Time Level 1 program and commence work on a new game. What's got the old juices flowing in the last week or so is a printout retrieved from my loft of LAND, a MUD game I wrote at the University of Essex with a friend back in 1989 using Trubshaw and Bartle's MUDDL programming language.
Well done. I did a school trip to Essex uni computer centre around 89, maybe I saw you .......

Post Reply