Artemis Development progress

[misfire]

I spent some time getting familiar again with my ancient remote debugger
code. The PS2-side server was written in C and ASM, while the PC-side
client was originally written in C only.

Recently, I've changed my mind and decided to use C# and the powerful
.NET Framework to develop the client instead. This step obviously
requires to port the TCP/IP communications code from C to C#. So far so
good.

While .NET is THE technology when it comes to rapid OOP and its TCP/IP
support is indeed excellent, it turned out that it really sucks when
trying to work with pointers and structures, i.e. unmanaged code (FYI,
the format of the UDP packets are defined using C struct's).

The way .NET handles unmanaged code is complicated and may result in
speed losses compared to the original C code. Therefore, I consider
moving the communications code (C) to an additional DLL which can be
invoked by the client (C#).
This approach has several advantages:
- server and client can use the same code base
- the code remains portable
- the DLL can be used by any application, enabling "third-party" clients

Opinions?

[misfire]

I guess my final decision will depend on some time measurements. With the C code, a complete BIOS dump takes ~3,8 sec, which is more than 1MiB/s. When I've completed the C# port of the dump function, I'll post the result of the speed comparison here.

[cYs Driver]

very nice misfire!!

[Lazy Bastard]

Moving the code for UDP communication to a separate DLL sounds like a good idea, considering. I'm eager to play with some (partially) working code.

I've fairly sure I can consistently defeat the PS2's copy protection scheme, though some thorough testing is still required, and I'm still considering ways to make the process less expensive.

We shall see...

[misfire]

Fortunately, it turned out that the C# implementation runs at the same speed as the code written in C. And, as there are no speed issues, I'll stick to C# on the client side.

Also, I've written a small test application which allows you to dump different memory regions (IOP RAM, ROM0, ROM1, ROM2, and EROM) and displays the elapsed time. I'm willing to share it after figuring out why my brand new PS2SDK build causes trouble...

[Lazy Bastard]

Great @ C# BIOS dump speed.

Incidentally, I've decided to go with a MinGW PS2SDK configuration rather than that of Cygwin or true Linux (with a VMWare appliance), and see what problems I run into via that avenue. So far, it seems to have worked out nicely.

What trouble have you had with the latest build?

[misfire]

I had to remove the AHX IOP driver code in order to build the latest SDK. There're no visible issues when compiling my source code with it, but there seems to be a problem with loading newer IOP modules, for example, loading ps2dev9.irx failed. Might be a compiler issue (I've used an older Cygwin GCC version to build the SDK) or some other incompatibilities...

BTW, dumping IOP RAM only takes about 1,5 secs.

[Lazy Bastard]

Ah...I hope that doesn't present a problem...I've noticed that PS2SDK periodically breaks with updates, then is fixed some time later...with varying results for different people.

Out of curiosity, what form is the output of those dumps in?

[misfire]

Nice - building the PS2SDK with MinGW worked quite well. I think I'll use it together with Eclipse from now on. No more Cygwin. Also, the MinGW version of ps2client is much more faster than the one compiled under Cygwin, which is an extra plus.

"Out of curiosity, what form is the output of those dumps in?"

Not sure what you mean. The files contain the raw bytes of the dumped memory region.

[Lazy Bastard]

Yes; I had no problems building with MinGW, whereas I had many building with Cygwin.

The files contain the raw bytes of the dumped memory region.

Ah; that's what I was wondering (was the output formatted in any way, or just a raw dump?). I see.

[misfire]

Hm, MinGW seems to cause trouble after all. For example, try to compile a simple hello world program with scr_printf() - it won't work. Also, I can't get my code to work with the IOP modules compiled under MinGW.

[Lazy Bastard]

Ack. I was still revelling in the fact that MinGW compiled the PS2 toolchain properly; I hadn't compiled anything using PS2SDK yet. I shall have to try mine as well.

[misfire]

Probably found the reason: I'm using outdated MinGW binaries that have a 64-bit integer bug. I'll download the latest (fixed) versions from http://lukasz.dk/programming/playsta...ingw-tutorial/ ASAP. This also explains why the IOP modules do weird things...

[Lazy Bastard]

Heh, I see. I followed that tutorial while setting up MinGW, though I modified my msys login script a bit, as it had problems when I followed his instructions explicitly. Also, for some reason, I had to make HOME="/home", rather than the default.

[Lazy Bastard]

Yes, my MinGW/msys build compiled a basic "hello world" ELF properly (it runs fine in PCSX2t, also). Let me know if updating MinGW fixed your problems.