Tim Wegner wrote:

Jonathan wrote:

...

It turns out the problem I'm seeing with the <t> screen is caused > by the patch I put in to fix your text screen problem with the virtual screens. I'll see if I can find a way around it.

I've had something on every evening so far so I haven't looked at the executable you asked me to try. Let me know if you still want me to. I can do it Saturday.

Take a look at it now. The fix I was trying to use to solve your text screen problem causes too many other problems. So, if it still occurs I'll need more specific information about when. And a lot of clues... Jonathan

Tim Wegner wrote:

Looks like my symptoms may not have anything to do with the virtual screens.

1. Start fractint 2. press <del> 3. Select 640x480 SVGA mode (SF5) Default Mandelbrot generates OK 4. Press ESC.

The text screen is garbled, looks like this: reverse thru history <ctl-h> quit FRACTINT <esc> OPTIONS restart FRACTINT <ins> basic options... <x> COLORS extended options... <y> color cycling mode <c> type-specific parms... <z> rotate palette <+>, <-> view window options... <v> palette editing mode <e> browse parms... <ctl-b> make starfield <a> evolver parms... <ctl-e> ant automaton <ctl-a> sound parms... <ctl-f> stereogram <ctl-s>

Use the cursor keys to highlight your selection Press ENTER for highlighted choice, or F1 for help

With some garbage below. Notice that the top of the text screen does not show.

Try it now. I still can't reproduce your problem, but I did fix something that could have been causing it. Jonathan

...

Try it now. I still can't reproduce your problem, but I did fix something that could have been causing it.

Same behavior. I'll see if I can debug where the problem is. Looks as though the address where the text is written is too low.

Tim

i've formerly encountered the same thing when switching back to the text screen from an already scrolled graphic one therefore i've put in a "scroll-home" (0,0) to the un/stackscreen() (that one that stacks the screen to allow switching between gr/txt) - is it still there?? but generating an image the way you described should not invoke any scrolling so far.. (although it looks so..) . . there is another problem, but not so serious: having a virtual resolution "hardcoded" in the fractint.cfg and selecting it at the <del> screen messes up the ascpect ratio.. it's caused by the effort to display squares really square (1:1) some kind of a 320x200 against 320x240 correction.. but it's dimmed by the rotated corners, so i've failed to fix it up for now charlie ______________________________________________________________________ Reklama: Aktualni zpravy z domova i ze zahranici, krimi, kultura, sport, zpravy ze spolecnosti, vztahy a sex, horoskop a televizni program http:\\www.novinky.cz

Tim Wegner wrote:

Same behavior. I'll see if I can debug where the problem is. Looks as though the address where the text is written is too low.

Try commenting out the call to VESAvirtscan in video.asm. That will defeat the virtual screen detection. Jonathan

Unless you have objections, I will add a new startup parameter:

virtual=yes

I think that's a good idea. Can they also turn that on interactively? Tim

Tim, Try it now. Jonathan

Tim Wegner wrote:

ESC from a fractal in the 640x480 mode works, but ESC from the <X> screen (and some other screens) gives a screen full of blue happy faces. Another escape gives the main menu.

Is this with or without using virtual=y? I'll assume it was without, and take a look at the stack and unstack routines. We made small changes to them that might be causing the problem.

I'll look into this some more. Re your other email, I also have mandrake 9.0, I'll look into compiling Xfractint. What were the problems you had? Which exact sources were you compiling?

I'm using my working source (version 20.2 patch 4.5, roughly). The variable names cimag and creal are now used for built-in functions. Jonathan

Tim,

Every time we do a video switch, the contents of the VESA buffer can change. Therefore, we need to save the vesa_xres and vesa_yres values elsewhere while we are in a text mode. I'll try it.

I didn't. I had actually done that sometime over the holidays and it didn't work. I did rearrange the logic a little, so try it now. Jonathan

Tim Wegner wrote:

Good news is that the SVGA modes work without problems, recent bad symptoms are gone.

That was what I wanted.

Bad news is that with virtual=yes, the text screens get messed up. I'll try to give you more details later, but basically, start with virtual=yes, goto a virtual mode, generate a fractal, and go back to a text screen.

Occurs to me that I have a houseful of computers, I'll try some of the other ones.

I wonder if stack is running out? Some VESA bioses use more stack than others. (cheking ...) debug=1000 shows 8444 stack bytes free at startup.

The switch between graphics modes changes the contents in the VESA buffer area we are using. If you take a look at the bottom of the <v> screen (with virtual=y) you will probably see that the resolution of the screen corresponds to a text mode. I can fix this by saving the x and y values to different variables and then using them. But, it breaks other things. The switch to the <t> screen, for instance. Jonathan

...

Occurs to me that I have a houseful of computers, I'll try some of the other ones.

Any results?

Thanks for the reminder. Just got back from Austin for my second marathon in four weeks, not to mention visiting my daughter. I put some Houston marathon pictures at http://tim.fractint.org (a.k.a. http://twegner.dynodns.org) in case anyone wants to see what a very slow, aging, non-athlete looks like while running :-) I'll run your latest executable on several machines: HP Pavilion 9680C (my current main machine) Win 98SE Dell Optiplex (Win 98SE) Compaq laptop (Windows XP) Sony laptop (Windows ME) Then there's my old no-name computer that used to be my main computer - Win 95. That's a pretty good collection with different video capabilities. Let me know if there is anything special to check out. Last time I tried, if I recall, the virtual mode had problems, but the regular moides were OK. Tim

On Monday 17 February 2003 07:32 pm, Tim Wegner wrote:

Just got back from Austin for my second marathon in four weeks, not to mention visiting my daughter. I put some Houston marathon pictures at http://tim.fractint.org (a.k.a. http://twegner.dynodns.org) in case anyone wants to see what a very slow, aging, non-athlete looks like while running :-)

Good for you!

Let me know if there is anything special to check out. Last time I tried, if I recall, the virtual mode had problems, but the regular modes were OK.

The <v> screen will tell you if the data in our VESA buffer is being changed by the switch to text mode. This confuses things if it doesn't get switched back when going back to graphics. Look at the <tab> screen also, for the resolution. Try it from a text mode to see if it changes. Jonathan

On Tuesday 18 February 2003 03:58 am, Charlie Chernohorsky wrote:

and what if there is a problem with VESA bios destroying the BP reg.?

looking at the other video routines, BP is often saved there before INT 10h call because of safety reasons..

this would result in some variables having "changed" their values.. (caused by the wrong BP-based addressing..)

I'll take a look. The problems I've seen are caused by sxdots and sydots getting changed in the switch between text and graphics modes. Jonathan