CT60 + CTEX + ScreenEye review & experiments

[mikro]

A few weeks ago I managed to get hold of the ScreenEye card for the Falcon. With zero information and expectations I managed to get it running. In 320x240@16-bit, that is (as it supports high colour only). It was fun (you may remember my Facebook post about it) but way too restricted. Having the card in possession got me thinking more about CT60's compatibility and interoperability with such hardware (because, as you are certainly aware, the CT60 doesn't provide the original pinout but rather it's own bus pins).

According to Rodolphe's CT60 website, it should be definitely possible:

Eclipse, Screen Eyes, Expose & Nova can be used with CT60 because CT60 don't modify the hardware of Falcon Bus (no solders for the fitting).

The CT60 don't give you a new Falcon bus slot because it is not needed ! The method is simple : keep your Falcon daughter card on the Falcon slot and solder two Male/Male HE13 connectors (2x15 & 2x25) on your 'old' card and plug the CT60 on it ! Sure, in this configuration the keyboard is out of the Falcon case !

Personally I wouldn't call this 'simple' but fair enough, at least it should work. And then there's of course the CTEX which offers two in one: moving the CT60 closer to the front part of the case (in case you want two boards on the CT60 inside standard Falcon case) and allowing to use one classic bus expansion card:

IMG_20180713_182035.jpg

I know of two persons who had attempted to use a bus expansion card with CT60: Tobias, who wanted to use his NOVA card and Wolfgang, who wanted to use his Eclipse and/or NOVA card. If you click on the links you will see they have failed.

Tobias mentions on his website that it is the NOVA driver's fault however in an email conversation he shared more of his investigation:

This got me started back when to contact Rodolphe to figure out why the NOVA didn't work with the CT60. He gave all kinds of reasons, mainly that it would be the drivers fault. After investing a lot of time, changing the drivers and a lot of long email exchanges with Rodolphe and Didier, I figured out the real reason. Rodolphe took a shortcut and didn't implement the full memory protocol for accessing the extension port. I was quite mad, sinde he always insisted that it was NOVA's fault. I even bought an Eclipse and had the same problem.

When I tested , I made a lot of modifications to the source code to make sure it is 060 safe. In the end it didn't solve the problem since the CT6x only implements the simple bus protocol. It waits a set amount of waitstates before it throws a bus error if the acknowledge (?) signal does not arrive. ATARI also specified a protocol for bus master devices, but the CT6x does not support this. I have not been able to find any classic card that works with the CT6x.

As you can see, he tried even the Eclipse, with the same result. Wolfgang shares a similar experience:

I tried both, the Nova and the Eclipse with my CT60. I also modified the drivers for the Nova to make it 060-proof without any success. Didier even made a special TOS addressing caching issues for the Nova address space.

Finally, I figured out the reason. The CT60 does not support the original enhanced Falcon bus protocol, which can handle wait-states. The necessary lines are not connected on the CT60.

I asked Rodolphe to modify the ABE, but even this did not help.

I am afraid that without the CT60 supporting wait-states, there will be no Nova/Eclipse-CT60.

and a bit later:

The ATARI Falcon 030 Hardware Reference Guide 10/1/92 states a
- 'Slave Devices/RAM' bus access protocol
and a
- 'Bus Masters' protocol

The latter needs the /EXPAND signal to include wait-states. Unfortunately the CT60 is not connected to the systems /EXPAND line. Therefore cards who need this signal (like the Nova or the Eclipse) are unlikely to work. :-(

I asked Rodolphe about his opinion now that he has a better perspective what should and shouldn't work and he is still confident that the CT60 should work with such card because they shouldn't do anything special, just behave as an I/O card. While he admits that the CT60 indeed doesn't pickup the /EXPAND line he still doesn't understand why the Eclipse and NOVA mess with it - I/O card should generate its DTACK when it needs to terminate the bus cycle and not use the /EXPAND (which is defined as something which I/O card must generate if it requires more than 4 CPU cycles). Either way, according to him these two guys have come to a wrong conclusion because even if the /EXPAND is needed/used by the cards, it doesn't make them bus masters, as the /EXPAND is for device cards (also it's hard to believe that those cards would contain a CPU or DMA).

So all of this made me curious how well the ScreenEye is going to work with CT60 - would it at least boot? Would I need to modify its driver? Slowly I had been gathering needed components but then I got lucky - Exxos is selling his CT60 and offered a CTEX as well. So I took it and voila, I have a CTEX! This really pushed me forward, as I needed to solder only basic header pins:

IMG_20180716_193531.jpg

OK, so let's try to squeeze it all in:

IMG_20180716_203649.jpg

Looks good, let's put the keyboard on top of it:

