List of known SuperVidel issues

[mikro]

Here's a list I'm keeping in my head. I've decided to post it publicly so a) Nature & AF post destroyer PeP can comment on them ;) b) make new people aware that they can encounter these issues as well, i.e. it's not their setup's fault.

• The infamous CT60 TOS boot lockup: viewtopic.php?p=439917#p439917
• When setting a 320x200 resolution without top/bottom borders, SuperVidel stretches the image to 320x240. When then switched back to full 320x240, SuperVidel still thinks it needs to stretch the image and 320x240 becomes something like 320x200 with stretched image over 240 lines (visible on my ScummVM port which uses 320x200@8-bit for some games but 320x240@16-bit for the overlay).
• For some reason, setting 640x480x16col (bitplane) in xaaes.cnf (i.e. "video = 26" or in recent builds "screendev = 5" & "modecode = 26") does terrible things in XaAES. Namely, when booting with MP enabled, starting any process leads to its immediate termination. Strangely, TosWin2 seems to start and even it starts (and immediately ends) any .ttp application but for example Qed or any GEM application I'd tried simply exits. Setting e.g. "video = $425c" or leaving xaaes.cnf without any explicit number (I had $425c as the default AES resolution in sv.inf, hmm...) or booting without NVDI makes the bug disappear. So it looks like a bug in SV's NVDI driver code.
• 1920x1080 not working on every LCD: viewtopic.php?p=408146#p408146

EDIT: Sorry for breaking this post before; I either had no idea I had admin rights for this subforum, or I've forgotten about it. I accidentally edited MiKROs original post rather than quoting and editing for a new one. Order has now been restored thanks to MiKRO. // Shoggoth/PeP

[Rustynutt]

Well, as I've just now put my CT60e back on a Falcon, I can try your test. Keep in mind some are very mean people I freal would travel to the US and take my hardware, so will hide behind you on these matters

[saulot]

I would add lack of driver integration in ct60tos, latest firmware for SV is supplied in not very user friendly way.
1st is a bummer for me (still got ct60 only) and I cannot use latest, patched versions of TOS.

[shoggoth]

When setting a 320x200 resolution without top/bottom borders, SuperVidel stretches the image to 320x240. When then switched back to full 320x240, SuperVidel still thinks it needs to stretch the image and 320x240 becomes something like 320x200 with stretched image over 240 lines (visible on my ScummVM port which uses 320x200@8-bit for some games but 320x240@16-bit for the overlay).

No it doesn't. The Supermodel doesn't stretch anything.Your monitor might get confused by what's nowadays considered non-standard timings though, and that can cause similar issues (I've seen it myself).

For some reason, setting 640x480x16col (bitplane) in xaaes.cnf (i.e. "video = 26" or in recent builds "screendev = 5" & "modecode = 26") does terrible things in XaAES. Namely, when booting with MP enabled, starting any process leads to its immediate termination. Strangely, TosWin2 seems to start and even it starts (and immediately ends) any .ttp application but for example Qed or any GEM application I'd tried simply exits. Setting e.g. "video = $425c" or leaving xaaes.cnf without any explicit number (I had $425c as the default AES resolution in sv.inf, hmm...) or booting without NVDI makes the bug disappear. So it looks like a bug in SV's NVDI driver code.

This might be the case of a recent XaAES/FreeMiNT combo, but it wasn't the case some years ago. So some version numbers wouldn't hurt here; I personally used XaAES with MP for several years without said issues, but then again the kernel/AES went through a period of deterioration after that.

1920x1080 not working on every LCD: viewtopic.php?p=408146#p408146

This is a deliberate compromise; it's 30Hz. Some screens doesn't support it, but the alternative might be not having a 1920x1080/1200 mode at all. It's a question of bandwidth.

[mikro]

No it doesn't. The Supermodel doesn't stretch anything.Your monitor might get confused by what's nowadays considered non-standard timings though, and that can cause similar issues (I've seen it myself).

Very good point. In that case it would seem that SuperVidel forgets to restore some border timings or something like that. Perhaps I should have taken a picture, it's worth a thousand words. Anyway, it doesn't happen on VGA output so it can't be the LCD's fault.

This might be the case of a recent XaAES/FreeMiNT combo, but it wasn't the case some years ago. So some version numbers wouldn't hurt here; I personally used XaAES with MP for several years without said issues, but then again the kernel/AES went through a period of deterioration after that.

