No need to look at the source code - it's obvious just from the screenshot. Paku Paku uses 80-column text mode with the character height reduced in order to get a 160x100 16 colour "graphics" mode even on CGA (quite a few CGA-era games did the same thing). Virtual PC obviously doesn't support that mode.

reenigne wrote:

No need to look at the source code - it's obvious just from the screenshot. Paku Paku uses 80-column text mode with the character height reduced in order to get a 160x100 16 colour "graphics" mode even on CGA (quite a few CGA-era games did the same thing). Virtual PC obviously doesn't support that mode.

That's what I've been thinking all along. The 160x100 16 colour graphics mode is undocumented and if it was recompiled in 320x200 16 EGA colour graphics mode with the source, it would take a lot of work to get it to work correctly.

The game actually auto-detects the video hardware (supported: CGA, PCJr, Tandy 1000, Tandy TL/SL, EGA, VGA, MCGA) and sets up the tweaked text mode accordingly. Loading a custom video BIOS - where applicable - may fix things.
The 160x100 16 color 'graphics' mode is very much documented, just perhaps not in 'official' sources. (Recompiling in 320x200 EGA graphics mode? Am I missing something?)

VileRancour wrote:

The game actually auto-detects the video hardware (supported: CGA, PCJr, Tandy 1000, Tandy TL/SL, EGA, VGA, MCGA) and sets up the tweaked text mode accordingly. Loading a custom video BIOS - where applicable - may fix things.
The 160x100 16 color 'graphics' mode is very much documented, just perhaps not in 'official' sources. (Recompiling in 320x200 EGA graphics mode? Am I missing something?)

Is there a custom video driver that will allow Virtual PC to detect 160x100 16 colour graphics?

If you download Paku Paku, the game is compiled using Pascal and Assembler. The source code can be found in the \SOURCE directory where all of the *.PAS files are located.

ppgrainbow wrote:

Is there a custom video driver that will allow Virtual PC to detect 160x100 16 colour graphics?

Well, I'm assuming that the problem lies in Virtual PC's VGA BIOS missing some compatibility features, which may cause one of two things:
1) It doesn't respond as expected to Paku Paku's video detection routine, so the game won't detect a VGA and won't set the proper registers, or
2) It does get detected as VGA, but the correct register behavior isn't fully emulated.

#2 sounds more likely, but this could be verified if you patch the game code to skip the detection and just assume VGA. In either case, the only likely solution would be to patch VPC's VGA BIOS and fix the compatibility issues - or to just replace it with a different BIOS dumped from a real VGA, but I haven't used VPC in ages so I couldn't tell you if that's even possible.

If you download Paku Paku, the game is compiled using Pascal and Assembler. The source code can be found in the \SOURCE directory where all of the *.PAS files are located.

Yep, I had looked at the source quite a bit some time ago (that video detection routine was particularly interesting to me, which is why I remembered that detail). I just don't get the concept of rewriting it for a different video mode, since it already works quite beautifully both on real hardware and in proper emulators... the effort would be better spent on fixing the broken emulators instead. 😁

VileRancour wrote:

Well, I'm assuming that the problem lies in Virtual PC's VGA BIOS missing some compatibility features, which may cause one of tw […]
Show full quote

Well, I'm assuming that the problem lies in Virtual PC's VGA BIOS missing some compatibility features, which may cause one of two things:
1) It doesn't respond as expected to Paku Paku's video detection routine, so the game won't detect a VGA and won't set the proper registers, or
2) It does get detected as VGA, but the correct register behavior isn't fully emulated.

#2 sounds more likely, but this could be verified if you patch the game code to skip the detection and just assume VGA. In either case, the only likely solution would be to patch VPC's VGA BIOS and fix the compatibility issues - or to just replace it with a different BIOS dumped from a real VGA, but I haven't used VPC in ages so I couldn't tell you if that's even possible.

Yep, I had looked at the source quite a bit some time ago (that video detection routine was particularly interesting to me, which is why I remembered that detail). I just don't get the concept of rewriting it for a different video mode, since it already works quite beautifully both on real hardware and in proper emulators... the effort would be better spent on fixing the broken emulators instead. 😁

