SVGA Point routine issue

[Jark]

(For Antoni: your Pset and Point routines are magic! But for that "Point issue"....)

When working in SVGA modes, the memory address is made of 1) a bank number, 2) an offset. Switching bank being very slow, the Pset and Point routines usually store the Current Bank in either a shared parameter, either a static parameter called CurBank.

This principle is the same for the "Pset" and "Point" routines.

Well, this used to work fine until I got my new machine (Compaq EvoN1050v): on this machine, saving CurBank is OK for the Pset, but I have to reassign the bank each time I call an SVGA Point. That means I just "comment" the Bank = CurBank test in the routine:

Code:

'IF Bank& <> CurBank THEN
CurBank = Bank&
Regs.ax = &H4F05
Regs.bx = 0
Regs.dx = CurBank
CALL INTERRUPT(&H10, Regs, Regs)
'END IF
Blue% = PEEK(Offset&)

If I don't do so : the progs work most of the time, and the machine gets blocked "some other times". When I say blocked, I mean blocked...

Never had this problem on other machines!

[Antoni Gual]

Maybe you computer has two overlaping SVGA windows defined , in this case you must define two Curbanks and call bank change
with BL=0 for A window and BL=1 for B window.

I suddenly realized that nothing prohibits the two windows are defined in the same segment address....This would work with my routines half of the times, but would fail if Point24 needs to work
in a different bank than the last Pset24.

If my hunch is correct it will be a proof of how loose is the VESA standard.. Creative developers will ever surprise us...

I will write something you can try tonight..

[Antoni Gual]

Maybe you computer has two overlaping SVGA windows defined, one write-only window A and one read-only window B.In this case you must define two Curbanks and call bank switcher with BL=0 for A window and BL=1 for B window.

I suddenly realized that nothing prohibits the two windows are defined in the same segment address....This would work with my routines half of the times, but would fail if Point24 needs to work
in a different bank than the last Pset24.

If my hunch is correct it will be a proof of how loose is the VESA standard.. Creative developers will ever surprise us...

I will write something you can try tonight..

[Jark]

I had tested both possibilities during lunch (in a horrible pizzeria, and a terrible heat here : between 35 and 40 degrees everyday, it's really tough!).

I have tested the progs with two separate CurBank1 and CurBank2, and also bx=0 in Pset24 and bx=1 in Point24.

These two modifications did not help...

I checked the two parameters ASC(WinAAttributes) and ASC(WinBAttributes) to get them numeric. I got "7" and "0", which means that Window A is read and write, and that B is not supported. Though, bx=1 works in Point24 !

I hope you can understand something with that weird card...

[Antoni Gual]

Ok, you thought about this and tested it. So Wrong way... I will not code anything tonight...

We should put up a museum of weird VESA implementations. Nathan and Rel could contribute with their cards. And you should contribute with all your PC's

[Antoni Gual]

Jark:
Just a guess..
Try to run the program without ffix enabled. FFIX masks math errors that will propagate thru the program and make it fail in unexpected places.

[Jark]

I just tried your suggestion: the problem is the same with and without Ffix

[Jark]

The program stores, in a shared parameter called CurBank, the number of the assigned bank each time the function &H4F05 is called via the interruption &H10.

For a strange reason, when the "point" routine is called, from time to time, the bank is not assigned any longer, and that causes the machine to block. A manner to avoid this problem is to re-assign the video bank to CurBank at the beginning of the Point routine, even if it doesn't seem necessary.

The question is : what causes the bank to be de-assigned when calling several times Point24, during a plain screen loop for example...

The only safe solution would be to find a function that would provide the REAL current bank, instead of storing the theoretical calculated value which doesn't always match the physical value. Is there such a function, that would return the actual current bank?????