SLID

want to contribute an update to the archive? post it here!
Post Reply
joachim
Posts: 134
Joined: Wed Jun 21, 2006 1:20 am
Contact:

SLID

Post by joachim » Sun Dec 17, 2017 11:15 pm

I dug up a snake game that we used to have on the school Econet. It was written for the BBC but runs fine on an Arc (apart from the sound, of course). It's rather challenging as the snake is 8-directional and therefore has a nontrivial turning circle.
I am told it was written by F. R. C. Dunn.

Instructions: press < and > (actually , and ., since Shift Lock must be off) to turn left and right, and SPACE to turn around — yes, this snake is reversible! Green mushrooms are good, red mushrooms are fatal, purple ones allow you to survive eating one fatal object (red mushroom or internal wall).

Edit: actually I'm surprised this runs on the Arc, since it uses OSBYTE 135 (&87) to read the screen (in fact, it charmingly uses the FNREADCH example from the User Guide verbatim). I thought USR worked differently in ARM BASIC … and besides I thought there was an issue with recognizing user-defined characters because some of them are aliased to each other in *FX 20,0 mode …
Attachments
slid.zip
(1.66 KiB) Downloaded 83 times

joachim
Posts: 134
Joined: Wed Jun 21, 2006 1:20 am
Contact:

Re: SLID

Post by joachim » Wed Dec 20, 2017 1:27 am

In fact, I think what I posted must be a modified version that only works on the Arc (or at least on Master upwards), because it expects OSBYTE &87 to return values in the range 224–255. On OS 1.0–1.2 the OSBYTE returns values 128–159: to make the program work with that, remove the REM from line 620.

Or better, fix it to work with either convention:

Code: Select all

620 IF C>32 THEN C=C OR &60

User avatar
jgharston
Posts: 3090
Joined: Thu Sep 24, 2009 11:22 am
Location: Whitby/Sheffield
Contact:

Re: SLID

Post by jgharston » Wed Dec 20, 2017 6:52 am

joachim wrote:Edit: actually I'm surprised this runs on the Arc, since it uses OSBYTE 135 (&87) to read the screen (in fact, it charmingly uses the FNREADCH example from the User Guide verbatim). I thought USR worked differently in ARM BASIC
BBC BASIC is specified that a call to &0000FFxx calls the BBC MOS API. Otherwise you kill millions of BASIC programs where the author didn't have a crystal ball to discover that they should have filled their code with IF this_is_an_arc THEN do_this ELSE do_this. You just do do_this.
joachim wrote:… and besides I thought there was an issue with recognizing user-defined characters because some of them are aliased to each other in *FX 20,0 mode …
That's the classic mistake people made of defining CHR$128-159 and then printing CHR$224-255 (or the other way around) and wondering why what was on screen was different and OSBYTE135 returned different characters. Well, what would you expect if you defined character A and then printed character B?

Code: Select all

$ bbcbasic
PDP11 BBC BASIC IV Version 0.25
(C) Copyright J.G.Harston 1989,2005-2015
>_

Michael Brown
Posts: 2007
Joined: Sat Apr 03, 2010 12:54 pm
Location: Nottingham
Contact:

Re: SLID

Post by Michael Brown » Wed Dec 20, 2017 7:31 am

Any chance of the BBC version as a .ssd image being posted please?

regards,
Mick.

joachim
Posts: 134
Joined: Wed Jun 21, 2006 1:20 am
Contact:

Re: SLID

Post by joachim » Wed Dec 20, 2017 1:58 pm

jgharston wrote:
joachim wrote:… and besides I thought there was an issue with recognizing user-defined characters because some of them are aliased to each other in *FX 20,0 mode …
That's the classic mistake people made of defining CHR$128-159 and then printing CHR$224-255 (or the other way around) and wondering why what was on screen was different and OSBYTE135 returned different characters. Well, what would you expect if you defined character A and then printed character B?
Well, it's a bit worse than that, you define CHR$224 and then you print CHR$224 and then OSBYTE 135 still gives you an answer you didn't expect.

To be fair, the User Guide popularized this problem because it says in both Ch. 29 and Ch. 34 that 224–255 are the characters that can be redefined without messing around with *FX 20. My understanding is that that's simply not true and the correct set is 128–159 (as explained in Ch. 42).

(Maybe it was true in OS 0.10 though? Or at least it was the way they were thinking at the time — that would explain the earlier User Guide entries. Which set of values does OSBYTE 135 return in OS 0.10?)
Last edited by joachim on Fri Dec 22, 2017 1:08 am, edited 1 time in total.

joachim
Posts: 134
Joined: Wed Jun 21, 2006 1:20 am
Contact:

Re: SLID

Post by joachim » Fri Dec 22, 2017 12:25 am

Michael Brown wrote:Any chance of the BBC version as a .ssd image being posted please?

regards,
Mick.
Try this SSD which I have built with BeebAsm and tested with jsbeeb. It includes the fix I posted upthread, but be aware that the fix is in the !BOOT file not in the main program, so if you try to CHAIN "SLID" directly you will get the unfixed version which only works on Master or Archimedes.
Attachments
slid.ssd.zip
(1.74 KiB) Downloaded 82 times

Michael Brown
Posts: 2007
Joined: Sat Apr 03, 2010 12:54 pm
Location: Nottingham
Contact:

Re: SLID

Post by Michael Brown » Fri Dec 22, 2017 7:50 am

Thanks for ssd

Mick.

joachim
Posts: 134
Joined: Wed Jun 21, 2006 1:20 am
Contact:

Re: SLID

Post by joachim » Mon Jan 01, 2018 2:25 am

joachim wrote:Maybe it was true in OS 0.10 though? Or at least it was the way they were thinking at the time — that would explain the earlier User Guide entries. Which set of values does OSBYTE 135 return in OS 0.10?)
Turns out richardtoohey in this thread confirmed my suspicions: the 224–255 range is returned in OS 0.10.

So, seems like Acorn's initial plan was that &E0–&FF was the definable range and &80–&DF was "undefined / for further expansion". When they brought in the *FX 20 stuff in OS 1.00 the official default definable range was changed to &80–&9F, but they never updated the User Guide to the new recommendation and so almost every BBC BASIC tutorial out there continued to use 224–255 for their example character definitions, thus setting people up for a surprise the first time they tried to use OSBYTE 135.

joachim
Posts: 134
Joined: Wed Jun 21, 2006 1:20 am
Contact:

Re: SLID

Post by joachim » Wed Feb 07, 2018 7:32 pm

I see SLID is now on bbcmicro.co.uk — thanks Lee/Mick?

I thought of one more possible correction — it runs rather slowly on the original model B, which is funny because there's a deliberate delay in line 140:

Code: Select all

140 A = INKEY(12):IF A=44 THEN D=D-1*8*(D=0)
I suspect that the 12 here is another change that was made later to run the game on an Arc. On a B it's smoother if you change it to INKEY(1) or INKEY(2) — I don't know what the original number was but it doesn't really matter, you just want no significant delay here because executing the BASIC game loop is already slow enough.

Alternatively, to save anyone the trouble of remastering the disc there's a very simple fix: add "&model=MasterTurbo" to the play URL, like this:
Play SLID on Master Turbo.

Post Reply