IMG_20180716_204452.jpg

While this looks good but it is not. The keyboard doesn't sit properly anymore:

IMG_20180716_204937.jpg

It's because every millimetre counts, the "pin base" is most likely to blame:

IMG_20180716_205816.jpg

The plastic column fits to the last micrometre:

IMG_20180716_210033.jpg

Unfortunately, even with the pins lowered, the biggest problem is the front part:

IMG_20180716_210332.jpg

As you can see, the PicoPSU is totally out of question and the CPU fan is hitting the ceiling, too (maybe because of the pin base, maybe because of its own height).

To be continued in the follow-up post...

[mikro]

OK, I'm not going to tease you much longer. :) Does it work? It does! It's nearly unbelievable because not only the ScreenEye driver/application works with CT60, it works with TT RAM flags enabled and without any sync issues at all!

This would be all cool and awesome except the developers had made a terrible assumption: they limited the max. number of frames to 500:

IMG_20180716_223605.jpg

Just like that? Just like that:

Code: Select all

./APP/MATDIGI.F/FILM.H:12:# define MAXframesPerSequence 500

How much does it give us? About 200 MB worth of data:

IMG_20180716_225315.jpg

What sounds like a lot (40 seconds of 1x1 recording) until you realise that's roughly one third of the capacity my CT60 is offering (856 frames more available...)

But nevertheless, the processing power is amazing. It streams nearly realtime (fullscreen 1x1 frames!!!), it definitely feels like somewhere in 20+ FPS area. The only downside is that stupid resolution. First I was thinking about my Phantom'ed Falcon to put in use (640x480@16-bit) but I realised this could lead to a worse performance in the end (bus is accelerated by about 50% but there's four times more data to process). So what to do then? Any ideas? Only if there was a card allowing to use true 16-bit hires resolutions... like, say, the SuperVidel:

IMG_20180716_230101.jpg

Will it work?! Oh yes it will:

IMG_20180716_231704.jpg

Yes ladies and gentlemen, that driver/app is so compatible that it even works with the SuperVidel!!!

And for the end, here's a live demonstration: https://youtu.be/TZ-hEQq9AeE

