My experience

[mikro]

Hi all,

just to share my experience with SuperVidel with you, perhaps I'll get smarter here. I assisted Xi, a friend of mine, to install his and everything went flawless (CT63, no wires, just plug&play) even on his old firmware which we were unable to update (my cable stayed at home). After some time / certain operations screen froze but we assumed that's because of the old firmware.

So, before doing anything I have updated my CT60 to the latest ABE/SDR, TOS is 1.03c.

1. I don't whether it's OK but my SV by no way can fit (at least somehow) with CTCM installed. It's just... too high, if I want to fit it, SV is connected maybe 1-2 mm deep, I don't think this is OK. Fortunately, I still have the old 66.6 MHz clock, with that it is much better.

2. Next trouble was actually fitting SV properly because the 2.5->3.5 adapter + IDE cable is like 0.01 mm away from the DVI connector (and I'm unable to use the screw, because it overlaps with it). Not a big deal, just a bit scary.

3. Then my another trouble was that I'm using Falcon in RGB, i.e. having a SCART cable. Yes, I did know that SV doesn't support RGB, first I only wanted to check out whether it's everything all right without drivers. And bam! No picture on DVI, 15 kHz/50 Hz (thank god for these smart LCDs showing me this). OK you say, remove the SCART cable. Sure. And what? TV output, i.e. the same. So I had to dig out a VGA adapter and put it in the monitor slot, even if I didn't have any VGA monitor. I find this as a big design flaw, guys! (I hope it can be corrected)

4. And finally... I don't know why but the system just wont boot. I see the CT60 stats/versions, amount of memory (but no logo, naturally) and .. that's it. I see SV must be working somehow (with the empty VGA adaptor) because I do see a nice, clean picture on the DVI output with the same stats. So I'm wondering what could go wrong? First I thought whether it isn't caused by the fact that I'm using the old clock but the CT60 has got those wires on the back (CTCM mod) but nope. As soon as SV is gone, everything boots up as before.

EDIT: ... and to add 5. to my whining: SV_drivers.zip are in fact SV_drivers.rar. Not cool, guys, not cool! :P

[mikro]

I don't know why but the system just wont boot. I see the CT60 stats/versions, amount of memory (but no logo, naturally) and .. that's it. I see SV must be working somehow (with the empty VGA adaptor) because I do see a nice, clean picture on the DVI output with the same stats. So I'm wondering what could go wrong?

Eh, it seems that some of the soldering points on the CT60 have loosened or so. Because I saw similar things with another SV + a message about SD RAM read failure, so I guess I can say SV is not guilty in this case. I'll try with ct63 and let you know. However, for 2-3 times I was pretty sure I killed falcon/ct60/sv for good :)

[shoggoth]

1-2. I'm using a CTCM, but I'd have to check my installation to see how that's possible I might have cheated somehow.

3. This is a tricky one, since we - so far - haven't put the drivers in the CT flash. When we do that, we could set a safe RGB resolution on the VIDEL output, and a VGA resolution on the SV output.

4. Hope it works out.

5. Someone needs a good spanking. Perhaps someone used some popular windows-utility instead of a real ZIP archiver.

[mdivancic]

1-2. I'm using a CTCM, but I'd have to check my installation to see how that's possible I might have cheated somehow.

FYI mine fits fine with the CTCM on my CT63. I did apply tape as recommended.

[mikro]

CTCM@CT63 is different, much better.

Anyway. After a lot of swearing (and buying a new hard disk and trying out another ct63 which turned out to be not only impossible to update but also non-working) I know the culprit now -- it was the f***ing PSU. So I bought another one, too (thank god for second hands). And then, voila! The original CT60 is all right, disk is all right, SuperVidel is all right. So after some fiddling I can say heureka!

However, there's one more glitch -- if SV_XBIOS.PRG is started without SV.INF in root, I'd expect it to fall back into some safe defaults. Nooo, it's messed up everything ;) I had to blindly disable it to PRX and then copy over the forgotten file.

Another thing -- what do the 'enabled by NVDI driver' options mean? That if I run NVDI, value specified there doesn't matter because they are enabled by NVDI anyway?

I'm going to play with XaAES and stuff to see what happens. Yes, I'm a terrible user and everything, I realize that. But anyway, when I saw the 1920x1080 resolution, I nearly fell of my chair ;)

