The Darkness of Raven Wood

[John_Acorn]

Dethmunk, how much memory did you have for the main program after screen memory and location text is loaded in?

[Dethmunk]

Dethmunk, how much memory did you have for the main program after screen memory and location text is loaded in?

It's in Mode 5 and to be honest once everything is loaded up it pretty much takes up nearly all the ram that is left roughly 22k I believe. Although someone like Lurkio or others who've worked on its optimization and compatibility would be able to give a more accurate number. I know when I was programming it in basic I was getting 'No Room' error towards the end and had to delete or shorten text or syntax to make it fit.

[radiorama]

FYI I heard back from Mark, he wasn't able to shed any light on the quirks but suggested I ask resident ADFS guru, JGH ... who is now on the case! Fingers crossed Jonathan can get to the bottom of it!

Is anyone still working on this game's quirks with ADFS? Any news from Jonathan?

Best,
Carlo.

[lurkio]

Carlo found some bugs in the game code, which I've now fixed:

• RWOOD-1B00-newN-order-carlo.ssd.zip

  .SSD DFS disc-image of Raven Wood with new bugfixes

  (126.76 KiB) Downloaded 209 times

[Michael Brown]

Hi,

What were the bugs?

Mick.

[lurkio]

Hi, What were the bugs?

See below, but the latest version of the .SSD, which I attached to my previous post in this thread, also contains fixes to the chardefs, and maybe some other minor changes too (e.g. ordering of files on disc).

I had found two bugs in Chapter 2, so I took a look at the code and went to the root of them. ... 1) I can "use handle" even outside of the water tank room. This bug is threefold, and it's all on line 1038 of RW2. The statement IFn$="HAND"ORn$="VALV"AND... is missing a pair of parentheses around n$="HAND"ORn$="VALV".

Fixed.

In the same line there's another bug with the value of V%(4) (plant status): looking everywhere else in the program, V%(4) assumes values 0 (live plant) or 2 (handle inserted, dying plant), while line 1038 checks for a value of 1 that will never be true.

I assume it should be checking for a value of 0 (rather than 1). Fixed.

The third bug on line 1038 is the lack of a check that the player actually has a valve handle in his inventory.

Fixed.

2) I can cut my hand even before visiting the dagger room. Line 141 of RW2 checks for verb "CUT" and noun "HAND" or "PALM", but doesn't look for a dagger in the player's inventory.

Fixed.

I will also mention that Alex Dijkstra reports a couple of bugs in his RW walkthrough on C.A.S.A.: http://solutionarchive.com/file/id%2C13730/ but I couldn't reproduce them. A brief look at the code seems to confirm that the bugs aren't there.

The bugs in question were fixed some time ago.

Maybe he played an earlier version of the game.

Yes, he did.

[radiorama]

Is anyone keeping track of all the minor modifications? The version posted by Lurkio today doesn't include my ADFS mods.

We should really set up a SVN or Git system for the Beeb

Carlo.

[minwah]

Just wanted to say thanks to Dethmunk for this game, really lovely. I haven't played it much yet but love the graphics, the font and the speed it runs at. Looking forward to playing it more.

Thanks also to lurkio for the version with fixes...that's the one I've been using.

Using a BBC Master with DataCentre (*DTRAP).

[lurkio]

Thanks also to lurkio for the version with fixes...that's the one I've been using.

Cheers! I've now uploaded that bugfixed version to bbcmicro.co.uk:

• http://bbcmicro.co.uk/game.php?id=2340

[zapiy]

Hi all,

I have been speaking to John about releasing this game on a 5.25 floppy, maybe in a box or something, I part own Bitmap Soft and you may know we have released All Hallows and soon we will release Rubicon too, both on tape.

So why am I here, well John mentioned there was a few issues, I wondered if anyone would be able to help us make this possible?

[lurkio]

I have been speaking to John about releasing this game on a 5.25 floppy, maybe in a box or something ... well John mentioned there was a few issues, I wondered if anyone would be able to help us make this possible?

