Getrez() + 2 is an unreliable way how to detect resolution

[mikrosk]

As discussed in our email conversation, there are at least two scenarios where I got vdi_vd.ttp crash in Falcon's 640x480@256c:

• if not using NVDI without AES (i.e. AUTO folder or FreeMiNT console), work_in[0] = Getrez() + 2 doesn't really work on Falcon. Getrez() produces a wrong number, leading VDI to believe that 640x480x8 is 640x400x1 in fact (in its work_out fields).
• if using NVDI without AES, you can't really write into the screen address. For some reason it seems the screen buffer is smaller than the actual resolution (perhaps related to off-screen bitmaps?). Try to boot into FreeMiNT console and run your vdi_vd.ttp - it will crash, badly (at least in 640x480x8)

In both cases, replacing work_in[0] = Getrez() + 2; with work_in[0] = 1; fixes the issue.

[mikrosk]

See also freemint/tos.hyp#89

[pmandin]

Hello,

I just read about this insane story on https://web.archive.org/web/20190531112355/http://www.fultonsoft.com/revisiting-gem-for-the-atari-st-part-1/
If I understand correctly, developpers never followed the doc, and use 1 as value for openwk(), instead of Getrez()+2 like the doc says?

I just have a question in this case, is it only for the Falcon, or all Atari machines?

[mikrosk]

Hi Patrice,

nice to see you around. Actually it is the other way around -- Mike Fulton believed that it is wrong to use 1 instead of Getrez() + 2 but see the linked issue -- freemint/tos.hyp#89 and also the discussion under Mike's article. It is wrong to use Getrez() + 2 on anything TOS > 3.x and graphics cards.

What he argued about was usage of direct constants instead of Getrez() + 2. I.e. you assumed your software will be run only on mono, so you passed 4 (640x400@mono) in work_in[0] and that is wrong. However using Getrez() + 2 instead of 1 is really a bad idea.

@th-otto made some very good points as of why it is OK to use 1.

[pmandin]

Do you think it would be OK this way, if I want a program that runs on any Atari, and whatever VDI is running:

vdi_workin[0] = Getrez()+2;
if ((tos_version>0x300) || vdi_not_in_rom) {
	vdi_workin[0] = 1;
}

Currently, I don't know how I could check for a custom VDI (FVDI or NVDI), maybe trap #2 not pointing into ROM ?
Because even Mega ST or TT could have video cards, with custom VDI.

[mikrosk]

I was thinking that maybe more like tos_version>=0x400 because your way you accept TOS 3.00 (the pre-release one) but not 3.01 and later. TOS 3.0x is still "stable" in this manner, it's graphics cards and TOS 4.0x where things break.

So just change that one check and you're good I think. What do you think @th-otto?

[th-otto]

I think that check isn't needed at all. workin[0] = 1 will work with all TOS versions, not only >= 3.x

Also, how would you check whether VDI is in ROM or not? Only because the VDI trap points to RAM does not mean that there is a different VDI behind it. It could be just some helper program like VDIFIX.

[pmandin]

In fact, I was wondering how the AES opens the physical workstation; either the ROM AES, or one of the few custom AES (NAES, myAES, Oaesis, etc).

So the purpose of this program is just that, showing how it is (or should be) done.