Using the /safe switch to not reprogramme CRTC on EGA/VGA cards had no affect. Virtual PC doesn't seem to emulate the correct register behaviour which is why Paku Paku will not run correctly. VPC's emulation is not 100% perfect. I mean, it can at least work if it is run in DOSBox under at least Windows 95 with Mouse Pointer Integration disabled.

Good evening, everyone.
I tested Paku Paku on the earliest version of Virtual PC I have got (v3.0).
The results are the same as from ppgrainbow and I also tried the /safe switch.

Jo22 wrote:

Good evening, everyone. I tested Paku Paku on the earliest version of Virtual PC I have got (v3.0). The results are the same as […]
Show full quote

Good evening, everyone.
I tested Paku Paku on the earliest version of Virtual PC I have got (v3.0).
The results are the same as from ppgrainbow and I also tried the /safe switch.

pakupaku_vpc3.png

It looks like VPC has problems with 160 x 100 graphics which has problems with certain games such as Paku Paku.

For now, running it in a unmodified version of DOSBox 0.74 under at least Windows 95 should fix this.

Okay, understood. I just wanted to give you some feedback. 😀
Bye the way, the last version of the Virtual PC emulator still had this issue (see pic).
So it seems this was never fixed. SoftWindows also suffered from similar problems, albeit much worse (garbled screen).

Jo22 wrote:

Okay, understood. I just wanted to give you some feedback. 😀
Bye the way, the last version of the Virtual PC emulator still had this issue (see pic).
So it seems this was never fixed. SoftWindows also suffered from similar problems, albeit much worse (garbled screen).

With the author being really busy IRL, I doubt that the half-screen issue in VPC or SoftWindows will not be addressed. 🙁

ppgrainbow wrote:

Jo22 wrote:

Okay, understood. I just wanted to give you some feedback. 😀
Bye the way, the last version of the Virtual PC emulator still had this issue (see pic).
So it seems this was never fixed. SoftWindows also suffered from similar problems, albeit much worse (garbled screen).

With the author being really busy IRL, I doubt that the half-screen issue in VPC or SoftWindows will not be addressed. 🙁

Oh, sorry to hear. 🙁 I tried to find a workaround for this, but doing so isn't that easy for me.

At first I tried to build Paku Paku with my dads Turbo Pascal 6.01, but it wouldn't even compile.
Looking at jfunc.pas, I realised that it had higher requirements than I thought (I assumed even TP 3.x would be fine, consideriung the amount of asm code)..
Alas, Paku needs at least fancy Pascal 7.x to compile that darned TPU. Which is quite pricey nowerdays, by the way (collectors item ?).

