PC-FX homebrew development.

[Arkhan Asylum]

Documentation for this crap is pretty much the most important part.

Even more important than getting it working, probably.

One day, when PCE/MSX stuff I am doing has died down, PC-FX is where my tentacle rape space pirate RPG Mahjong dating sim is going to be.

[OldRover]

Documentation for this crap is pretty much the most important part.

Absolutely. Poorly-documented toolchains go nowhere fast. Imagine if WinterMute had taken the time to properly document *anything* he worked on... way more people would be using devkitpro... but since he never felt it necessary, only those with free time on their hands had the patience to figure everything out on their own. Just one example. HuC did not have the greatest documentation at first either, but several people stepped up to help. Your Squirrel library is probably the best-documented dev tool there is in the PCE scene.

[elmer]

Documentation for this crap is pretty much the most important part.

Well, I'd say that we're lucky to actually have the full system documentation, even if it is in Japanese.

I've got all the docs readable by Microsoft Word ... and we can convert them into any modern format for translation/editing.

All the work that Alex Marshall did in converting the old http://hp.vector.co.jp/authors/VA007898/pcfxga/ website into English is still available for updates & edits.

(His site "daifukkat.su" website died last year, but I've got a backup of it.)

He was very good about including doxygen tags in his source, so there's some semi-decent documentation for how to use the code that he's written.

I'm cleaning up my "build" scripts so that they're a bit-more sensibly organized.

I've got Mednafen building a 64-bit Windows version now, and I'll try to get the tools 64-bit-clean over the next week or so.

I'll also try to put a hack into Mednafen so that we've got 8MB on the PC-FX instead of 2MB.

It's so much easier to have extra memory available in "debug" builds to compensate for the larger size of the compiled code, and to also provide extra space for in-game logging/debugging info.

[Arkhan Asylum]

This reminds me, I need to work on PCFXTOO.com again... lol

I hate websites.

[OldRover]

My PC-FX came in today, so it's on like popcorn.

[elmer]

Congratulations, that was quick!

Now, I've still got some important stuff left to do on the toolchain (like getting newlib compiling again), so I'm going to have to slow you down somehow ... 

Errrrmmm ... you do realize that I can only pass on the new toolchain to folks who have completed the Zeroigar translation's "Sakuraigar Mode"?  (That should keep him busy for a while!)

[Gredler]

Congratulations, that was quick!

Now, I've still got some important stuff left to do on the toolchain (like getting newlib compiling again), so I'm going to have to slow you down somehow ... 

Errrrmmm ... you do realize that I can only pass on the new toolchain to folks who have completed the Zeroigar translation's "Sakuraigar Mode"?  (That should keep him busy for a while!)

I'll never work with these tools, drat!

[OldRover]

OK I beat your game... any idea on when this might be ready for testing?

[elmer]

OK I beat your game... any idea on when this might be ready for testing?

Oh, cr*p that was quick! 

I hope that you didn't actually take me seriously and really play the game ... unless you actually wanted to! 

[OldRover]

After being a royal pain in elmer's ass (sorry bro hehe), I got the toolchain working here... so now comes the fun part.


facebook.com/photo/?fbid=10208018991819913

[elmer]

After being a royal pain in elmer's ass (sorry bro hehe), I got the toolchain working here... so now comes the fun part.

Woohoo!

Well ... there's the V810 VWF-code that I wrote for Zeroigar and posted in one of the other threads when you're ready to tackle that nasty ROM font in Alex's example code! 

[OldRover]

Ran it on my PC-FX... works beautifully.


facebook.com/photo/?fbid=10208019177784562

Woohoo!

Well ... there's the V810 VWF-code that I wrote for Zeroigar and posted in one of the other threads when you're ready to tackle that nasty ROM font in Alex's example code! 

Oh yeah, definitely... and I'm gonna test the hell out of this thing and annoy you further ;) haha

[OldRover]

Naturally, one of the first things I looked for was library code to play CD audio tracks... looks like there are none, but there's low-level SCSI command access, so I can just write some code to do all the drive stabbies and wrap it up in a neat high-level implementation.

EDIT: OK, this part would be easier if I knew what the LUN was of the drive...

[OldRover]

According to Ryphecha, the LUN should be 0. So, I attempted to edit the hello.c example program to play a CD track. I'm getting no audio, and it must be because I am missing some important step.

Code Select Expand

eris_low_psg_set_main_volume(15,15);
eris_low_cdda_set_volume(63,63);
scsicmd10[0] = 0x48;
scsicmd10[1] = 0;
scsicmd10[4] = 2;
scsicmd10[5] = 1;
scsicmd10[7] = 3;
scsicmd10[8] = 1;
scsicmd10[9] = 0;
eris_low_scsi_command(scsicmd10,10);

[OldRover]

I still can't get CD audio to work and I am not sure why... in the meantime, I've added some more high-level functionality to mimic HuC's behavior, as I did with the high-level sprite library. While it's pretty basic for now, it's a good proof of concept.

First up is put_string() as per HuC's implementation, with the addition of the Tall font.

Code Select Expand

void put_string(char* str, int x, int y, int tall)
{
u32 o[256];
int i;
int len = strlen8(str);
if (len > 255) len = 255;
for(i = 0; i < len; i++)
o[i] = str[i];
o[i] = 0;
u32 kram = x + (y << 5);
len = strlen32(o);
for(i = 0; i < len; i++) {
printch(o[i], kram + i, tall);
}
}
Then there's put_number() which requires itoa... looks like this is in stdlib but the default makefile explicitly prevents stdlib from linking so I just added K&R's implementation of itoa, slightly modified to work with this toolchain.

Code Select Expand

void put_number(int thenumber, int length, int x, int y, int tall)
{
char onum[33];
if (length > 32) length = 32;
if (length < 1) length = 1;
itoa(thenumber,onum);
onum[length] = 0;
put_string(onum, x, y, tall);
}

/* itoa:  convert n to characters in s */
void itoa(int n, char s[])
 {
     int i, sign;
 
     if ((sign = n) < 0)  /* record sign */
         n = -n;          /* make n positive */
     i = 0;
     do {       /* generate digits in reverse order */
         s[i++] = n % 10 + '0';   /* get next digit */
     } while ((n /= 10) > 0);     /* delete it */
     if (sign < 0)
         s[i++] = '-';
     s[i] = '\0';
     reverse(s);
 }
 
 /* reverse:  reverse string s in place */
 void reverse(char s[])
 {
     int i, j;
     char c;
 
     for (i = 0, j = strlen8(s)-1; i<j; i++, j--) {
         c = s[i];
         s[i] = s[j];
         s[j] = c;
     }
 }
And yeah, this is based on chartou32() and printstr() in hello.c... they work well, so why reinvent the wheel... I just merged them into a single function and added a safeguard.

[OldRover]

Here's a put_hex() based on Robert Jan Schaper's itoa() that hardcodes in a base value of 16:

Code Select Expand

void put_hex(int thenumber, int x, int y, int tall)
{
static char buf[32] = {0};
int i = 30;
if (thenumber < 1)
{
put_string("0",x,y,tall);
return;
}
for(; thenumber && i ; --i, thenumber /= 16)
buf[i] = "0123456789ABCDEF"[thenumber % 16];
put_string(&buf[i+1],x,y,tall);
}

[elmer]

Then there's put_number() which requires itoa... looks like this is in stdlib but the default makefile explicitly prevents stdlib from linking so I just added K&R's implementation of itoa, slightly modified to work with this toolchain.

Yes, I've got to figure out what the command-line-magic is that's needed to get stdlib actually linked into the build again.

I've got newlib is compiled for the V810, and it provides all the usual goodies, but I guess that Alex wasn't using it when he did his work on liberis.

Good work on the investigations ... I'll be interested to see what kind of code the compiler comes up with for some of the C code that you've done.

[OldRover]

Okay so I had the code working fine for CD audio playback all along... there was actually a bug in liberis that prevented it from outputting sound.

In src/low/soundbox.S:

Code Select Expand

.global _eris_low_cdda_set_volume

_eris_low_cdda_set_volume:
out.b r6, 0x12A[r6]
out.b r7, 0x12C[r6]
jmp [lp]
change it to this:

Code Select Expand

.global _eris_low_cdda_set_volume

_eris_low_cdda_set_volume:
out.b r6, 0x12A[r0]
out.b r7, 0x12C[r0]
jmp [lp]
though you can get the same effect in regular C code with the following:

Code Select Expand

out8(0x12A, leftvol);
out8(0x12C, rightvol);
so that's one mystery solved!

[OldRover]

So... we got some basic CD audio functionality now as well... here we go:

Code Select Expand

void cd_set_volume(u8 leftvol, u8 rightvol)
{
if (leftvol > 63) leftvol = 63;
if (rightvol > 63) rightvol = 63;
out8(0x12A, leftvol);
out8(0x12C, rightvol);
}
This does not exist in HuC because there's apparently no way to adjust the volume outside of using the hardware faders.

Code Select Expand

void cd_playtrk(u8 start, u8 end, u8 mode)
{
u8 scsicmd10[10];
scsicmd10[0] = 0x48;
scsicmd10[1] = 0;
scsicmd10[2] = 0; /* reserved */
scsicmd10[3] = 0; /* reserved */
scsicmd10[4] = start;
scsicmd10[5] = 1;
scsicmd10[6] = 0; /* reserved */
scsicmd10[7] = end;
scsicmd10[8] = 1;
scsicmd10[9] = 0;
eris_low_scsi_command(scsicmd10,10);
}
I made the prototype identical to the HuC one, although this is incomplete. There's probably a way to set the track(s) to loop, but I don't know what it is yet... made sense to prepare for it though. If there's no way to do it in hardware (what a step back that would be), then it could probably be emulated by polling the drive status at regular intervals.

Anyway, this is all tested working... I will try to add the rest of the CD audio functionality from here. MSF playback is supported, as well as pause/resume, so these won't be too difficult to add in. I just wanted to get a working base to start... now that it's working fine, it can be expanded.

[OldRover]

More CD functionality based on direct SCSI commands.

Code Select Expand

void cd_pause()
{
u8 scsicmd10[10];
scsicmd10[0] = 0x47; // operation code PAUSE RESUME
scsicmd10[1] = 0; // Logical unit number
scsicmd10[2] = 0; // reserved
scsicmd10[3] = 0; // reserved
scsicmd10[4] = 0; // reserved
scsicmd10[5] = 0; // reserved
scsicmd10[6] = 0; // reserved
scsicmd10[7] = 0; // reserved
scsicmd10[8] = 0; // Resume bit
scsicmd10[9] = 0; // control
eris_low_scsi_command(scsicmd10,10);
}

void cd_unpause()
{
u8 scsicmd10[10];
scsicmd10[0] = 0x47; // operation code PAUSE RESUME
scsicmd10[1] = 0; // Logical unit number
scsicmd10[2] = 0; // reserved
scsicmd10[3] = 0; // reserved
scsicmd10[4] = 0; // reserved
scsicmd10[5] = 0; // reserved
scsicmd10[6] = 0; // reserved
scsicmd10[7] = 0; // reserved
scsicmd10[8] = 1; // Resume bit
scsicmd10[9] = 0; // control
eris_low_scsi_command(scsicmd10,10);
}

void cd_playmsf(u8 strt_m, u8 strt_s, u8 strt_f, u8 end_m, u8 end_s, u8 end_f, u8 mode)
{
u8 scsicmd10[10];
scsicmd10[0] = 0x47; // operation code PLAY AUDIO MSF
scsicmd10[1] = 0; // Logical unit number
scsicmd10[2] = 0; // reserved
scsicmd10[3] = strt_m; // starting M
scsicmd10[4] = strt_s; // starting S
scsicmd10[5] = strt_f; // starting F
scsicmd10[6] = end_m; // ending M
scsicmd10[7] = end_s; // ending S
scsicmd10[8] = end_f; // ending F
scsicmd10[9] = 0; // control
eris_low_scsi_command(scsicmd10,10);
}
Again, using HuC's convention. The pause/unpause functions could easily be put into a single function with a parameter... would save some code space...

Code Select Expand

void cd_pausectrl(u8 resume)
{
u8 scsicmd10[10];
if (resume > 1) resume = 1; // single bit; top 7 bits reserved
scsicmd10[0] = 0x47; // operation code PAUSE RESUME
scsicmd10[1] = 0; // Logical unit number
scsicmd10[2] = 0; // reserved
scsicmd10[3] = 0; // reserved
scsicmd10[4] = 0; // reserved
scsicmd10[5] = 0; // reserved
scsicmd10[6] = 0; // reserved
scsicmd10[7] = 0; // reserved
scsicmd10[8] = resume; // Resume bit
scsicmd10[9] = 0; // control
eris_low_scsi_command(scsicmd10,10);
}
Some #defines would make that clearer...

Code Select Expand

#define CD_PAUSE 0
#define CD_UNPAUSE 1
#define CD_RESUME 1three #defines, because reasons.

[OldMan]

May I ask why you do

"if (leftvol > 63) leftvol = 63;
 if (rightvol > 63) rightvol = 63;"

rather than
"
 leftvol &= 63;
 rightvol &= 63;
" ?

And does it work right if leftvol = -1? I believe HuC has some problems with mixed mode compares.

(ie, 63 is an int (presumably signed) and leftvol is unsigned char; Huc doesn't sign extend afaik, so
 it's possible to get things that seem to work in most cases...but not in all)
I know its not HuC, that's why I'm asking.

[NightWolve]

I wondered about that. It all depends on what causes less cycles. If it's generally false 90% of the time, maybe quick value tests and a jump are faster than always AND'ing and assigning/writing to a memory location. You guys would know, maybe Rover cycle-tested his code. I wanna agree it could be faster your way, but I'd wanna test it, dunno.

[OldRover]

May I ask why you do

"if (leftvol > 63) leftvol = 63;
 if (rightvol > 63) rightvol = 63;"

rather than
"
 leftvol &= 63;
 rightvol &= 63;
" ?

Because I didn't know I could. I tend to code in non-clever ways. I'll leave the weirdness to the experts.

[elmer]

May I ask why you do

"if (leftvol > 63) leftvol = 63;
 if (rightvol > 63) rightvol = 63;"

rather than
"
 leftvol &= 63;
 rightvol &= 63;
" ?

Because I didn't know I could. I tend to code in non-clever ways. I'll leave the weirdness to the experts.

That's not exactly "clever" C code ... "+=", "-=", "*=", "/=", etc are pretty standard stuff.

OTOH ...
[tt]  if (leftvol > 63) leftvol = 63;[/tt]
is actually very different to ...
[tt]  leftvol &= 63;[/tt]

Your version clamps an over-the-limit value of 64 to the maximum of 63.

OldMan's version wraps 64 back to 0 (which is pretty-much-never what you want in practice).

Given that neither are particularly good end-results, and that you're programming for a fairly-slow videogame console and not a medical life-saving device ... IMHO it's best not to waste the CPU cycles by even trying to clamp/wrap it, and just leave it up to the programmer to feed it legal values.

[OldRover]

I've always said that we should just remove the safeguards and let the problems solve themselves... but I was just being cautious, as I tend to do. I'll remove all safeguard code from my work and also not add any in the future.

[OldRover]

Okay so I guess one thing we're going to need is some utility tools to convert graphics and other such things.. if stuff like this does not already exist, I can spend this weekend working on such things.

[NightWolve]

NightWolve's version wraps 64 back to 0 (which is pretty-much-never what you want in practice).

Uh, you mean OldMan? I only wondered which version uses less CPU cycles factoring in the % rate that over 63 is possible. If it's 9X% false in general use, then I'm guessing reading those variables and always writing back to them with an AND operation will take more CPU cycles versus a cmp to 63 and jumping over the assignment/writing of 63 to the variable. I'm not sure either way, but I think a test is worth it to know what's fastest to keep the library code fast if such safeguards are really needed (sounds like they might not be).

But anyway, good point if his AND'ing with 63 would cause a wrap back to 0 with 64 which rules out considering it at all... I thought it was legit code to accomplish the same result at first glance and simply compact but doubted the CPU cycle gains in switching.

[OldRover]

I am starting on some tools to get graphics conversion done. As far as I know, this uses YUV colorspace with 16 bit palettes arranged as Y8U4V4. I'm going to assume that Y is the upper 8 bits, U is the high nybble of the lower 8 bits and V is the lowest nybble... someone please correct me if I'm wrong. I am going to be using this formula:

Code Select Expand

Y = (0.299*R) + (0.587*G) + (0.114*B)
U = ((B-Y)*0.565) / 4
V = ((R-Y)*0.713) / 4
YUV = (Y << 8) + (U << 4) + V
If any of this is wrong, I'd like to know...

EDIT: Fixed mah formula!

[elmer]

Uh, you mean OldMan? I only wondered which version uses less CPU cycles ...

Sorry, I got confused! 

I am starting on some tools to get graphics conversion done. As far as I know, this uses YUV colorspace with 16 bit palettes arranged as Y8U4V4. I'm going to assume that Y is the upper 8 bits, U is the high nybble of the lower 8 bits and V is the lowest nybble... someone please correct me if I'm wrong. I am going to be using this formula:

Code Select Expand

Y = (0.299*R) + (0.587*G) + (0.114*B)
U = ((B-Y)*0.565) / 2
V = ((R-Y)*0.713) / 2
YUV = (Y << 8) + (U << 4) + V
If any of this is wrong, I'd like to know...

I'm afraid that my graphics toolchain still needs a lot of cleanup before it's shareable.

I've got 131 undocumented options in there now from 25+ years of "just-get-it-done" ... it badly needs some TLC before anyone else would find it useful.

But here's the palette code that I added to it for converting graphics for Zeroigar.

It's not pretty, but it worked.


        float fl___R = (float) pcl__P->m_uRgbR; // 8-bit (0-255)
        float fl___G = (float) pcl__P->m_uRgbG; // 8-bit (0-255)
        float fl___B = (float) pcl__P->m_uRgbB; // 8-bit (0-255)

        float fl___Y =
          ( 0.2990f * fl___R) + (0.5870f * fl___G) + (0.1140f * fl___B);
        float fl___U =
          (-0.1686f * fl___R) - (0.3311f * fl___G) + (0.4997f * fl___B) + 128.0f;
        float fl___V =
          ( 0.4998f * fl___R) - (0.4185f * fl___G) - (0.0813f * fl___B) + 128.0f;

        if (fl___Y <   0.0f) fl___Y =   0.0f;
        if (fl___Y > 255.0f) fl___Y = 255.0f;
        if (fl___U <   0.0f) fl___U =   0.0f;
        if (fl___U > 255.0f) fl___U = 255.0f;
        if (fl___V <   0.0f) fl___V =   0.0f;
        if (fl___V > 255.0f) fl___V = 255.0f;

        unsigned ui___Y = (unsigned) fl___Y;
        unsigned ui___U = (unsigned) fl___U;
        unsigned ui___V = (unsigned) fl___V;

        ui___U = (ui___U + 8 ) >> 4;
        ui___V = (ui___V + 8 ) >> 4;

        ui___P = (ui___Y << 8 ) + (ui___U << 4) + ui___V;

        *puw__Q++ = (uint16_t) ui___P;

[OldRover]

I was actually wrong on the / 2... it should be / 4 (or >> 4, both work)... realized that when I was taking a shower... why is it that all this stuff comes to me when I'm all wet? Anyway, I recognize that algorithm as well, and I am not sure which one would produce more accurate results... maybe neither, heh.

[elmer]

Anyway, I recognize that algorithm as well, and I am not sure which one would produce more accurate results... maybe neither, heh.

Well ... mine comes directly from the PC-FX SDK documentation, but I'm not sure where yours comes from (especially since you're missing the center-bias on the U & V). 

[OldRover]

Mine comes from here:

http://www.fourcc.org/fccyvrgb.php

because I don't have access to such fancypants thingos.

[OldRover]

Okay so I implemented the algorithm you have up there... here's the results I get parsing a simple 16 color palette:

Code Select Expand

255 0 255 -> 0x69DF
0 0 0 -> 0x88
36 0 0 -> 0xB89
0 36 72 -> 0x1DA7
72 0 0 -> 0x167A
36 72 144 -> 0x45B7
36 108 180 -> 0x5FB5
144 36 36 -> 0x447B
180 36 36 -> 0x4F7D
144 72 36 -> 0x596A
180 108 36 -> 0x795B
216 72 72 -> 0x737D
216 144 72 -> 0x9D5B
255 144 72 -> 0xA95C
255 216 72 -> 0xD33A
255 180 144 -> 0xC66B
As long as I didn't mess anything up, I assume your implementation should get the same results.

[OldMan]

...Because I didn't know I could. I tend to code in non-clever ways. I'll leave the weirdness to the experts.

Ok. I do that too.
Asking because I often see the & route used, suposedly being 'faster'.
And because I've had trouble with mixed-type compares...Maybe 0x3f would be 'better' than 63?
personally, I'm not sure though that clamping it is 'better'. I like to know when there are problems with input variables, and no sound would be a sure indication of that
Since I'm not familiar with the machine, or the compiler generated code, I'll leave it  to the experts.

As for the input checks...we do it all the time. It's easy enough to use a #ifdef/#endif to turn them
on/off.

I am starting on some tools to get graphics conversion done. As far as I know, this uses YUV colorspace with 16 bit palettes arranged as Y8U4V4.

Ouch.Good luck.

[OldRover]

Okay so now this subforum needs to be changed to Turbo/PCE/PC-FX Game/Tool Development...

[OldRover]

I made an RGB to YUV conversion utility that takes a JASC-PAL 16 or 256 color palette and spits out a header file with the palette encased in an array. Hopefully I got everything right... I have not actually used it in a source file yet because I don't yet have anything to convert actual graphics with, but this is a start.

./pal2yuv.zip
http://www.obeybrew.com/pal2yuv.7z

Source code is included; built using fbc 1.05, not gcc, so it's probably out of some people's comfort zone, but it's right at home for me.

[elmer]

Since I'm not familiar with the machine, or the compiler generated code, I'll leave it  to the experts.

With these old CPUs, it's definitely a good exercise to take a look at what the compiler generates to see how good a job it's doing.

One of the big things to note about the V810 is that all loads from memory-to-registers are automatically sign-extended to 32-bit, and that all internal arithmetic is done as signed 32-bit.

So any "unsigned" C variables are likely to need another instruction to zero-extend them (usually an "and"), and that you don't get much (if any) benefit from using 8-bit or 16-bit ("char" or "short") variables.

As for the input checks...we do it all the time. It's easy enough to use a #ifdef/#endif to turn them
on/off.

Having extra checks that are only compiled in "debug" mode is definitely good practice.

But "clamping" or "wrapping" is IMHO almost never a good idea in game development.

An "assert" is a good way to cause an instant blow-up, and so to cause a programmer to see and fix a problem.

"Warning" messages just tend to be ignored until they become a more-serious problem.

Okay so now this subforum needs to be changed to Turbo/PCE/PC-FX Game/Tool Development...

Source code is included; built using fbc 1.05, not gcc, so it's probably out of some people's comfort zone, but it's right at home for me.

FreeBASIC? Wow! Well, each of us has our own comfort-zone.

I'm investigating "Go" to see if it's good replacement for "C" for tool/systems programming.

It's the first "modern" langauge that I've ever seen that actually seems well-designed and aimed at the solving the kind of problems that I've seen in my years of software development.

[Gredler]

An "assert" is a good way to cause an instant blow-up, and so to cause a programmer to see and fix a problem.

"Warning" messages just tend to be ignored until they become a more-serious problem.

From a content creation viewpoint I would certainly agree. The warnings become neglected and not addressed unless noticed during gameplay, and are almost always ignored and often referred to as red spew.

Asserrts are unavoidably required to be corrected, submitting files that are causing asserts hardly happens because during the testing phase before submission it's blatent that your changes broke the build.

[elmer]

From a content creation viewpoint I would certainly agree. The warnings become neglected and not addressed unless noticed during gameplay, and are almost always ignored and often referred to as red spew.

Hahaha! 

Color-coding the insane volume of messages that most games spit out is one of the first attempts to try to stop the "important" stuff from getting lost in all the "noise".

It never works.

There's never enough free time to fix the "small" stuff ... so it just gets sidelined with a "we'll fix it later".

That's why I like "asserts" for things like bad parameters to functions ... it causes the problem to be dealt with at a time when somebody still probably remembers why that change was made that broke things.

Asserts are unavoidably required to be corrected, submitting files that are causing asserts hardly happens because during the testing phase before submission it's blatent that your changes broke the build.

Yeah, someone repeatedly "breaking the build" is a self-correcting problem ... either the peer-pressure will cause the offender to learn better habits, or if they're too stupid to do so, they'll get fired, and the average I.Q. of the team will raise by a couple of points.

Either circumstance is a "win" for the team.


*************

Anyway ... back to the PC-FX.

On the "plus" side ... the toolchain now goes through the magical "2nd-GCC-build" stage that's needed to get newlib working properly, and I've got newlib actually linked into a test program.

That means that we've now got "stdlib", and "sprintf", and "malloc", and all those other goodies.

On the "negative" side ... calling "sprintf" crashes.

2 steps forward, 1 step back ... as usual. 

[OldRover]

All the apps in the PC-FXGA download are incompatible with Windows 7... guess I better install a VM.

[NightWolve]

Ah, yeah, Windows 7 broke my TurboRip app also because Microsoft tightened security and no longer allowed you to build a SCSI command packet for reads and pass it directly to the CD/DVD drive, you must instead use their SPTI methods for reading data/audio sectors, otherwise the packet is rejected...

All other command packets to read the CD's TOC, set the drive speed, etc. are allowed, just command packets for reads are policed. You also cannot read a MODE1 sector in raw 2352 form, only in 2048 cooked... MODE2 sectors have multiple forms, and they couldn't police raw reads there as then you couldn't detect Form 1 or 2, so they left that alone...

I suspect they pissed off a lot of developers/customers by breaking many apps having done this though which might explain why such SCSI policing was removed for Windows 8/8.1/10 and CD/DVD apps started working again, TurboRip included. But anyway, I researched the changes needed and actually got it working on Windows 7 after johnnykonami/SamIAm reported the problem to me.

[OldRover]

frozenutopia.com/mpconv2.png

After a hard-fought battle, I finally got Windows 95 installed into a VM and the PC-FXGA toolset installed... this looks like the only thing really worth using in the whole bloody package though... aside from the docs that are all in Japanese...

[SamIAm]

Ah, good old MPCONV2. How many times did it get used to encode yet another test video for Zeroigar subtitles? It must have been hundreds.

[NightWolve]

Hm, so https://www.virtualbox.org/ ?

I use Microsoft's Virtual PC 2007, but I don't recall it allowing Windows 95, lowest selection was 98 I think. I resurrected a real Windows 95 PC I bought in 1996 however, my first computer which I still have. It would be useful to get a Win95 install set up in my main workstation though for rare testing when needed assuming it works reasonably well in an emulated setting. Will check out VM Box some time.

[elmer]

I use Microsoft's Virtual PC 2007, but I don't recall it allowing Windows 95, lowest selection was 98 I think. I resurrected a real Windows 95 PC I bought in 1996 however, my first computer which I still have. It would be useful to get a Win95 install set up in my main workstation though for rare testing when needed assuming it works reasonably well in an emulated setting. Will check out VM Box some time.

IMHO Virtual PC 2007 is better than VirtualBox for a DOS/Win3/Win95 virtual machine, mostly because it emulates an older set of hardware, and it comes with "shared folder" additions for those old OS versions that IIRC VirtualBox doesn't.

If you want to run Win95 or earlier on Virtual PC 2007, just set the OS to "Other" and use the "additions" from Virtual PC 2004 (they work fine).

After a hard-fought battle, I finally got Windows 95 installed into a VM and the PC-FXGA toolset installed... this looks like the only thing really worth using in the whole bloody package though... aside from the docs that are all in Japanese...

Hahaha ... you wimped-out and didn't install the Japanese version of Windows! 

I ended-up buying a copy of Win95 OSR2.5 from Japan just so that I could run all the PC-FXGA utilities on my old PC that has the PC-FXGA card installed.

[OldRover]

Hahaha ... you wimped-out and didn't install the Japanese version of Windows! 

Nah dude, just didn't get that far... wanted to know I could even get it to work before going through such trouble.

EDIT: The program runs in Windows XP but I don't know yet how well it actually functions:

frozenutopia.com/mpconv2xp.png

[elmer]

EDIT: The program runs in Windows XP but I don't know yet how well it actually functions:

IIRC, WinXP is the last version that included a compatibility-layer for 16-bit Windows programs.

Good to know that MpConv2 runs on it.

If it runs at all, then I'd be a bit surprised if it didn't run correctly ... it's just doing graphics/sound processing, and I don't remember it having a direct connection to the PC-FXGA hardware.

EDIT:

I just checked again ... it's been a while since I looked.

MpConv2 has both Japanese and English resources (as so looks fine on an English version of Windows), but its .hlp file is all in Japanese, and looks like garbage on English Windows).

