New Adventures?

[jms2]

For moving things between single disk and double disk images, I use beebem.
For this, load the .dsd, it will be in drives 0 and 2 (the two sides of the first drive).
Use the menu to make a new .ssd in disk 1, *OPT 4 3, *COPY 0 1 *.*, eject the disc and repeat copying 2 1 for the second side.
No need to *OPT the second disc, beebem creates a formatted image, so no need to format either.
I've also done the same in reverse to create double sided images.

That's handy, thanks.

However, I'm not sure whether you can then use Omniflop to write both sides of a DS disk as two separate SSDs? I think not, because it doesn't have a way of specifying which side you're writing to.

I might try writing a DSD again with Omniflop, because despite making some very odd noises and not displaying any progress bar, it did actually seem to partially work - maybe I should have given it more time.

[tricky]

Thanks for the adventure, my daughter has been playing it, she is sick in the woods. I might get a chance this afternoon.

[PitfallJones]

Hi,
I tried it on a real Master 128 with a double sided drive but it doesn't work.
It also doesn't work in B-em when set to be a Master 128
The first two menus appear but the ingame screen in black
- PJ

[lurkio]

The Master-incompatibility may be partly due to the Slim Chars code, which is taken from pages 60 and 61 here but isn't compatible with the Master.

Here's a Master-only version of Robin Nixon's Slim Characters program:

• SlimChars.ssd.zip

  Robin Nixon's Slim Chars program adapted for the Master 128

  (1.44 KiB) Downloaded 188 times