Anyway, I managed to compile the game later on and it did also run just fine in DOSBox.
However, any modifications to the code had almost no effect in Virtual PC.
You know, things like enabling/disabling line doubling, changing the character's height and so on.
I tried to apply these changes to both the CRTC directly and via Video BIOS, but without any success
(Perhaps I did some mistakes here. I'm aware that some registers are write-proteced by default).

Even more, I bypassed the auto detection routine and forced EGA and CGA modes, which worked, but changed very little :
In CGA mode, the screen would not stop blinking (apparently VGA handles blinking differently).
Other effects were not visible, but maybe they were there. I hoped I could at least break something in a spectacular way. 😁

So all in all, I believe VPC's VGA implementation is really just missing certain features which Paku Paku needs.
Maybe this issue can somehow be circumvented by using S3 specific registers, I don't know.
Or by running PCem/DOSBox inside of it, haha. 😀

Another approach would be to modify Virtual PC itself or its VGA Font/BIOS in RAM.
Understandably, this requires someone with a better understanding of this matter.

Jo22 wrote:

Oh, sorry to hear. :( I tried to find a workaround for this, but doing so isn't that easy for me. […]
Show full quote

ppgrainbow wrote:

Jo22 wrote:

Okay, understood. I just wanted to give you some feedback. 😀
Bye the way, the last version of the Virtual PC emulator still had this issue (see pic).
So it seems this was never fixed. SoftWindows also suffered from similar problems, albeit much worse (garbled screen).

With the author being really busy IRL, I doubt that the half-screen issue in VPC or SoftWindows will not be addressed. 🙁

Oh, sorry to hear. 🙁 I tried to find a workaround for this, but doing so isn't that easy for me.

At first I tried to build Paku Paku with my dads Turbo Pascal 6.01, but it wouldn't even compile.
Looking at jfunc.pas, I realised that it had higher requirements than I thought (I assumed even TP 3.x would be fine, consideriung the amount of asm code)..
Alas, Paku needs at least fancy Pascal 7.x to compile that darned TPU. Which is quite pricey nowerdays, by the way (collectors item ?).

Anyway, I managed to compile the game later on and it did also run just fine in DOSBox.
However, any modifications to the code had almost no effect in Virtual PC.
You know, things like enabling/disabling line doubling, changing the character's height and so on.
I tried to apply these changes to both the CRTC directly and via Video BIOS, but without any success
(Perhaps I did some mistakes here. I'm aware that some registers are write-proteced by default).

Even more, I bypassed the auto detection routine and forced EGA and CGA modes, which worked, but changed very little :
In CGA mode, the screen would not stop blinking (apparently VGA handles blinking differently).
Other effects were not visible, but maybe they were there. I hoped I could at least break something in a spectacular way. 😁

So all in all, I believe VPC's VGA implementation is really just missing certain features which Paku Paku needs.
Maybe this issue can somehow be circumvented by using S3 specific registers, I don't know.
Or by running PCem/DOSBox inside of it, haha. 😀

Another approach would be to modify Virtual PC itself or its VGA Font/BIOS in RAM.
Understandably, this requires someone with a better understanding of this matter.

Something is amiss when it comes to running Paku Paku inside Virtual PC 2004/2007.

I bet that it would take a lot of hard work to use S3 Trio specific registers. Is it possible to try to modify Virtual PC 2007 using a hex editor or modifying the VGA Font/BIOS in RAM?

If so, how can it be done?

ppgrainbow wrote:

I bet that it would take a lot of hard work to use S3 Trio specific registers.

There are no S3 Trio specific registers for this. There are VGA ones, which will work correctly on a real S3 Trio. The problem is that Virtual PC does not implement them correctly.

ppgrainbow wrote:

Is it possible to try to modify Virtual PC 2007 using a hex editor or modifying the VGA Font/BIOS in RAM?

Modifying the VGA font or BIOS wouldn't help because neither of these are the problem. Modifying VPC's VGA emulation to fix this is intractable without access to its source code. I don't expect that sending a bug report to Microsoft will get you very far either. Just use an emulator (like DOSBox) which is designed to cope with the kind of hardware tricks that DOS games play.

According to the ViRGE doc, there are Extended CRTC registers..
No idea if they can be found on the earlier Trio, aswell or whether they are even useful for this purpose or not.
I only read that some of them handle things like logical screen size, memory mapping, hw cursors and so on.
So I mentioned this for completeness. It's unlikely that VPC fully emulates all of these things, anyway.

Edit: I've just tested Paku Paku on original PCE and got the same results,
while the later released multi-system PCE works just fine with it (coincidence or the work of a Paku Paku fan ? 😉 ).

I'm afraid there are at least a dozen emulators which don't support the way how Paku Paku works.
So we really can't blame Virtual PC for this. Even more, VPC originated on the Mac platform,
which was entirely GUI driven and cared very little about text mode.

reenigne wrote:

There are no S3 Trio specific registers for this. There are VGA ones, which will work correctly on a real S3 Trio. The problem is that Virtual PC does not implement them correctly.

I can't blame Microsoft for not implementing VGA specific registers correctly on the emulated S3 Trio.

Virtual PC is a product that is no longer updated and that it will not even run at all under Windows 10. It obviously won't be too much longer when Microsoft drops Virtual PC 2007 support when Windows Vista goes out of support next Spring and Windows Virtual PC when Windows 7 goes out of support in early 2020.

Emulators like DOSBox and PCem have the capability to to cope certain hardware tricks that DOS games are designed to play. VMware Player and VirtualBox as well as several other emulators don't support the way how Paku Paku operates its 160 x 100 graphics, although they have not be tested at this time.