Tag Archives: Dreamcast

End of an era


Dreamcast BBA
Dreamcast BBA

I am selling my Broadband Adapter (NIC) for the Sega Dreamcast.

Been tidying up at home and it was time to admit my days as a Dreamcast hacker were over – my last posting to LKML, a filesystem driver for the File Allocation Table (FAT) filesystem found on the DC’s  “Visual Memory Unit” flash device (called VMUFAT), didn’t even elicit a response.

The BBA is a rare item and cost me about £100 plus import duties back in 2001 and they still seem to sell for high prices, but I started my auction at 99p – if there is another hacker out there who is still beavering away at their DC maybe they’ll be able to pick it up cheaply (of course I want as much as I can get!).

The big advantage of the BBA is that it allows you to do things like mount NFS volumes on your Dreamcast and so is much more flexible for a developer.

I am a bit sad about it but it’s the sensible thing to do.

New version of mkfs.vmufat available


Linux Filesystem Permissions
Linux Filesystem Permissions (Photo credit: Wikipedia)

I have posted a new version of mkfs.vmufat, a tool to make a VMUFAT filesystem, at my GitHub repo: it will now format a file as VMUFAT volume (if you use the -f switch).

Would love to hear your feedback – my posting of the source code for the filesystem itself generated a bit of interest, but have not heard anything back from any Dreamcast hackers though.

More delays for VMUFAT


Seagate Barracuda HDD
Seagate Barracuda HDD (Photo credit: Andres Rueda)

Obviously the whole world is waiting for VMUFAT to hit the streets, but it looks as though it will have to hold its collective breath a little longer, as I have hit more delays.

Working with big volumes (several megabytes) reveals the code eats a lot of memory in ways I don’t yet fully understand. But that will need to be fixed, even if no one is ever really likely to want a 32MB VMUFAT volume.

Spoke too soon (of course)


SOMEONE SPOKE OUT OF TURN - NARA - 515451
Image via Wikipedia

It’s like the curse of the software demonstration: it doesn’t break until then.

I discovered as soon as I posted that I was ready to (try to) push the VMUFAT stuff up to main line that there was a bug in the software.

Very large VMUFAT volumes were not being properly handled. But I think I have fixed that now. Some more testing is due, though, before I proclaim victory a second time!

VMUFAT: almost done (I hope)


A Sega Dreamcast Visual Memory Unit
Image via Wikipedia

About a decade ago I first wrote some Linux kernel code that would handle the filesystem on the little slab of flash storage that came with a SEGA Dreamcast Visual Memory Unit (VMU).

A few attempts to get this in the kernel mainline then followed. It was a bruising experience and unsuccessful. But I am about to try again.

I am a bit more confident this time – not least because I have written some userland code which will allow anyone to test the filesystem out, whether they have a VMU or not: mkfs.vmufat is now available at GitHubhttps://github.com/mcmenaminadrian/mkfs.vmufat/blob/master/mkfs.vmufat.c

Secondly I do think I am a better coder thanks to the MSc and have put some effort into fixing the filesystem code itself.

But we’ll see, hopefully tomorrow, how it goes down.

One of those debugging nights


English: An NTSC Sega Dreamcast Console and PA...
Image via Wikipedia

It must be a situation every programmer is familiar with – you write some code, you are pretty pleased with it, but it just doesn’t work and while you know it is only a small thing that is stopping it from functioning properly, but you just cannot track it down.

That is exactly where I am with my code for the “VMUFAT” file system – the file system for the Sega Dreamcast VMU. After a decade of trying (in fits and starts), I now have a code base which I think is good enough, or almost good enough, to post to LKML without me being burnt to a crisp by the subsequent flames.

But it just doesn’t work! Trying to list the files on the device gets a list of 200 copies of the same file (200 is the maximum number of files that a standard VMU can index in its directory blocks and the code throws an error when you exceed that).

The thing is, the old, ugly, code worked at this. But I cannot see what I am doing wrong with the new, clean, code. Indeed it seems to replicate exactly the same functionality. Last night I picked up a couple of bugs in the code quickly but, whilst they addressed one error, they did not fix the big one.

Time for a rotary debugger? Well, it will be a roti debugger in this house, this Friday evening.

Working on filesystem code


English: A North American Sega Dreamcast VMU, ...
Image via Wikipedia

Nearly a decade ago I wrote a crude, but working, filesystem for the Sega Dreamcast VMU on Linux. I then put ported a very simple web server to the Dreamcast and got the whole thing on Slashdot.

I never managed to get the thing into mainline – indeed the battering I got last time I tried, in 2009, more or less made me give up writing anything for the kernel and the Dreamcast was put away.

I am not pretending my code was pretty or even particularly good but it is no wonder people get put off from contributing when you get pig ignorant comments like these:

Everything about the on-disk format is tied to the VMU. Until that sinks in, don’t bother sending me email, thanks.

This was someone, who ought to have known better, claiming that it was not possible to have a free standing filesystem for this at all – though they were making their, incorrect, claim in the manner seen all too frequently on the Linux Kernel Mailing List.

No comments.  Really.  There must be some limits on the language one is willing to use on public maillist, after all.

As you can tell this person – a top flight Linux hacker – did not like my code. And, looking back, I can hardly blame him, it was pretty ugly. But as a help to fix it this is of next to no use – and only serves to demotivate. Nasty computer scientists, again.

Ok, so I have got that off my chest. And I am once more placing myself in the firing line.

The filesystem code, a work in progress (so check where the code has got to once you click the link), can be found here. A filesystem that you should be able to mount under loopback, can be found here. All testers welcomed with open arms.