[Gllug] Dreamcast stuff

[Adrian McMenamin]

On Monday 12 May 2003 17:08, Tethys wrote:
> Adrian McMenamin writes:
> >I am still have difficulties - eg there is a file on the DC that my
> >software (ie the driver) can see, but VFS and thus the kernel, won't
> >- so plenty more to do.
> >
> >Happy to say more if anybody really wants to know...
>
> Yes please...
>
> Tet

Ok, well I am not the first - kallistios - a sort of mini Unix-like game 
framework for the DC has had a file system for the DC VMU for some time 
(though I only found this out this week!).

Essentially the DC's VMU is a very small piece of flash (mtd). Once I had 
written the mapping driver (did that about 8 or so months ago) it was 
theoretically possible to mount a file system on top of the VMU via the 
mtdblock module/driver - a highly caching low level block device driver for 
mtd.

Getting a read only version wasn't too difficult and I finished that in 
December. Simply look for the super block (in commercial VMUs always in block 
255, but I wanted the driver to entertain the possibility of bigger vmus as 
they were once planned and rumour has it there are some in the wild :->) - 
read off the basic details, traverse the FAT etc.

A write supporting VMU driver was slightly more difficult and I sort of gave 
up, only to try again last month.

The Linux VFS is not overly documented - the ext2/3 developers obviously know 
it backwards but they haven't written much down. But I used various other fs 
driver code to pick up what I was doing wrong and what I needed to add.

There are still problems, though. My driver uses a very simply inode number 
allocation system - a file that starts in block 199 has inode 199 etc. 
Unfortunately, as I discovered today, traditional Unix systems - including 
Linux - do not list files with inode == 0. As a special category of file on 
the VMU starts at block 0 and runs up (most start high and run down) this is 
a problem. But I am sure I can fix it.

One other problem I had was that I assumed that the maximum length of a VMU 
file name was 12. In fact all native VMU files are created with a name of 12 
characters and no terminating null - this was causing odd behaviour - the 
code in the CVS is broken in this way, I was developing new code to fix it 
when I got /.ed :->

I will put new code in the CVS tonight and turn my DC off for the first time 
in two and a half days....


Adrian



-- 
Gllug mailing list  -  Gllug at linux.co.uk
http://list.ftech.net/mailman/listinfo/gllug