Hudson's AGE graphics editor only contains Japanese resources, and a Japanese .hlp file.

It's possible to extract/translate/reinsert both the resources and the .hlp file contents ... but it's one heck of a lot of work.

I can just-about see it being worthwhile for MpConv2, because the PC-FX video is unique, and there is no other tool available to do the conversion.

AGE, OTOH, is a pretty crappy graphics editor whose only real use is in converting BMP images into the PC-FX's bitmap and tile formats ... and these tasks are usually better performed with modern tools and modern formats (like PNG).

I did use it to convert Zeroigar's English title-screen, because it saved a bunch of time in writing an alternative ... but it's not really a good long-term solution.

[OldRover]

I have AGE (Awful Graphics Editor) almost figured out. Yeah, in the long run, it's a rather poor program, and forget about using it as a graphics editor... I think MS Paint is more useful... but as a conversion tool, it does the trick for now. I'm using Borland Resource Workshop 4.5 to edit it.

frozenutopia.com/vbageedit.png

[elmer]

Just in case  anyone out there that understands Japanese is looking at this and thinking "This is all very cool, I wish that I could help!" ... then here's your opportunity! 

SamIAm is rather snowed-under with everything that he's doing on the Xanadu  games, so I'd really rather not pester him for help on this.

Here is the documentation for mpconv2 in .rtf and .doc format.

dropbox.com/s/9pia84lwn3einla/mpconv2e.zip?dl=0

It would be really great if someone could translate the Japanese text into English (preferably without destroying the actual formatting so that it can be recompiled into a .hlp file).

There are a bunch of embedded pictures in there, but I'm not expecting anyone to get out a paint program and try to edit those (although it would be wonderful if someone did).

Is anyone willing to help?

[OldRover]

I can do replacement graphics for AGE's help file once it's translated, if that helps.