I did my tests on https://tho-otto.de/snapshots/freemint/ ... clones.zip. Even though I'm well aware of the state of current XaAES code base, this really smells more like this bug has been well hidden because who uses bitplane resolution on SV, right? Also it is possible that XaAES is more strict than it was before. I'll do more testing.

This is a deliberate compromise; it's 30Hz. Some screens doesn't support it, but the alternative might be not having a 1920x1080/1200 mode at all. It's a question of bandwidth.

Damn it PeP, if this is the case, why on earth do you list that mode as 1920x1080@60/61 Hz in the resolution dialog? ;-) It would save me a lot of fiddling if I knew that my monitor must support 30 Hz (what the Dell one mentioned in my post does support).

[mikro]

This might be the case of a recent XaAES/FreeMiNT combo, but it wasn't the case some years ago. So some version numbers wouldn't hurt here; I personally used XaAES with MP for several years without said issues, but then again the kernel/AES went through a period of deterioration after that.

I did my tests on https://tho-otto.de/snapshots/freemint/ ... clones.zip. Even though I'm well aware of the state of current XaAES code base, this really smells more like this bug has been well hidden because who uses bitplane resolution on SV, right? Also it is possible that XaAES is more strict than it was before. I'll do more testing.

And I did. Bad news for the poor SuperVidel drivers developer - it is not a FreeMiNT/XaAES bug. I went as back as FreeMiNT 1.16 and its XaAES and the bug was still there. So you must have overlooked this test scenario, i.e. booting XaAES in a bitplane mode. Btw, I was pretty close to get fooled, too -- it seems that 1.16 kernel has a bug, it refuses to save the MP flag in mint.ini. I didn't notice at first, thinking that I'm booting with MP enabled and everything worked. Only after setting it for real (while booting) I could observe a nice "private violation" error when starting qed (it's a bit worrying that this dialog is shown on 1.16, 1.17 and 1.18 but not on the latest 1.19... but that's for another time).

[shoggoth]

I can assure you that this was tested and worked; some circumstance gave different results though

It's difficult for me to test this atm since my CT60 suffers from bad health, but I believe certain parts of SVSCREEN.SYS suffers from "works by chance", and that it could be beneficial to replace it with a new one. Coincidentally, I made one for the Vampire V4, and that can probably be re-used with very little modifications. It's a cleaner implementation compared to SVSCREEN.SYS, and it uses a different mechanism to load the actual screen drivers.

It could make a difference, so this is what I'll do for now.

[mikro]

Just a brief update: PeP managed to fix the NVDI driver so 640x480@16c works.

Found a workaround for the 240 / 200 issue: one has to set a native SuperVidel resolution (with the SVEXT bit set) to reset SuperVidel into a "true 240/480" state. Nothing else (setting 240/480 manually, via VsetMode(), ...) helped. Not very happy about it as it creates an unnecessary long resolution switch on my LCD but ... it works. Better than returning to a fake 640x400 desktop with top and bottom icons not visible.

[shoggoth]

Found a workaround for the 240 / 200 issue: one has to set a native SuperVidel resolution (with the SVEXT bit set) to reset SuperVidel into a "true 240/480" state. Nothing else (setting 240/480 manually, via VsetMode(), ...) helped. Not very happy about it as it creates an unnecessary long resolution switch on my LCD but ... it works. Better than returning to a fake 640x400 desktop with top and bottom icons not visible.

It is likely an issue with how your monitor handles non-standard resolutions; the SuperVidel doesn't stretch things - it's done in the monitor itself. So, no need for a grumpy face, just fix your custom video code to handle it. The fact that it happens to work on the VIDEL output is more of a bonus.

[shoggoth]

Just a brief update: PeP managed to fix the NVDI driver so 640x480@16c works.

It's actually an entirely new SVSCREEN.SYS based on the one I'm writing for the V4. It's less hacky internally since I know a lot more about NVDI now than I did when I wrote the old one (it was based solely on disassembly and experimentation + bad assumptions).

While it cures the issues mentioned here, it doesn't read SV.INF at all at this point, so I should probably fix that before making an official release. If someone wants the new SVSCREEN.SYS binary, I could put a link to it here.

[mikro]

It is likely an issue with how your monitor handles non-standard resolutions; the SuperVidel doesn't stretch things - it's done in the monitor itself.