Hi. Welcome to Stardot!

Can you elaborate on what the issues are..?

[zapiy]

John mentioned some were looking onto putting on disk, but he thinks they ran into a memory issue/bug to do with the DFS system?

[Arcadian]

Hi Jamie,

The reason I withheld issuing the physical copies of Raven Wood is because I don't believe we ever quite nailed down the ADFS compatibility issues that were effecting certain versions of ADFS, especially those patched for IDE devices such as Datacentre (scroll up through the thread for an example of some of my test results).

I did actually print inlays/labels/instruction slips and generate 20 x copies on 3.5" floppy disc (10 x ADFS, 10 x DFS) but refrained from issuing them as I wanted to see if the ADFS issue could be fixed first.

In theory, the DFS version should be fine on any system, however, as it's effectively the same code as the ADFS version, I wanted to wait until the issue had been addressed so that a 'universal' version of the code could be produced, which would run correctly regardless of what filing system it was ran on (DFS or, any flavour of ADFS including the patched ADFS versions). The idea being exactly the same code is featured on each disc, regardless of the format (DFS/ADFS).

I was probably being a bit too pedantic - I should have just issued them as-is. Going by what's been posted in the thread, it's possible the issues were down to known bugs in certain ADFS roms, so there might not even be a solution..

(I still have the copies I mastered several years back btw, but I managed to stand on the box containing all the cases, and crushed quite a lot of them! ). I still have lots more empty 'dual' cassette cases, but they're all in palletised storage in Leicester (place I told you about before Xmas, which also houses all of my cassette duplicators).

Edit - piccies added

[lurkio]

John mentioned some were looking onto putting on disk, but he thinks they ran into a memory issue/bug to do with the DFS system?

I think it was the ADFS system that some machines had problems running the game on. [EDIT: Since I started writing this post Arcadian has filled in some of the background.]

As far as I'm aware, the game runs fine on DFS, which is a simpler filesystem than ADFS. I believe DFS was more popular than ADFS back in the day, and it possibly still is. (Modern filesystems like MMFS, which use SD cards, are derived from DFS, in part.) The game should run without any problems on real DFS floppies, and on modern MMFS-based SD-card systems, and on Goteks. (I've tested it on DFS floppies and MMFS -- though I wouldn't claim that my testing has been what you might call "exhaustive" -- but I haven't tested on a Gotek at all.)

[Arcadian]

Chet did you ever incorporate Carlo's fixes into the most recent .ssd you mastered? According to his post above they appeared to be missed?

[lurkio]

Chet did you ever incorporate Carlo's fixes into the most recent .ssd you mastered? According to his post above they appeared to be missed?

The "fixes" or "modifications" that Carlo is referring to in that post are all to do with ADFS filesystem issues, and not with any gameplay-related bugs.

I've already fixed all the actual gameplay bugs that Carlo reported, and I've released my bugfixed DFS .SSD of the game on bbcmicro.co.uk. (I don't really understand ADFS, so I haven't touched it at all.)

[Arcadian]

Ah, but can you see what I'm getting at regarding the advantages of having a single 'universal' version of the code, that features both gameplay fixes and ADFS-file system fixes?

The idea being that if all files are copied from DFS > ADFS or ADFS > DFS the game will still work regardless of filing system version it is being executed on.

Judging by Carlo's comments it would appear that he thinks it should be possible?!

(I don't really understand ADFS, so I haven't touched it at all.)

Appreciate that, Carlo if you're reading is this something you could attempt to do i.e. (Migrate your ADFS fixes into Chet's SSD?) Can you even remember the fixes? I appreciate it was quite a long time ago now!

(just quoting Carlo so he should get a notification! )

Is anyone keeping track of all the minor modifications? The version posted by Lurkio today doesn't include my ADFS mods.

We should really set up a SVN or Git system for the Beeb

Carlo.