[mdivancic]

I'm going to play with XaAES and stuff to see what happens. Yes, I'm a terrible user and everything, I realize that. But anyway, when I saw the 1920x1080 resolution, I nearly fell of my chair

It is amazing, is it not? I've had a blast with mine learning MiNT. Well worth the wait.

[instream]

Hi all,

just to share my experience with SuperVidel with you, perhaps I'll get smarter here. I assisted Xi, a friend of mine, to install his and everything went flawless (CT63, no wires, just plug&play) even on his old firmware which we were unable to update (my cable stayed at home). After some time / certain operations screen froze but we assumed that's because of the old firmware.

So, before doing anything I have updated my CT60 to the latest ABE/SDR, TOS is 1.03c.

1. I don't whether it's OK but my SV by no way can fit (at least somehow) with CTCM installed. It's just... too high, if I want to fit it, SV is connected maybe 1-2 mm deep, I don't think this is OK. Fortunately, I still have the old 66.6 MHz clock, with that it is much better.

2. Next trouble was actually fitting SV properly because the 2.5->3.5 adapter + IDE cable is like 0.01 mm away from the DVI connector (and I'm unable to use the screw, because it overlaps with it). Not a big deal, just a bit scary.

3. Then my another trouble was that I'm using Falcon in RGB, i.e. having a SCART cable. Yes, I did know that SV doesn't support RGB, first I only wanted to check out whether it's everything all right without drivers. And bam! No picture on DVI, 15 kHz/50 Hz (thank god for these smart LCDs showing me this). OK you say, remove the SCART cable. Sure. And what? TV output, i.e. the same. So I had to dig out a VGA adapter and put it in the monitor slot, even if I didn't have any VGA monitor. I find this as a big design flaw, guys! (I hope it can be corrected)

4. And finally... I don't know why but the system just wont boot. I see the CT60 stats/versions, amount of memory (but no logo, naturally) and .. that's it. I see SV must be working somehow (with the empty VGA adaptor) because I do see a nice, clean picture on the DVI output with the same stats. So I'm wondering what could go wrong? First I thought whether it isn't caused by the fact that I'm using the old clock but the CT60 has got those wires on the back (CTCM mod) but nope. As soon as SV is gone, everything boots up as before.

EDIT: ... and to add 5. to my whining: SV_drivers.zip are in fact SV_drivers.rar. Not cool, guys, not cool!

I see that I'm a bit late to the discussion, but here goes:

1) I have seen many variants of the CTCM all with different heights. We mention the problem with the CTCM in the SuperVidel Installation Manual, which you of course have read Miro. I also have a CTCM and put the SV on extra 2x25 pin headers to get the SV up from the CT60. Since I have no other board on there (except Svethlana on flat cable) I can put the original case top on the falcon.
2) We forgot to mention harddrive troubles in the manual, but it is mentioned on the SV project page at nature.atari.org. Anyway, I would recommend losing the old 3.5" drive and getting a small form factor SSD that sits directly on the 44pin connector. No cables! Can be found on ebay for. I think there is a discussion about those drives on this forum.
3) The SV currently doesn't emulate RGB modes. The VGA adapter on the old Videl port is needed since TOS checks what cable is attached using the old Videl register. We would either have to patch the TOS to get rid of this behavior, or implement hi-jacking of that Videl register in the SV VHDL code, so we can tell TOS what monitor is attached. But we have no means for the user to select this on the SV (no free jumper) and I don't want to have to organize two different firmwares for VGA and RGB.
4) Good that you found the problem.
5) I think the RAR ended up there since there were severe problems with different versions of the ZIP format on windows/mint/TOS/MAC etc.

[mdivancic]

2) We forgot to mention harddrive troubles in the manual, but it is mentioned on the SV project page at nature.atari.org. Anyway, I would recommend losing the old 3.5" drive and getting a small form factor SSD that sits directly on the 44pin connector. No cables! Can be found on ebay for. I think there is a discussion about those drives on this forum.

I got something like this:

http://www.amazon.com/Kingspec-Series-V ... B009FX9AYK

You can find them on amazon or ebay (or most likely may other places). Works well with the SV

[shoggoth]

