DFS ROM source code

sweh · Post by **sweh** » Sun Jul 15, 2012 6:28 pm

Does anyone have any source code for a DFS ROM? In my copious free time (hahaha) I'm thinking of writing a fresh DFS ROM for Steve Picton's TurboMMC card; in particular an SWR E00 version and a Master version that uses Hazel. I figure it would be easier to modify an existing ROM than reimplement from scratch.

(Of course I also have to reverse engineer how Steve's MMC board works 'cos it's different to the original designs and Steve appears to have lost his code).

jgharston · Post by **jgharston** » Sun Jul 15, 2012 9:51 pm

http://mdfs.net/Info/Comp/BBC/DFS/

They need cleaning up a bit.

sweh · Post by **sweh** » Sun Jul 15, 2012 10:54 pm

Hmm, thanks but they look more like disassemblies rather than real source code. Even if 245 can be run to re-assemble, there's just too much hard-coded cruft to be useful - eg "LDA &C000,Y :\ 8493= B9 00 C0 9.@"; I'd have to find every potential memory reference and determine if it's really memory or data or what...

retroclinic · Post by **retroclinic** » Sun Jul 15, 2012 11:43 pm

This is DFS 0.98, as an assembler input file that works in Beebasm. It's the basis I used to write RamFS for DataCentre.

!DFS098.zip: (17.64 KiB) Downloaded 128 times

Mark.

sweh · Post by **sweh** » Mon Jul 16, 2012 12:02 am

Interesting. Again a disassembly but with some nice annotations. Still has absolute memory references, however (eg absolute reference to &0E00, &1000, &1100 and so on). But this might be a starting point to convert those to configurable variables. So then I could compile one version that uses &C000 (for the master), one version for &0E00 (standard beeb) and one version for &B000 for SWR.

Hmm, I also spotted http://mdfs.net/Apps/Emulators/BBC/6502 ... S/VDFS04.S which looks interesting! (ETA: Or maybe not as useful as I originally thought...)

Thanks,

Post by **Rich Talbot-Watkins** » Mon Jul 16, 2012 8:57 am

I don't remember the exact details (maybe JGH can step in here), but I think the differences between Beeb and Master are a bit more involved than simply where workspace is claimed from, so it mightn't be trivial to create two versions.

I think different service calls are generated to claim workspace from HAZEL than to claim workspace from the bottom of main RAM. Also, on the Master, there are a number of new FSCV codes to handle things like *INFO, *EX, *RENAME etc. Also I think OS 3.20 on the Master automatically handles things like *DUMP, *TYPE etc (by calling OSBGET to read files byte by byte), so you don't need to do anything special there. On a Beeb these have to be written as regular filesystem *-commands. And also I remember something about a different version of FSCV which lives in HAZEL, but I don't remember if this is something that the OS deals with, or if it's something you have to do yourself.

sweh · Post by **sweh** » Mon Jul 16, 2012 11:58 am

Rich Talbot-Watkins wrote:I think different service calls are generated to claim workspace from HAZEL than to claim workspace from the bottom of main RAM.

Yes; service calls &21 and &22 (corresponding to calls &01 and &02) handle HAZEL allocation for shared and private workspace areas.

Also, on the Master, there are a number of new FSCV codes to handle things like *INFO, *EX, *RENAME etc.

*EX (A=9) and *INFO(A=10). There are a few more ROM service calls as well. I believe it's possible to code these into a generic ROM 'cos the B won't issue them or, worst case, conditional compilation logic. Page 159 of David Atherton's "Master Operating System" details the FS changes needed for a Master.

jgharston · Post by **jgharston** » Mon Jul 16, 2012 1:16 pm

Yes; service calls &21 and &22 (corresponding to calls &01 and &02) handle HAZEL allocation for shared and private workspace areas.

I would strongly advise against creating seperate versions for seperate machines. If you want you code to run on both the BBC and the Master you can either use the workspace at &E00 regardless of what machine it's running on and just respond to service calls &01 and &02, or respond to &21/&22 as well as &01/&02 and use high or low workspace as appropriate. In fact, even with Master-only code you are supposed to be able to use low workspace if there is not enough high workspace. If all the high workspace is claimed, the MOS doesn't pass &21/&22 calls on to lower numbered ROMs.

The usual method of combining a private workspace pointer and an enabled flag into the ROM workspace byte at &DF0+rom is to use:
%00xxxxxx - low workspace at &0000-&3F00
%01xxxxxx - ROM disabled
%10xxxxxx - ROM disabled
%11xxxxxx - high workspace at &C000-&FF00

*EX (A=9) and *INFO(A=10). There are a few more ROM service calls as well. I believe it's possible to code these into a generic ROM 'cos the B won't issue them or, worst case, conditional compilation logic.

The best thing to do is implement all the FSC calls and also implement *INFO, *EX, *RENAME as stubs that just do, eg:

Code: Select all

.ex:JSR F2toXY:LDA #9:JMP (FSCV)
.info:JSR F2toXY:LDA #10:JMP (FSCV)
.rename:JSR F2toXY:LDA #12:JMP (FSCV)

If you want to dive into some hairy code that's been updated and rewritten multiple times over 20-odd years, there's the HADFS source.

sweh · Post by **sweh** » Mon Jul 16, 2012 3:00 pm

jgharston wrote:
Yes; service calls &21 and &22 (corresponding to calls &01 and &02) handle HAZEL allocation for shared and private workspace areas.
I would strongly advise against creating seperate versions for seperate machines. If you want you code to run on both the BBC and the Master you can either use the workspace at &E00 regardless of what machine it's running on and just respond to service calls &01 and &02, or respond to &21/&22 as well as &01/&02 and use high or low workspace as appropriate. In fact, even with Master-only code you are supposed to be able to use low workspace if there is not enough high workspace. If all the high workspace is claimed, the MOS doesn't pass &21/&22 calls on to lower numbered ROMs.

The "generic" TurboMMC-DFS ROM does appear to work adequately well on the Master. The problem, of course, is that it brings PAGE up to &1900 'cos it doesn't know about HAZEL. So my desire was to do a DFS version that would make use of HAZEL properly. (Which, yes, means falling back to 01/02 if there's not enough space in 21/22). I also wanted to a SWram version that would work on a B or B+ (similar to existing E00DFS versions); just need to make sure the ROM image stops at &AFFF to leave 4K for workspace

f you want to dive into some hairy code that's been updated and rewritten multiple times over 20-odd years, there's the HADFS source.

It was your HADFS source (clever, BTW, to make use of other ROMS to do the physical communication to hardware, and you just do the higher level structures) which made me wonder and hope someone had done a DFS version

mm67 · Post by **mm67** » Tue Jul 17, 2012 11:37 pm

I did start on a new version of the filing system last year for mmbeeb.
Not really tested it, or documented it, and it still needs some debugging.
But it's attached for all to play with.

regards
Martin

sweh · Post by **sweh** » Tue Jul 17, 2012 11:58 pm

Neat. And you've already done MASTER SWR B versions! If it works, all I should need to do is modify the MMC interface routines!

hoglet · Post by **hoglet** » Sun Nov 08, 2015 9:59 pm

... and three years go by ....

Has anyone done any further development on Martin's MMFS? It looked like it was almost complete.

I'm looking for a SD/MMC filesystem that runs on the Master and leaves PAGE at &E00

I wonder how hard it would be to merge Dukkie's enhancements for SDHC cards into this?

Anyone interested?

Dave

dv8 · Post by **dv8** » Mon Nov 09, 2015 2:37 pm

MMFS seems to be working okay in its current state.

I tried it with the STH games menu and didn't see any problems.

If anyone else wants to give it a go, I've attached the ROM images here. There are separate versions for Model B, Master and SWRAM.

Paul.

hoglet · Post by **hoglet** » Mon Nov 09, 2015 2:58 pm

dv8 wrote: MMFS seems to be working okay in its current state.

I'm guessing it won't work with newer SDHC cards (which is all my current BeebFPGA hardware supports).

The work Dukkie has been doing to transform SUPERMMC into SMARTSPI needs to be re-applied to MMFS I think.

I might have a look at what this would involve over the next few days....

Dave

hoglet · Post by **hoglet** » Mon Nov 09, 2015 10:55 pm

hoglet wrote: I'm guessing it won't work with newer SDHC cards (which is all my current BeebFPGA hardware supports).

The work Dukkie has been doing to transform SUPERMMC into SMARTSPI needs to be re-applied to MMFS I think.

I might have a look at what this would involve over the next few days....

It didn't work with SDHC cards, but it does now

The changes are here:
https://github.com/hoglet67/BeebFpga/co ... 6beec524c3

It's working well enough to load programs from the STH archive on a FAT-16 SDHC card.

And PAGE remains at E00

FAT-32 is currently untested.

However, *INFO and *EX seem to be broken (they return immediately without any output).

Dave

sweh · Post by **sweh** » Tue Nov 10, 2015 1:51 am

hoglet wrote: However, *INFO and *EX seem to be broken (they return immediately without any output).

Are you doing this on a Master-based MOS? If so then *INFO and *EX are built into the MOS and call OSFSC with A=10 or A=9; these aren't implemented on a Model B and so DFS's originating from a B probably won't handle them.

hoglet · Post by **hoglet** » Tue Nov 10, 2015 7:17 am

Hi Stephen,

sweh wrote:
hoglet wrote: However, *INFO and *EX seem to be broken (they return immediately without any output).
Are you doing this on a Master-based MOS? If so then *INFO and *EX are built into the MOS and call OSFSC with A=10 or A=9; these aren't implemented on a Model B and so DFS's originating from a B probably won't handle them.

Nice catch!

This is exactly what's happening.

BeebWiki's list of FSCV calls is:

Code: Select all

&00	*OPT command. X and Y hold parameters.
&01	EOF on channel Y being checked with OSBYTE &7F. On exit, X=&FF if EOF, X=&00 otherwise. If Y=&00, (ie, EOF#0) action is implementation specific.
&02	*/ command. XY points to the command text.
&03	Unrecognised OSCLI. XY points to the command text. The command has already been offered to the paged ROMs via service call &04, and none have responded.
&04	*RUN command. XY points to filename.
&05	*CAT command. XY points to any pathname.
&06	A new filing system is about to take over. This call is generated by filing systems themselves before they start their initialisation.
&07	File handle range request. Lowest returned in X, highest in Y.
&08	OSCLI command being processed. This is used to facilitate the *ENABLE command.
&09	*EX command. XY points to any pathname.
&0A	*INFO command. XY points to the object name.
&0B	*RUN from library. XY points to the filename.
&0C	*RENAME command. XY points to the object names after the command.

Currently MMFS 1.00 implements:

Code: Select all

	\ OSFSC table 1 low bytes
.fscv_table1
	EQUB LO(fscv0_starOPT-1)
	EQUB LO(fscv1_EOF_Yhndl-1)
	EQUB LO(fscv2_4_starRUN-1)
	EQUB LO(fscv3_unreccommand-1)
	EQUB LO(fscv2_4_starRUN-1)
	EQUB LO(fscv5_starCAT-1)
	EQUB LO(fscv6_shutdownfilesys-1)
	EQUB LO(fscv7_hndlrange-1)
	EQUB LO(fscv_osabouttoproccmd-1)

So 09, 0A, 0B, and 0C need to be implemented. Excellent, something well defined to do!

Dave

Post by **richardtoohey** » Tue Nov 10, 2015 7:47 am

hoglet wrote:Excellent, something well defined to do!

It's exhausting just watching you.

sweh · Post by **sweh** » Tue Nov 10, 2015 11:27 am

hoglet wrote: &0C *RENAME command. XY points to the object names after the command.

Not sure this one is part of Master MOS or if it comes from a later machine.

hoglet · Post by **hoglet** » Tue Nov 10, 2015 2:05 pm

sweh wrote:
hoglet wrote: &0C *RENAME command. XY points to the object names after the command.
Not sure this one is part of Master MOS or if it comes from a later machine.

Thanks for that.

The other three are now implemented and working I think:
https://github.com/hoglet67/BeebFpga/co ... 577ca051c4

Dave

stardot.org.uk

DFS ROM source code

DFS ROM source code

Re: DFS ROM source code

Re: DFS ROM source code

Re: DFS ROM source code

Re: DFS ROM source code

Re: DFS ROM source code

Re: DFS ROM source code

Re: DFS ROM source code

Re: DFS ROM source code

Re: DFS ROM source code

Re: DFS ROM source code

Re: DFS ROM source code

Re: DFS ROM source code

Re: DFS ROM source code

Re: DFS ROM source code

Re: DFS ROM source code

Re: DFS ROM source code

Re: DFS ROM source code

Re: DFS ROM source code

Re: DFS ROM source code