[lurkio]

can you see what I'm getting at regarding the advantages of having a single 'universal' version of the code, that features both gameplay fixes and ADFS-file system fixes? The idea being that if all files are copied from DFS > ADFS or ADFS > DFS the game will still work regardless of filing system version it is being executed on.

Ah. Gotcha. Sorry, I think I must have glazed over when you all started talking about ADFS!

But I think I understand now. I'll have a look, if Carlo doesn't beat me to it...

[lurkio]

Here is a new version adapted to different incarnations of ADFS. Tested and apparently working with:

* B-em in BBC B mode;

Check.

* B-em in BBC B+ mode with ADFS;

Check.

* B-em in Master 128 mode with DFS;

Check.

* B-em in Master 128 mode with ADFS;

Can't get it to work. I can choose option 2 ("Play the game") on the first menu screen, but then the screen clears and the cursor just blinks indefinitely. Nothing else happens. Same in BeebEm in M128 mode with ADFS.

[julie_m]

One thing I always wanted to do, but never got the chance with real Beeb hardware, was a game that would supplied on cassette but include a disc installer.

(The first draft of the idea would have involved mounting a small magnet inside the cassette shell, downstream of the playback head, to ensure it could only be installed once..... )

[danielj]

* B-em in Master 128 mode with ADFS;

Can't get it to work. I can choose option 2 ("Play the game") on the first menu screen, but then the screen clears and the cursor just blinks indefinitely. Nothing else happens. Same in BeebEm in M128 mode with ADFS.

Same on a real Master. Given that I don't know how the ADFS loader is put together I'm a bit dead-ended there.

-> There is no sense in worrying about it working under ADFS in a B+, as a B+ has DFS and ADFS is a memory hog on it. It really only matters for the Master Compact?

d.

[lurkio]

It really only matters for the Master Compact?

Just dug my neglected Master Compact out of the attic and dusted it off. And because I still don't know how to write ADFS .ADL disc-images onto physical media, I used the DFS disc-image RAVENWCC.SSD instead: I exported imported* the .SSD from a USB stick to RAM drive 0 of my DataCentre, which was connected to a Master 128, and I then used the *XFER command in the ADT ROM to copy the files from the RAM drive onto a 3.5-inch ADFS-format floppy disc on the same M128. I then took that floppy and inserted it into the amazingly-still-functioning "pedestal" disc drive of the Master Compact, which successfully ran the game. Phew.

I'll now look at how to integrate the latest gameplay bugfixes into this "universal" version of the game framework (RAVENWCC.SSD) created by Carlo.



* Btw, why in the name of holy nomenclature are the *EXPORT and *IMPORT commands in the DataCentre's RamFS called what they're called? To me, the names seem rather unintuitive and easily confused. Do you *EXPORT from the DataCentre to a real floppy? No, you don't. Apparently you have to *IMPORT from the DataCentre to the floppy. *EXPORT is for when you transfer data in the other direction. (Obvs..!?) Here's what the commands should have been called: *USB2BBC (for when you're transferring from the DataCentre's USB stick to one of the BBC's other filesystems (e.g. DFS)) and *BBC2USB (for when you're doing the reverse). Simples!

[zapiy]

Wow guys, this is awesome.

Not sure I even understand half of it but great news.

[SimonSideburns]

* Btw, why in the name of holy nomenclature are the *EXPORT and *IMPORT commands in the DataCentre's RamFS called what they're called? To me, the names seem rather unintuitive and easily confused. Do you *EXPORT from the DataCentre to a real floppy? No, you don't. Apparently you have to *IMPORT from the DataCentre to the floppy. *EXPORT is for when you transfer data in the other direction. (Obvs..!?) Here's what the commands should have been called: *USB2BBC (for when you're transferring from the DataCentre's USB stick to one of the BBC's other filesystems (e.g. DFS)) and *BBC2USB (for when you're doing the reverse). Simples!