However, there's one more glitch -- if SV_XBIOS.PRG is started without SV.INF in root, I'd expect it to fall back into some safe defaults. Nooo, it's messed up everything I had to blindly disable it to PRX and then copy over the forgotten file.

Don't be a douche Start it with SV.INF in the root directory.

(seriously I didn't know about this problem. The driver does set sane defaults internally, but aparently fruitcakes when SV.INF isn't there. This will be fixed.)

Another thing -- what do the 'enabled by NVDI driver' options mean? That if I run NVDI, value specified there doesn't matter because they are enabled by NVDI anyway?

I didn't intend for all these options to be official. Basically it's a way to enable 8bpp chunky and 32bpp modes without using NVDI. TOS4 VDI has built-in support for these modes, but the code is unfinished and some stuff (icons and some other stuff) doesn't look right.

I'm going to play with XaAES and stuff to see what happens. Yes, I'm a terrible user and everything, I realize that. But anyway, when I saw the 1920x1080 resolution, I nearly fell of my chair

Yeah it's pretty, isn't it

[mikro]

Let's continue :D svupd005.app from Nature's website -- 404 error. File for JTAG update is available, it's just this one. I'm wondering how come nobody has noticed this.

But no, seriously, I'm doing also something else than trying to piss you off guys :P

[shoggoth]

Let's continue svupd005.app from Nature's website -- 404 error. File for JTAG update is available, it's just this one. I'm wondering how come nobody has noticed this.

Ah well. svupd006 is about to be released afaik, so stay tuned for a working download link. Meanwhile I'll contact you in a pm.

But no, seriously, I'm doing also something else than trying to piss you off guys

Sure you are Otherwise you wouldn't be so good at it

[mikro]

But no, seriously, I'm doing also something else than trying to piss you off guys :P

Sure you are :) Otherwise you wouldn't be so good at it ;-)

But we are having so much fun. So here is a couple of new bugs:

- if I specify bootmode = $445c (which is supposed to be 1920x1080/16bit), console output is broken (in Desktop, if you click 'Show' you see only funny colour pixels instead of text). If I let bootmode as it is and boot into Desktop in the same resolution, it works
- the resolution dialog is quite misleading -- I set 1920x1080/16, it's set, all right. Then I go to the dialog again, I see my number ($445c) but the other information (width, height, perhaps others) are (re)set to 1024x768

Question: why can't I set 24 and 32 bit depth? It's a future feature?

EDIT: also, what's the difference between:

dual = on/off
clone = true/false

Does 'clone' imply that 'dual' has to be set 'on'? How does this work?

and:

primary = VGA

what is the other value? DVI? What does it do in practice?

[shoggoth]

But we are having so much fun. So here is a couple of new bugs:

- if I specify bootmode = $445c (which is supposed to be 1920x1080/16bit), console output is broken (in Desktop, if you click 'Show' you see only funny colour pixels instead of text). If I let bootmode as it is and boot into Desktop in the same resolution, it works

Oops, I had no idea. Are you using the TOS VDI or NVDI? Makes quite a difference. There are console issues in bitplane modes when using NVDI right now, simply because my SVSCREEN.SYS does not yet implement the console properly (TC and chunky resolutions implement their own consoles for some reason, I guess Behne^2 wanted to save some space and put it in the NVDI.PRG binary (SCREEN.SYS is in there) instead of in the NVDIDRV1-8.SYS files).

- the resolution dialog is quite misleading -- I set 1920x1080/16, it's set, all right. Then I go to the dialog again, I see my number ($445c) but the other information (width, height, perhaps others) are (re)set to 1024x768

The resolution dialog needs to be rewritten from scratch; it's based on TOS code which has been altered to sort of work for the SV. It's not nice, and I'm aware of this particular bug.

Question: why can't I set 24 and 32 bit depth? It's a future feature?

24bpp isn't available on the SV (it's not a useful feature anyway). 32bpp is, however. Either load NVDI, or enable 32bpp in SV.INF. 32bpp and 8bpp chunky is disabled by default when you're not using NVDI, because the results are not 100% with the built-in VDI (support for these colour depths aren't exactly an official feature in the TOS4 VDI).

EDIT: also, what's the difference between:

dual = on/off
clone = true/false

