SMB support

[Former user]

Original issue 82 created by talantyyr on 2010-05-13T12:09:27.000Z:

Please provide a SMB Share Option like the other Emulators. Many people are
using NetworkStorages and it's a hillarious feature to load you ROM's from
a SMB Share.

[Former user]

Comment # 1 originally posted by ekeeke31 on 2010-05-13T14:24:05.000Z:

issue \#15 has been merged into this issue.

[Former user]

Comment # 2 originally posted by ekeeke31 on 2010-05-13T14:26:25.000Z:

[Former user]

Comment # 3 originally posted by hielke79 on 2010-12-05T19:04:42.000Z:

Yes if that could be possible!

[Former user]

Comment # 4 originally posted by pmagnus87 on 2011-01-19T16:18:01.000Z:

Megadrive had a lot of games, SMB support is very important

[Former user]

Comment # 5 originally posted by ekeeke31 on 2011-01-19T23:10:31.000Z:

The whole Megadrive library (zipped) takes less than 1.2 GB. And lucky for you, the Wii has SD/SDHC support and those cards are very cheap and easy to found so no, that's not really a good argument.

Seriously, I've yet to read one good and valid reason to implement this (besides the fact it's a cool feature for a few users that like having "everything in the same place" and don't mind having a noisy computer running just to stream a 2MB ROM file for less than 1s).

[Former user]

Comment # 6 originally posted by Thomas.Werewolf on 2011-01-29T22:46:20.000Z:

Why keep your library in two or more places? Who, in 2010/11, doesn't have a computer running almost all of the time anyway? Some of us have gone completely discless and run centralized media servers. Can we burn a DVD of ROMs, or load an SD card? Sure, but why bother when everything already exists on a shared drive that the Wii can readily access? That's not to say we don't appreciate the emulator as is, we're just suggesting improvements that will bring it up the level of the NES and SNES emulators and would be grateful for an SMB feature add.

[Former user]

Comment # 7 originally posted by ekeeke31 on 2011-01-30T07:29:03.000Z:

Maybe because I personally don't have a computer running "all the time" and especially not when playing on Wii (and i don't plan to change in 2011) so i don't see the interest of that feature. It also means modifying the interface and adding a way to configure user/pwd which i don't want to do because it's the most boring task when working on an emulator and i would like to work on more interesting stuff in my limited time. That's also why the emulator is open-source so anybody coul code and submit a patch...

[Former user]

Comment # 8 originally posted by pmagnus87 on 2011-03-26T00:35:28.000Z:

Others emuletors have SMB, why not genplus gx??. SD memories are so fragile

[Former user]

Comment # 9 originally posted by auntieNeo on 2011-03-26T09:16:30.000Z:

I have attached a patch for basic SMB support. It seems to work fine without much modification to the existing code, as it just uses the tinysmb that comes with libogc. It took me longer to set up my build environment then it took to steal Visual Boy Advance GX's network code.

I didn't include an icon for the SMB button, so if you want to test it just copy Load\_usb.png to Load\_smb.png for now. The samba share info is hard-coded, so you'll have to change that as well.

The biggest obstacle with adding SMB support is implementing an on-screen keyboard (and textbox) to allow the user to input the share/username/password/ip to set up SMB. There is a simple keypad for entering game genie codes, and I might even look into stealing VBA-gx's keyboard code like I stole their little bit of network code.

It looks like at least a few people are interested in this, so I'll start working on a keyboard. No promises though, as it sort of depends on how much time I can take away from school. I should be able to hack something together though.

Sorry I promised a patch a few years ago. Things came up and I didn't follow through. It's not like this patch is usable either, but I swear it works.

[Former user]

Comment # 10 originally posted by auntieNeo on 2011-03-29T16:34:14.000Z:

I wrote some keyboard code and uploaded what I have so far to github.

There are a few issues with it. The d-pad control on the menu items I added is broken, and I don't know where to fix that. The network code doesn't reconnect when the config is changed. And I still don't have icons for the load or config menu.