The original Elk/ModelB version of the program stored the slim char definitions in Pages &9, &A and &C, but in the Master there's (always?) space set aside high up in memory (in ANDY?) for the fully exploded character set, so you don't need to (and can't?) put char defs elsewhere.

[lurkio]

I tried it on a real Master 128 with a double sided drive but it doesn't work. It also doesn't work in B-em when set to be a Master 128. The first two menus appear but the ingame screen in black

That specific problem can be fixed if you replace line 380 in the BASIC program $.RW --

Code: Select all

380IFLC%<>0ANDLC%<30THEN *DRIVE2 ELSE *DRIVE0

-- with this:

Code: Select all

380*DRIVE0
381IFLC%<>0ANDLC%<30THEN *DRIVE2

At least, this works in Master 128 mode in BeebEm.

I believe this issue arises because in the original line 380, everything after the first asterisk, up to the end of the line, is treated by BASIC as if it were all one big OS command: "*DRIVE2 ELSE *DRIVE0"! (I.e. the "ELSE" isn't parsed as a BASIC keyword.)

The original line 380 won't be parsed as intended on a Model B either, I think..? But for some reason the game still works on a Model B anyway (probably because the Model B DFS just ignores everything after "*DRIVE2", whereas the Master DFS stops and complains about it).

So, this is my attempt at making the game Master-compatible:

1. Replace line 380 in $.RW with the new lines 380 and 381 as shown above.

2. Add the following new lines 105 and 630 to $.LOAD:

Code: Select all

105IFINKEY-256=253 FORI%=32TO96STEP32:READ F$:F%=OPENIN(F$):FORC%=I%TOI%+31:VDU23,C%:FORV%=1TO8:VDUBGET#F%:NEXT:NEXT:CLOSE#F%:NEXT

630DATA SMALL-N,SMALL-U,SMALL-L

[EDIT: Step 3 not needed. Slim char defs incorporated into Step 2 above.]

3. Save the following BASIC program as LOAD2 on side 0 of the disc:

Code: Select all

 10 REM Slim char defs
 20 RESTORE
 30 FOR I%=32 TO 96 STEP 32
 40  READ F$:F%=OPENIN(F$)
 50  FOR C%=I% TO I%+31
 60   VDU 23,C%
 70   FOR V%=1 TO 8:VDU BGET#F%:NEXT
 80  NEXT
 90  CLOSE#F%
100 NEXT
110 CHAIN "RW"
120 END
130 DATA SMALL-N,SMALL-U,SMALL-L

[/s]

Code: Select all

10REM Slim char defs
20VDU23,32,0,0,0,0,0,0,0,0
30VDU23,33,&40,&40,&40,&40,&40,0,&40,0
40VDU23,34,&A0,&A0,&A0,0,0,0,0,0
50VDU23,35,0,&A0,&E0,0,&E0,&A0,0,0
60VDU23,36,&40,&E0,&C0,&40,&60,&E0,&40,0
70VDU23,37,&A0,&20,&40,&40,&80,&A0,0,0
80VDU23,38,&A0,&E0,&A0,0,&A0,&40,&A0,0
90VDU23,39,&20,&60,&40,0,0,0,0,0
100VDU23,40,&40,&80,&80,&80,&80,&80,&40,0
110VDU23,41,&40,&20,&20,&20,&20,&20,&40,0
120VDU23,42,0,&40,&E0,&40,&E0,&40,0,0
130VDU23,43,0,&40,&40,&E0,&40,&40,0,0
140VDU23,44,0,0,0,0,0,&40,&40,&80
150VDU23,45,0,0,0,&E0,0,0,0,0
160VDU23,46,0,0,0,0,0,&40,&40,0
170VDU23,47,&20,&20,&40,&40,&80,&80,0,0
180VDU23,48,&40,&A0,&A0,&A0,&A0,&A0,&40,0
190VDU23,49,&40,&C0,&40,&40,&40,&40,&E0,0
200VDU23,50,&E0,&A0,&20,&E0,&80,&80,&E0,0
210VDU23,51,&E0,&A0,&20,&40,&20,&A0,&E0,0
220VDU23,52,&80,&80,&A0,&A0,&E0,&20,&20,0
230VDU23,53,&E0,&80,&E0,&20,&20,&A0,&E0,0
240VDU23,54,&E0,&A0,&80,&E0,&A0,&A0,&E0,0
250VDU23,55,&E0,&20,&20,&20,&20,&20,&20,0
260VDU23,56,&E0,&A0,&A0,&40,&A0,&A0,&E0,0
270VDU23,57,&E0,&A0,&A0,&E0,&20,&A0,&E0,0
280VDU23,58,0,&40,&40,0,0,&40,&40,0
290VDU23,59,0,&40,&40,0,0,&40,&40,&80
300VDU23,60,0,&20,&40,&80,&40,&20,0,0
310VDU23,61,0,0,&E0,0,&E0,0,0,0
320VDU23,62,0,&80,&40,&20,&40,&80,0,0
330VDU23,63,&E0,&A0,&20,&60,&40,0,&40,0
340VDU23,64,&E0,&A0,&A0,&E0,&80,&A0,&E0,0
350VDU23,65,&E0,&A0,&A0,&E0,&A0,&A0,&A0,0
360VDU23,66,&C0,&A0,&A0,&C0,&A0,&A0,&C0,0
370VDU23,67,&E0,&A0,&80,&80,&80,&A0,&E0,0
380VDU23,68,&C0,&A0,&A0,&A0,&A0,&A0,&C0,0
390VDU23,69,&E0,&A0,&80,&C0,&80,&A0,&E0,0
400VDU23,70,&E0,&A0,&80,&C0,&80,&80,&80,0
410VDU23,71,&E0,&A0,&80,&A0,&A0,&A0,&E0,0
420VDU23,72,&A0,&A0,&A0,&E0,&A0,&A0,&A0,0
430VDU23,73,&E0,&40,&40,&40,&40,&40,&E0,0
440VDU23,74,&E0,&20,&20,&20,&20,&A0,&E0,0
450VDU23,75,&A0,&A0,&C0,&C0,&A0,&A0,&A0,0
460VDU23,76,&80,&80,&80,&80,&80,&A0,&E0,0
470VDU23,77,&A0,&E0,&E0,&A0,&A0,&A0,&A0,0
480VDU23,78,&A0,&A0,&E0,&E0,&E0,&A0,&A0,0
490VDU23,79,&E0,&A0,&A0,&A0,&A0,&A0,&E0,0
500VDU23,80,&E0,&A0,&A0,&E0,&80,&80,&80,0
510VDU23,81,&E0,&A0,&A0,&A0,&A0,&C0,&20,0
520VDU23,82,&E0,&A0,&A0,&E0,&C0,&A0,&A0,0
530VDU23,83,&E0,&A0,&80,&E0,&20,&A0,&E0,0
540VDU23,84,&E0,&40,&40,&40,&40,&40,&40,0
550VDU23,85,&A0,&A0,&A0,&A0,&A0,&A0,&E0,0
560VDU23,86,&A0,&A0,&A0,&A0,&A0,&A0,&40,0
570VDU23,87,&A0,&A0,&A0,&A0,&E0,&E0,&A0,0
580VDU23,88,&A0,&A0,&40,&40,&40,&A0,&A0,0
590VDU23,89,&A0,&A0,&E0,&40,&40,&40,&40,0
600VDU23,90,&E0,&A0,&20,&40,&80,&A0,&E0,0
610VDU23,91,&E0,&80,&80,&80,&80,&80,&E0,0
620VDU23,92,&80,&80,&40,&40,&20,&20,0,0
630VDU23,93,&E0,&20,&20,&20,&20,&20,&E0,0
640VDU23,94,&40,&E0,&A0,0,0,0,0,0
650VDU23,95,0,0,0,0,0,0,0,&E0
660VDU23,96,&E0,&A0,&80,&80,&40,&80,&E0,0
670VDU23,97,0,0,&E0,&20,&E0,&A0,&E0,0
680VDU23,98,&80,&80,&E0,&A0,&A0,&A0,&E0,0
690VDU23,99,0,0,&E0,&A0,&80,&A0,&E0,0
700VDU23,100,&20,&20,&E0,&A0,&A0,&A0,&E0,0
710VDU23,101,0,0,&E0,&A0,&E0,&80,&E0,0
720VDU23,102,0,0,&E0,&80,&C0,&80,&80,0
730VDU23,103,0,0,&E0,&A0,&A0,&E0,&20,&E0
740VDU23,104,&80,&80,&E0,&A0,&A0,&A0,&A0,0
750VDU23,105,&40,0,&C0,&40,&40,&40,&E0,0
760VDU23,106,&20,0,&60,&20,&20,&20,&A0,&E0
770VDU23,107,&80,&80,&A0,&A0,&C0,&A0,&A0,0
780VDU23,108,&C0,&40,&40,&40,&40,&40,&E0,0
790VDU23,109,0,0,&A0,&E0,&E0,&A0,&A0,0
800VDU23,110,0,0,&E0,&A0,&A0,&A0,&A0,0
810VDU23,111,0,0,&E0,&A0,&A0,&A0,&E0,0
820VDU23,112,0,0,&E0,&A0,&A0,&E0,&80,&80
830VDU23,113,0,0,&E0,&A0,&A0,&E0,&20,&20
840VDU23,114,0,0,&E0,&A0,&80,&80,&80,0
850VDU23,115,0,0,&E0,&80,&E0,&20,&E0,0
860VDU23,116,&40,&40,&E0,&40,&40,&40,&60,0
870VDU23,117,0,0,&A0,&A0,&A0,&A0,&E0,0
880VDU23,118,0,0,&A0,&A0,&A0,&40,&40,0
890VDU23,119,0,0,&A0,&A0,&E0,&E0,&A0,0
900VDU23,120,0,0,&A0,&A0,&40,&A0,&A0,0
910VDU23,121,0,0,&A0,&A0,&A0,&E0,&20,&E0
920VDU23,122,0,0,&E0,&20,&40,&80,&E0,0
930VDU23,123,&20,&60,&40,&C0,&40,&60,&20,0
940VDU23,124,&40,&40,&40,0,&40,&40,&40,0
950VDU23,125,&80,&C0,&40,&60,&40,&C0,&80,0
960VDU23,126,&A0,&E0,&80,0,0,0,0,0
970VDU23,127,0,0,0,0,0,0,0,0
980CHAIN "RW"

[/s]

[tricky]

I would have thought

Code: Select all

380IFLC%<>0ANDLC%<30THEN OSCLI("DRIVE2") ELSE OSCLI("DRIVE0")

would be the way to go, but I don't do much BASIC.
But maybe not as no one has suggested it

[Dethmunk]

This is really cool! Thank you for something new and interesting on the beeb, really liking it so far

One little thing that may be a bug, on the first screen I tried typing random commands like LOOK, LOOK DOWN, LOOK TAVERN, etc. The screen goes black and then reloads from disk, and sometimes goes black altogether to which I pressed ESC which caused the graphic to load but no text or input and seemed to be hung. It just seems to be the word LOOK that it doesn't like... but i'm trying more

Would be happy to assist with some of the game logic if you wanted, or also happy to wait for another version to test out as well. I do a lot of testing at work so I am always trying lots of things to break applications so I know how to fix them

Let me know if you can reproduce this issue above or if you need more info.

Lots of feedback to do... LOL
LOOK is a singular command and it simply reloads of the screen and description. Pressing ESC with just hang the game its to stop people just trying to access the code.

[Dethmunk]

Time for some quick feedback...

My children have been playing this for a couple of hours yesterday - good timing actually, my wife's been poorly and it gave them something quiet to do while she was recovering! They're really into it, and I'm very impressed with the beautiful illustrations and the nice gameplay. We're stuck at... well, a certain point, but have not given up hope yet. The hints sheet doesn't seem to be helping us at the moment.

No real bugs found, although on BeebEm we forgot to turn off disc protection and were mystified for a while as to why it wasn't saving. Ideally it would give an error message rather than restart the game, but I appreciate this might be difficult to arrange.

I did try really hard to get it loaded on some real hardware (for testing purposes), but I ran into two major issues relating to the game being on DSD disk:

1) Omniflop seems to struggle to write the image to a 3.5" disk - I abandoned the operation part way through because the drive was making odd noises and there wasn't a progress bar shown on the screen. However I later discovered that it had written the catalogue to side 0 of the disk, so maybe it was working after all.

2) MMBImager only deals with SSD images, so I was unable to load it onto SD card.

