On Monday 03 March 2003 05:31 am, Charlie Chernohorsky wrote:
that jumps you've suggested to Tim at VESAvirtscan, the destination "(4) here" should be at "bad_vesa", otherwise it would do.. nothing at all, beacuse if
(4) here + cmp sxdots,cx ; max width in pixels in cx + jae alreadyset ; can't set more + bad_vesa:
then sxdots always equals to cx when skipping the parts above, this cmp is related to the last VESA call, so it should be skipped also like:
+ cmp sxdots,cx ; max width in pixels in cx + jae alreadyset ; can't set more (4) here + bad_vesa:
Since it is just for testing purposes, it makes no difference. We just need to see if one of these bios calls is causing the problems.
while looking at the experimental patch 5 diff file:
at loadfdos.c, at restoring images, the function which resizes dotmode==28 entries (well, to be honest, i've forgotten its name) - it should also be disabled when virtual=no, like:
+ /* try to change any VESA entries to fit the loaded image size */ + if (virtual && video_vram && initmode == -1) {
I'll fix it. Thanks.
then, i've found a mistake at prompts2.c / getviewparams(): instead of:
+ if truebytes==4 (32 bit) it does &= ..FFFE (&= -2) if (truebytes < 2) + */ + ++truebytes;
it should be:
+ if truebytes==4 (32 bit) it does &= ..FFFE (&= -2) + */ + if (truebytes < 2) + ++truebytes;
(i guess it was caused by inserting that truebytes explanation) nothing serious, it just miss-estimates..
I can increase the number of lines that diff catches on either side of changes. This will increase the diff file size, but the problem should go away.
finally, using view-window for smaller-than-screen request is ok, but why do you turn off view-window for greater-than-screen? do you think it would have no use then?
( ! if (sxdots < vesa_xres && sydots < vesa_yres) { ! viewwindow = 1; ! viewxdots = sxdots; ! viewydots = sydots; ! sxdots = vesa_xres; ! sydots = vesa_yres; ! } else { ! viewwindow = 0; /* make sure it is off */ ! viewxdots = 0; ! viewydots = 0; ! } )
There are problems which occur when the two are used at the same time. For example, using orbits doesn't work quite right (in terms of where they appear). There may be other problems, as well. It is true that if all you are doing is drawing an image, it works fine. At this point, I'd rather it was turned off so that we don't get complaints about it not working right.
VESAvirtscan once more: that "mov ax,2" is strange! (so is "mov ax,1" fifteen lines above..)
the scroll test should scroll the screen to the [cd; dx] not to the ax.. ax just indicates top-left corner here..
+ noretrace: + ;; xor ax,ax + mov ax,2 ; try to move a tad + mov wait_retrace,0 ; don't wait for v. retrace + mov video_startx,ax ; video didn't scroll yet + mov video_starty,ax + call VESAscroll ; try the instant scrolling + cmp ax,004fh ; did this scroll? + je wedone
it is also non-serious, but i see no use of it..?
Yes, indeed! That is strange. But, it is there because of how VESAscroll is coded. If you pass (Xc/2-1,Yc/2-1) (screen center offset divided by 2 then subtract 1) in cx and dx, then subtracting the screen center offset from them returns a negative number. The code then sets cx and dx to (0,0). Then we compare them to video_startx and video_starty, which we set in VESAvirtscan to (0,0). But, since we have zeroes all around, we bail out without calling the bios move screen routine. Not too big a deal, except we are using the return from the bios call to determine success. Since we haven't made the bios call, ax still contains 0, and we fail the test. Therefore, I added a small nudge (which doesn't happen anyway because it is too small) to force the bios call to occur. Let me know if you need more detail. Jonathan