Fix for Windows home directory with spaces and fixes also issue #207

[ruben-balea]

Update wx-utils.cc Fix for Windows home directory with spaces

Update vid_unk_ramdac.c Fixes ET4000AX (kasan16) hang in win95 in 16/24 bit modes https://github.com/sarah-walker-pcem/pcem/issues/207

It's just a copy of: https://github.com/86Box/86Box/blob/291ac890e2cfa355b81fe1d78697541172d6bbc1/src/vid_unk_ramdac.c

In 86box they later renamed it to vid_sc1502x_ramdac.c which makes sense knowing exactly what ramdac it is.

[eddmanx]

I'm not familiar with that card and don't know enough about coding to know what this fix is, but if this issue actually exists on real cards with certain BIOS, it shouldn't be fixed on PCem either.

If that's the case, then the correct solution would be to use a fixed BIOS.

[ruben-balea]

I'm not familiar with that card and don't know enough about coding to know what this fix is, but if this issue actually exists on real cards with certain BIOS, it shouldn't be fixed on PCem either.

If that's the case, then the correct solution would be to use a fixed BIOS.

Of course all real ET4000AX cards worked fine with their own original BIOSes, the graphics chip was the same and the memory 1MB in most cases, it seems a few models were sold with only 512KB but probably had sockets for the remaining 512KB. What changed was the RAMDAC, there were a few of them, from 8bpp to 24bpp, and some supported 15bpp but not 16 bpp an the like. PCem when using the wrong BIOS is like switching BIOS chips between cards with different features, most likely it won't work too well.

In the original code the RAMDAC was unknown, it's pretty hard to emulate correctly some random hardware:

/*It is unknown exactly what RAMDAC this is
  It is possibly a Sierra 1502x   It is possibly a Sierra 1502x
  It's addressed by the TLIVESA1 driver for ET4000*/

The fixed code was writtten for a specific RAMDAC: /* Note by Tenshi: Not possibly, this *IS* a Sierra 1502x. */

It works with Tseng 8.x BIOSes everybody seems to be using and it's actually a piece of PCem code with some corrections done, if you look at the Github history the 86Box 'vid_unk_ramdac.c' a month before was the exact same file that PCem still has right now, then the problems were fixed but only for 86Box, the changes were never committed to PCem because 86Box was already a different project.

It might seem strange* to some people to reuse 86Box code in PCem but I don't care in the slightest, both projects originally shared the same code, even though now each project has slightly different goals there's no reason to reinvent the wheel.

*Even wrong, but reusing GPL'd code on other GPL'd project is not stealing as long as you credit the original author(s)

[eddmanx]

I don't care where the code comes from. I was simply wondering maybe the actual BIOS of this Kasan card has issues and hangs on real hardware too. In that case PCem's code shouldn't be altered.

Sarah left hardware and BIOS related bugs intact to emulate their problems too. :))

However, if this issue only happens on PCem and not real hardware, then it's fine. It's good to see PRs being submitted.

I don't know if these matter, but here's the original patch submission:

https://pcem-emulator.co.uk/phpBB3/viewtopic.php?t=3487 http://pcem-emulator.co.uk/phpBB3/viewtopic.php?p=13515#p13515

[ruben-balea]

I was not insinuating that you were one of those concerned about the origin of the code, here it may go unnoticed but if it were in the official forum surely some member would complain, I have seen similar comments on other occasions in all these years.

The problem was not with the Kasan, it was with the generic ET4000AX, I have no idea what color depth the Kasan should support, I've never even seen one in a photo :-) I never used it on PCem either...

The OP first chose by mistake a Kasan isntead of the generic ET4000AX, then he switched to the generic ET4000AX and that's when he found the problem with 640x480x24bpp mode.

[michael-manley]

I personally don't see the harm in using 86Box code here, I mean you will have to adapt it to work as they are vastly different now, and will continue to diverge as we progress with modernizing the codebase.

I know the dev there had issues with the original dev here, which is a shame but doesn't mean I won't accept code from a project due to personal differences. GPL allows this and as much as I'm not a huge fan of GPL (I use Apache License on most of my projects) it's one of the perks lol.

[ruben-balea]

Yes, adapting the current code is probably beyond my skills and/or patience, for that reason I went back to the Github history to find the time when that problem had been fixed and apparently it was only a month after the creation of the 86Box project so it was still pretty much the same.

And on the other issue, the problems that I saw between the two developers were simply of the type I prefer to do it one way and you the other, the solution they took of continuing each one with their own project was the most logical to be able to adapt it to the project of each to their preferences. But in the PCem forums I never noticed problems between them, just as I say different opinions, different priorities, etc. But that's normal, the only thing that would bother me would be if they disrespected each other with expressions like "your code sucks", "learn to program" and things like that. Shortly after registering on the forum, I myself experienced one of those attacks by a forum user who, as far as I know, only entered from time to time to give opinions and criticize others but never did anything to improve PCem... the typical know-it-all who likes to stick his nose where he's not called ;-) but I answered him politely and I think he wasn't expect that because I never heard from him again LOL