New adventure game and BASIC (and now C) framework (don’t expect a new Ravenswood)

Got a programming project in mind? Tell everyone about it!
User avatar
Lardo Boffin
Posts: 1542
Joined: Thu Aug 06, 2015 6:47 am
Contact:

Re: New adventure game and BASIC framework (don’t expect a new Ravenswood)

Post by Lardo Boffin » Fri Apr 20, 2018 1:37 pm

As a guide without adventure specific code the program is about 5.2K and with the verbs etc. loaded for the Ransom adventure there is about 2.2K of heap used by variables / data.
I make that about 17K free for user code and additional verbs etc. on a beeb model B with DFS in mode 7.
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
Pablos544
Posts: 341
Joined: Tue Jul 15, 2014 4:25 pm
Location: London, UK
Contact:

Re: New adventure game and BASIC framework (don’t expect a new Ravenswood)

Post by Pablos544 » Fri Apr 20, 2018 2:43 pm

It sounds very interesting this system of yours. I was hoping to do a PAW for the BBC Micro myself, with graphics similar to TKV. Yours seems like it's got some of the right stuff and it's going the right way, I hope you do well LardoBoffin

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

Re: New adventure game and BASIC framework (don’t expect a new Ravenswood)

Post by Lardo Boffin » Fri Apr 20, 2018 3:03 pm

Pablos544 wrote:It sounds very interesting this system of yours. I was hoping to do a PAW for the BBC Micro myself, with graphics similar to TKV. Yours seems like it's got some of the right stuff and it's going the right way, I hope you do well LardoBoffin
Thanks. Graphic are not on my radar - I would not know where to start!
Hopefully I will be able to shrink the main program down and speed it up by replacing some of the stuff with machine code. That way if someone wanted to add graphics they could run it in a mode where that is possible. Although having seen some of the mode 7 artwork it could work right now!
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
Pablos544
Posts: 341
Joined: Tue Jul 15, 2014 4:25 pm
Location: London, UK
Contact:

Re: New adventure game and BASIC framework (don’t expect a new Ravenswood)

Post by Pablos544 » Sat Apr 21, 2018 12:00 am

Lardo Boffin wrote:
Pablos544 wrote:Graphic are not on my radar - I would not know where to start!
Hopefully I will be able to shrink the main program down and speed it up by replacing some of the stuff with machine code. That way if someone wanted to add graphics they could run it in a mode where that is possible...
Might well be worth taking a look at this. Although my 6502 assembler skills are slightly non existent. I was always very partial to PAW, in my youth I made an Adventure Game sort of like TKV that easily could have been published had er.. things not got in the way of it. I actually really loved that system and see it as a long term goal to make it work on a BBC B with sideways RAM. As I said though my 6502 assembler skills are pretty well on the non-existent side, so I'm really hoping your BASIC/6502 is a bit better than mine and I'll definitely be checking out your code. Thanks Lardo Boffin

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

Re: New adventure game and BASIC framework (don’t expect a new Ravenswood)

Post by lurkio » Sat Apr 21, 2018 12:04 am

Lardo Boffin wrote:I have changed it to load the system messages into an array ...
Would it speed things up a bit more if you cached the current location-description in memory and then used the cache (instead of accessing the disc) if the player types LOOK when they haven't moved to a new location?

:?:

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

Re: New adventure game and BASIC framework (don’t expect a new Ravenswood)

Post by Lardo Boffin » Sat Apr 21, 2018 5:59 am

lurkio wrote:
Lardo Boffin wrote:I have changed it to load the system messages into an array ...
Would it speed things up a bit more if you cached the current location-description in memory and then used the cache (instead of accessing the disc) if the player types LOOK when they haven't moved to a new location?

:?:
It would but rooms are allowed any number of messages for their description (well, up to around 100) so it could in theory be caching a load of data.
It should be possoble to always cache the first one as I suspect most rooms will only have one or two.
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: 1542
Joined: Thu Aug 06, 2015 6:47 am
Contact:

Re: New adventure game and BASIC framework (don’t expect a new Ravenswood)

Post by Lardo Boffin » Mon May 14, 2018 10:11 pm