Glad to see I'm not the only one who gets this in a muddle. I'm all for changing the names of the commands to something that's infinitely more unambiguous and with names that truly reflect their purpose.

If you wanted to hack the ROM image and keep everything else the same then I'd suggest using 6 characters, so maybe BBCUSB and USBBBC, but where adjusting the size is possible (for example when changing the source code), how about TOUSB and FROMUSB, or DSK2USB and USB2DSK. Anything but IMPORT and EXPORT!

[lurkio]

The way I'd been developing the two main BASIC programs for Raven Wood was by editing a "verbose" (i.e. not compressed) version of the BASIC code before compressing it using the Pack routine in the PRES Advanced BASIC Editor, to reduce the space it took up in user RAM. The Pack routine does various things to a BASIC program, including changing variable names and removing spaces -- which can make a compressed or "Packed" program unreadable and, often, uneditable.

The problem is that, in the course of creating his "universal" ADFS-compatible framework for the game, Carlo has edited the Packed version of the BASIC programs $.RW and $.RW2 regardless -- which means that the variable names and the spaces (or lack thereof) in his versions of the programs no longer match up with the vars and spaces in the non-compressed "verbose" versions that I use when I make gameplay-bugfixes, etc.

So I've now had to go back to try to unpick Carlo's changes from the Packed programs, figure out what the original variable names were, and then reintegrate his changes into my original (verbose) BASIC source so that I will then be able to copy and paste the source from my Mac text editor into BeebEm as per my usual workflow. (Said workflow is the reason I couldn't just blat my gameplay-bugfixes into Carlo's versions of the programs, which are Packed.)

Fortunately Carlo's changes to RW and RW2 weren't too extensive -- but still, to put it mildly, aargh.

[lurkio]

As far as I can say, ADFS pushing PAGE way up shouldn't be a problem. A 12 kB BASIC program running in MODE 5 with HIMEM at &5800, even with PAGE at &1F00, leaves abouk 2 kB of wiggle room.

Apparently not:

Screenshot showing "No room" error in Raven Wood when running on ADFS in B-Plus mode in Mac BeebEm

You get a no-room error when you try to complete the game when it's running with PAGE at &1F00 on ADFS in B-Plus mode in BeebEm. You don't get that error with PAGE at &1900 in Model B mode on DFS, as far as I can tell.

The error occurs quite a long way into the walkthrough (but still in Part 1), so it looks like Carlo's version of the game hasn't been tested thoroughly when PAGE is high.

EDIT: Btw, the fix isn't as simple as using a Shadow MODE instead of MODE5 because tricky's graphics loader routine has been set up to load a compressed image directly into screen RAM (starting at &5800) and then to uncompress it in screen RAM too -- and I don't know how to load data directly from disc into Shadow RAM instead of ordinary MODE5 screen RAM. Anyway, the more obvious solution would probably be to re-examine how the program declares variables (particularly string variables, I suspect) with the aim of making its use of the heap more efficient.

EDIT 2: And now, to cap it all, the version of the game I've attached to this post, which integrates my gameplay-bugfixes and Carlo's ADFS mods, and which works* on ADFS in B-Plus mode in BeebEm, no longer runs on ADFS on my real Master Compact! I can get to the second menu and press 1 to "Start Adventure", but then everything stops! No idea why. I give up!



* EDIT 3: I mean, I say "works"... The game boots and runs and lets you start playing, but of course it still crashes with a no-room error, as described above.

• RWerr.zip [DOWNLOAD DELETED to avoid confusion] + DFS .SSD disc-image of Carlo's version of the game with my gameplay-bugfixes integrated. Fails if PAGE is too high. + ADFS .ADL disc-image of same but WITHOUT gameplay-bugfixes. Fails if PAGE too high.
• RWerrSRC.zip [DOWNLOAD DELETED to avoid confusion] Uncompressed ("verbose") BASIC source code for the two main game files $.RW and $.RW2. Includes my gameplay-bugfixes and Carlo's ADFS-compatibility changes. Fails if PAGE is too high.

