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.
No posts, and it's already slashdotted. That has to be a world record.
;)
Let me guess, they probably were on like 56k or somethin, or some ADSL. I mean, thats a dyndns A pointer
Fun, fun.
Free means no restrictions, ironic the FSF's GPL forces restrictions, isn't it? What's your definition of free?
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.
Mirror
Flash memory has a limited number of write cycles, I hope you have done as much as possible to minimise write cycles?
You're right, it's really terrible.
Gamecube dvd discs DO NOT spin backwards. Run a game and open the cover when it's loading something if you don't believe me.
Endless arguments over trivial contradictions in books written by ignorant savages to explain thunder in the dark.
From memory it's not that the disc's spin backwards, but that they are written backwards. The track goes from the outside to the inside. There was talk of a hack to actually wire up a normal CD/DVD drive to the gamecube as a way of using normal media, rather than the mini-backwards-written-dvd. Thargor66