This is an archive of a topic from NESdev BBS, taken in mid-October 2019 before a server upgrade.
View original topic
by on (#101098)
Hello NesDevvers,

I'm new here. I've used the wiki a bunch, however.

I'm working on a NES networking project; an NES BBS client. It will connect to a custom BBS server which I'm writing and allow those who connect to play simple games, have leaderboards, or chat even if you wanted to cursor around an onscreen keyboard like the old days. I currently have communications set up out controller port 2 via an arduino sending serial to my mac which forwards the port on to the server (i'm open to supporting native ethernet whenever that happens).

Now, the different games/modules would need to be downloadable and I've been thinking about where to put them in memory. So far my ideas are either using UNROM and keep the code in real RAM in 1K chunks.. sorta networked in banks, probably at $0400-$07ff. And the other option I was thinking of would be using an SxROM variant (Kid Icarus?) and have the modules written to PRG-RAM. Also, CHR-RAM is a necessity.

I'm planning on having a hefty kernel stored in ROM to do a lot of the heavy lifting for the modules.

So, my first question is, what is the most common dev cart mapper you guys use which could be used as a standard of sorts?

by on (#101101)
NROM, UNROM, MMC1 seems to be the most popular in homebrews, in descending order, with rare occasions of MMC3.
by on (#101118)
And if you want to add PRG RAM at $6000-$7FFF to UNROM, it's always just two more chips (the RAM itself and a 74HC20 to decode it).
by on (#101120)
Maybe incorporate this into your design ?: viewtopic.php?f=9&t=9006
by on (#101124)
That sounds like a cool idea. :)

Here are some suggestions:
- Online multiplayer support;
- Emulator support: it would simplify the life of developers and, at the same time, give it broader appeal;
- Combining the two above would allow people who user real on real hardware interace/play online with people who use emulators, wich would be a nice extra.

Additional (slightly difficult, slightly crazy) suggestion:
- Design a multiplatform virtual machine: the application code would be developed and stored on the servers on a platform-agnostic VM format; whenever a client requested a download, the application would be translated to native format (say, NES, SNES, SMS, Genesis, GB, whatever) by the server, and sent to the client. Of course, while technically possible, that would only make sense if there were clients for more than one hardware platform.
by on (#101125)
@Shiru, tepples: Great and thanks. I'm going to start with UNROM first and see how it feels working in 1K chunks. It'd be nice to have the extra 8K, but I really would like it be as accessible as possible to everyone and easy enough to make one yourself. However if 1K is just too restrictive, I may switch.

@Movax12 Yes, I would like to incorporate various networking scenarios like the ENIO when it's available, but not require it, of course.

@haroldo Yes, I'm planning on multiplayer. I'm not sure if it will be active or turn based. I'm also totally in favor of emulator support. I guess once I get something usable up, we can hand it off to the various emulator coders to add to add some kind of network stuff to their projects. I like developing on my system, personally. And yeah.. a VM is crazy! ;) However, the server could be coded to handle various clients like an SNES version. But that would have to be an eventual collaboration since my focus is the NES. Time will tell.

Not a whole lot yet, but this is my debug stuff for the two-way serial connection which is working well.