Does 'clone' imply that 'dual' has to be set 'on'? How does this work?

and:

primary = VGA

what is the other value? DVI? What does it do in practice?

Ignore these settings for the time being. They won't have any effect right now, but they will. Basically they'll be used to set dual screen resolutions, and to disable unused output to save bandwidth.

[mikro]

- if I specify bootmode = $445c (which is supposed to be 1920x1080/16bit), console output is broken (in Desktop, if you click 'Show' you see only funny colour pixels instead of text). If I let bootmode as it is and boot into Desktop in the same resolution, it works

Oops, I had no idea. Are you using the TOS VDI or NVDI? Makes quite a difference. There are console issues in bitplane modes when using NVDI right now, simply because my SVSCREEN.SYS does not yet implement the console properly (TC and chunky resolutions implement their own consoles for some reason, I guess Behne^2 wanted to save some space and put it in the NVDI.PRG binary (SCREEN.SYS is in there) instead of in the NVDIDRV1-8.SYS files).

Yes, it's with NVDI. But how come it works in the same resolution when not using the 'bootmode' (i.e. to me it seems like it switches from something to 1920x1080x16 and therefore there's some initialization happening while when the resolution is set right from the beginning of the boot process, a desktop/console initialization is not happening afterwards). Apropo, haven't you thought of using NVRAM for this? It would be sweet to see the resolution set after power on (assuming that there's no additional initialization needed).

Either load NVDI

Oh really. I'm using NVDI all the time.

or enable 32bpp in SV.INF.

Now who's a douche ;-) How do I do that?

Ignore these settings for the time being. They won't have any effect right now, but they will. Basically they'll be used to set dual screen resolutions, and to disable unused output to save bandwidth.

Maybe it's good idea to hide these for the time being, then. Curious people like me are very frustrated when there isn't anything happening ;-)

[shoggoth]

Yes, it's with NVDI. But how come it works in the same resolution when not using the 'bootmode' (i.e. to me it seems like it switches from something to 1920x1080x16 and therefore there's some initialization happening while when the resolution is set right from the beginning of the boot process, a desktop/console initialization is not happening afterwards).

Actually I had no idea about this. I'll try to reproduce it when I have time. Didier has replaced the TOS console, which mean I have to re-install the TOS console, then NVDI installs a console on top of that - but only when the physical workstation is open.

Plenty of room for mishaps, in other words.

You are sure that your ASSIGN.SYS is correct?

Apropo, haven't you thought of using NVRAM for this? It would be sweet to see the resolution set after power on (assuming that there's no additional initialization needed).

Of course I did. But the driver is loaded from the auto folder, which means there will still be some delay. But I guess that I could read the NVRAM instead of SV.INF for the boot resolution, since it's possible to store an SV modecode in there.

Either load NVDI

Oh really. I'm using NVDI all the time.

or enable 32bpp in SV.INF.

Now who's a douche How do I do that?

Ok this is weird, then. 32bpp is not available in VIDEL resolutions obviously, but with NVDI it is supposed to be available in all SV resolutions. It is on my machine. Wonder what goes wrong here.

Maybe it's good idea to hide these for the time being, then. Curious people like me are very frustrated when there isn't anything happening

Yeah, I should have known better

[mikro]

You are sure that your ASSIGN.SYS is correct?

Sure, I think it's a straight copy from the SV driver package, I have no reason to change anything there. If you manage to reproduce it, cool.

But I guess that I could read the NVRAM instead of SV.INF for the boot resolution, since it's possible to store an SV modecode in there.

I'm asking mainly because my long(-ish)-term plan is to put the XBIOS driver into the CT60 TOS (1.03c), ideally with your fix for the Atari logo. I'm not planning to use the CTPCI anytime soon and on the other hand I'd like to have nice resolution from the start, having the .PRG only as a fallback solution when something goes wrong.

Ok this is weird, then. 32bpp is not available in VIDEL resolutions obviously, but with NVDI it is supposed to be available in all SV resolutions. It is on my machine. Wonder what goes wrong here.

