X-MASS, a mass-storage expansion for all CPC.

[Ast]

I am glad that it works, @Ast !

Ok, I will add an icon for this little app 

Yeahhh, it will be cool to have an icon...
If possible, add Something like one key to modify drive a to drive c instead of all these modification.... It will be better to install...
Or maybe an install file... if you had time, many time... many many time...

Do you remember, a few years ago, when i ask you to make a part for the "only for your eyes 2 Megademo" ? A really fucking cool time...

[Prodatron]

If possible, add Something like one key to modify drive a to drive c instead of all these modification.... It will be better to install...
Or maybe an install file... if you had time, many time... many many time...

Yes, I will do that definitely, as I already told MacDeath

I am planning to add a setup utility for the CPC version of SymbOS 3.0 which can be started after booting the first time, which will do all this automatically.

This release is planned for May, maybe I can release another preview before.

Do you remember, a few years ago, when i ask you to make a part for the "only for your eyes 2 Megademo" ? A really fucking cool time...

Holy shit, you are right, yes I remember!  That's more than 20 years ago!

[Ast]

Now it's time to give you new values :


BytsPerSec : #0002
SecPerClus : #04
RsvdSecCnt : #0001
NumFATSz : #02
RootEntCnt : #0002
TotSec16 : #0000
Media : #f8
FATSz16 : #0100
SecPerTrk : #0020
NumHead : #0040
HiddSec : #00000000
TotSec32 : # 000367e0
---
Ok for these value but with these info i don't find the entry of directory... Fuck off... :-(


I know the sector of the directory (#221) but i found it after seeing sector per sector (hard and long...)
It could be so easy to use a formula to find it... Help should be welcome here !


@Prodatron : your format tool doesn't erase all data presents on the x-mass but only implents fat16 format in sector 0, am i right ?

[Ast]

BPB_SecPerClus                 = patritionOffset +  1901          + (2-2)*2                 = patritionOffset +  1901

@Gerald : where can i find partitionOffset ?

[Prodatron]

@Prodatron : your format tool doesn't erase all data presents on the x-mass but only implents fat16 format in sector 0, am i right ?

Yes, it exactly prepares...
- the boot sector (sector 0)
- the FAT
- and the root directory (some more sectors)
...like HAL6128 made ist. So it's like a "quick format", which does all what is needed to init a mass storage with a file system without proceeding/rewriting every single sector (which would take longer but doesn't make any sense in a normal case).

[gerald]

@Gerald : where can i find partitionOffset ?

In the partition table 
If you don't have one, it's 0.

BytsPerSec : #0002
SecPerClus : #04
RsvdSecCnt : #0001
NumFATSz : #02
RootEntCnt : #0002
TotSec16 : #0000
Media : #f8
FATSz16 : #0100
SecPerTrk : #0020
NumHead : #0040
HiddSec : #00000000
TotSec32 : # 000367e0
---
Ok for these value but with these info i don't find the entry of directory... Fuck off... :-(


