--- In gbadev@y..., "Fatty diZilla" <fattydesign@e...> wrote:
> One thing which might work, however, would be a similar product
> which connected via multiboot. No, really: a cart for the SIO
> port.

I've been thinking the same thing, except not a cart, but a drive
that takes 8cm Compact Disc media. Think "Famicom Disk System".
http://nesdev.parodius.com/

8cm CD-R. 180 megabytes per disc. 300 KB/s data transfer in
double-speed mode. Sub-$1 replication. Yum.

> It'd be a pain in the butt to write for

Not necessarily. Many games already load and decompress their
assets from a faux "filesystem" in ROM. Look at the GBFS code in
Tetanus On Drugs to see what I mean. It wouldn't take much work
to adapt the filesystem code to read from the serial port instead
of from the cart. Code would work the same way: just split your
game's code into multiple .mb files and store them on the cart or
disc.

Reading files over the serial port is already possible. According
to the MBV2 FAQ: "File server software is also supported which
allows the GBA to read or write PC files over the link." If the
system had the same interface as the MBV2 cable, it'd be very easy
to test games on hardware.

However, it *would* be a pain in the butt to play music files with
lots of big samples. But then, so what? This would only mean
we're back to the Super NES days where the sound data has to fit
in 64 KB. And Mario Kart clones on such a system wouldn't have
those annoying player voices ("Here we gooo!").

> and you wouldn't be able to write multiplayer games

How do you know it wouldn't have a pass-through interface for the
multiplayer cable, like some external lights use? A flash-based
system would almost have to have such an interface to connect to
the PC.

> but the extant games would be fundamentally unusable,
> and that ought to tickle Big N pink.

Nintendo has had previous experience with magnetic-disk-based game
systems (Famicom Disk System, 64DD) where piracy had run rampant.
That's why you never saw those outside of Japan.

--
Damian