Sun Dec 2 20:28:07 PST 2001
Well, waiting for my dreamcast coders cable to show up at this point. Yea, I could have built one using a MAX3232, but I didn’t exactly have any lying around since all my stuff is now old (5 volt logic, how quaint!). And I kinda wanted a VGA adapter as well since the DC linux framebuffer uses the overscan region on NTSC video, so I can’t see several columns on both the right and left, which isn’t so bad, but also missing is the bottom line, where all the typing takes place.
- So, getting Linux running standalone wasn’t too hard thanks to a nice distribution combined with some boot disk guides from Marcus Comstat’s site which helped me burn the disk correctly:
- http://www.m17n.org/linux-sh/dreamcast/
http://mc.pp.se/dc/ And once I figured out that the root filesystem wasn’t the GDROM drive (it is the boot/initrd.gz file) I had fairly good luck doing some basic activities and adding things to the disk.
I got reasonably far compiling the distributed.net client natively after setting up a ramdisk on the DC and symlinking the sources to the ramdisk with a pair of find commands since lndir isn’t on the distribution. But after several hours of trying to compile the ‘mips-linux’ distribution, it ran out of ram, and halted. Other configuration options for the client yielded errors much earlier in the configuration process.
Under "Plan B" I built a cross-compiler following the instructions on a website and then tried compiling it on my x86-linux box. But unfortunately, it hit some errors on the rc5 mips cruncher code. I’m currently attempting to contact the dnet coders to see if they have some idea what the error messages mean. It could be an issue with my cross-compiler, or it might be that I’m using gcc 3.0.1 and it’s being more picky than usual. There aren’t too many mips-linux owners out there anymore since I had to remove the ‘cpu=r3000’ string from the gcc compile options because gcc didn’t even recgonize it.
Once the DC/coders cable gets here, I’ll NFS mount the source across a PPP link and try natively compiling the source to see if it is a problem with the way that the cross-compiler is built.
So, you might be wondering why bother even trying this. The bottom line is that I’m curious as to the real-world performance of the platform. Because the platform is incredibly cheep ($30 used, $40 refurbished, $50 new) the price/performance for distributed apps might make this a viable platform. On the other hand, at only 200Mhz, and a single 5-stage pipeline, It is very likely that a bare bones 800Mhz-1GHz, which is available for $400 or so, could easily have 10x performance over the DC, making the DC a very poor choice.
The other major hurdle for the DC as a viable platform is the lack of either high speed or low cost networking. While the Broadband Adapter (10/100Base-TX ethernet, also called the BBA) exists, it costs $80-120 assuming that you can find a source. Clearly, this would negate the price/perf of the platform. The serial alternative isn’t bad, but deployed as a star network, the price for <4 serial ports on the server is likely to be quite prohibitive.
Doing something custom with the serial port might be feasible. For example, turining it into a unidirectional token ring with one agent acting as the router might be a viable low-cost low-speed solution. But doing so, might also put undue additional load on the CPUs since the serial port is directly connected to the SH4, and a store and forward mechanism would need to be used for moving data around the ring.
Yet another option might be to build some low-cost hardware to interface with the controler ports Maple-bus, a 2Mb/s bus. While the hardware would be fairly simple, it would represent a non-trival hardware and software investment to deploy on a per-port basis.
Of course one could leave them completely disconnected from any network using something like the work-over-email system used by distributed.net. As long as the work package description and the returned values are sufficiently small (128K), you could put the binaries onto CD-R, and provide the work orders on VMUs (the removeable memory units for DC). Unfortunately this would likely be a very manual task to physically move the VMUs around, and also cause the DCs to take up extra space due to the need for controllers to be attached to the machines.
- On the plus side, the previous solution requires very little hardware, and most of the software exists. The bulk of the controler code for the Maple bus is in place, and the protocol for communicating with a VMU is very well documented. Also, a homebrew connector for programming a VMU from a PC is also available:
- http://www.maushammer.com/vmu.html
Now the other possible usage model that I was thinking of for my DC was that of a media player, preferably both .mp3 audio files and .mp2 or .mp4 video files. Clearly there’s plenty of cpu power to decompress audio files, and while video might be a bit of a streach, it seems plausable, since people have gotten video running on StrongArm 204Mhz chips. But here again the issue of delivering data to the machine is a severe problem. Even with the serial port running at 114Kbs, it just isn’t enough to play the .mp3 audio files stored on my fileserver, which are all 128Kbs or higher.
- As I mentioned before the BBA might be an option, but for the price of just the adapter, I can almost buy a Rio Receiver:
- http://www.riohome.com/HomeAudio.htm So unless I can come up with a cheap BBA or figure out how to get my Linux server to run RS-232 a < 114Kbps, it seems to be a dead end again since I’ve got way too many .mp3s to fit on a single CD-R, or even a reasonable number of CD-Rs.