Wednesday, May 6, 2020

MegaWiFi, and why you should code for it

It's been a long time since I wrote here about MegaWiFi. To date, there are still no games released using it, so you might think this project is long dead, do you?

Well, if you do, you are wrong! Progress has been slow (my spare time is limited), but lot of things have happened:

  • MegaWiFi API has greatly matured (currently it is version 1.3), and I spent a lot of time working on making it easy to use. I have created an implementation of pseudo threads and timers, allowing to use the APIs in both synchronous and asynchronous flavors. It has support for TCP, UDP, SNTP, HTTP/HTTPS, etc.
  • I also spent a lot of time working on API documentation. All API functions are pretty well documented, and I have provided properly explained examples for most common use cases.
  • There was an initial effort long time ago to add MegaWiFi support to the great Blastem! emulator. Unfortunately this was halted prior completion. But recently I have resumed work on this, and now MegaWiFi support in Blastem! is very usable.
  • There is a game finished and ready for release (WorldCup 1985 by Pocket Lucho) with MegaWiFi support! It should be released soon by 1985alternativo. Go to my previous post to reach the repos
 
Megadrive/PC cross play, what a time to be alive!
  • There is at least another game with MegaWiFi support in early development, again by Pocket Lucho.
  • I added support to use MegaWiFi with the popular SGDK development kit, with detailed instructions and a precompiled toolchain for Windows, ready to use.
  • I wrote a Gaming Channel implementation, allowing devs to publish games online, and users downloading them directly to the cart. This shows the platform is rock-solid stable, allowing to flawlessly download and play games.
 
Steam is something from the past!

  • And there are many many more features I will not bring here now, to avoid making this post too long.
So, to sum it all, if you like coding for these vintage devices, you should consider starting coding a WiFi enabled Megadrive game NOW! The reasons?:
  1. Hardware and Firmware are mature.
  2. API is mature, well documented and easy to use.
  3. You can code your way or use SGDK for an easy kickstart.
  4. There are great development tools readily available, and emulator support, including integrated debugger with breakpoints, variables watch, etc. Yes, Blastem! is great!
  5. You should be able to publish the games in physical cartridge format, make them available as digital downloads directly to the Megadrive, or play them via emulator.
  6. Everything is Open Source Software and Hardware: the cart and programmer schematics, the firmware for the WiFi module and programmer, the API for Megadrive, the PC tool for programming, the WiFi bootloader...). Go to my previous post to reach the repos.
  7. Megadrive is cool, and WiFi on the Megadrive is even cooler!

5 comments:

  1. Just come across this page, very interesting stuff! I recently started following the attempt at reviving the Mega Drive/Genesis XBand service but that died a year ago when they realised the modem's high baud rate wouldn't play nicely with a VoIP box (lossy audio degradation made the signal unstable, though it works for Saturn and Dreampi works for Dreamcast).

    Someone suggested a WiFi direct replacement cart would work better. Something you've managed to do here! XBand could take pre-existing offline games (such as Mortal Kombat) and "patch" them using the XBand cart to make them play online. Is this something that could be possible with the MegaWifi?

    ReplyDelete
    Replies
    1. Thanks for your comment.

      I do not know how XBand worked. I have always suspected it might use direct peer-to-peer telephone connection in order to keep latency low (so data does not travel through Internet at all, it goes from one subscriber to the other directly, using telephone circuits), but I have never investigated that (so I do not know if my suspicion is correct). Other than that, I think it also has some patching mechanism like the one in Action Replay carts. MegaWiFi cannot do that (and in fact you cannot plug an original cartridge on top of it like with the XBand), but you could burn the pre-patched ROM to achieve the same effect.

      With a pre-patched game, it might work on best conditions. The problem here is variable latency. A simple patch like the one I suppose XBand does, that assumes low and fixed latency, will not work reliably. So either you make a complex patch that takes this into account to avoid losing synchronization (complicated to add to a game that was not coded with online gaming in mind), or you will face sync problems that will ruin the experience.

      About where to get the carts... unfortunately you cannot buy cartridges as of today. I have considered several times making a batch of them, but there is some kind of chicken and egg problem: as I have no equipment to make them in series, I have to send them to a fab house to make the PCBs. So making a batch is very expensive if the number of units is small. Unless the cart picks interest, they will be expensive to produce, and unless they are produced it will not pick interest.

      So my intention is to release a game using it. 1985 World Cup should have been released some months ago, but it isn't yet. I hope it hits the streets soon...

      For game developers, I could hand solder some units myself, but this takes time and I have little to spare. So please do not request an unit if you are not serious about releasing something.

      Delete
    2. That makes perfect sense on the fabrication side. Unfortunately I'm not a developer so I'm unable to help, I was just hoping for a use akin to XBand.

      From what I've seen, XBand used a 2400 baud modem to reduce latency as much as possible. Some info here;
      https://www.sega-16.com/forum/showthread.php?24521-Xband-has-someone-got-it-working-yet/page3

      The developers explain how they reduced latency more here;
      https://youtu.be/k_5M-z_RUKA

      The core issue with replicating XBand seems to be latency and audio compression introduced by VoIP conversion, which is why I thought a pure WiFi option would avoid the issue. But as I'm not a developer I'm only guessing.

      On the cartridge adapter idea, I think you're right that downloading a patched ROM to the cart prior to play would likely be the best option now. But I understand that's way easier said than done.

      I'll keep an eye out for World Cup 1985. I don't like football but the WiFi interconnectivity certainly interests me.

      Delete
    3. The Sega16 post is very interesting, and unfortunately it confirms my suspicion: it worked by connecting both peers directly using standard telephone circuits to keep latency to a minimum. Unfortunately that will be very difficult to emulate as of today if using IP networks, and as explained in the Sega16 post, even using today's telephone technology (that usually converts the analog signal to VoIP) might be very difficult.

      Using a direct WiFi/Ethernet approach will get rid of some of the problems (basically the problems with modulation/demodulation due to the VoIP signal), but will make the latency problem worse (due to the IP network latency will be most likely higher and even worse will be variable).

      So this is definitely possible, but to solve the problems it would require making patches to the games ranging from very hard (if using delay-based netcode) to almost impossible if the game was not thought with online in mind (if using rollback-based netcode). So unless someone has a very clever idea I cannot grasp, unfortunately I would not expect this to work anytime soon.

      BTW if you want to better understand the problem, I would recommend reading these series of posts: https://ki.infil.net/w02-netcode.html

      Maybe it is a bit developer oriented, but I think explanations are simple enough for anyone to get the basics, and animations help a lot!

      Delete
    4. Actually that was a super helpful link! Thank you :)

      Delete