tricky wrote: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.

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

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.

Last edited by lurkio on Thu Dec 22, 2016 9:59 pm, edited 2 times in total.

PitfallJones wrote: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 --

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.

FourthStone wrote: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.

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.

tricky wrote: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

lurkio wrote: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

PitfallJones wrote: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 --

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.

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:

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.!

Last edited by lurkio on Sat Dec 31, 2016 2:01 pm, edited 2 times in total.

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.

Dethmunk wrote: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.)

Dethmunk wrote: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.

Dethmunk wrote: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..?

Last edited by lurkio on Sat Dec 31, 2016 1:58 pm, edited 1 time in total.

tricky wrote: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.

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).

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...

tricky wrote: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:

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.