the scrolling of DOS/V 6.2

[SA1988]

While the previous patch makes it boot without hanging, the scrolling when typing dir /s or any command that makes it scroll gets messed up somehow, I've been working on for some time, but I need more info about this bug.

Note: this is not dependent on the graphics card used, it happens on all emulated graphics cards.
Edit: this happens without parameters on /HS, happens with /HS=ON and /HS=LC, but it scrolls fine without glitches with /HS=OFF.

[Battler]

Basically, the behavior is as such:
- With /HS=ON, it just starts displaying blackness when offset wraparound occurs on scrolling - result: at one point, output stops beign displayed but does scroll down;
- With /HS=LC, it just starts displaying text from the top of the screen when offset wraparound occurs on scrolling - result: at one point, output starts being drawn starting from the top of the screen when it should instead be scrolling down;
- With /HS=OFF, it works perfectly fine because software scrolling is used;
- DOS/V 5.0 and 4.x scroll fine but sometimes part of the output is list.

This article on the OS/2 Museum explains more on what DOS/V does:
http://www.os2museum.com/wp/dosv-graphi ... scrolling/ .

[SA1988]

Update:
With the S3 Trio32/64, TGUI9440, ET4000, ET4000W32P and Mach64GX, this happens while typing dir or going down with the scrolling (in the screenshot below) with /HS=ON:

PCemET4K.png (46.61 KiB) Viewed 22147 times

And it doesn't seem to happen on the S3 Virge, S3 VirgeDX, TVGA8900D and standard IBM VGA.

[SarahWalker]

The /HS=ON failures are presumably just cards that don't wrap at 256kb - it's possible there are some bugs on some cards but I'm fairly certain the ET4000s don't implement the wrapping.

[Battler]

The /HS=ON failures are presumably just cards that don't wrap at 256kb - it's possible there are some bugs on some cards but I'm fairly certain the ET4000s don't implement the wrapping.

Nope, it's /HS=LC that requires the 256 kB wrapping. But from what I know, SA1988 tested it even on your IBM VGA code and it still didn't work properly. Neither does it work properly on the TVGA 8900 or what it is, even if you put 256 kB memory.
And ET4000 certainly does implement the wrapping. Japanese drivers exist for it for Windows 3.0 (included with 3.02 Japanese) and that Windows ran on DOS/V 4.0 which does the same thing DOS/V 6.x an later do with /HS=LC - uses the 256 kB wrap. So why wouldn't it implement the wrap?

/HS=ON on the other hand uses the split screen technique (all explained in the OS/2 Museum article I linked to), which explicitly does what /HS=LC (and DOS/V 5.x and earlier) implicitly expect to happen. And it does work on some cards PCem emulates, ie. the TVGA 8900. On other it does not, even when it should. S3 Trio, for example, has Japanese Windows 3.1 drivers for it, and Japanese Windows 3.1 runs on DOS/V, so certainly DOS/V runs fine on it (they wouldn't bother writing Japanese Windows 3.1 drivers if the Japanese DOS/V the Windows requires to even install wouldn't work on the card).

But for the Trio, it's easy to fix.
In vid_s3.c, in s3_out find this: svga->vrammask = /*(val & 8) ? */s3->vram_mask/* : 0x3ffff*/; and replace with this: svga->vrammask = (val & 8) ? s3->vram_mask : 0x3ffff; ie. remove the comments. That fixes /HS=ON on the Trio.

