Redirecting *TAPE to a faster filling system, e.g. DFS or MMC

for bbc micro/electron hardware, peripherals & programming issues (NOT emulators!)
Post Reply
User avatar
Lardo Boffin
Posts: 1647
Joined: Thu Aug 06, 2015 6:47 am
Contact:

Redirecting *TAPE to a faster filling system, e.g. DFS or MMC

Post by Lardo Boffin » Sat Oct 15, 2016 1:37 pm

I'm sure this kind of question gets asked every so often so I guess it's my turn!

I started a thread a while back about saving games in Twin Kingdom Valley and how it can't be done except on cassette. So you can load it from an MMC and it runs but you cannot save. The end result was that the game would need some considerable rewriting to work on MMC etc.

I recently got a retro clinic datacentre and it has a *DTRAP function which grabs all calls to DFS and processes them so that any games that calls *DISC etc before saving still save to the data centre.

So I was wondering if the same was possible with *TAPE? If standard calls to Save and Load etc. could be rerouted to the current fs, e.g. RAMFS or MMC then a lot of adventure games could be used (and progress saved) without them having to be individually hacked to work with disc.

Needless to say I am not volunteering to try to do this as it is way beyond my meagre skills but having seen some of things people have posted on here I am sure someone can do it!

I would imagine it would be popular if it could be done (either on a ROM that hijacks the system or hacked OS etc.) - I can't be the only one who enjoys games like TKV but doesn't have the extra time to load it from and save it to cassette?

Lardo
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
davidb
Posts: 2496
Joined: Sun Nov 11, 2007 10:11 pm
Contact:

Re: Redirecting *TAPE to a faster filling system, e.g. DFS or MMC

Post by davidb » Sat Oct 15, 2016 2:03 pm

You can trap calls to *TAPE and select another filing system instead but you would have to be careful that the filing system doesn't need to use the same part of RAM as the game you are running. Some other issues are covered in this message in the Compressed ROMs thread.

Something I would consider adding to my UEF2ROM tool is the ability to uninstall the *TAPE trap when the last part of the last file is loaded. The primary use case for that tool is the Mega Games Cartridge so there's no default alternative filing system to switch to: users might have a preference for DFS or ADFS, for example, and there's no way to know which one to switch to.

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

Re: Redirecting *TAPE to a faster filling system, e.g. DFS or MMC

Post by lurkio » Sat Oct 15, 2016 2:59 pm

As David implied, the problem with switching from tape to disc in the middle of a game is that the DFS needs to grab "workspace" RAM which is usually between &E00 and &1900 (which is why PAGE is raised to &1900 in most Beebs with disc interfaces), but unfortunately a lot of big text adventures that came on tape will be using that RAM for game code, so any "official" disc access will stomp all over the game code. (Maybe there are ways to get around that, but that's for wiser heads than mine, I'm afraid!)

I honestly think the most convenient way to play Beeb text adventures is in an emulator like BeebEm because you can save at any time, instantly, using the Save State emulator menu command.

But if you're dead-set on using real hardware (and so you should be!), another option is to try to track down the Replay ROM by Vine Micros, which consists of a ROM attached to a button and hooks that latch onto other chips inside the Beeb. When you press the button, it can "pause" or "freeze" a game in the middle of play and save almost the whole of the Beeb's RAM at that moment to a custom file on disc, which can be reloaded later, whenever you want to resume playing from the save-point.

:idea:

User avatar
davidb
Posts: 2496
Joined: Sun Nov 11, 2007 10:11 pm
Contact:

Re: Redirecting *TAPE to a faster filling system, e.g. DFS or MMC

Post by davidb » Sat Oct 15, 2016 5:05 pm

Reading the original question again, I wonder why *DTRAP couldn't also handle *TAPE calls. I'm assuming that the software running via MMC has been hacked to be disk-friendly, anyway, so it shouldn't matter if all loads and saves go via the MMC. Not having seen how *DTRAP is implemented, I don't know how much work it would be to add support for this feature.

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

Re: Redirecting *TAPE to a faster filling system, e.g. DFS or MMC

Post by jgharston » Sat Oct 15, 2016 6:16 pm

The way the Acorn API works a program should use whatever filing system is present without knowing or caring what filing system iy is. *TAPE, CHAIN "fred" should be exactly the same as *DISK, CHAIN "fred". In effect, you "redirect" tape commands to a faster filing system by just simply selecting that filing system.