I then resorted to UPURS (on the Electron), but I've modified my EUP card to get the sideways RAM working AND then stupidly not put the UPURS rom image onto a floppy! Given that I now have sideways RAM elsewhere I think I'll de-modify the EUP board and stick a proper ROM on there to save this kind of faffing around. Ultimately UPURS will be the solution, and then I can test on my Elks & BBC Master for you.

You might want to wait til the new year when I plan to release a separated SSD file version of the game for the BBC. Also I'll be doing a tweaked version for the Electron as it doesn't like the *DRIVE0 and *DRIVE2 switching it does for the BBC.

[Dethmunk]

Just a bug-spot:
The narrow font doesn't work on the Master (MOS 3.2 or 3.5) - this will be some OS shenanigans to do with character sets... It works fine on my master booted into OS1.2

DSC_2263.JPG

It won't boot at all on Beebem in M128 mode.

d.

Yep its not Master compatible at the moment. It's the Font's memory locations that it does to halve the printable width and where the new font is stored... I think.

[Dethmunk]

Thanks for the adventure, my daughter has been playing it, she is sick in the woods. I might get a chance this afternoon.

LOL. No prob. Its it the first woods, The Siren Woods? There two ways out of them... A magic word that can be discovered in that area or a set of directions used north of the Brook. As the Hint Sheet on the website says... Never, Never, Ever give up

[Dethmunk]