I beg to disagree here - if I send to my monitor whatever I set to (Super)Videl registers, sure, my LCD can interpret it any way it likes (currently as a aspect ratio correction for free ;)). But: if I send correct video signal (i.e. 640x480@16col) back again, there's no freaking way that it is the LCD's fault that the stretch mode is still there.

If that were true, the poor LCD could be messed up by simple out of sync resolution or whatever because it would never recover.

I did a nice experiment for you: I switched the LCD off. Completely, off the grid. While being in the messed-up 640x400. If your theory were correct, I should get 640x480 back again because what? LCD messed it up and didn't recover correctly while SuperVidel is sending proper signal! Well, nope, the signal is still wrong.

I'm telling you, SuperVidel FW doesn't reset some internal bit or value indicating the vertical size of the top and bottom borders.

EDIT: I'm be damned. Maybe you are actually right (or at least partially right). I gave it one more try - I was playing with the monitor's aspect ratio settings (dot by dot, full screen, aspect ratio). And to my eternal surprise, not only changing the ratio reset the image to proper stretch mode but for instance when in "dot by dot", my 320x200 resolution would be completely messed up from the beginning.

That doesn't mean that SuperVidel is innocent here (it may send the 320x200 in some way unfriendly to the DVI specification) but this new discovery definitely casts a shadow on the LCD as well.

[shoggoth]

On the driver department, what's left in such case is the 1920x1080 modes.

There are two 1920x1080 modes in the code; 60Hz and 80Hz. Try setting the PAL-bit in the 1920 modecode, see what happens.

EDIT: What I said before about a 30Hz mode was wrong, it seems it wasn't included after all, but it would make sense to add it. 30Hz isn't 30Hz on-screen, the monitor does some magic on top.

[mikro]

I tried it with a custom build of uconvert, even connected a DVI cable to avoid weird surprises like in viewtopic.php?p=408146#p408146 but no change.

Are you referring to CTPCI's way of handling refresh frequency:

Code: Select all

// OVERSCAN and PAL flags are used for select refresh frequency:
// OVERSCAN | PAL | Freq
// ---------+-----+-----
//        0 |  0  | 56
//        0 |  1  | 60
//        1 |  0  | 70
//        1 |  1  | 85

? From what I have seen, SVXBIOS seems to have only:

Code: Select all

mode &= ~(OVERSCAN | PAL);

so that would explain why it didn't have any effect.

Btw how did you guys calculate the values for SV registers for each mode?

[shoggoth]

I tried it with a custom build of uconvert, even connected a DVI cable to avoid weird surprises like in viewtopic.php?p=408146#p408146 but no change.

Are you referring to CTPCI's way of handling refresh frequency:

Code: Select all

// OVERSCAN and PAL flags are used for select refresh frequency:
// OVERSCAN | PAL | Freq
// ---------+-----+-----
//        0 |  0  | 56
//        0 |  1  | 60
//        1 |  0  | 70
//        1 |  1  | 85

No, nothing like that. While I was peeking at the CTPCI implementation in the beginning, I was horrified after a while, and decided not to go that route.

? From what I have seen, SVXBIOS seems to have only:

Code: Select all

mode &= ~(OVERSCAN | PAL);

Ok, better have a look at that then.

Btw how did you guys calculate the values for SV registers for each mode?

Most of it comes from known/standard timing values, all of it available online. It's been a decade now, so who knows if it's still there.

There are exceptions, where certain modes have been had to be tweaked due to bandwidth and how the SV functions internally.

Perhaps you should just get another monitor, because I doubt this is a widespread problem. As I said, I know certain modes had to be tweaked because of internal bandwidth issues and to let the SV get enough time to fetch data before the beginning of a visible scanline etc. So the timings you consider "wrong" may very well be what you get. Sure, it's possible that you could tweak the modes a bit more to make it work on your particular monitor, but then again, you may cause it to fail on anything else.

What I could do though, as I intend for SVXBIOS to get a little makeover now that NVDI got a new SVSCREEN.SYS, is to put all modes in some config file.

[mikro]

What I could do though, as I intend for SVXBIOS to get a little makeover now that NVDI got a new SVSCREEN.SYS, is to put all modes in some config file.

That would be fantastic yes. ;)

[NEMOx]

Yes, there is no option to easily upload the latest firmware versions