• Raven Wood walkthrough.txt

  Walkthrough for the game

  (1.44 KiB) Downloaded 101 times

EDIT 4: Amended the description of the ADFS .ADL disc-image in RWerr.zip to make clear that it doesn't include my gameplay-bugfixes. But the DFS .SSD does!

[Dave Footitt]

Glad to see I'm not the only one who gets this in a muddle. I'm all for changing the names of the commands to something that's infinitely more unambiguous and with names that truly reflect their purpose.

Haha yes it confuses me too!

[BeebMaster]

EDIT 2: And now, to cap it all, the version of the game I've attached to this post, which integrates my gameplay-bugfixes and Carlo's ADFS mods, and which works* on ADFS in B-Plus mode in BeebEm, no longer runs on ADFS on my real Master Compact! I can get to the second menu and press 1 to "Start Adventure", but then everything stops! No idea why. I give up! ](*,) ](*,)

I've had a go with the ADFS image in Station 114 (Master 128, MOS 3.20).

The game doesn't start properly as-is. When it stops with a blank screen after pressing 1 to Start the Adventure, it is in fact giving the error "Channel on channel 57" but you can't see it because VDU 21 mode is still engaged. This is because of the CLOSE#0 in the !Boot file. If this line is eliminated, the game does start.

But then after the first "What now?", the game stops again with the same channel error. This appears to be because of another CLOSE#0 in the exec file LOAD2. If you edit that out, you can play the game.

[P.S. can you change the blue writing to a different colour? I can't read blue on black on a CRT TV set!]

[lurkio]

the version of the game I've attached to this post ... no longer runs on ADFS on my real Master Compact! I can get to the second menu and press 1 to "Start Adventure", but then everything stops!

I've had a go with the ADFS image in Station 114 (Master 128, MOS 3.20). The game doesn't start properly as-is. When it stops with a blank screen after pressing 1 to Start the Adventure, it is in fact giving the error "Channel on channel 57" but you can't see it because VDU 21 mode is still engaged. This is because of the CLOSE#0 in the !Boot file. If this line is eliminated, the game does start. But then after the first "What now?", the game stops again with the same channel error. This appears to be because of another CLOSE#0 in the exec file LOAD2. If you edit that out, you can play the game.

Thanks for testing this! Did you definitely use the version of the game I attached to this previous post? I ask because I've made the edits you suggested (to !BOOT and LOAD2), and although I can now get past the second menu screen, the game just hangs on a blank, black screen when I press 1 to "Start Adventure"! That was on ADFS on my M128. The same thing happens on ADFS on my Master Compact too.

can you change the blue writing to a different colour? I can't read blue on black on a CRT TV set!

I do understand, but that was a design decision by the author of the game, John, who also did all the graphics, so I don't really feel I have the right to change the actual appearance of the game without his permission! But maybe he'll weigh in on the subject if he happens to read this...

[BeebMaster]

Just been reading further up:

If ADFS is detected, the program looks for the ADFS signature "Hugo" at &C401 (where the Compact ADFS stores the current directory information) and at &1201 (where regular 1D00 and 1F00 ADFSs store it); failing that, it systematically searches all the sideways RAMs/ROMs (that's where the PRES E00 ADFS stores the directory info). When a directory is found, a search starts for a "Lpics2" file and, if found, its starting sector on disc is finally read.


-- Carlo.

I presume this is so that specific data from part-way in the file can be loaded as required. I was sure that there was an OSFILE call to part-load a file, but apparently there isn't!

In ADFS you can refer to the current directory as "@", and open it for reading, so you could skip all the different guesses about where it might be in RAM and use

Code: Select all

DIM csd 1280
B%=OPENIN"@"
FOR C%=0TO1279:csd?C%=BGET#B%:NEXT
CLOSE#B%

and then you've got the CSD object in RAM starting at csd.