Menu
▾
▴
gc-linux-devel
|
From: David R. <da...@it...> - 2004-02-06 15:58:56
|
Has any work, or thought, been put into creating a driver for the GameCube memory cards? I ordered a cheap 64 MB memory card, so that could be a very convenient source of a reasonable amount of persistent storage. I have no experience of writing neither block device drivers, nor MTD drivers for Linux, so I'm unsure of what the best route is. If someone knows better, I'd love to listen and do the work. There isn't that much to read about the memory card in the R.E. spec, but as far as I can discern (with my limited driver and hardware hacking knowledge) there aren't any gaping holes there. It should be "a simple matter of programming", right? Unless someone else already did this, or planned to do it soon, I will make an attempt as soon as I receive all the necessary equipment. / Regards, David Remahl --- PGP key information--- pub 1024D/ 87256085 2003/06/12 David Remahl <da...@it...> Web: http://ittpoi.com/david_remahl.asc Fingerprint: 0C38 293C 86A9 7756 9CEA 4ED6 1651 620E 8725 6085 |
|
From: Michael S. <st...@in...> - 2004-02-06 16:59:01
|
On 06.02.2004, at 16:58, David Remahl wrote: > Has any work, or thought, been put into creating a driver for the > GameCube memory cards? I don't think so. > I ordered a cheap 64 MB memory card, so that could be a very > convenient source of a reasonable amount of persistent storage. That's probably 64 Mbits, not MBytes, so your memory card is just 8 MB. Mine is just 2 MB :-( > I have no experience of writing neither block device drivers, nor MTD > drivers for Linux, so I'm unsure of what the best route is. If someone > knows better, I'd love to listen and do the work. There are always lots of people in the IRC, and perhaps even someone who can help you interactively. > There isn't that much to read about the memory card in the R.E. spec, > but as far as I can discern (with my limited driver and hardware > hacking knowledge) there aren't any gaping holes there. It should be > "a simple matter of programming", right? Probably. > Unless someone else already did this, or planned to do it soon, I will > make an attempt as soon as I receive all the necessary equipment. Excellent. Michael |
|
From: David R. <da...@it...> - 2004-02-06 23:39:03
|
On 6 feb 2004, at 17.58, Michael Steil wrote: > On 06.02.2004, at 16:58, David Remahl wrote: >> Has any work, or thought, been put into creating a driver for the >> GameCube memory cards? > > I don't think so. > >> I ordered a cheap 64 MB memory card, so that could be a very >> convenient source of a reasonable amount of persistent storage. > > That's probably 64 Mbits, not MBytes, so your memory card is just 8 MB. > Mine is just 2 MB :-( Oh...How disappointing. The web site I ordered from (DVDBoxOffice) clearly used the MB unit with a capital B, so I just assumed they meant bytes (that's the common thing to do for storage :). And the label on the card also sports a clear MB unit. But you're probably right that they mean bits... Yeah, after checking, I find that it is advertised to have 1019 blocks (1024, including 5 "filesystem" blocks). With each block 8KB large, that's 8MB. Well, then at least its _some_ persistent storage for the system...I'm now even happier that I didn't buy the Nintendo 4 Mb card (59/64 blocks) that was even more expensive than the 1024 one...Half a meg, that isn't much to cheer for. >> I have no experience of writing neither block device drivers, nor MTD >> drivers for Linux, so I'm unsure of what the best route is. If >> someone knows better, I'd love to listen and do the work. > > There are always lots of people in the IRC, and perhaps even someone > who can help you interactively. Sounds great. / Regards, David (damned deceptive advertising! ;-). --- PGP key information--- pub 1024D/ 87256085 2003/06/12 David Remahl <da...@it...> Web: http://ittpoi.com/david_remahl.asc Fingerprint: 0C38 293C 86A9 7756 9CEA 4ED6 1651 620E 8725 6085 |
|
From: DCGrendel <dcg...@co...> - 2004-02-07 05:50:22
|
David Remahl wrote: > Has any work, or thought, been put into creating a driver for the > GameCube memory cards? I ordered a cheap 64 MB memory card, so that > could be a very convenient source of a reasonable amount of persistent > storage. > > I have no experience of writing neither block device drivers, nor MTD > drivers for Linux, so I'm unsure of what the best route is. If someone > knows better, I'd love to listen and do the work. > > There isn't that much to read about the memory card in the R.E. spec, > but as far as I can discern (with my limited driver and hardware > hacking knowledge) there aren't any gaping holes there. It should be > "a simple matter of programming", right? I belive the kernel MTD stuff has support for SPI flash, so you would just need to add a driver there for the EXI dma/pio stuffs, which is quite simple. referencing the us patent #6609977 should provide you with most of the info, as would referencing the gclib sources, though i don't remember what license the gclib sources are under... adding a gc memcard fs should also be possible using the gclib sources, or re-reverse engineering the fs. |
|
From: Groepaz <gr...@gm...> - 2004-02-07 15:08:22
|
On Saturday 07 February 2004 06:50, DCGrendel wrote: > David Remahl wrote: > > Has any work, or thought, been put into creating a driver for the > > GameCube memory cards? I ordered a cheap 64 MB memory card, so that > > could be a very convenient source of a reasonable amount of persistent > > storage. > > > > I have no experience of writing neither block device drivers, nor MTD > > drivers for Linux, so I'm unsure of what the best route is. If someone > > knows better, I'd love to listen and do the work. > > > > There isn't that much to read about the memory card in the R.E. spec, > > but as far as I can discern (with my limited driver and hardware > > hacking knowledge) there aren't any gaping holes there. It should be > > "a simple matter of programming", right? > > I belive the kernel MTD stuff has support for SPI flash, so you would > just need to add a driver there for the EXI dma/pio stuffs, which is > quite simple. referencing the us patent #6609977 should provide you with > most of the info, as would referencing the gclib sources, though i don't > remember what license the gclib sources are under... > adding a gc memcard fs should also be possible using the gclib sources, > or re-reverse engineering the fs. i would suggest using the gclib source as reference (its gpl) ... any questions that might arise should be answered in the docs i have written... (that patent is kinda pain to read, and doesnt really contain more info) gpz |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X