Edit: This also fixes DOS/V 5.x and earlier on the Trio64. But DOS/V 6.2 with /HS=LC is still borked. It scrolls better now but it ends up writing stuff to the wrong part of the display memory. So in short, this fix makes all cases of DOS/V work on the emulated S3 Trio, except for DOS 6.2/V with /HS=LC set (to which for some reason DOS 6.2/V defaults on PCem - I'm going to look at how it gets supported scrolling methods).

Edit: What the... I just added: svga->split |= 0x3ff; after svga->split++; in svga_recalctimings in vid_svga.c... and /HS=LC is fixed. Renders and scrolls perfectly fine now. Though I have absolutely no idea why setting split to that fixed it.

Edit: Changed the or line to: svga->split |= 0x200;. Evidently for some reason, 3d4h index 9 bit 6 isn't being set correctly, resulting in bit 9 of the split never being set, and therefore DOS/V 6.2 with /HS=LC malfunctioning.

Edit: I just realizes... this means I was wrong, and it's /HS=ON that uses the old wrapping, while /HS=LC (which it therefore correctly defaults too) uses the split screen.

Edit: I just made PCem log a few things, and saw this in the log:
Setting crtc[7] to 2E, original value 3E
Setting crtc[9] to 00, original value 00
split: F5, crtc[0x18]: F5, crtc[7]: 3E, crtc[9]: 00
At the very point the problems usually appear. So for some reason, bit 4 of CRTC 7 gets reset to 1 after it gets specifically set to 0, and not by a port I/O from inside the guest. Which means it gets reset by the PCem code itself. Why?

Edit: Bingo!
From another source I found:
7 Disables writing to registers 0-7 if set 3d4h index 7 bit 4 is not
affected by this bit.
In CRTC 0x11. Notice, it specifically mentions 7 bit 4. So if 7 bit 4 IS affected, writing is not disabled. Yet, in PCem, it IS disabled in that case too.

I just removed my modifications in vid_svga.c, and added replace the relevant part in vid_s3.c / s3_out with:

Code: Select all

                if (svga->crtcreg <= 7 && svga->crtc[0x11] & 0x80)
		{
			if (svga-> crtcreg == 7)
			{
				if ((svga->crtc[7] & 0x10) == (val & 0x10))  return;
			} else  return;
		}

Recompiled, and voilà, DOS/V 6.2 works perfectly fine with /HS=LC or without parameters (both enter the same mode, ie. split screen)!

So the reason why the split screen wasn't working correctly, was because disabling write to registers 0-7 should NOT disable modifying bit 4 of CRTC 7 (which has bit 8 of the line compare register), yet it was disabling that in PCem, something which the code I put here fixes - notice how it if the CRTC register you're modifying is 7, it only blocks the write (with return) if new bit 4 is the same as the old one, ie. exactly how it should behave.

[SA1988]

patches from Battler in action:

https://mega.co.nz/#!xN1AAQ6J!YnZxNA0cz ... R9iVt8cDFA

[SarahWalker]

notice how it if the CRTC register you're modifying is 7, it only blocks the write (with return) if new bit 4 is the same as the old one, ie. exactly how it should behave.

Actually, it should behave more like :

Code: Select all

if (svga->crtcreg <= 7 && svga->crtc[0x11] & 0x80)
{
    if (svga-> crtcreg == 7)
        val = (svga->crtc[7] & ~0x10) | (val & 0x10);
    else
        return;
}

ie only allow bit 4 to be modified. Your change would allow the entire register to be modified when bit 4 changed.

Good spot though, my documentation completely failed to mention this...

[Battler]

- TomWalker: Don't forget to have the code ignore svga->crtc[svga->crtcreg] = val; in the case only bit 4 of CRTC 7 is allowed to be modified then.

Edit: It should look like this:

Code: Select all

                if (svga->crtcreg <= 6 && svga->crtc[0x11] & 0x80)  return;

And then:

Code: Select all

                if (svga->crtcreg == 7 && svga->crtc[0x11] & 0x80)
		{
			val = (svga->crtc[7] & ~0x10) | (val & 0x10);
		} else
                	svga->crtc[svga->crtcreg] = val;
		}

[SA1988]

