v_opnvwk() / v_opnwk shouldn't use Getrez() + 2

[mikrosk]

Nice explanation by Johan Klockars: http://www.fultonsoft.com/revisiting-gem-for-the-atari-st-part-1/comment-page-1/#comment-11 (at the bottom).

When using 2 + Getrez() as recommended in toshyp on Falcon's 640x480x8 for example, VDI thinks it is 640x400x1, i.e. totally wrong.

[pulsar122]

You mean that 2 + Getrez() is wrong?

Mike Fulton wrote me:

For the v_opnwk() and v_opnvwk() functions, the correct input for work_in[0] is always the value of Getrez() + 2.

The idea of a value of 1 meaning the current resolution is not correct. The source of this idea seems to be the common reference to device 1 in the ASSIGN.SYS file being commented as “default screen” in many examples, but that was never intended to mean “current resolution”.

At least not on the Atari. Maybe on PC.

This mistake is easily overlooked because in most cases there is no consequence to doing it wrong. That’s largely because the device code is actually ignored by the ROM implementation of VDI.

However, if you are loading GDOS, it can cause problems with loading the correct fonts, and it can cause problems with the correct driver not being used when a non-standard display is used.

This was constantly a pain in my behind back in the day. Pretty much whenever a program didn’t work right with the TT030 or Falcon030’s newer video modes, or when it didn’t work right with an add-on display of some sort, it tracked back to this as often as not.

I know of at least one company that created a patch program to go along with their add-on display that grabbed the GEM trap, looked for open-workstation calls, and changed references to device 1.

[mikrosk]

@pulsar122 that's why I linked the comment of the fVDI author, stating otherwise.

And I have a personal experience with that too - in 640x480x8bpl Getrez() + 2 leads VDI to believe that it is 640x400x1bpl what was requested, allocating physical workstation only for 1/8th of memory needed. Supplying '1' as the parameter fixes it.

NVDI fixes the Getrez() call but still, it's wrong.

[th-otto]

On Donnerstag, 18. Oktober 2018 19:42:22 CEST pulsar122 wrote:

That’s largely because the device code is actually ignored by the ROM implementation of VDI.

The problem is, that this is not true anymore. The VDI of TOS 4.04 at least does honor the device ID. And it also interprets device id 1 as synonym for "current resolution". So imho using 1 is the correct thing to do, Getrez() +2
has absolute no meaning for device drivers of video cards, where you can have almost any resolution in steps of 16.

[mikrosk]

As I'm constantly forgetting about this: https://github.com/freemint/freemint/issues/102#issuecomment-432100301 ... fVDI in 256c crashes regardless of the work_in[0] value. So one can't test this kind of VDI stuff in the console when using 8-bit colour depth.

[mikrosk]

I see https://freemint.github.io/tos.hyp/en/vdi_control.html#v_opnvwk still recommends Getrez() +2, should we changed it to 1 (and maybe mention the fVDI bug) ?

[mikrosk]

Actually The Compendium differentiate between v_opnvwk and v_opnwk which confirms Mike Fulton's words but also doesn't rule out our findings.

v_opnvwk: [...] _workin[0]: Device identification number. This indicates the physical device ID of the device (the line number of the driver in ASSIGN.SYS when using GDOS). For screen devices you should normally use the value of 1.

v_opnwk: [...] _For screen devices you should normally use the value Getrez() + 2 for the workin[0] field, however, a value of 1 is acceptable if not using any loaded fonts.

I think tos.hyp should say something similar.