openMSX network device emulation

Page 2/3
1 | | 3

By Parn

Paladin (775)

Parn's picture

26-01-2022, 13:38

Nope. AFAIK, no network adapter is emulated by OpenMSX. I presume this is impossible or very hard to do, since if it were easy it would already have been done (at least ObsoNet, which is relatively simple compared to GR8NET).

By ducasp

Hero (537)

ducasp's picture

26-01-2022, 14:59

raymond wrote:

Sorry for reviving this old thread. But is the GR8NET working in openMSX nowadays?

It is not, and it is very likely it is not ever going to be supported. GR8NET has a huge FPGA that plays quite a role in all its functionalities, it is proprietary, not open source (no criticism here, just facts).... Unlikely to have it emulated.

Now, if you wanna try UNAPI programming, BlueMSX on Windows is your only choice:

https://www.msx.org/forum/msx-talk/emulation/bluemsx-emulati...

I've took the time to make an image for it as well instructions on how to make it work, most people were able to get it working, one or two didn't... Obsonet is not nearly as fast as GR8NET, and its UDP emulation is flawed.... But hey, it works to most extents and is your best (and only) bet to emulate UNAPI...

P.s.: if that works for you, and you feel adventurous (so please try that first, if that doesn't work, unlikely you will get the second one working), I have a private build of BlueMSX that includes "emulation" of the SM-X UNAPI WiFi Adapter... Emulation in the sense it emulates the interface between ESP-01 module and the "MSX", but you still would need a USB to Serial 3V3 adapter and an ESP-01 module with the custom firmware installed on it. It tends to be as fast as GR8NET using UNAPI, but if what you want is to use GR8NET specific API, basic extensions or other features, then you are out of luck...

By ducasp

Hero (537)

ducasp's picture

26-01-2022, 15:10

Parn wrote:

Nope. AFAIK, no network adapter is emulated by OpenMSX. I presume this is impossible or very hard to do, since if it were easy it would already have been done (at least ObsoNet, which is relatively simple compared to GR8NET).

Many issues implementing network devices on OpenMSX, first, Obsonet, since it lays on a lower layer of network (not TCP-IP), to emulate it, like BlueMSX, you would need npcap or other API/Driver that allows you to "hijack" the physical layer. Now, BlueMSX was Windows only, and rely on npcap... OpenMSX is for too many systems, so, is there a common solution for all operating systems Open MSX supports, or, at least for most, like npcap? If not, unlikely the OpenMSX team will accept any code exclusive for Windows or any given operating system....

Now, let's talk about GR8NET, that would be even more difficult, given the proprietary stuff on FPGA and all extensions... Who would be able to do a FPGA emulation? Unlikely....

Lastly, at some point in time I think Manoel said perhaps the team could be persuaded to accept a "not-real" device, where you would have a fake device connecting to TCP-IP and UDP using something that would be common for all OS's, problem is, someone would need to develop a driver or bios for that effect as well as implement "the fake device" and test it on many OS's... I would like to do it at some point in time, but currently and for the foreseable future, I don't have enough "Hobby time" to a big project like this... That might be the nice route to have an UNAPI device on OpenMSX, not emulating a real device, but would work to allow developers to debug UNAPI software as well allow people to test UNAPI MSX Network programs Wink

P.s.: Denyonet perhaps could be done, but emulating the Wiz chip would require even more work than the above proposition, give no real benefits (other than being a real device being emulated, that is) to the end user of Open MSX and would exchange the work of having a UNAPI Driver/BIOS made for the fake device (which would be easy using my driver for SM-X Wifi, all functionality is on the ESP itself, so it is just a wrapper for UNAPI calls) to the work of emulating the Wiz chip (that seems quite a lot of work) and connecting it to the plethora of OS's TCP IP / UDP stacks or API that works for all/most (common work on both propositions)

By Parn

Paladin (775)

Parn's picture

26-01-2022, 15:51

Thank you for explaining it again, @ducasp. I remember you explained this to me earlier, but for the life of me I wouldn't be able to recall so many details. I believe there exists multiplatform virtualization software, but I have no idea how those work and what's the feasibility of using the same solution on OpenMSX.

By raymond

Hero (595)

raymond's picture

26-01-2022, 19:29

ducasp, thank you for your thorough explanation! Then I have to test on real hardware, no problem, takes a bit more time.

By geijoenr

Champion (305)

geijoenr's picture

26-01-2022, 21:07

A UNAPI TCP/IP Extension seems doable and portable, because it requires only sockets on the host side.

For Obsonet Ethernet emulation, there is maybe using AF_PACKET(Linux) or SOCK_RAW(Windows), but those will require running as administrator which is probably not an option for openMSX.

By Parn

Paladin (775)

Parn's picture

27-01-2022, 14:59

It could be an option if this service were provided by a separate driver (or something like that) which would in turn be used by OpenMSX. But I suspect this would also be not trivial.

By ducasp

Hero (537)

ducasp's picture

27-01-2022, 15:38

Parn wrote:

It could be an option if this service were provided by a separate driver (or something like that) which would in turn be used by OpenMSX. But I suspect this would also be not trivial.

You most likely would need a library that fits well with OpenMSX choices to abstract sockets at least for x64 Windows/Linux/Mac OS, if it works for Android would be a bonus, but I think if just Android doesn't have it, it would be acceptable by the OpenMSX team.

By Manuel

Ascended (18715)

Manuel's picture

27-01-2022, 20:19

What would make it acceptable is that the code is of good quality and maintainable by someone, preferably by an active person. We have some optional components, it's okay if these don't work on all platforms. But a good maintainer is much more important.

So, go ahead and start working on a patch. And if you need help, you know where you can find us.

By ducasp

Hero (537)

ducasp's picture

28-01-2022, 17:13

Manuel wrote:

What would make it acceptable is that the code is of good quality and maintainable by someone, preferably by an active person. We have some optional components, it's okay if these don't work on all platforms. But a good maintainer is much more important.

So, go ahead and start working on a patch. And if you need help, you know where you can find us.

Great to hear that, taking Android out of the equation makes it easier, seems like SDL_Net abstracts TCP and UDP and works on Windows/Linux/MacOS, so a solution using it could be PC OS Agnostic and cover the main releases of OpenMSX.

Not sure if I will have some time to do it, maintain is a lot easier once it is in place, not something that would require huge eforts to maintain, if not, hopefully someone can pick-up the idea and do it Smile

Page 2/3
1 | | 3