Why is it not working when you load it from a non-TAPE filing system? Does the program have embedded *TAPE commands in it? Remove them. A program should not forcibly force itself into a particular state, it should just damn well do as the user tells it, this isn't Microsoft. "I see you're trying to write a letter, do you want me to launch an intercontinental missle?" No, I b***y well don't!

Code: Select all

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

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

Re: Redirecting *TAPE to a faster filling system, e.g. DFS or MMC

Post by jgharston » Sat Oct 15, 2016 6:23 pm

Ah, I've tracked down Twin Valley Kingdom to see what it is. You question is really:
"When I have a program that fills the entirety of memory, including all the filing system memory, how do I use a filing system?"

Answer: you can't. The filing system workspace has been claimed and used by Twin Valley Kingdom, there's no way to use a filing system that uses that memory without kicking Twin Valley Kingdom out of that memory.

RetroClinic RAMFS doesn't use any main memory, so you should be able to use RAMFS as the filing system and a program that stomps on memory all the way down to &E00. You appear to be wanting to load/save to RAMFS on the DataCentre, so just use RAMFS on the DataCentre.

...or does TVK have loads of *TAPE commands embedded in it, as I though in my previous post? In that case, TVK still needs to be bashed into behaving itself.

Code: Select all

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

User avatar
MartinB
Posts: 5237
Joined: Mon Mar 31, 2008 9:04 pm
Location: Obscurity
Contact:

Re: Redirecting *TAPE to a faster filling system, e.g. DFS or MMC

Post by MartinB » Sat Oct 15, 2016 6:30 pm

UPCFS, which is part of the UPURS rom suite, loads and runs UEF mirror-images of cassette-based programs directly from a PC with no intermediate storage system. It works by re-directing the OS FS calls applicable to the *TAPE system to the UPCFS replacements but we found that a huge number of programs contain explicit *TAPE directives and this significantly contributed to UPCFS only achieving a percentage compatibility (of those we tested) in the high eighties. A list of those that worked and that should therefore be suitable for testing in the context of this thread can be found here....

http://www.retro-kit.co.uk/page.cfm/con ... ng-titles/

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

Re: Redirecting *TAPE to a faster filling system, e.g. DFS or MMC

Post by jgharston » Sat Oct 15, 2016 6:44 pm

And on the Master filing systems don't use main memory, so you should be able to use a program that gobbles up memory and access the filing systems.

I've just been trying to use TVK, and I can't get past the first screen. Any command I give it ends up with it hanging. Pressing break leaves me with the current filing system selected, so it hasn't tried to change to tape.

Anyway, getting hungry, time for tea. EAST, TAKE KETTLE, FILL KETTLE ;)

Code: Select all

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

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

Re: Redirecting *TAPE to a faster filling system, e.g. DFS or MMC

Post by Lardo Boffin » Sat Oct 15, 2016 10:26 pm

Thanks for all the replies!

I guess my original question breaks down into 2 main sections:-

1) Memory issues with large adventure games and DFS etc.

2) How to ignore the multitude of nefarious *TAPE commands in some of these games and still save to MMC etc.

With regards to 1) I am aware of the issue (jgh pointed it out to me in my original TKV thread viewtopic.php?f=40&t=9950 ) and that having an E00 filing system (on the data centre, and i am also lucky enough to have an Opus Challenger 3 which has an E00 DFS) will most likely avoid it. Sorry - I should have made that clear but I was trying to post my question before my 2 year old woke up and wanted to play on my phone! :oops:

As for 2) *DTRAP on the datacentre doesn't help. If I type in *SAVE in TKV it hangs (flashing cursor but otherwise unresponsive - the caps light stays on and pressing the caps lock key makes no difference) the same as without it on an MMC system. Other than not being able to save the game works fine - it's is the version of TKV that comes preloaded on many MMC systems.

The ideal scenario then is that regardless of the game having *TAPE calls present it still saves to MMC or whatever. In effect it ignores *TAPE calls and sticks with whatever fs was in use before being loaded.

I did do a quick file dump of the main program and it does have *Tape in at least one place. I could try and remove that or change it to *RAM or similar but I suspect there could be other calls to set up the tape system not stored in plain text?

I know I keep on banging on about Twin kingdon valley but this question also applies to other tape based games with save facilities.

I would definitely rather play these games on an actual Beeb rather than an emulator as using the machine itself is part of the joy of the experience for me. :D

