pspdebugkb.c patch

[NoEffex]

http://rapidshare.com/files/186940799/p ... ch.gz.html

This patch it to maintain(well, in this case, gain) compatibility with kernel-mode, as pspDebugScreenPrintf is not usable in kernel-mode modules, and pspDebugScreenKprintf is not usable in user-mode(to the best of my knowledge), so I added a macro I came across somewhere to it to substitute that, so that way it would work on both usermode and kernel-mode.

[jimparis]

Code: Select all

--- pspdebugkb.c        2009-01-21 00:27:21.000000000 -0500
+++ pspdebugkb_new.c    2009-01-21 00:27:17.000000000 -0500
@@ -15,6 +15,8 @@
 #include <string.h>
 #include "pspdebugkb.h"
 
+#define pspDebugScreenPrintf&#40;...&#41; &#123; char buf&#91;256&#93;; sprintf&#40;buf,__VA_ARGS__&#41;; pspDebugScreenPuts&#40; buf &#41;; &#125;
+
 static char loCharTable&#91;PSP_DEBUG_KB_NUM_ROWS&#93;&#91;PSP_DEBUG_KB_NUM_CHARS&#93; = &#123;
   &#123; '`', '1', '2', '3', '4', '5', '6', '7', '8', '9', '0', '-', '=' &#125;,
   &#123; 'q', 'w', 'e', 'r', 't', 'y', 'u', 'i', 'o', 'p', '&#91;', '&#93;', '\\' &#125;,

I don't see how this is any different from the existing pspDebugScreenPrintf implementation in the pspsdk...? Is it just that vsnprintf doesn't exist but sprintf does?

[NoEffex]

The pspDebugScreenPrintf does not work in kernel mode(thus the entire debug keyboard), and from my experience, pspDebugScreenKprintf does not work in user mode. So, instead of manually going and doing sprintf this that puts this I just used Raphael's macro he gave me a while back to overcome this.

[jimparis]

But pspDebugScreenPrintf is implemented just like what you wrote here. If this works in kernel mode, the existing pspDebugScreenPrintf should work too.

Unless, as I said, the difference is that vsnprintf doesn't exist in kernel mode, in which case the pspsdk implementation could be changed.

[NoEffex]

Correct, vsnprintf does not exist in kernel.

[TyRaNiD]

Well the "changed" version if the pspDebugScreenKprintf which I modified to use the kernel's callback formatter. Alas due to obvious name conflicts there was no easy and compatible way of matching the two up :) Now if we had a clear separation between kernel and user libraries that wouldn't now be an issue :)