complete patch (and updated to match Tom's)

https://mega.co.nz/#!YI1xyQwQ!KAcK6sPo- ... ge93nIr-r8

[SarahWalker]

- TomWalker: Don't forget to have the code ignore svga->crtc[svga->crtcreg] = val;

In which case bit 4 won't be modified at all...

[SarahWalker]

Fix committed in rev 171.

When you submit patches in future, can you _please_ remove the whitespace changes? Your patch has about 10k of actual changes and 150k of junk whitespace changes.

Also you should be able to attach patches to posts rather than using download sites...

[Battler]

Proper patch: http://citadel.ringoflightning.net/pcemdosv_patch.txt .

Edit: Seems you already did everything except for the 256k wrap in the Trio. The wrap needs to be there.

Edit: This is the patch with only the S3 Trio 256k wrap: http://citadel.ringoflightning.net/pcem ... _patch.txt .

Edit: Evidence for Trio having the wrap: http://pdos.csail.mit.edu/6.828/2012/re ... doc/S3.TXT .

To quote:

Code: Select all

       3  Use Enhanced Mode Memory Mapping (ENH MAP). Set to enable access to
           video memory above 256k.

So indeed, for all S3 cards, memory about 256k is disabled (and hence the wrap occurs) if bit 3 of CR31 Memory Configuration Register is clear.

[SarahWalker]

The S3 wraparound was deliberately disabled back in rev 9. I don't entirely remember what it broke - possible Win 3.1 drivers? The Trio32/64 datasheet doesn't seem to describe bit 3 like that though - the wording specifically states :

Bit 3 ENH MAP - Use Enhanced Mode Memory Mapping
0 = Force IBM VGA mapping for memory accesses
1 = Force Enhanced Mode mappings

Setting this bit to 1 overrides the settings of bit 6 of CR14 and bit 3 of CR17 and causes the use of doubleword memory addressing mode. Also, the function of bits 3-2 of GR6 is overridden with a fixed 64K map at A0000H.

Nothing about wraparound there. Maybe it controlled wraparound on an older S3 chip.

[Battler]

The S3 wraparound was deliberately disabled back in rev 9. I don't entirely remember what it broke - possible Win 3.1 drivers? The Trio32/64 datasheet doesn't seem to describe bit 3 like that though - the wording specifically states :

Bit 3 ENH MAP - Use Enhanced Mode Memory Mapping
0 = Force IBM VGA mapping for memory accesses
1 = Force Enhanced Mode mappings

Setting this bit to 1 overrides the settings of bit 6 of CR14 and bit 3 of CR17 and causes the use of doubleword memory addressing mode. Also, the function of bits 3-2 of GR6 is overridden with a fixed 64K map at A0000H.

Nothing about wraparound there. Maybe it controlled wraparound on an older S3 chip.

And what do you think IBM VGA mapping dows? Exactly that - limits it to 256 kB. And obviously if it's limited to 256 kB, the wraparound will occur, because obviously access to addresses above 256 kB won't be allowed if memory above 256 kB is disabled. It makes no sense to allow accessing addresses above 256 kB when they are disabled. Nowhere does it state that the wraparound shouldn't occur. In addition, both DOSBox-X and Virtual PC 2007 implement the wraparound and the Windows 3.1 drivers work correctly, as do they in my PCem with the S3 Trio wraparound reenabled.
In addition, if you look at your own S3 Virge code, it does the wrapping the exact same way. Why would the wrapping be implemented on the Virge but not in the Trio?

[SarahWalker]

As it happens, I've had a further read of the Trio64 datasheet, and the correct bit for 256kb wraparound is actually CR32 bit 6. So the rev 9 change is correct.

[Battler]

- TomWalker: I told you my logic. You didn't bother to debunk a single part of it. You just completely ignored all I said in my last post and provided another thing seemingly in the support of your position, even though it clearly doesn't prove your assertion that disabling memory above 256 kB doesn't enable the wraparound, even though it's logical it should (again, why should you be allowed to access memory addresses above 256 kB if they are disabled?). Could you please read what I'm saying?
Since the documentation says CR32 bit 6 controls the wraparound, I do not object to that. I am just saying that does that CR31 bit that disabled memory above 256 kB. If you want to convince me my interpretation is wrong, please provide me evidence for that. Simply ignoring all I say and stating I'm wrong contributes nothing to this discussion. I also listed the examples of two other pieces of software emulating the Trio with CR31 working according to how I say it should, I even proved that doing it my way makes DOS/V work correctly in wraparound mode.

and the correct bit for 256kb wraparound is actually CR32 bit 6. So the rev 9 change is correct.

This is also a non-sequitur. Because the documentation saying another bit of another regisgter controls the wraparound does not prove at all that that bit of the CR31 register doesn't disable memory above 256 kB. It also does not prove that addresses above 256 kB should remain accessible when such memory is disabled. I think that bit controls wraparound in case memory above 256 kB is enabled, and in case said memory is disabled, it's irrelevant because by virtue of said memory being disabled it is inaccessible, and therefore when an operation ends up at memory above 256 kB, it instead wraps around.
In addition, two different pieces of software, written by different people, also disagree with your interpretation. And I'm sure those at Connectix and Microsoft would have done their research in the S3 Trio when writing the emulation, as would have the DOSBox developers when writing theirs.
But well, if needed, I'm going to try to find a way to contact someone from S3 about that CR31 bit and see what they say.
Edit: I just e-mailed the S3 Contact found on their website about this. Let's hope they reply and if they do, we'll see what they say.
Edit: I just tried your CR32 bit 6 suggestion, and it doesn't work at all. So DOS/V works correctly in wrapping mode if wrapping is done by CR31 bit 3 and not if it's done by CR32 bit 6. And DOS/V doesn't talk to S3-specific CRTC's. So it boils down to what the BIOS does. Evidently the BIOS itself clears CR31 bit 3 in certain display modes. And evidently, then DOS/V works correctly wrapping mode.

[SarahWalker]

- TomWalker: I told you my logic. You didn't bother to debunk a single part of it.

Yes, because I wrote that last post very quickly first thing in the morning before I went to work. I didn't have time to write more than a one liner.

Edit: I just tried your CR32 bit 6 suggestion, and it doesn't work at all.

Funny, it seems to work fine for me, hence I just committed it. I'd guess that based on past experience, you probably failed to make the change correctly.

And as for the rest of your posting, you seem to be working under a fundamental misconception. I don't have to convince you of anything. I'm the emulator author, you have to convince me. I will be convinced by proof of your argument, which is tests on real hardware, possibly backed up with quality documentation (which S3.TXT, sourced from the PCGPE, is not).

References to questionable documentation are not proof. Saying "other emulators do it" is not proof. Discounting my own research and experience, insulting my intelligence in the process is not proof. And going on the rants you do whenever I disagree with you is frankly pretty pathetic, particularly over minor issues like this, and this is not the first time.

And while I'm a tolerant person, I see no reason to put up with your behaviour. So this is your final warning. Sort your attitude out.

[Battler]

Funny, it seems to work fine for me, hence I just committed it. I'd guess that based on past experience, you probably failed to make the change correctly.

You're right, I did end up makign the change in reverse of how it should be. However that's simply because I had no idea how it should operate, so I just reused the code that used to be used for CR31 bit 3. My bad. But your generalization of my ability to make changes correctly is out of place. I do however apologize for making my change lazily and assuming it doesn't work based on that.

And as for the rest of your posting, you seem to be working under a fundamental misconception. I don't have to convince you of anything. I'm the emulator author, you have to convince me. I will be convinced by proof of your argument, which is tests on real hardware, possibly backed up with quality documentation (which S3.TXT, sourced from the PCGPE, is not).

Well I would be glad to test things on real hardware, but I do not have it, not can I afford it. So I do all I possibly can. And I tend to go by how the majority of emulators do something. Though I do admit that in this case I was outright misinterpreting the fact those emulators did a wrap around 256k as proving my specific hypothesis correct, even when it did not. I apologize for that.
And I never stated I do not have to convince you. Of course I do. But my reasoning is, both side need to present their case with relevant evidence. Neither side should just demand that their point of view is accepted on the word. I do however admit that I often tend to defend my position too zealously, which is a bad thing, and I apologize for that.

Discounting my own research and experience, insulting my intelligence in the process is not proof.

Nowhere did I discount your own research and experience. If you notice, I accepted that your finding was indeed correct, I merely stated I believed your finding did not negate my hypothesis. I was indeed mistaken about that, and I apologize. But I certainly did not mean to discount your own research and experience, nor did Ii meant to insult your intelligence.

And going on the rants you do whenever I disagree with you is frankly pretty pathetic, particularly over minor issues like this, and this is not the first time.

And while I'm a tolerant person, I see no reason to put up with your behaviour. So this is your final warning. Sort your attitude out.

I do realize I'm a difficult person to work with, I've always been. I do tend to defend my opinions and positions too zealously, and I realize that's wrong, but habits are just difficult to change. And the fact I have OCD makes it all the more difficult. But I do know I have my issues and am trying to work on them. I again apologize for the angry tone of my previous post.

[SarahWalker]

Okay, as long as we're nice and calm and not taking these minor issues too seriously I suggest we put this behind us.

Just for the hell of it, I did some testing on a ViRGE/DX (at 640x480x8 and 1024x768x8), with some inconclusive results :
- CR31 bit 3 set, CR32 bit 6 clear - normal
- CR31 bit 3 set, CR32 bit 6 set - normal
- CR31 bit 3 clear, CR32 bit 6 clear - screwed up display at 640x480x8 (as if display offset was wrong), normal at 1024x768x8
- CR31 bit 3 clear, CR32 bit 6 set - screwed up display at 640x480x8 wrapping at 256kb, 1024x768x8 wrapping at 256kb

So it looks like for wrapping to be enabled _both_ bits have to be changed, at least on this card. Though not sure I understand the behaviour well enough to want to try to emulate it, besides I think there are more important things to work on! Also this may be different on the 864 and Trio chips, I can't test as my 864 card is broken.

[roytam1]

I have Troi64V+ real card (with 2 RAM chips only, other 2 RAM sockets has no chips)
Is is enough to test?

EDIT: I tested the card on a PC which has ASUS P4 mainboard, and I can have 640x480 4bpp in Windows PE.
JDOS 6.2: blank screen, run "cls" will return to text mode.
dspvv/dispvb/IBM $FONT.SYS: can't change to graphics mode, saying success but still in 80x25 MDA text mode.

[SarahWalker]

Trio64V+ is probably a bit too recent - IIRC it's a somewhat different core to the original Trio64 that PCem emulates.

[Battler]

I have Troi64V+ real card (with 2 RAM chips only, other 2 RAM sockets has no chips)
Is is enough to test?

EDIT: I tested the card on a PC which has ASUS P4 mainboard, and I can have 640x480 4bpp in Windows PE.
JDOS 6.2: blank screen, run "cls" will return to text mode.
dspvv/dispvb/IBM $FONT.SYS: can't change to graphics mode, saying success but still in 80x25 MDA text mode.

Did you install the font driver before the display driver? And do you have the fonts in the root directory?

[roytam1]

I have Troi64V+ real card (with 2 RAM chips only, other 2 RAM sockets has no chips)
Is is enough to test?

EDIT: I tested the card on a PC which has ASUS P4 mainboard, and I can have 640x480 4bpp in Windows PE.
JDOS 6.2: blank screen, run "cls" will return to text mode.
dspvv/dispvb/IBM $FONT.SYS: can't change to graphics mode, saying success but still in 80x25 MDA text mode.

Did you install the font driver before the display driver? And do you have the fonts in the root directory?

of course. I think they don't like the card.

[Battler]

I have Troi64V+ real card (with 2 RAM chips only, other 2 RAM sockets has no chips)
Is is enough to test?

EDIT: I tested the card on a PC which has ASUS P4 mainboard, and I can have 640x480 4bpp in Windows PE.
JDOS 6.2: blank screen, run "cls" will return to text mode.
dspvv/dispvb/IBM $FONT.SYS: can't change to graphics mode, saying success but still in 80x25 MDA text mode.

Did you install the font driver before the display driver? And do you have the fonts in the root directory?

of course. I think they don't like the card.

Did you set country to 081 (Japan) and code page to 932 before installing the drivers? From what I know, JDISP.SYS of DOS/V 6.2 will behave exactly like you described if the code page is not 932.
Bascially, before loading any Japanese drivers, make sure you have COUNTRY=081,932,C:\DOS\COUNTRY.SYS or well whatever path COUNTRY.SYS is in, if you don't have it in C:\DOS.