The Master-incompatibility may be partly due to the Slim Chars code, which is taken from pages 60 and 61 here but isn't compatible with the Master.

Here's a Master-only version of Robin Nixon's Slim Characters program:

• SlimChars.ssd.zip

The original Elk/ModelB version of the program stored the slim char definitions in Pages &9, &A and &C, but in the Master there's (always?) space set aside high up in memory (in ANDY?) for the fully exploded character set, so you don't need to (and can't?) put char defs elsewhere.

Awesome I'll look at that when I get back home after christmas, then may be I can sort out a Master Compatible version

[Dethmunk]

I tried it on a real Master 128 with a double sided drive but it doesn't work. It also doesn't work in B-em when set to be a Master 128. The first two menus appear but the ingame screen in black

That specific problem can be fixed if you replace line 380 in the BASIC program $.RW --

Code: Select all

380IFLC%<>0ANDLC%<30THEN *DRIVE2 ELSE *DRIVE0

-- with this:

Code: Select all

380*DRIVE0
381IFLC%<>0ANDLC%<30THEN *DRIVE2

At least, this works in Master 128 mode in BeebEm.

I believe this issue arises because in the original line 380, everything after the first asterisk, up to the end of the line, is treated by BASIC as if it were all one big OS command: "*DRIVE2 ELSE *DRIVE0"! (I.e. the "ELSE" isn't parsed as a BASIC keyword.)

The original line 380 won't be parsed as intended on a Model B either, I think..? But for some reason the game still works on a Model B anyway (probably because the Model B DFS just ignores everything after "*DRIVE2", whereas the Master DFS stops and complains about it).

So, this is my attempt at making the game Master-compatible:

1. Replace line 380 in $.RW with the new lines 380 and 381 as shown above.

2. Add the following line 105 to $.LOAD:

Code: Select all

105IF INKEY-256=253 CHAIN "LOAD2"

3. Save the following BASIC program as LOAD2 on side 0 of the disc:

Code: Select all

10REM Slim char defs
20VDU23,32,0,0,0,0,0,0,0,0
30VDU23,33,&40,&40,&40,&40,&40,0,&40,0
40VDU23,34,&A0,&A0,&A0,0,0,0,0,0
50VDU23,35,0,&A0,&E0,0,&E0,&A0,0,0
60VDU23,36,&40,&E0,&C0,&40,&60,&E0,&40,0
70VDU23,37,&A0,&20,&40,&40,&80,&A0,0,0
80VDU23,38,&A0,&E0,&A0,0,&A0,&40,&A0,0
90VDU23,39,&20,&60,&40,0,0,0,0,0
100VDU23,40,&40,&80,&80,&80,&80,&80,&40,0
110VDU23,41,&40,&20,&20,&20,&20,&20,&40,0
120VDU23,42,0,&40,&E0,&40,&E0,&40,0,0
130VDU23,43,0,&40,&40,&E0,&40,&40,0,0
140VDU23,44,0,0,0,0,0,&40,&40,&80
150VDU23,45,0,0,0,&E0,0,0,0,0
160VDU23,46,0,0,0,0,0,&40,&40,0
170VDU23,47,&20,&20,&40,&40,&80,&80,0,0
180VDU23,48,&40,&A0,&A0,&A0,&A0,&A0,&40,0
190VDU23,49,&40,&C0,&40,&40,&40,&40,&E0,0
200VDU23,50,&E0,&A0,&20,&E0,&80,&80,&E0,0
210VDU23,51,&E0,&A0,&20,&40,&20,&A0,&E0,0
220VDU23,52,&80,&80,&A0,&A0,&E0,&20,&20,0
230VDU23,53,&E0,&80,&E0,&20,&20,&A0,&E0,0
240VDU23,54,&E0,&A0,&80,&E0,&A0,&A0,&E0,0
250VDU23,55,&E0,&20,&20,&20,&20,&20,&20,0
260VDU23,56,&E0,&A0,&A0,&40,&A0,&A0,&E0,0
270VDU23,57,&E0,&A0,&A0,&E0,&20,&A0,&E0,0
280VDU23,58,0,&40,&40,0,0,&40,&40,0
290VDU23,59,0,&40,&40,0,0,&40,&40,&80
300VDU23,60,0,&20,&40,&80,&40,&20,0,0
310VDU23,61,0,0,&E0,0,&E0,0,0,0
320VDU23,62,0,&80,&40,&20,&40,&80,0,0
330VDU23,63,&E0,&A0,&20,&60,&40,0,&40,0
340VDU23,64,&E0,&A0,&A0,&E0,&80,&A0,&E0,0
350VDU23,65,&E0,&A0,&A0,&E0,&A0,&A0,&A0,0
360VDU23,66,&C0,&A0,&A0,&C0,&A0,&A0,&C0,0
370VDU23,67,&E0,&A0,&80,&80,&80,&A0,&E0,0
380VDU23,68,&C0,&A0,&A0,&A0,&A0,&A0,&C0,0
390VDU23,69,&E0,&A0,&80,&C0,&80,&A0,&E0,0
400VDU23,70,&E0,&A0,&80,&C0,&80,&80,&80,0
410VDU23,71,&E0,&A0,&80,&A0,&A0,&A0,&E0,0
420VDU23,72,&A0,&A0,&A0,&E0,&A0,&A0,&A0,0
430VDU23,73,&E0,&40,&40,&40,&40,&40,&E0,0
440VDU23,74,&E0,&20,&20,&20,&20,&A0,&E0,0
450VDU23,75,&A0,&A0,&C0,&C0,&A0,&A0,&A0,0
460VDU23,76,&80,&80,&80,&80,&80,&A0,&E0,0
470VDU23,77,&A0,&E0,&E0,&A0,&A0,&A0,&A0,0
480VDU23,78,&A0,&A0,&E0,&E0,&E0,&A0,&A0,0
490VDU23,79,&E0,&A0,&A0,&A0,&A0,&A0,&E0,0
500VDU23,80,&E0,&A0,&A0,&E0,&80,&80,&80,0
510VDU23,81,&E0,&A0,&A0,&A0,&A0,&C0,&20,0
520VDU23,82,&E0,&A0,&A0,&E0,&C0,&A0,&A0,0
530VDU23,83,&E0,&A0,&80,&E0,&20,&A0,&E0,0
540VDU23,84,&E0,&40,&40,&40,&40,&40,&40,0
550VDU23,85,&A0,&A0,&A0,&A0,&A0,&A0,&E0,0
560VDU23,86,&A0,&A0,&A0,&A0,&A0,&A0,&40,0
570VDU23,87,&A0,&A0,&A0,&A0,&E0,&E0,&A0,0
580VDU23,88,&A0,&A0,&40,&40,&40,&A0,&A0,0
590VDU23,89,&A0,&A0,&E0,&40,&40,&40,&40,0
600VDU23,90,&E0,&A0,&20,&40,&80,&A0,&E0,0
610VDU23,91,&E0,&80,&80,&80,&80,&80,&E0,0
620VDU23,92,&80,&80,&40,&40,&20,&20,0,0
630VDU23,93,&E0,&20,&20,&20,&20,&20,&E0,0
640VDU23,94,&40,&E0,&A0,0,0,0,0,0
650VDU23,95,0,0,0,0,0,0,0,&E0
660VDU23,96,&E0,&A0,&80,&80,&40,&80,&E0,0
670VDU23,97,0,0,&E0,&20,&E0,&A0,&E0,0
680VDU23,98,&80,&80,&E0,&A0,&A0,&A0,&E0,0
690VDU23,99,0,0,&E0,&A0,&80,&A0,&E0,0
700VDU23,100,&20,&20,&E0,&A0,&A0,&A0,&E0,0
710VDU23,101,0,0,&E0,&A0,&E0,&80,&E0,0
720VDU23,102,0,0,&E0,&80,&C0,&80,&80,0
730VDU23,103,0,0,&E0,&A0,&A0,&E0,&20,&E0
740VDU23,104,&80,&80,&E0,&A0,&A0,&A0,&A0,0
750VDU23,105,&40,0,&C0,&40,&40,&40,&E0,0
760VDU23,106,&20,0,&60,&20,&20,&20,&A0,&E0
770VDU23,107,&80,&80,&A0,&A0,&C0,&A0,&A0,0
780VDU23,108,&C0,&40,&40,&40,&40,&40,&E0,0
790VDU23,109,0,0,&A0,&E0,&E0,&A0,&A0,0
800VDU23,110,0,0,&E0,&A0,&A0,&A0,&A0,0
810VDU23,111,0,0,&E0,&A0,&A0,&A0,&E0,0
820VDU23,112,0,0,&E0,&A0,&A0,&E0,&80,&80
830VDU23,113,0,0,&E0,&A0,&A0,&E0,&20,&20
840VDU23,114,0,0,&E0,&A0,&80,&80,&80,0
850VDU23,115,0,0,&E0,&80,&E0,&20,&E0,0
860VDU23,116,&40,&40,&E0,&40,&40,&40,&60,0
870VDU23,117,0,0,&A0,&A0,&A0,&A0,&E0,0
880VDU23,118,0,0,&A0,&A0,&A0,&40,&40,0
890VDU23,119,0,0,&A0,&A0,&E0,&E0,&A0,0
900VDU23,120,0,0,&A0,&A0,&40,&A0,&A0,0
910VDU23,121,0,0,&A0,&A0,&A0,&E0,&20,&E0
920VDU23,122,0,0,&E0,&20,&40,&80,&E0,0
930VDU23,123,&20,&60,&40,&C0,&40,&60,&20,0
940VDU23,124,&40,&40,&40,0,&40,&40,&40,0
950VDU23,125,&80,&C0,&40,&60,&40,&C0,&80,0
960VDU23,126,&A0,&E0,&80,0,0,0,0,0
970VDU23,127,0,0,0,0,0,0,0,0
980CHAIN "RW"

Ahhhhhh!!!! I've been hacked!!!!! Someone call the Authorities!!!
Good work that...

[PitfallJones]

Thanks so much for the fixes.

I can't seem to get b-em (or beebem) to save the changes back to the disk image however - can anyone help?

Thanks

PJ

[Dethmunk]

In BeebEm goto File - Disc Options - and you will see Write Protect 0 is ticked.... Un tick this and you'll be allowed to save the game.

[Lardo Boffin]

Ahhhhhh!!!! I've been hacked!!!!! Someone call the Authorities!!!
Good work that...

Good luck protecting your code from this lot!

[Dethmunk]

Lol. Yeah I know. It's no biggy.

[lurkio]

Lol. Yeah I know. It's no biggy.

I hope you mean that, because... stand by for more hacking! (I'm hoping all this might eventually be useful, or at least interesting.)

My listing for $.LOAD2, above, which helps make the game Master-compatible, can be modified to save space by using the existing char def binaries that are already included on your disc -- $.SMALL-N, $.SMALL-U and $.SMALL-L:

Code: Select all

 10 REM Slim char defs
 20 RESTORE
 30 FOR I%=32 TO 96 STEP 32
 40  READ F$:F%=OPENIN(F$)
 50  FOR C%=I% TO I%+31
 60   VDU 23,C%
 70   FOR V%=1 TO 8:VDU BGET#F%:NEXT
 80  NEXT
 90  CLOSE#F%
100 NEXT
110 CHAIN "RW"
120 END
130 DATA SMALL-N,SMALL-U,SMALL-L

[EDIT: The code can be compacted. See my post above.]

... Here is a disc with your image compressed with my compressor ...

tricky, I used your C program to compress all the images on side 2 of the game disc. Here are the compressed files:

• 

And here are the uncompressed files on side 0 of the disc:

• 

If you add up all the file lengths, you get a total of about 220KB, which means you'd still have to find a way to "lose" about 20KB of data if you wanted to squeeze the whole game, including all the pictures, onto a .SSD disc image.* (I think there are a few pics on side 0 that I left uncompressed. Would compressing them be enough?)



* Of course, you'd also have to lump all the images into one file and write a loader that could load in data from an offset within that file, etc., etc.!

[Dethmunk]

No problem Lurkio. I'm not precious about it. It's just a BASIC prog. I would be a bit miffed if it got hacked to be easier or to change the game play etc. That would be a bit rude in my book.
But if you can get a nice solution for a Master version working, then fair play. and I'd be happy to stick that on the website with credit to you.

I still have an Electron version to get working when I get back from Xmas break.

I'm convinced that this could be a far more compressed and efficient game, but I'm only a humble artist. I do what I can, i'll never be in the league of you guys lol.

[lurkio]

if you can get a nice solution for a Master version working, then fair play

If you make the changes detailed in my post above then you'll have a version of the game that'll run on both a Master and a Model B. (It detects if it's running on a Master and if so it defines the slim characters in a Master-compatible way.)

I still have an Electron version to get working

Try my Master-compatible version in an Electron/emulator. I suspect it was the "*DRIVE2 ELSE *DRIVE0" problem in $.RW that was stopping the game from running on Elks as well as Masters.

I'm convinced that this could be a far more compressed and efficient game

Ideally, tricky would modify his decompression machine-code so that it reads compressed data straight off disc. Then you'd be able to lump all your pictures together in one file, compressed, and load-and-decompress them direct to screen RAM. Then hopefully your whole game would fit onto a single .SSD disc image.

tricky..?

[tricky]

The decompresser was written to be fast and tiny, but I'm sure a few lines of basic would load the but you want.
Over to someone who writes basic

[lurkio]

The decompresser was written to be fast and tiny, but I'm sure a few lines of basic would load the but you want.

Sure, but it's just a question of where to load the compressed data before decompressing it! Because memory's already rather tight. (There is the solution of temporarily disabling the display, loading the compressed data to screen RAM, decompressing it to the top of the screen, and then re-enabling the display. But it seems a bit faffy!)

I was thinking it might be possible for your decompressor to use OSFIND and OSGPBPBGB (or whatever it's called!) to do random-access back-and-forths directly from the disc file while decompressing.

Just a thought.

[fuzzel]

Back to the game itself...
I'm loving the atmosphere engendered by the graphics but after an hour or two of wandering around, drawing a map and solving a couple of puzzles I'm well and truly stuck. I think I'll have a breather and get back to work on LOT 2 again (level 1 is coming on nicely).

[tricky]

Sure, but it's just a question of where to load the compressed data before decompressing it!

As the decompresser can overwrite what it has decompressed, as long as the last bye (0) is not overwritten, you can load the compressed data to the end of the display area overrunning by 1 bye (0).

[AndyF]

Regarding 'new' I have plenty of conversions still to do on my list from a couple of years ago, its a question of finding time and being in the right mindframe to start (and finish! more importantly) some of them...

[lurkio]

As the decompresser can overwrite what it has decompressed, as long as the last bye (0) is not overwritten, you can load the compressed data to the end of the display area overrunning by 1 bye (0).

Okay, I wrote a BASIC test prog that loaded, decompressed and displayed the compressed picture files using your decompressor, tricky. The program ran quickly, but at this stage there were still 30 individual picture files on the disc.

Then I lumped all the compressed files into one big file and amended my BASIC program to call OSGBPB to load successive chunks of the big file, one chunk per compressed picture. The program wasn't as fast this time. In fact, I think it might be unacceptably slow.

Here's the listing for the slow program. It includes the source for your decompressor, tricky, but it's not the decompressor that's slowing things down:

Code: Select all

MODE7:HIMEM=&5800
DIM O%(30):REM Offsets within pic file
O%(1)=0
O%(2)=&E32
O%(3)=&1D8F
O%(4)=&2819
O%(5)=&378D
O%(6)=&4618
O%(7)=&560A
O%(8)=&666B
O%(9)=&745B
O%(10)=&7EC7
O%(11)=&8B74
O%(12)=&959A
O%(13)=&A48B
O%(14)=&B38F
O%(15)=&C149
O%(16)=&CE16
O%(17)=&DF27
O%(18)=&ED35
O%(19)=&FB81
O%(20)=&10762
O%(21)=&11896
O%(22)=&124A7
O%(23)=&13436
O%(24)=&14090
O%(25)=&14EEE
O%(26)=&15BE8
O%(27)=&169CB
O%(28)=&176D7
O%(29)=&18088
O%(30)=&18F10
DIM D%(30):REM Compresed pic lengths
D%(1)=&E32
D%(2)=&F5D
D%(3)=&A8A
D%(4)=&F74
D%(5)=&E8B
D%(6)=&FF2
D%(7)=&1061
D%(8)=&DF0
D%(9)=&A6C
D%(10)=&CAD
D%(11)=&A26
D%(12)=&EF1
D%(13)=&F04
D%(14)=&DBA
D%(15)=&CCD
D%(16)=&1111
D%(17)=&E0E
D%(18)=&E4C
D%(19)=&BE1
D%(20)=&1134
D%(21)=&C11
D%(22)=&F8F
D%(23)=&C5A
D%(24)=&E5E
D%(25)=&CFA
D%(26)=&DE3
D%(27)=&D0C
D%(28)=&9B1
D%(29)=&E88
D%(30)=&D23
DIM CODE 100
PRINT'"Assembling tricky's decompressor..."
FOR Q% = 0 TO 2 STEP 2
P%=CODE
[ OPT Q%
ldx #0       ; (zp,x) will be used to access (zp,0)
.for
lda (&80,X)  ; next control byte
beq done     ; 0 signals end of decompression
bpl copy_raw ; msb=0 means just copy this many bytes from source
clc
adc #&80 + 2 ; flip msb, then add 2, we wont request 0 or 1 as that wouldn't save anything
sta &84      ; count of bytes to copy (>= 2)
ldy #1       ; byte after control is offset
lda (&80),Y  ; offset from current src - 256
tay
lda &80  ; advance src past the control byte and offset
clc
adc #2
sta &80
bcc pg0
inc &80+1
.pg0
dec &82+1    ; -256
lda (&82),Y  ; +y
inc &82+1    ; +256
sta (&82,X)  ; +0
inc &82  ; INC dst (used for both src of copy (-256) and dst)
bne pg1
inc &82+1
.pg1
dec &84      ; count down bytes to copy
bne pg0
beq for      ; after copying, go back for next control byte
.copy_raw
tay          ; bytes to copy from src
.copy
inc &80  ; INC src (1st time past control byte)
bne pg2
inc &80+1
.pg2
dey
bmi for
lda (&80,X)  ; copy bytes
sta (&82,X)
inc &82  ; INC dst
bne pg3
inc &82+1
.pg3
bne copy     ; rest of bytes ; #1 replace with jmp if wrapping back to &0000 is required
.done
RTS
]
NEXT
PRINT'"Done"'
TIME=0:REPEATUNTILINKEY(0)>-1ORTIME>200
MODE5:VDU28,0,31,19,16
F%=OPENIN"Lpics"
?&900=F%
FORL%=1TO30
VDU19,0,0;0;19,1,0;0;19,2,0;0;19,3,0;0;
!&901=&6260
!&905=D%(L%)
!&909=O%(L%)
X%=0:Y%=9:A%=3
CALL&FFD1:REM OSGBPB
!&80=&58006260
CALL CODE:*| tricky's decompressor
CLS
VDU 19,0,0;0;19,1,7;0;19,2,6;0;19,3,4;0;
PRINT';L%;
*FX15
TIME=0:REPEATUNTILINKEY(0)>-1ORTIME>200
NEXT
CLOSE#F%

And here's a link -- SPOILER ALERT!!* -- to a disc image with the prog running in JSBeeb (I know the colours are wrong!):

• http://bbc.godbolt.org/?autoboot&disc=h ... 20pics.ssd

Not sure how I can speed things up.



* Reveals pictures of locations you might not yet have discovered in gameplay.

[danielj]

Which filing system are you doing this on? If it's a datacentre, I think RAMFS is based on DFS 0.9 which has the stupidly slow OSGBPB?

d.

[hoglet]

Which filing system are you doing this on? If it's a datacentre, I think RAMFS is based on DFS 0.9 which has the stupidly slow OSGBPB?

Actually, it turns out OSGBPB is slow in all versions of Acorn's DFS:
http://www.stardot.org.uk/forums/viewto ... 54#p154154

Dave

[lurkio]

Which filing system are you doing this on? If it's a datacentre, I think RAMFS is based on DFS 0.9 which has the stupidly slow OSGBPB?

I'm just using DFS 1.2 in BeebEm.

Actually, it turns out OSGBPB is slow in all versions of Acorn's DFS: http://www.stardot.org.uk/forums/viewto ... 54#p154154

Looking through that thread, I get the impression that direct sector-reads might be the way to go? That's what I was dreading!

Hmm. Perhaps a DSD isn't so bad after all..?!

[lurkio]

^
Feel the fear and do it anyway...

Loading the compressed pic data straight to screen RAM by using direct sector-reads with OSWORD &7F certainly sped things up.

SPOILER ALERT!! The links below might reveal pics of locations you haven't yet discovered in gameplay.

Before:

• http://bbc.godbolt.org/?autoboot&disc=h ... 20pics.ssd

After:

• http://bbc.godbolt.org/?autoboot&disc=h ... OSWORD.ssd

Fast OSWORD &7F slideshow code (scroll down to end):

Code: Select all

MODE7:HIMEM=&5800
DIM O%(31):REM Sector offsets
O%(1)=&0
O%(2)=&F
O%(3)=&1F
O%(4)=&2A
O%(5)=&3A
O%(6)=&49
O%(7)=&59
O%(8)=&6A
O%(9)=&78
O%(10)=&83
O%(11)=&90
O%(12)=&9B
O%(13)=&AA
O%(14)=&BA
O%(15)=&C8
O%(16)=&D5
O%(17)=&E7
O%(18)=&F6
O%(19)=&105
O%(20)=&111
O%(21)=&123
O%(22)=&130
O%(23)=&140
O%(24)=&14D
O%(25)=&15C
O%(26)=&169
O%(27)=&177
O%(28)=&185
O%(29)=&18F
O%(30)=&19E
O%(31)=&1AC
S%=2:REM Starting sector
DIM CODE 100
PRINT'"Assembling tricky's decompressor..."
FOR Q% = 0 TO 2 STEP 2
P%=CODE
[ OPT Q%
ldx #0       ; (zp,x) will be used to access (zp,0)
.for
lda (&80,X)  ; next control byte
beq done     ; 0 signals end of decompression
bpl copy_raw ; msb=0 means just copy this many bytes from source
clc
adc #&80 + 2 ; flip msb, then add 2, we wont request 0 or 1 as that wouldn't save anything
sta &84      ; count of bytes to copy (>= 2)
ldy #1       ; byte after control is offset
lda (&80),Y  ; offset from current src - 256
tay
lda &80  ; advance src past the control byte and offset
clc
adc #2
sta &80
bcc pg0
inc &80+1
.pg0
dec &82+1    ; -256
lda (&82),Y  ; +y
inc &82+1    ; +256
sta (&82,X)  ; +0
inc &82  ; INC dst (used for both src of copy (-256) and dst)
bne pg1
inc &82+1
.pg1
dec &84      ; count down bytes to copy
bne pg0
beq for      ; after copying, go back for next control byte
.copy_raw
tay          ; bytes to copy from src
.copy
inc &80  ; INC src (1st time past control byte)
bne pg2
inc &80+1
.pg2
dey
bmi for
lda (&80,X)  ; copy bytes
sta (&82,X)
inc &82  ; INC dst
bne pg3
inc &82+1
.pg3
bne copy ; rest of bytes ; #1 replace with jmp if wrapping back to &0000 is required
.done
RTS
]
NEXT
PRINT'"Done"'
TIME=0:REPEATUNTILINKEY(0)>-1ORTIME>200
MODE5:VDU28,0,31,19,16
FORL%=1TO30
 VDU19,0,0;0;19,1,0;0;19,2,0;0;19,3,0;0;
 T1%=(S%+O%(L%))/10:REM start track
 S1%=S%+O%(L%)-T1%*10:REM start sector
 T2%=(S%+O%(L%+1)-1)/10:REM end track
 S2%=(S%+O%(L%+1)-1)-T2%*10:REM final sct read
 P%=&6260
 FOR T%=T1% TO T2%
  ?&900=0:REM drive num
  !&901=P%:REM data buffer
  ?&905=3:REM num params
  ?&906=&53:REM command code 
  ?&907=T%:REM logical track num
  REM ?&908=logical sector num
  REM ?&909=num sects of 256B
  IF T%=T1% ?&908=S1%:?&909=&20+10-S1%:P%=P%+256*(10-S1%)
  IF T%>T1% AND T%<T2% ?&908=0:?&909=&2A:P%=P%+256*10
  IF T%=T2% ?&908=0:?&909=&20+S2%+1
  A%=&7F:X%=0:Y%=9
  CALL &FFF1
  REM P.'?&90A:REM result
 NEXT
 !&80=&58006260
 CALL CODE:*| tricky's decompressor
 CLS:VDU 19,0,0;0;19,1,7;0;19,2,6;0;19,3,4;0;
 PRINT';L%;:*FX15
 TIME=0:REPEATUNTILINKEY(0)>-1ORTIME>200
NEXT

So, loading is faster, but the big lumpen all-in-one compressed pic data file is slightly larger now because I had each compressed pic start on a sector boundary (to make the maths less of a nightmare!). The big file is about 107KB in size, and that still doesn't include the pics on side 0 of the original DSD!

So I'm still far from sure that the whole game will compress onto a single SSD.

[danielj]

Single sided drives are for wimps.