I know the sector of the directory (#221) but i found it after seeing sector per sector (hard and long...)
It could be so easy to use a formula to find it... Help should be welcome here !

Your RootEntCnt look's wrong to me : only 2 entry in the root directory  . I guess it's 0x0200.

Code Select Expand


RootDirSectors  = (BPB_RootEntCnt  * 32 + BPB_BytsPerSec-1 ) / BPB_BytsPerSec;
                = (      512       * 32 + 512           -1 ) / 512
                = 32
2- get the number of sectors used by non-data section
systemSectors = BPB_RsvdSecCnt + BPB_FATSz * BPB_NumFATs + RootDirSectors
              = 1              + 256       * 2           + 32
              = 545

3- get the number of cluster for data storage
clusters = (BPB_TotSec - systemSectors) / BPB_SecPerClus
         = (223200     - 201          ) / 4
         = 55749

4085 <= 55749 <= 65525  :  FAT16 => root directory is just after the FAT(s) and BPB_RootEntCnt*32 long

So at BPB_RsvdSecCnt + BPB_FATSz * BPB_NumFATs = 1 + 256*2 = 0x201

The directory you see at 0x221 is not the root one, but the may be 1st directory created in the root one.

[HAL6128]

Now it's time to give you new values :


BytsPerSec : #0002
SecPerClus : #04
RsvdSecCnt : #0001
NumFATSz : #02
RootEntCnt : #0002
TotSec16 : #0000
Media : #f8
FATSz16 : #0100 >> IS THIS and are the NEXT VALUES CORRECT read out???
SecPerTrk : #0020
NumHead : #0040
HiddSec : #00000000
TotSec32 : # 000367e0
---
Ok for these value but with these info i don't find the entry of directory... Fuck off... :-(


I know the sector of the directory (#221) but i found it after seeing sector per sector (hard and long...)

It seems that there is a error with reading the values from beginning RootCount (LSB first, MSB last) maybe one byte shifted during reading)? e.g. FATSz should #0001

With FAT16 everything is fixed:
that means the First Sector is for the Boot Sector Information (BytsPerSec : #0002 = 512 = only 512 Bytes) = 1
next comming two FAT table (NumFATSz : #02) with the size of (FATSz16 : #0001 = 256) = 2 * 256 = 512
next comming the Root Directory = 1 + 512 = 513

Attached you will find a small code in BASIC (txt-format). Maybe it helps you?

[Ast]

In the partition table 
If you don't have one, it's 0.
Your RootEntCnt look's wrong to me : only 2 entry in the root directory  . I guess it's 0x0200.

Code Select Expand


RootDirSectors  = (BPB_RootEntCnt  * 32 + BPB_BytsPerSec-1 ) / BPB_BytsPerSec;
                = (      512       * 32 + 512           -1 ) / 512
                = 32
2- get the number of sectors used by non-data section
systemSectors = BPB_RsvdSecCnt + BPB_FATSz * BPB_NumFATs + RootDirSectors
              = 1              + 256       * 2           + 32
              = 545

3- get the number of cluster for data storage
clusters = (BPB_TotSec - systemSectors) / BPB_SecPerClus
         = (223200     - 201          ) / 4
         = 55749

4085 <= 55749 <= 65525  :  FAT16 => root directory is just after the FAT(s) and BPB_RootEntCnt*32 long

So at BPB_RsvdSecCnt + BPB_FATSz * BPB_NumFATs = 1 + 256*2 = 0x201

The directory you see at 0x221 is not the root one, but the may be 1st directory created in the root one.

I confirm that there is no directory in #201... Directory starts in #221... Really Strange of course !

[gerald]

I confirm that there is no directory in #201... Directory starts in #221... Really Strange of course !

As HAL6128 said, your value seems wrong (endianess or shift ?).
Can you post a picture of the boot sector.

[Ast]

Here is the boot :

[merlinkv]

Hello to all,


I'm a new member of the site and owner of three CPC 6128 (two are working  , one is dead ) ....

I have the X-MASS & X-MEM and are working fine with BonnyDOS 1.72 (modded to set the DoM as drive D), but I want to change to SymbOS because it seems more powerful. My question is ... the SymbOS ROMs/Disks include a format utility or I need to use the PC to re-format de DoM as FAT16?

My idea is:

- Flash the SymbOS ROMs at X-MEM
- Format the DoM and set it as drive D:
- Copy the INI file to the root of D: and the SymbOS disk contents to a Directory called D:/SymbOS

This setup can work with the RAM Disk C: and I can start SymbOS from D:?

Thanks in advance.

[Bryce]

Hi Merlin,
         welcome to the Forum. I think I know you from Amibay too (assuming you're the same one)?

Bryce.

[gerald]

Here is the boot :

Any picture of the 1st sector of the root directory you found (0x0221) ?

[merlinkv]

Hi Bryce,

Yes I'm

A very interesting site ... I hope that I can put my two pennyes. 

[TotO]

Hey!

You should try this: X-MASS, a mass-storage expansion for all CPC.

[merlinkv]

Hello TotO

Thanks, I will try later at home .... 

Other question (sorry) .....

The drive D: will be available with Roms: AMSDOS, ParaDOS and SymbOS (flashed together at lower positions) without entering the SymbOS environmment? For example .... If I create a dir called GAMES01 put some game files inside ... I can play directly from D: ? Or I need other ROMs for that .....

[TotO]

To use them from BASIC too, you will require ACMEDOS (wip).

[Ast]

After verification, you're right. The Root starts in #201.
#221 is the rest of the directory.
#225 is the start of the files.

How can I calculate faster the exact adress of each files ?

[merlinkv]

To use them from BASIC too, you will require ACMEDOS (wip).

Is planned to be available shortly?

[gerald]

After verification, you're right. The Root starts in #201.
#221 is the rest of the directory.
#225 is the start of the files.

How can I calculate faster the exact adress of each files ?

There is only one method to find the exact address of each file : read the FAT specification 
You should read the Section 6: Directory Structure
Everything you need is there (hint : offset 20 and 26) of the 32 byte entry.

[TotO]

Is planned to be available shortly?

Only gods known. (beta testing)

[Ast]

Is planned to be available shortly?

You'll have to wait... ACMEdos is not ready yet.

@Gerald : there is a byte, for example in #105a, for the filename "APPCALC.EXE" (#03) , or in #107A for the file "APPCMDER.EXE" (#08) to access file sector faster, but I don't undestand how it works  ?
I'm going to read Section 6 as you told me... Maybe Something new.

@TotO : Gods are waiting too... ^^

[Ast]

Yo, here is the result of my research...

Remember old calculated Values :

RootDirSectors = 32
NumFats = 2
Fatz = 256
RsvdSecCnt = 1
SecPerClus = 4

--------
FirstDataSector = RsvdSecCnt + ( NumFats * Fatz ) + RootDirSectors
                       =          1        + (      2      * 256 ) + 32
                       = 545

545 -> #221 (Arf, I finally found it !!!)
--------
N=offset in #105B-#105A -> #0003

FirstSectorOfClusters = (( N - 2 ) * SecPerClus ) + FirstDataSector
                               = (( 3 - 2 ) *        4         ) + 545
                               =                 4                   + 545
                               = 549

549 -> #225 (Entry of the first file)

That rules !!!!!

Finally Section 6 allows me to succeed ;-) but I'd never succeed without my friends' help. Thanks.
                               

[Ast]

Hey men, it's not over...

We have to find how is calculated DIR_FileSize in Offset #28 (4 bytes)...

[gerald]

Hey men, it's not over...

We have to find how is calculated DIR_FileSize in Offset #28 (4 bytes)...

it's just a 32 bit value, nothing special (stored in little endian)