I have finally managed to get to a beeb and install an SD card reader and it actually runs quite well! [-o< Certainly somewhat better than BeebEm which presumably more accurately reflects the disc drives of the day.
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: 1542
Joined: Thu Aug 06, 2015 6:47 am
Contact:

Re: New adventure game and BASIC framework (don’t expect a new Ravenswood)

Post by Lardo Boffin » Thu Apr 11, 2019 9:21 pm

In an effort to learn C I have rewritten the BASIC framework in C, because, well, why not? :D

I have written it using the Norcroft Compiler and Twin as an editor on my Master 128 running a Pi ARM Co-processor. Having the files installed on my DataCentre HDD has helped somewhat with speed issues! Over a 1000 lines (with comments and white space) tends to compile in around 30 seconds.

As it stands it is BBC Basic rewritten as C and so is not really making much use of the extra facilities of the language and my head hurts from trying to get to grips with pointers - given all of the text and array handling it turns out this was an ideal crash course in using them. So in effect the program is as before - a chunk of generic code acting as an API and then functions where the game logic is implemented.

I have written it using only commands taken from the Beebug C manual so presumably it will be compatible with this but as I move forward with this program I am getting spoilt by having 4MB of RAM... It is kind of tempting to load everything into RAM and avoid all wait times where previously it was loading from disc.

It is still a little rough around the edges with some unwanted formatting and lack of nice colouration in Mode 7 yet but this will be added as I go along. I have added the facility to use IT in commands, so you can type "Take lamp", "Light it". It will refer to the previous noun.

I am planning on adding the ability to have NPCs (which can wander around like in TKV) along with combat and a more sophisticated parser etc. After I get it to do everything like this I think it needs (any suggestions welcome) I will start the process of creating its own language so it no longer needs any skills in C or use of the compiler to create the game logic. I think that the 10MHz processor coupled with the C compiling to ARM Code (I believe) will make an interpreter fast enough without me immediately having to resort to learning assembly. Once I have the language working in C I suspect the assembly implementation will be a lot easier (not easy but easier :? ).

Attached is the Ransom SSD - you will need a Beeb running DFS and an ARM co-proc to run it. I appreciate that running it on the ARM limits its target audience somewhat but hopefully most people have a Pi co-proc by now. Given that they only cost the equivalent of a good night out on the ale there is really little reason not to. :D

It saves to disc at times (the achievements process, which I think I will make optional so it can be switched off via a command line or similar).

At the moment the RANSOM exe is about 49K in size so no concern yet about the 64K file limit in some DFS implementations.

So there you go, nothing particularly clever but I suspect there are not too many games for the beeb written in C running on the ARM (cue a huge list of games that do... :lol: )

Any problems running it please let me know.
Attachments
Ransom.ssd
Type *RANSOM to run game
(104.25 KiB) Downloaded 6 times
Last edited by Lardo Boffin on Fri Apr 12, 2019 6:29 am, edited 1 time in total.
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: 1542
Joined: Thu Aug 06, 2015 6:47 am
Contact:

Re: New adventure game and BASIC (and now C) framework (don’t expect a new Ravenswood)

Post by Lardo Boffin » Thu May 02, 2019 10:32 am

I have done a bit on the parser and you can now use IT and AND.

So for example you could type

TAKE LAMP(return)

LIGHT IT(return)

Or type

TAKE LAMP AND LIGHT IT(return)

Both will work. Using AND effectively chops a sentence into separate actions and is only limited by the size of the input buffer (255 chars at the mo).
IT retrieves the last NOUN used.

You could therefore type the following in Ransom: -

TAKE LAMP AND LIGHT IT AND E AND S AND TAKE RAT AND N AND E AND E AND SEARCH TREE AND TAKE KEY AND W AND W

etc.

Note that normal actions occur in between each input chunk so in games where there are wandering monsters or random traps you may not get to the end of the input without dying.
Also if the parser detects an error or cannot pick up an object in the input etc. it will (hopefully) stop at that point and ignore the rest.
Attachments
Ransom.ssd
Updated parser
(127.93 KiB) Downloaded 6 times
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
Richard Russell
Posts: 759
Joined: Sun Feb 27, 2011 10:35 am
Location: Downham Market, Norfolk
Contact:

Re: New adventure game and BASIC framework (don’t expect a new Ravenswood)

Post by Richard Russell » Thu May 02, 2019 2:59 pm

Lardo Boffin wrote:
Thu Apr 11, 2019 9:21 pm
In an effort to learn C I have rewritten the BASIC framework in C, because, well, why not? :D
Why not? A few reasons that I can think of (albeit that I am somewhat prejudiced):
  1. Ease of porting to other platforms. If it was coded in 'portable' BBC BASIC it could run without modification on a BBC Micro, RISC OS, Windows, MacOS, Linux, Raspberry Pi, Android, iOS and more. Although C is itself a very portable language, once you introduce a dependency on MODE 7 it would be much more difficult to build for the majority of those platforms,
  2. Ease of being modified / improved by others. I would suggest that many more people would feel confident in making changes to the code if it was in BASIC.
  3. Memory efficiency. Crunched BBC BASIC is likely to use considerably less memory than the same functionality achieved in compiled C or assembler, so should increase the chance of it fitting on a machine with limited resources (I appreciate that an adventure game may be mostly data rather than code so this may not apply).
Just my twopence-worth, there may be equally valid arguments in the opposite direction.

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

Re: New adventure game and BASIC framework (don’t expect a new Ravenswood)

Post by lurkio » Thu May 02, 2019 7:41 pm

Lardo Boffin wrote:
Thu Apr 11, 2019 9:21 pm
... as I move forward with this program I am getting spoilt by having 4MB of RAM... It is kind of tempting to load everything into RAM and avoid all wait times where previously it was loading from disc ... I suspect there are not too many games for the beeb written in C running on the ARM
FWIW, my take is that it's a shame you don't seem to be targeting an ordinary Beeb any more. If your code's in C and requires several MB of RAM then you've left 32K Beebs far behind. Or have I got the wrong end of the stick?

:?:

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

Re: New adventure game and BASIC framework (don’t expect a new Ravenswood)

Post by Lardo Boffin » Thu May 02, 2019 7:56 pm

Richard Russell wrote:
Thu May 02, 2019 2:59 pm
Lardo Boffin wrote:
Thu Apr 11, 2019 9:21 pm
In an effort to learn C I have rewritten the BASIC framework in C, because, well, why not? :D
Why not? A few reasons that I can think of (albeit that I am somewhat prejudiced):
  1. Ease of porting to other platforms. If it was coded in 'portable' BBC BASIC it could run without modification on a BBC Micro, RISC OS, Windows, MacOS, Linux, Raspberry Pi, Android, iOS and more. Although C is itself a very portable language, once you introduce a dependency on MODE 7 it would be much more difficult to build for the majority of those platforms,
  2. Ease of being modified / improved by others. I would suggest that many more people would feel confident in making changes to the code if it was in BASIC.
  3. Memory efficiency. Crunched BBC BASIC is likely to use considerably less memory than the same functionality achieved in compiled C or assembler, so should increase the chance of it fitting on a machine with limited resources (I appreciate that an adventure game may be mostly data rather than code so this may not apply).
Just my twopence-worth, there may be equally valid arguments in the opposite direction.
All very valid points. The program compiles to a stand alone exe of over 40K. The same program in BASIC is about 6 or so K.

But to quote the Billie defence:-
‘Why did you write that code in C?’
‘Because we want to!’
‘Why didn’t you write it BASICally?’
‘Because we want to!’

I think she also ‘sang’ that writing code in C was ‘Like honey to the bee(b)’. But that may be pushing it. =P~

It was for me purely an exercise in learning C and also doing something a little different on the beeb. We have all these co-procs and I wanted to do something in one of them. So when I saw a C compiler on the ARM that was it. :D

BBC Basic is a great language and I pretty much owe my career to it - a hearty thanks to all at Acorn and the BBC who were involved. The built in assembler is genius - I doubt I would have ever dabbled in assembly otherwise and got to learn something about what makes computers tick.
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: 1542
Joined: Thu Aug 06, 2015 6:47 am
Contact:

Re: New adventure game and BASIC framework (don’t expect a new Ravenswood)

Post by Lardo Boffin » Thu May 02, 2019 8:12 pm

lurkio wrote:
Thu May 02, 2019 7:41 pm
Lardo Boffin wrote:
Thu Apr 11, 2019 9:21 pm
... as I move forward with this program I am getting spoilt by having 4MB of RAM... It is kind of tempting to load everything into RAM and avoid all wait times where previously it was loading from disc ... I suspect there are not too many games for the beeb written in C running on the ARM
FWIW, my take is that it's a shame you don't seem to be targeting an ordinary Beeb any more. If your code's in C and requires several MB of RAM then you've left 32K Beebs far behind. Or have I got the wrong end of the stick?

:?:
Thus far all of the code is written using C that is in the Beebug C manual and therefore should compile onto a normal beeb and run (assuming it has 16K of sideways RAM for the C ROM) although I have not tried it yet.

I thought it might be an interesting opportunity to be able to write larger adventures that make use of the ARM co-proc’s increased memory. Given the advent of very cheap pi co-procs I wonder if only targeting standard beebs is as necessary as it used to be?
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
marcusjambler
Posts: 595
Joined: Mon May 22, 2017 11:20 am
Location: Bradford
Contact:

Re: New adventure game and BASIC (and now C) framework (don’t expect a new Ravenswood)

Post by marcusjambler » Sat May 04, 2019 5:35 pm

Its working great on my Integra B Nula Beeb with Gotek :D =D>

Marcus

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

Re: New adventure game and BASIC framework (don’t expect a new Ravenswood)

Post by lurkio » Sat May 04, 2019 6:14 pm

Lardo Boffin wrote:
Thu May 02, 2019 8:12 pm
Thus far all of the code is written using C that is in the Beebug C manual and therefore should compile onto a normal beeb and run (assuming it has 16K of sideways RAM for the C ROM) although I have not tried it yet.
Does the Beebug C ROM have to be present while the game is running? Or only during compilation?

:?:

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

Re: New adventure game and BASIC framework (don’t expect a new Ravenswood)

Post by Lardo Boffin » Sat May 04, 2019 6:46 pm

lurkio wrote:
Sat May 04, 2019 6:14 pm
Lardo Boffin wrote:
Thu May 02, 2019 8:12 pm
Thus far all of the code is written using C that is in the Beebug C manual and therefore should compile onto a normal beeb and run (assuming it has 16K of sideways RAM for the C ROM) although I have not tried it yet.
Does the Beebug C ROM have to be present while the game is running? Or only during compilation?

:?:
There is a run-time compiler for this but otherwise the ROM has to be present. I suspect the runtime would take up a fair chunk of RAM (I think it starts at around 5K) so added to the game code would probably mean a 6502 co-proc.
Otherwise 16k of sideways RAM is required.

I suspect the C version of this will probably prove to be a dead end but a) I wanted to learn a bit of C and b) writing it in C is actually quite good for (hopefully, eventually) writing it in pure 6502.
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

Post Reply