Programming ObsoNET | MSX Resource Center (Page 2/2)

Paladin (677)

28-10-2022, 22:51

aoineko wrote:

I traced the code of ONET_RESET and it crashes deep in the code because of uninitialized value.
In my opinion, it is mandatory to execute the ObsoNET cartridge startup code before using it.
In fact, ONET_RESET works just fine if I delay the start of my program with the H_STKE hook.

An alternative would be to make a call on the address which is in the ROM header of the ObsoNET cartridge slot. But it seems cleaner to let the card initialize itself.

One possibility is that the code in ONET_RESET expect other pages to be selected from the slot Obsonet is, not just the address page... But if H_STKE was easy for you, even better, as this is surely the preferred approach, hope you get something cool to demonstrate this, there are certainly a good number of Obsonet's around.

By aoineko

Paladin (899)

29-10-2022, 01:14

ducasp wrote:

When we talk about UNAPI, remember we have two types, Ethernet [...] and TCP-IP [...]

Yes, I know.
My plan is:
- ObsoNET specific module with maximum speed to create LAN games (so no other API wrapper),
- UNAPI Ethernet module (as you said, it will be a good taste before the main course) for ObsoNET (and Gr8net if this stack is available),
- UNAPI TCP/IP module for ObsoNET (with INL installation) and Gr8net.

But first things first.

By aoineko

Paladin (899)

30-10-2022, 18:06

The ObsoNET module is progressing well (for the moment I made a sniffer tool but I will make a more complete sample later).
Everything works just fine except one thing: the size value returned by the BIOS function GET_PACKET is incorrect while the one returned by the GET_INSTAT function is correct.
Is this a known issue in the BIOS?

This is not a problem for me, but it could generate problems for the upper layers like UNAPI which is based on the BIOS.

By ducasp

Paladin (677)

31-10-2022, 14:23

aoineko wrote:

The ObsoNET module is progressing well (for the moment I made a sniffer tool but I will make a more complete sample later).
Everything works just fine except one thing: the size value returned by the BIOS function GET_PACKET is incorrect while the one returned by the GET_INSTAT function is correct.
Is this a known issue in the BIOS?

This is not a problem for me, but it could generate problems for the upper layers like UNAPI which is based on the BIOS.

My guess is that it should work ok, if you check the bios code for the BIOS / UNAPI ETHERNET you will see the GET_PACKET indeed calls GET_INSTAT and rely on it to tell the packet size, keeping it on the same register (BC)...

Now, after you double check your code, if all seems fine, you probably would need someone with a real Obsonet / Obsonet Clone to test it for you, I know that the BlueMSX Obsonet Emulation has a bug that causes UDP packages to be received twice, but TCP-IP always worked fine, so perhaps you really found an issue affecting deeper the Obsonet bios... But again, that would be very, very weird because GET_PACKET uses GET_INSTAT internally to figure out package size and returns exactly what GET_INSTAT tells (on a quick glance, did not look that much, so perhaps I'm wrong). If it occurs on real Obsonet too, I would recommend contacting Nestor / Konamiman, he is a really nice guy and will help you for sure.

By ducasp

Paladin (677)

31-10-2022, 14:32

P.s.: talking about your work for MSX-GL, I think that a really cool library would be a simple send joystick over network thing... You send a header byte counting the frame, and other byte containing joystick info (directions + A and B have 6 bits)... So a game engine would most likely do that:

- Call a function to initialize conversation with other end / address
- Success? Cool, let's start to receive joystick information from the other end and send joystick information to the other end
- Game engine would render based on waiting the joystick packet to arrive for that frame, until it receives the joystick packet, it simply freezes and wait for the next frame
- Game engine probably can have some counters like if more than 60 frames without information, disconnect, etc
- Game engine probably can adapt itself rendering less frames (i.e. 30) per second but the engine still runs at 60... That gives 33,3ms to receive information without impacting / freezing

That should work nice, perhaps a version for TCP-IP / non-local network would need to render 20 FPS, so it can wait up to 50ms without freezing...

By aoineko

Paladin (899)

31-10-2022, 16:42

In my sample program (s_onet), I have two tools:
- a sniffer (fully functional) and
- a pseudo-game that looks like what you describe (but still WIP).

I'll receive 2 ObsoNET cartridges soon (one, kindly lent for a few months) so I'll be able to test on real hardware.

By aoineko

Paladin (899)

31-10-2022, 17:59

ducasp wrote:

My guess is that it should work ok, if you check the bios code for the BIOS / UNAPI ETHERNET you will see the GET_PACKET indeed calls GET_INSTAT and rely on it to tell the packet size, keeping it on the same register (BC)...

And you were right.
It was a mistake on my side (I didn't pay attention that the HL register was modified by the BIOS routine).
Everything works fine now.

My problem now is to be able to test with two instances of the program. I tried with two BlueMSX (each on one of the network cards of my PC) but I can't see the messages sent by one to the other.
I don't know if this is a limitation of the emulation.
Has anyone ever tried a LAN with two BlueMSX on the same PC?

By ducasp

Paladin (677)

01-11-2022, 15:41

So, I believe you need to have two different physical network adapters and link each instance to each one. And both network adapters should be connected to the same network, as you are not using TCP-IP / Internet.

Also, you probably want to make sure the second obsonet has a different MAC address, two devices with the same MAC address on the network will cause nothing but chaos...

http://www.konamiman.com/msx/msx-e.html#obsonet

eth.com should allow you to change the MAC Address, not sure how this is going to work on blue msx running twice on the same computer though... You probably are going to have an easier setup when you get the real cartridge so you can interface emulator vs computer, or, perhaps, if you have a different computer, try to set-up bluemsx on it as well. I don't think bluemsx code was thinking on multiple instances using obsonet, so this might be difficul to debug / understand what is going on, if it is your software or the emulator...