So, to conclude this ScreenEye/CTEX review:
+ it works with the CT60, even SuperVidel and I'm confident it would work with the CTPCI as well
+ super fast performance
+ source code available
+ sits nicely on the CTEX (but you need some support material in the front, similar as with the CT60e)
- some bugs in the app (for some reason some of the x2 modes refuse to show correctly on the CT60, if you don't name your video short enough, it starts overwriting previous frames, ...)
- terrible UI and keyboard shortcuts (with help in German...)
- to make it original case friendly I need to desolder the "pin bases", not use PicoPSU and perhaps buy a smaller fan (and I'm still not sure whether the SDRAM will fit)

[evil]

Cool that you got it working Mikro.

I think that Apex (http://www.leonik.net/dml/sec_apex.py) will also let you use the ScreenEye to record video (and, edit it).
Apex ran fine on my CT60 with SuperVidel when I tried it a couple of years ago.

[Rustynutt]

Crap, you got way ahead of me here!
Firstly, KUDUOS!
Secondly, on my AB, Expose and Apex Media will capture until the amount of RAM set aside for Apex is used up. There is no frame limit.
Screen Eye works with Apex as evil says, have you tried that (as I am typing ) ?
Thanks too for proving that cards "Undertel" the CT can use fast ram. Don't know on how many occasions I was told it would NOT work!
Wanted to believe Rodolphe.....

Feel for exxos, but great deal for you! Very clean installation.
So, reading through this, all you have done is properly install the hardware to get the ScreenEye Working?
I have a PAL Expose I could part with, it will allow much higher capture quality (SVHS-RGB) than the ScreenEye.
I'm aghast that you are getting near 20fps. Even 320*240 is considered low resolution, when working with VHS and DVD, the quality is quite high.
My AB only manages about 1/2 (12fps) full frame capture with a Nemesis at 44/22 MHz....

Guess I'm gong to have to hunt down a Falcon Rack again.....
Can you imagine, AB040-Expose-NOVA-CT60-SV-CTPCI-PCI DSP-ATI Rage video capture card (Linux sources available for capture function).

[mikro]

Yep, Apex is next on my list.

Feel for exxos, but great deal for you! Very clean installation.

Just to clarify, I bought only the CTEX from him. He had no use for it.

I have a PAL Expose I could part with, it will allow much higher capture quality (SVHS-RGB) than the ScreenEye.

There's a guy asking 500 pounds for one, if you would part with yours for not so steep price, let me know. ;)

I'm aghast that you are getting near 20fps. Even 320*240 is considered low resolution, when working with VHS and DVD, the quality is quite high.
My AB only manages about 1/2 (12fps) full frame capture with a Nemesis at 44/22 MHz....

It depends how the driver works. I was afraid that the ScreenEye directly captures images into ST RAM from the card and just displays them but fortunately the developers weren't total idiots - it stores the capture into a generic RAM and then (I assume) use VDI for blitting. So if this isn't the case with Expose driver, too bad - AB040 has a terrible performance in ST RAM access.

Can you imagine, AB040-Expose-NOVA-CT60-SV-CTPCI-PCI DSP-ATI Rage video capture card (Linux sources available for capture function).

I guess you need to leave out either the AB040 or CT60 part out of your equation. :-)

[Rustynutt]

Yep, Apex is next on my list.

No list, Doug has it all fixed up on his site (dml here).

Feel for exxos, but great deal for you! Very clean installation.

Just to clarify, I bought only the CTEX from him. He had no use for it.

Ahh, miss-read that. I have something smaller looking that came with the SV. Going to use it with the AB.

I have a PAL Expose I could part with, it will allow much higher capture quality (SVHS-RGB) than the ScreenEye.

There's a guy asking 500 pounds for one, if you would part with yours for not so steep price, let me know.

Saw that. I have a good guy Atari programmer support sale going on now. Will PM

I'm aghast that you are getting near 20fps. Even 320*240 is considered low resolution, when working with VHS and DVD, the quality is quite high.
My AB only manages about 1/2 (12fps) full frame capture with a Nemesis at 44/22 MHz....

It depends how the driver works. I was afraid that the ScreenEye directly captures images into ST RAM from the card and just displays them but fortunately the developers weren't total idiots - it stores the capture into a generic RAM and then (I assume) use VDI for blitting. So if this isn't the case with Expose driver, too bad - AB040 has a terrible performance in ST RAM access.

I'm pretty sure how the Expose works is with a 512k frame buffer and it writes directly to TT RAM (if available) until it gobbles it all up. It's much different card than the ScreenEye.

Can you imagine, AB040-Expose-NOVA-CT60-SV-CTPCI-PCI DSP-ATI Rage video capture card (Linux sources available for capture function).

I guess you need to leave out either the AB040 or CT60 part out of your equation.

Oh hell no, I love my AB Redundancy is a fanatics obsession

[wongck]

Great write up !!
Thanks for doing this...
Even greater that it works, even with that amazing stack of hardware.
If that Pico does not fit, a normal standard ATX cable & header will probably impose the same height requirements or more, will be worst.

[mikro]

If that Pico does not fit, a normal standard ATX cable & header will probably impose the same height requirements or more, will be worst.

That remains to be seen. There are solutions like this one: https://mnpctech.com/case-mods-gaming-p ... board.html plus there's always the possibility to solder the wires directly.

[wongck]

That remains to be seen. There are solutions like this one: https://mnpctech.com/case-mods-gaming-p ... board.html plus there's always the possibility to solder the wires directly.

nice find. Would be useful. Thanks for pointing it out.

[joska]

There are solutions like this one: https://mnpctech.com/case-mods-gaming-p ... board.html

I could be wrong here, but wouldn't that adapter be pointing the wrong way on a CT60? To me it looks like it will point the ATX socket towards the SIMM-slot.

This is how I solved the "PicoPSU too tall to fit the case"-problem:

2018-03-06 12.27.03.jpg

I snipped off the ATX legs on one side of the PicoPSU, bent the PicoPSU towards the back of the case just enough to fit the top lid and then resoldered it. You probably don't want to mount the PicoPSU horizontally as this might affect cooling.

[mikro]

I could be wrong here, but wouldn't that adapter be pointing the wrong way on a CT60? To me it looks like it will point the ATX socket towards the SIMM-slot.

Could be. But even it's not the case, it doesn't matter:

IMG_20180718_144815.jpg

There simply isn't enough space for anything, incl. your very elegant solution.

This really makes me wonder whether the CTEX had ever been tested before going public.

[joska]

Good point. And an even bigger problem is that it lifts the CT atleast 10mm, which - as you've already pointed out - makes it difficult to fit the fan inside a stock case.

To me it looks like the CTEX was mainly designed to create a through-port for the expansion port.

[mikro]

OK, all the issues have been more or less fixable but I have found the final showstopper: the CTEX simply doesn't allow me to have the SuperVidel mounted! Unlike CT60e, CTEX moves the CT60 way too much to the rear (causing the issues mentioned above) but most importantly, totally hadn't accounted for the fact that an expansion card for CT60 can be slightly wider than the CT60 itself.

In practice it means that one of the case columns goes to the area where the Svethlana's flat cable is connected. Therefore not only the CTPCI is out of question but even the EtherNAT. What a bummer.

What is quite ironic because the first EtherNATs had been assembled in July 2004 and the CTEX website had been introduced in August 2004 with description "This expander allows to move the CT60 at the rear of the Falcon case to avoid all place problems under the keyboard with the Fan and the CT60 add-on cards...". Well, yeah, technically speaking my keyboard is happy but it doesn't allow one single CT60 addon mounted.

[mikro]

Indeed, Apex definitely works with it:

IMG_20180718_165853.jpg

That Picture-in-Picture mode is really funny (although, I suspect due to SE's driver, a bit buggy). Since I suck at Apex in general, I was just blindly trying everything. ;) It has a nice grabbing option, I managed to save a "huge" 768x576 image:

grab1.jpeg

And as evil said, all works well with the SuperVidel, 640x400@16-bit screen works like a charm.

[viking272]

Nice write up Mikro. Thanks for posting. We really do need a larger case for Falcons with CT63 and add-ons!

[mikro]

Here's a follow-up to the CTEX confusing origin and the /EXPAND signal problems.

Rodolphe had indeed never done a single prototype of the CTEX. So that explains all the issues - I still think the idea is great, just needs an adjustment or two. So for that reason you can find CTEX Eagle files here: http://powerphenix.com/ct60/english/CTEX.htm. And as a bonus, Rodolphe sent me CTCM Eagle files as well: http://powerphenix.com/ct60/english/CTCM.htm

The "mystery" around the /EXPAND signal has been more or less resolved too thanks to https://ia600205.us.archive.org/0/items ... 3_text.pdf. A loose translation of the section we are interested in would be:

If an access to this memory area is performed, the addresses and data are placed on the VMEbus and the control signals AS, DS0, DS1, WRITE activated. At the same time the FALCON is signalled by means of the EXPAND signal that a "longer" external access occurs and the internal bus error generation must be deactivated. Thus the computer at failure of the external DTACK signal does not wait endlessly and thereby "hangs", is a watchdog timer on the rhothron VMEbus interface implemented that generates a bus error signal after approx. 20 μs.

So this has confirmed Rodolphe's suspicion, /EXPAND is suited for signal responses which take more than Combel's watchdog BERR time (16 us). That on the other hand means that the NOVA and Eclipse need sometimes more than 16 us to be accessed what is really a very long bus access. Perhaps because the Videl is busy with video ram?

Rodolphe has been even optimistic about adding /EXPAND on the ABE chip, should he find a free pin on it.

[viking272]

Did you notice the ScreenEye source code is available - I'm sure it's dotted around but its also on DevDocs:
https://www.dev-docs.org/docs/

[Rustynutt]

Here's a follow-up to the CTEX confusing origin and the /EXPAND signal problems.

Rodolphe had indeed never done a single prototype of the CTEX. So that explains all the issues - I still think the idea is great, just needs an adjustment or two. So for that reason you can find CTEX Eagle files here: http://powerphenix.com/ct60/english/CTEX.htm. And as a bonus, Rodolphe sent me CTCM Eagle files as well: http://powerphenix.com/ct60/english/CTCM.htm

The "mystery" around the /EXPAND signal has been more or less resolved too thanks to https://ia600205.us.archive.org/0/items ... 3_text.pdf. A loose translation of the section we are interested in would be:

If an access to this memory area is performed, the addresses and data are placed on the VMEbus and the control signals AS, DS0, DS1, WRITE activated. At the same time the FALCON is signalled by means of the EXPAND signal that a "longer" external access occurs and the internal bus error generation must be deactivated. Thus the computer at failure of the external DTACK signal does not wait endlessly and thereby "hangs", is a watchdog timer on the rhothron VMEbus interface implemented that generates a bus error signal after approx. 20 μs.

So this has confirmed Rodolphe's suspicion, /EXPAND is suited for signal responses which take more than Combel's watchdog BERR time (16 us). That on the other hand means that the NOVA and Eclipse need sometimes more than 16 us to be accessed what is really a very long bus access. Perhaps because the Videl is busy with video ram?

Rodolphe has been even optimistic about adding /EXPAND on the ABE chip, should he find a free pin on it.

I know with the NOVA/ATI on the Afterburner, there's a program that can be used to actually turn the VIDEL off.
Think it was actually wrote to enhance process performance where no video output was necessary. Installing it as an app, you could hot key it off or on.
Pretty sure I just ran it from the autofolder after the NOVA driver loaded.
Forget it's origin. JoEven or DML would be better users to ask.
NOVA drivers can run from alternate ram. It uses address space above 4mb of ST RAM, the reason for the ST RAM limit.

Hope you have those Falcon 040 MiNTlibs ready