So you say you boot with NVDI enabled, go to the desktop resolution change dialog, choose SV mode and boom, you can set both 16-bit and 32-bit? I see always 16-bit only :(

[shoggoth]

I'm asking mainly because my long(-ish)-term plan is to put the XBIOS driver into the CT60 TOS (1.03c), ideally with your fix for the Atari logo. I'm not planning to use the CTPCI anytime soon and on the other hand I'd like to have nice resolution from the start, having the .PRG only as a fallback solution when something goes wrong.

That's my long term goal as well, and my CTPCI is still in a box somewhere, I'll most likely never use it.

So you say you boot with NVDI enabled, go to the desktop resolution change dialog, choose SV mode and boom, you can set both 16-bit and 32-bit? I see always 16-bit only

I'll have to check it. The video dialog is a bit of a hack to say the least. There's no API to change it, which means there's only ugly ways to achieve that..

[shoggoth]

I'm asking mainly because my long(-ish)-term plan is to put the XBIOS driver into the CT60 TOS (1.03c), ideally with your fix for the Atari logo. I'm not planning to use the CTPCI anytime soon and on the other hand I'd like to have nice resolution from the start, having the .PRG only as a fallback solution when something goes wrong.

That's my long term goal as well, and my CTPCI is still in a box somewhere, I'll most likely never use it.

So you say you boot with NVDI enabled, go to the desktop resolution change dialog, choose SV mode and boom, you can set both 16-bit and 32-bit? I see always 16-bit only

I'll have to check it. The video dialog is a bit of a hack to say the least. There's no API to change it, which means there's only ugly ways to achieve that..

EDIT: I made a change to the internal config structure in the last version, and perhaps this accidentally messed up a setting which hides 32bpp and 8bpp chunky. I'll have to check it, but it's the only thing I can think of. One solution is to just remove this features (hiding 8bpp and 32bpp modes) completely, but it was implemented to prevent VDI-only users from complaining about messed up icons in these modes

[mikro]

Another bug report: if I set 640x480x8C, "Videl" is shaded out. However, if I set 640x480x8-bit (planar), let "Videl" as it is and then choose the chunky mode, I can set the resolution with no problem (=$001f). It seems you have forgotten that the chunky mode can be set with Videl, too.

Btw, in this specific resolution, I'm not seeing the 1024x768x16 fallback as reported above, the resolution change dialog shows correct (current) numbers.

[shoggoth]

I can confirm the bugs in the video dialog. I introduced them very recently I think. No big deal, should be able to fix it soon.

EDIT: The reason is most likely that I forgot to compile a new version of SVSCREEN.SYS; it shares some code with SV_XBIOS.PRG. No big deal, it'll be cured for sure in the next rev. Meanwhile you just have to live with it

[Beetle]

Last Weekend, i got the opportunity to test my Falcon on a really giant TFT screen.
Its native res. was 2560x1440 pixels. I got some fast-hacked-SV-drivers for it and *bang*
they did work!

kronos-screenshot.jpg

Kewl

[instream]

Yay! just need to buy a 2560x1440-monitor then...

[Dal]

Is the bug with the video dialog fixed yet? I am using the latest driver pack, V006 firmware and NVDI but not able to set 32bit true colour mode. Can I 'hack' it by enabling 32bit mode in SV.INF?

**EDIT: Yes - it appears forcing 32bit mode on in the SV.INF does allow me to select it in Video Prefs**

[shoggoth]

Is the bug with the video dialog fixed yet? I am using the latest driver pack, V006 firmware and NVDI but not able to set 32bit true colour mode. Can I 'hack' it by enabling 32bit mode in SV.INF?

**EDIT: Yes - it appears forcing 32bit mode on in the SV.INF does allow me to select it in Video Prefs**

It is indeed fixed (afaik), but the drivers aren't officially released yet.

Release candidate here: https://dl.dropboxusercontent.com/u/709 ... alpha4.zip

It's however not an official release, so keep your old copies of the driver stuff.

EDIT: This particular issue wasn't really a "bug" but rather a "feature": SVSCREEN.SYS and SV_XBIOS.PRG must be kept in sync, and that wasn't the case. They share an internal data structure, and SVSCREEN.SYS probably messed this up since it was "older" than SV_XBIOS.PRG.

[Dal]

Thanks for fixing the 'features'

I have it running on my system now for some days. Is it my imagination or does Silkcut demo now run a little bit less jerky than before?

Overall, it seems solid and I've not found any more...errr...features so far.