Slashdot Mirror
Dreamcast Web Server Running Off Memory Card
Adrian writes "I have written a new file system for Linux - to read and write files on the Sega Dreamcast's visual memory unit (VMU)- a small slab of flash memory used by the console to save game files. To see it in action - and see a DC serve some html, go to the Landslide test server - though I have no doubt that micro_http, the web server I am using (said to be the world's smallest), will result in the quickest Slashdotting in history :)" Gentlemen, start your mirrors now.
Said with a straight face and enough fluff to bypass the crapfilter
"Draco dormiens nunquam titillandus."
The VMS flash memory contains 128 kilobytes of storage. These are divided into 256 blocks of 512 bytes each. Of these blocks, 200 are available for user files. The rest of the blocks contain filesystem information, or are simply not used at all.
... ...
The allocation of the 256 blocks is as follows:
The Directory, FAT and Root block are system files. They are not listed in the Directory, but do appear in the FAT. The Root block is always block 255. The start block of the FAT and Directory can be found in the Root block, see below.
The root block (block 255) contains information such as:
The date when the card was formatted
The color and icon for this VMS in the Dreamcast file manager
Location and size of the FAT and Directory system files
I'm not sure about the actual format of this block, apart from the following:
0x000-0x00f : All these bytes contain 0x55 to indicate a properly formatted card.
0x010 : custom VMS colour (1 = use custom colours below, 0 = standard colour)
0x011 : VMS colour blue component
0x012 : VMS colour green component
0x013 : VMS colour red component
0x014 : VMS colour alpha component (use 100 for semi-transparent, 255 for opaque)
0x015-0x02f : not used (all zeroes)
0x030-0x037 : BCD timestamp (see Directory below)
0x038-0x03f : not used (all zeroes)
0x046-0x047 : 16 bit int (little endian) : location of FAT (254)
0x048-0x049 : 16 bit int (little endian) : size of FAT in blocks (1)
0x04a-0x04b : 16 bit int (little endian) : location of directory (253)
0x04c-0x04d : 16 bit int (little endian) : size of directory in blocks (13)
0x04e-0x04f : 16 bit int (little endian) : icon shape for this VMS (0-123)
0x050-0x051 : 16 bit int (little endian) : number of user blocks (200)
The File Allocation Table works similar to a MS-DOS FAT16 File Allocation Table. It serves two purposes; it indicates which blocks are unallocated, and it links the blocks of a file together. Each of the 256 blocks have an entry in this table consisting of a 16-bit integer value (little endian). The entry for block 0 is stored first in the FAT, and the entry for block 255 is stored last. The entry is interpreted like this:
0xfffc : This block is unallocated
0xfffa : This block is allocated to a file, and is the last block in that file
0x00-0xff : This block is allocated to a file, and is not the last block in that file
In the last case, the actual value of the entry indicates the next block in the file. This way, if the number of the first block of a file is known, the subsequent blocks can be found by traversing the FAT. The number of the first block can be found in the Directory if it is a user file, or in the Super block if it is a system file.
Note that mini-game files are allocated starting at block 0 and upwards, while a data file is allocated starting at block 199 selecting the highest available free block. This is probably because a mini-game should be able to run directly from the flash, and thus needs to be placed in a linear memory space starting at a known address (i.e. 0).
Although block 200 through 240 are marked as "free" in the FAT, they can not be used for anything.
The Directory lists all the user files stored in the VMS. The Directory consists of a sequence of 32-byte entries each potentially describing a file. When the VMS is formatted, enough space is allocated to the Directory file to accommodate 200 entries. This is enough, since each file must be at least one block long, and there are only 200 blocks available for user files. The actual blocks making up the Directory can be found using the Root block and the FAT, although it should be safe to assume that the Directory has been allocated to blocks 241 through 253; 253 being the first block of the Directory, and 241 the last.
An entry in the directory is either all NUL-bytes (denoting an unused entry), or a structure describing a file. This structu
Bush is on fire and its not good for my lungs.
I submitted this yesterday and it didn't go up. Now I'm working on the vmufs driver - so apologies if you get junk :)
Adrian
I got to it before the /.; this is all it said:
"This is a test server only
This is not the server you were looking for.
Actually, it is micro_http running on a Dreamcast and serving a piece of html saved on the Dreamcast vmu.
For more details please visit linuxdc.net.
To show your deep admiration of this utterly useless hack, email me."
This almost makes me wish I didn't sell my Dreamcast a couple weeks ago. Though to me it was kind of useless since I wasn't going to spend $100 for a DC NIC anytime soon.
Flash memory has a limited number of write cycles, I hope you have done as much as possible to minimise write cycles?
who is paranoid about visiting .cx websites?
Huh? The content isn't the point. It's the device serving it. So, unless those mirrors are runnin' on Sega Dreamcasts, the novelty is gone.
JHU used to have an ancient Mac IIcx(not even a IIci) running MacBSD, about the only thing it ever did(I think) was serve up a picture of the Cruise Basselope, which, for a slow-as-molassis MacBSD box, kinda makes for an appropriate mascot.
Please help metamoderate.
slashdot posted a story about a commodore 64 that was running a http server a couple years ago. It seemed to hold up longer than this Dreamcast. I mean, I remember there being at least 300 posts before it was /.ed
They sure dont make 'em like they used to.
Karma: The shiznight, mostly because I am the Drizzle.
... we've about doubled the number of people to ever "use" a Dreamcast...