I'll fix these issues hopefully soon, but you can check the code on github the url is: https://github.com/auntieNeo/genplus-gx I also put a genplus\_wii.dol build there if anyone wants to test it. Use this at your own risk. I have added some things to the config, so don't be surprised if your config gets borked somehow. It works fine for me, though.

[Former user]

Comment # 11 originally posted by ekeeke31 on 2011-03-29T20:04:21.000Z:

About D-PAD issues, make sure the shift[] parameter of your buttons is not zero, this is what controls offsets applied to current selection when pressing D-PAD keys

shift[0] for up shift[1] for down shift[2] for left shift[3] for right

About your patch, I see that network adds a running thread, is this thread terminated properly when running a game ? this could bring significant performance issues otherwise :-/

for an odd reason, it seems that adding libraries slightly & therefore increasing the binary size somehow impact emulation performances as well (another reason why I'm not a big fan of adding non vital features like this)

[Former user]

Comment # 12 originally posted by ekeeke31 on 2011-03-29T20:19:06.000Z:

Sorry, after actually reading your code it appears you are not using shift[] and gui.c help functions so this wouldn't help.

Try reading input keys ( p = m\_input.keys; ) AFTER refreshing the screen, not before. Calling gxSetScreen() indeed makes the program wait for next VSYNC, which is also when inputs get updated (during VSYNC callback).

[Former user]

Comment # 13 originally posted by auntieNeo on 2011-03-30T07:21:51.000Z:

Thanks for the tips, I think I know how to fix the gui now.

The thread in networkop.c just initializes the network, and joins with the main thread when the network thread is done. As far as I can tell, the thread is not running once the network is initialized. But now that you mention it, it doesn't look like the thread is joined if it ever hangs somehow... I'll look into that.

Like I said, the network code is mostly ripped from VBA-gx, and I haven't touched hardly any of the existing file loading code. I still need to tweak that part of the gui so that it's more aware of network changes and timeouts.

As for the size of the tinysmb library, there's not much I can do. My libtinysmb.a is about 200KB. Correct me if I'm wrong, but that's like 0.3% of the Wii's 64MB of main memory. There would have to be a really odd reason if increasing the size of a binary causes it to run slower, if my understanding of computer architecture is correct. I'm not familiar with genplus-gx's memory situation. Does the emulator use some kind of cache that actively uses up the spare memory? Maybe I'll try some large roms and see if it ever runs out. In any case, even if you decide it's too big to include in the main distribution, I'll continue to maintain a patchset and binary on github in case anyone really wants it.

I'll post another .patch file here in a week or two once I think I've ironed out most of the gui/network bugs.

[Former user]

Comment # 14 originally posted by ekeeke31 on 2011-03-30T08:22:13.000Z:

The problem is actually not running out of memory (on Wii at least, though 200K seems a lot to just load a ROM file from network) but more general speed drop because of binary size.

Test case for emulation speed is Virtua Racing rolling demo. If sound starts scratching and framerate drops, then it means emulation runs too slow. I really don't understand why binary total size in memory would have any impact on code execution (maybe PowerPC experts would know better) but it seems it has.

I'm ok with having a separated patch and eventually two versions. I'm going to release a new version soon though with many modifications to the core (and some to menus regarding controllers) so you will probably need to adapt your patch.

Regarding the thread, it seems to me it is only joined when calling StopNetworkThread but this function is itself only called by InitializeNetwork, which is a little odd. Seems to me that if you only call InitializeNetwork once, the thread will run endlessly in background.

[Former user]

Comment # 15 originally posted by ekeeke31 on 2011-03-31T09:12:23.000Z:

After further inspection, SMB support indeed creates two additional threads in libogc that keeps running in the background:

- one is created by net\_init (network.c) when connecting to network (for example when calling if\_config).

- one is created by smbInitDevice (smb\_devoptab.c) which serves as devoptab caching (?) thread.

The major flaw in libogc design is that both threads can NEVER be terminated once they have been started, they just keep running in the background, even if you close SMB and shutdown network connection, taking CPU process time to more important things when emulation is actually very processor demanding (and therefore maybe increasing emulation latency, video lag, etc).

[Former user]

Comment # 16 originally posted by ECMIYAM on 2011-04-02T06:52:37.000Z:

I have faith in your coding ability, ekeek, that you can manage the SMB support (w/ auntieNEO's able assist) w/ little-to-no perceptible impact on speed--after all, if Tantric can manage it (on the SNES emu), surely you can handle it as well.

[Former user]

Comment # 17 originally posted by ekeeke31 on 2011-04-02T17:53:19.000Z:

You didn't understand, there is nothing i can do on my side, this is already like this in libogc, which means that other emulators like snes9xgx ALREADY have one or two additional threads running in background while playing games, for no purpose. It does not mean it is perceptible or that slowdowns you can sometime notice in snes9xgx are caused by that (also keep in mind you cannot directly compare different emulators speed and make assumptions since they have different CPU requirements). What i am saying is that I don't want to add something that can potentially increase emulator latency for not much benefits in the end.

[Former user]

Comment # 18 originally posted by pmagnus87 on 2011-04-04T17:58:37.000Z:

USB Mouse support but not SMB Support?? This is unfair :S

[Former user]

Comment # 19 originally posted by ekeeke31 on 2011-04-05T06:52:08.000Z:

I don't see the relation between both of them but yeah, life is unfair...

[Former user]

Comment # 20 originally posted by pmagnus87 on 2011-04-05T21:01:11.000Z:

Its unfair because SMB support is more important than mouse support. Genplus GX doesnt update frequently. Maybe doesnt a next update exist :S

[Former user]

Comment # 21 originally posted by auntieNeo on 2011-04-05T23:00:58.000Z:

Don't worry about it. I don't think ekeeke wants an SMB patch, but I'll have a decent patch probably this weekend, with network button graphics and all. I already have a half-working build, and any newer builds will show up at this link: https://github.com/auntieNeo/genplus-gx/raw/master/genplus\_wii.dol Life isn't so unfair.

[Former user]

Comment # 22 originally posted by ekeeke31 on 2011-04-06T06:37:10.000Z:

Yeah, as I said 100x time now, I won't add SMB support in its current state because it adds more drawbacks than advantages in my opinion. I don't mind that a "mod" exists with SMB support as long as GPL is respected though.

@ pmagnus: you must understand that this is not a scheduled project with goals and priority step to achieve. There is no "more important" feature in my eyes and I really do not work on this project to please user requests but for me to have fun coding interesting & challenging stuff. In short, better see the releases I do as a nice extra you get, not something you own.

[Former user]

Comment # 23 originally posted by pmagnus87 on 2011-04-06T10:49:57.000Z:

Calm down, Dont shake your chocolate.

[Former user]

Comment # 24 originally posted by ekeeke31 on 2011-04-06T14:04:47.000Z:

I'm quite calm. Just trying to explain how things work and why there is no need to cry for a feature :)

[Former user]

Comment # 25 originally posted by pmagnus87 on 2011-04-07T11:01:01.000Z:

Oh Yeah!

[Former user]

Comment # 26 originally posted by maddin1502 on 2011-04-09T12:09:59.000Z:

thx ekeek for the great work. but smb suport is important. all my stuff is on hdd, so why buy a new sd with more space. On the SD is other stuff, not only roms for your sega emu. its much easier to start the games over smb. so you dont have to put the stuff on the SD with limited space.

thx auntieNeo for your work. i tested it and it workes really good. just button icns arent right. smb button looks like usb button and the smb settings button looks like another one. i hope you can finish your work, i need it and i will test every new version. THX

[Former user]

Comment # 27 originally posted by auntieNeo on 2011-04-11T00:21:04.000Z:

I made a button for loading the network with gimp, but I can't for the life of me get my pngs to render on the GUI, and I get a lot of core dumps. It does fine if I copy the existing pngs, but pngs I make with gimp or imagemagick, or even reference pngs, don't work. Is there something special I need to do to these pngs to get them to work? Maybe I'm missing something.

Attached is the png that's giving me problems, but most other pngs I've tried are just as problematic.

[Former user]

Comment # 28 originally posted by ekeeke31 on 2011-04-11T07:32:25.000Z:

PNG image dimensions (width AND height) must be multiple of 4 pixels, this is a texture limitation of GX hardware.

Also, the format must be RGBA8 i.e 32 bits per pixels.

[Former user]

Comment # 29 originally posted by maddin1502 on 2011-04-11T17:23:58.000Z:

@ ekeek thx for help

@ auntieNeo, tell me when the icon works, i will test it. thx

[Former user]

Comment # 30 originally posted by maddin1502 on 2011-04-14T16:18:20.000Z:

any news? artwork working? i would do it myself, but i dont know how to use the makefile with windows

[Former user]

Comment # 31 originally posted by auntieNeo on 2011-04-14T20:51:02.000Z:

If you don't have anything to say, stop posting to this thread. I appreciate the encouragement/prodding, but this thread has enough of those posts. I've got a semester project due in a week, and I'm sure ekeeke is busy at times too and doesn't need that in his inbox either.

The .dol file I posted works FINE if you enter the ip and everything correctly the first time, and click on the "load usb" icon. I'll post one with the new icon when it's ready. <\_<

[Former user]

Comment # 32 originally posted by maddin1502 on 2011-04-15T13:08:29.000Z:

sorry, and yes it works fine. now i shut up.... wasnt my intention to spam. thx

[Former user]

Comment # 33 originally posted by SonicXxRush on 2011-04-25T01:24:26.000Z:

This PNG should fix it, I opened one of the icons that do work and opened it as a layer and resized it to fit the canvas. It also saved it as the exact same format as that other working icon. I hope it works, but I can't figure out how to compile and it's killing me... Here it is attatched.

[reydarz]

Comment # 34 originally posted by reydarz on 2011-05-11T20:04:51.000Z:

Compiled with your icon SonicXxRush

[Former user]

Comment # 35 originally posted by danieldematteis on 2011-05-12T10:28:22.000Z:

I can pretty much verify what ekeeke is saying about additional libraries causing performance problems - I've found this to be pretty much true on PS3 as well - it's the main reason why I mostly refrain from adding any bloated libraries unless it's absolutely necessary (in VBA PS3 I'm currently debloating it and taking out everything that me and the original porters put in - SFML, LibPNG, et al. I've even found that taking out the SFML code in VBA causes two games to start working again - Sonic Advance 1/2).

Ultimately, these emulators are meant to do one thing and only one thing only - play games - anything that hurts performance and is not absolutely necessary (as in - it has nothing to do with what the emulator/app is meant to achieve - as in this case, playing games) - it has no purpose in a console emulator port.

For the same reason I thought it was very smart of ekeeke not to bother with filters such as HQ2x - sure, SNES9x GX/FCEU GX has them included, but seeing it run with frameskip 2/3/4 only ends up exposing the inadequacies of the Wii CPU - therefore, a less is more approach is definitely better - if it can't be done at 60fps, then don't include it since it will only show your port in a bad light.

[Former user]

Comment # 36 originally posted by ekeeke31 on 2011-05-13T16:14:41.000Z:

About soft filters: that's really not about showing the emulator "in a bad light" (well, the NTSC filter might even be slower than HQ2x on that matter) but more that I am quite lazy and not very excited by porting video filters which code has already been copy-pasted in every possible emulators out there and which I have actually zero use for (I still have my good old Sony Trinitron CRT and in my opinion, real 15Khz beats up any of these filters anytime ;-))

Most likely, when I (finally) got a real HDTV I will see things differently and add HQ2x filter support but until then, it's just that I don't feel the need.

[Former user]

Comment # 37 originally posted by danieldematteis on 2011-05-13T16:40:26.000Z:

HQ2x on the CPU is probably too much to handle for the Wii CPU though - it's too much for the PS3 PPU too - which is why we rely on the shaders - a much preferable route to take in the end.

Speaking of which, has anybody in the Wii homebrew scene ever attempted the equivalent of writing an image-enhancement shader? I know there's nothing like GLSL, HLSL or Cg available on Wii - I'm not too knowledgeable on the Wii but apparently the TEV allows you to do the equivalent of programmable shaders - has anybody in the homebrew scene ever attempted this?

[Former user]

Comment # 38 originally posted by thiagoalvesdealmeida on 2011-05-13T18:45:24.000Z:

Ekeeke, if you like a real 15khz picture, like me, you better grab a PS3 too, because I also have my Wii hooked to a Sony Trinitron and the picture looks almost the same as the PS3 emulator using the CRT shader with my HDTV. A truly incredible achievement, that no other filter can match.

I've been playing emulators using 240p for years and I can't tolerate filters. But the CRT shader is so faithful that I'm considering give up CRT in favor of a LCD.

And thanks to our friend here, you can use the CRT shader with Genesis games too (something that you can't do using your PC).

[Former user]

Comment # 39 originally posted by ekeeke31 on 2011-05-14T08:59:53.000Z:

Yeah shader seems cool but I always found that CRT shaders somehow did not look "right", either scanlines were too much visible or too regular (on a real CRT, scanline visible "intensity" varies depending on adjacent lines intensity) or they add features I have yet to see on my CRT (like phosphor "emulation" or vertical grid). Though, I admit I never seen one in action, only screenshots so I will have to believe you on that one ;-)

But as I said, SCART RGB with true 15kHz signal is for me the best experience I can have right now and I barely see any differences with my old Mega Drive so I'm happy with that :)

About doing shader filters using GX TEV, I believe it's not possible. As far as I understand it, TEV let you mix multiple textures through several stages, using output of previous stages, color/alpha channels or fixed values as inputs to get various effect through multiple pass. This is done for each pixel of the rendered screen, simultaneously for each color/alpha channels. The problem is that video filters require to perform operations on neighbor pixels from the SAME texture and I think TEV simply does not allow that. Also add the fact that TEV operation is somehow limited compared to programmable GPUs, with a fixed set of operation (add, scale,bias,clamping) that you can only configure, a limited number of registers for storing temporary results and no floating-point support.

That's said, I might be wrong, this part is not very well documented and not much used in Wii/GC homebrew (basically we only use one stage), people who might know the most are Wii64/WiiSX devs (tehpola especially) and I think that the initial port of M-Player did use TEV multiple stages for faster video decoding/rendering.

[Former user]

Comment # 40 originally posted by thiagoalvesdealmeida on 2011-05-16T04:13:12.000Z:

You can also use the CRT shader with bsnes(https://gitorious.org/bsnes/bsnes/blobs/patches/snesshader/CRT.OpenGL.shader)

It's not perfect, but it's the first time that I can play old games on my LCD without wishing I was using my CRT instead. There is even some advantages, like perfect geometry, which my Sony Trinitron lacks.

[Former user]

Comment # 41 originally posted by ekeeke31 on 2011-09-19T10:11:08.000Z:

issue \#188 has been merged into this issue.

[Former user]

Comment # 42 originally posted by mansell.john on 2012-07-03T14:34:48.000Z:

Given that SEGA CD/ MEGA CD support is now implemented official SMB support would prove incredibly useful now..

Only question would it work with SEGA CD/ MEGA CD games ?

[Former user]

Comment # 43 originally posted by mansell.john on 2012-07-03T14:34:48.000Z:

Given that SEGA CD/ MEGA CD support is now implemented official SMB support would prove incredibly useful now..

Only question would it work with SEGA CD/ MEGA CD games ?

[Former user]

Comment # 44 originally posted by ekeeke31 on 2012-07-03T15:09:47.000Z:

No, it would probably be too slow to read CD image data in real time from network, not even worth the try.

[Former user]

Comment # 45 originally posted by Thomas.Werewolf on 2012-07-03T15:29:09.000Z:

Sega CD had a 1x drive. That's just over 1Mb rate. The wireless-g adapter in the Wii is capable of up to 54Mb.

I imagine streaming a standard definition movie would require a significantly faster data rate than a Sega CD emulator and there aren't any issues with that.

[Former user]

Comment # 46 originally posted by ekeeke31 on 2012-07-03T15:37:51.000Z:

We are speaking about emulation here, not video streaming. The emulator needs much faster access speed than 1x drive speed to keep a playable framerate, remember this is a single CPU that must do much more tasks in 1/75 s than just reading a single block of CD data.

[Former user]

Comment # 47 originally posted by mansell.john on 2012-07-03T15:43:54.000Z:

I think it would work.. based on the Thomas's theory.. WIIMC works brilliant in terms of streaming content via SMB without a hitch..

But then what do I know about emulation..

[Former user]

Comment # 48 originally posted by auntieNeo on 2012-07-03T15:49:06.000Z:

I would guess that how feasible this is depends on how effectively the emulator can anticipate (and then buffer) the data that it will need in advance. Unless I'm missing something here, at some point emulator has to read and buffer from a file on disk, using the same file API as it reads ROMs with? Network storage isn't too far off from a local file; they're both quite slow in CPU terms.

Converting the ROM reading code to use SMB was very trivial, and most of my work to patch it was getting familiar with the GUI code. I might just try doing it with CD, as an experiment.

[Former user]

Comment # 49 originally posted by mansell.john on 2012-07-03T16:03:49.000Z:

@ auntieNeo It will certainly be interesting to see how that works out..

The only worry as ekeeke said previously the additional process running may reduce performance, more specifically for MEGA CD emulation..

[Former user]

Comment # 51 originally posted by ekeeke31 on 2012-07-03T16:31:01.000Z:

It's absolutely not complicated from a technical point, it's indeed exactly the same as reading file from SD or USB. The problem is that Sega Cd emulation is not video processing and has high requirements while SMB is the slowest way of reading data. The most CPU time you spend reading from the device, the less you have to emulate the other hardware components (and there are a lot) until the next frame. That's actually quite simple to understand. Again, why would anyone spend time adding something that will be less efficient than sd or usb, takes extra cpu time even when not used and extra memory that could be used for more important things ?

[Former user]

Comment # 52 originally posted by mansell.john on 2012-07-03T19:23:57.000Z:

..Ekeeke, I totally get where your a you are coming from... People though like to add these features, if anything to experiment and see how it works I guess..

Doesn't WIISX have SMB support..? How does that fair ?

[Former user]

Comment # 53 originally posted by sonic21963 on 2012-07-19T06:57:53.000Z:

The whole reason we want SMB isnt because the games cant fit on the SD card we have (for if we even have a cheap 2GB SD card the whole library can still fit on it), but because the latest USB Loader GX releases force us to use the SD Card for the Gamecube dumps for now, leaving -no- room for the Genesis games.

Of course, this is all an optimization issue, but not even future planned SMB Support irks me and a whole lot of people that simply want the whole library or games stored elsewhere accessed from many Wiis across the house, which is much simpler than having a whole bunch of copies on many SDs.

[Former user]

Comment # 54 originally posted by ekeeke31 on 2012-07-19T07:31:33.000Z:

Then buy another sdcard dedicated for your emulation needs, why should i care about what usb loaders "force" you to do ? This would still be easier and faster than implementing smb support in the emulator..

And what irks me personally are people who always complain about having to do minimal efforts or expect devs and apps to do whatever they want. I know people are now used to get nice stuff for free but you should really not take this for granted and keep in mind i am coding this app for me, not for you or any other users.

[Former user]

Comment # 56 originally posted by sonic21963 on 2012-07-19T07:36:54.000Z:

Why dont you just add a game cache for SMB mode where it transfers the game to the cache before running the game? This would, theoretically, eliminate any lag issues.

Here's some pseudocode.

onStartup > isSMBCacheFull? -Yes :: ClearCache onShutdownToMenu > ClearCache

onSelectSMBGame > LoadGameToCache onSelectSMBGame > RunGameFromCache

[Former user]

Comment # 57 originally posted by ekeeke31 on 2012-07-19T11:17:37.000Z:

Because it would be useless ? ROM files are running from RAM, not from sd,usb, smb,... so they are already "cached".

Again, the problem is that connecting to networks adds a thread running which will potentially increase emulation latency by adding uneccessary background processing. This is actually true for all things you add in an emulator, yet people complain about input lags in other emulators while still wanting them to support every possible things.

Now i don't have measured that "latency" or verified it was even meaningful but really i don't care,that's not the point. The point is that i only support features that are absolutely necessary to run the emulator, bring benefit to emulation accuracy/authenticity or eventually have no impact on emulation itself, which i think is the main thing an emulator should focus on, not how many minutes of user's precious life it will save when loading ROM files...

Hmm... why do i feel i am repeating myself ?

[Former user]

Comment # 58 originally posted by Beren.Lyell on 2012-07-29T03:08:14.000Z:

I also would like to have a "load from SMB" option like on wiisx/snes9xgx and other emulators. These seem to all work fine especially snes9xgx. I think the issue here is; you already have a powerful, great piece of software. Now it's time to make it an exemplary piece of software by implementing features such as the SMB load functionality that the users want.

Steal the code if you have to, everyone does it ;), the guys who build the snes9xgx and wiisx might even give it to you anyway??

Cheers

[Former user]

Comment # 59 originally posted by ekeeke31 on 2012-07-29T07:24:50.000Z:

In french we say "autant pisser dans un violon"... Coding it is not difficult, everybody could do it... just that I won't, for the aforementionned reasons that you apparently didn't bother to read. I think the issue here is some people don't understand I am not at their service. "Now it's time" for you to accept that I do what I want :-p

[Former user]

Comment # 60 originally posted by sonic21963 on 2012-09-25T21:16:16.000Z:

Just a note, maybe the process would involve a quick test to see the speed of the wireless network.

If one is streaming Genesis games over a network, Im guessing the response rate has to be pretty fast to be stable, as the Genesis had a fast processor.

If the wireless response speed is found to be below a certain number, it would grey out the SMB Option.

Eke's opinion though makes sense, why do that when the entire library of Genesis games is somewhere around 1.2GB and can be stored on an SD Card?

[Former user]

Comment # 61 originally posted by auntieNeo on 2012-09-25T21:49:48.000Z:

My interest in this faded once I had Sonic 2 running from SMB. If you'd just scroll up, I wrote a buggy patch (with code ripped from snes9x GX). It even has most of the code for an onscreen keyboard. If you want to fix it up to the point where it doesn't have the broken connection issues anymore, maybe ekeeke will include it. Then again, he probably doesn't want to support it. The .dol I posted should still work if you're too lazy to compile it (I know I am).

[Former user]

Comment # 64 originally posted by ekeeke31 on 2012-10-22T23:37:41.000Z:

[Former user]

Comment # 65 originally posted by ekeeke31 on 2013-02-11T07:28:51.000Z:

issue #325 has been merged into this issue.

[Former user]

Comment # 66 originally posted by ekeeke31 on 2014-09-15T06:40:31.000Z:

issue #15 has been merged into this issue.