Lardo
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
lurkio
Posts: 2177
Joined: Tue Apr 09, 2013 11:30 pm
Location: Doomawangara
Contact:

Re: Redirecting *TAPE to a faster filling system, e.g. DFS or MMC

Post by lurkio » Sat Oct 15, 2016 10:35 pm

Lardo Boffin wrote:... having an E00 filing system (on the data centre
I thought that the RamFS that comes with the RetroClinic DataCentre raised PAGE above &E00..? Mine certainly always seems to!

:?:

User avatar
davidb
Posts: 2496
Joined: Sun Nov 11, 2007 10:11 pm
Contact:

Re: Redirecting *TAPE to a faster filling system, e.g. DFS or MMC

Post by davidb » Sat Oct 15, 2016 11:23 pm

Lardo Boffin wrote:The ideal scenario then is that regardless of the game having *TAPE calls present it still saves to MMC or whatever. In effect it ignores *TAPE calls and sticks with whatever fs was in use before being loaded.
That's what I do for the MGC and what Slogger more or less did with their T2P* ROMs.
Lardo Boffin wrote:I did do a quick file dump of the main program and it does have *Tape in at least one place. I could try and remove that or change it to *RAM or similar but I suspect there could be other calls to set up the tape system not stored in plain text?
That might work if it's *RAM that selects the MMC. Alternatively, just change it to ***** (five asterisks).

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

Re: Redirecting *TAPE to a faster filling system, e.g. DFS or MMC

Post by Lardo Boffin » Sun Oct 16, 2016 7:43 am

lurkio wrote:
Lardo Boffin wrote:... having an E00 filing system (on the data centre
I thought that the RamFS that comes with the RetroClinic DataCentre raised PAGE above &E00..? Mine certainly always seems to!

:?:
Did you also go for the ADFS for the cf HDD? I did and page is over &E00. I think it is supposed to be E00 without it.

Lardo
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
JudgeBeeb
Posts: 899
Joined: Thu Sep 10, 2015 8:56 pm
Contact:

Re: Redirecting *TAPE to a faster filling system, e.g. DFS or MMC

Post by JudgeBeeb » Sun Oct 16, 2016 11:45 am

Looking at the DataCentre manual, it is clear that it uses its own internal RAM as workspace and so, presumably, RamFS needs very little RAM on the Beeb (unlike other filing systems that seem to use great tracts of RAM).

The CF (IDE) interface is used to emulate a Winchester Hard Drive and uses a patched version of ADFS which like other versions of ADFS (certainly on my Beeb) raises PAGE not only beyond &E00, but beyond &1900 too. (On mine it is &1D00.) There is no mention in any of the documentation that I can see of using any other filing system with the CF card. I believe you can use JGH's HADFS, which will allow you to get away with PAGE at &1800.

There is reference in the manual to part of the DataCentre RAM being allocated to "ADFS Workspace", but then it says "Allocated for future use." The impression I get from this is that Mark has (or had) plans to do a patch of ADFS that could use the internal RAM rather than the Beeb's. But that doesn't appear to have been developed yet.

If you don't use the CF card, you could always remove the ADFS ROM (RamFS is on a separate ROM). But then, of course, you lose the CF card functionality, which is a pity.
There is so much wonder in the universe; why should you want to imagine that there is more?

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

Re: Redirecting *TAPE to a faster filling system, e.g. DFS or MMC

Post by lurkio » Sun Oct 16, 2016 11:58 am

In my Model B with DFS 1.20 and RamFS, and no other filing systems installed, PAGE is at &1900.

If I disable the DFS 1.2 ROM, then PAGE comes down to &1700.

Is this not what I should be seeing?

:idea:

User avatar
JudgeBeeb
Posts: 899
Joined: Thu Sep 10, 2015 8:56 pm
Contact:

Re: Redirecting *TAPE to a faster filling system, e.g. DFS or MMC

Post by JudgeBeeb » Sun Oct 16, 2016 12:18 pm

When you say 'disable' the DFS, what are you actually doing? I have a set up which has just 3 ROMs physically in the Beeb: MOS, BASIC and RamFS. With that configuration, PAGE is &E00. In other words, I have physically pulled the DFS ROM. I struggle to get consistent and logical effects with utilities like *UNPLUG.
There is so much wonder in the universe; why should you want to imagine that there is more?

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

Re: Redirecting *TAPE to a faster filling system, e.g. DFS or MMC

Post by jgharston » Sun Oct 16, 2016 1:33 pm

With just RAMFS and no other ROMs enabled PAGE should be at &E00.

I've just been playing with TVK on my Master with all ROMs other than BASIC and RAMFS *UNPLUGged with PAGE at &E00. It loads and runs from RAMFS happily but I can't find what the save command is to see what happens when I try to save the game. SAVE gives 'I do not understand'.

Also done the same with BeebEm configured as a BBC with all ROMs removed except BASIC and VDFS with PAGE at &E00. Exactly the same. What's the save command?

Code: Select all

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

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

Re: Redirecting *TAPE to a faster filling system, e.g. DFS or MMC

Post by lurkio » Sun Oct 16, 2016 2:02 pm

jgharston wrote:I've just been playing with TVK on my Master with all ROMs other than BASIC and RAMFS *UNPLUGged with PAGE at &E00. It loads and runs from RAMFS happily but I can't find what the save command is to see what happens when I try to save the game. SAVE gives 'I do not understand'. Also done the same with BeebEm configured as a BBC with all ROMs removed except BASIC and VDFS with PAGE at &E00. Exactly the same. What's the save command?
*SAVE
Lardo Boffin wrote:[Re RamFS and PAGE] Did you also go for the ADFS for the cf HDD? I did and page is over &E00. I think it is supposed to be E00 without it.
lazarusr wrote:... just 3 ROMs physically in the Beeb: MOS, BASIC and RamFS. With that configuration, PAGE is &E00.
jgharston wrote:With just RAMFS and no other ROMs enabled PAGE should be at &E00.
Yes, you're all quite right. I'd been forgetting to do a Ctrl-Break after disabling the DFS with the ARM ROM's *KILL command. :oops: _ (Also, I glossed over the fact that I actually had two different versions of DFS installed, which might have been contributing to the problem!)

:!:

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

Re: Redirecting *TAPE to a faster filling system, e.g. DFS or MMC

Post by jgharston » Sun Oct 16, 2016 9:38 pm

lurkio wrote:
jgharston wrote:... but I can't find what the save command is to see what happens when I try to save the game. SAVE gives 'I do not understand'.
*SAVE
Doesn't seem to do anything. I've tried *SAVE, *SAVE FRED, *SAVE FRED 1000+2000. Testing if it just passes on *commands, *., *HELP, *FX0 also gives nothing.

Looking through the disassembly there is a call to OSFILE with A=0 (save) and A=&FF (load), so I can try and track down how it gets there. So far I've found no calls anywhere that change the filing system, confirmed by the fact that pressing Break on the Master results in being in the filing system you started off in.

Code: Select all

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

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

Re: Redirecting *TAPE to a faster filling system, e.g. DFS or MMC

Post by lurkio » Sun Oct 16, 2016 9:59 pm

jgharston wrote:
lurkio wrote:
jgharston wrote:... but I can't find what the save command is to see what happens when I try to save the game. SAVE gives 'I do not understand'.
*SAVE
Doesn't seem to do anything. I've tried *SAVE, *SAVE FRED, *SAVE FRED 1000+2000. Testing if it just passes on *commands, *., *HELP, *FX0 also gives nothing.
Try the .UEF tape image:
Untitled 3.png
Screenshot of TKV saving to tape
:idea:

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

Re: Redirecting *TAPE to a faster filling system, e.g. DFS or MMC

Post by jgharston » Mon Oct 17, 2016 12:46 am

Ta. I've done some digging, and it trashes the vector workspace at &D90-&DFF, so any call to any filing system call crashes out back to the command prompt. That will be the same for any non-TAPE filing system, it's irrelevent whether you just select another filing system or try to do a *DTRAP equivalent, because any *DTRAP-type command would still need to redirect the filing system vectors to the replacement filing system, and TKV trashes the vectors. If you can stop it trashing the extended vectors then it would be possible to use a different filing system.

Looking at what TKV puts there I don't know how easy it would be to lift it out and put it somewhere else.

BTW, the 'VALLEY' file gets moved around in memory, so if you want to investigate it it is laid out as:
1000 -> 0400
13FF -> 07FF
---------------
1400 -> 1400
5DFF -> 5DFF
---------------
5E00 -> 0B00
5EFF -> 0BFF
---------------
5F00 -> 5F00
6FFF -> 6FFF
---------------
7000 -> 0C00
77FF -> 13FF

Code: Select all

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

Post Reply