Look what Ive just nabbed off Ebay...

[mrbombermillzy]

This could end up an ongoing 'blog', as despite the horrid mess that that place has become, I still do manage to find the odd bargain now and then. Whether that's due to judicious logic, or pure luck is open for debate.

Nevertheless I will carry on with the show;

Today's bargain find was a DCTV unit for the Amiga with the extra RGB converter included:

s-l1600.jpg (150.44 KiB) Viewed 6392 times

Now Im still waiting for the unit to arrive, but from what I have read up on it, the ramifications were both huge and mainly passed by at the time.

Basically, its a unit that puts some 'magic cookie' pixels in the top few rasters of the display which then kickstarts (excuse the pun) the unit into displaying through its own custom framebuffer. Its fully compatible with the OS and can be switched in when needed.

From what I can glean, it uses a similar technique to the C64 to display extra colours (i.e. a bitpattern), but in this case, the colour count increases dramatically due to colour compression I believe, with 3bpp being able to display around 256000 colours and 4bpp managing around 2 million.

Now that's all well and good, you say; the PC/Rpi/etc can do that. However, the big thing here is the bandwidth of the thing.

Using 3 bpp to sling stuff around the screen is something easily attainable on the 16-bit class computers. If only Commodore (or indeed Atari) had developed this compressed bandwidth display system and included it into their machines... forget AGA!

Below is an example of the image quality on an Amiga.

I'm still waiting for it to arrive, but I was so excited, I just had to say something!

Oh and don't worry, I WILL attempt to get it to work on the Atari line if its at all possible!

hqdefault.jpg (12.6 KiB) Viewed 6392 times

[Higgy]

Nice.
The logo looks familiar, it was probably reviewed in Amiga Format or they advertised it heavily in there.

[mrbombermillzy]

Well, I've not got it yet, but by the looks of it, it's got a fair chance of working on an ST. (I wonder if I have the right lead handy?)

I believe it needs either 5 or 4 bitplanes to work successfully.

However, I just found out that someone had managed to use it with 3 bp, but the colour count was a fair bit more reduced.

What the heck though, if I can get more than 16/4/2 colours for free on the ST (at no extra processing cost ) then who cares?

I won't speculate any more until I have looked at it properly.

[mrbombermillzy]

OK. Ive just recieved the unit in the post and have somehow managed to find the time to hook it up to my A500 and Dell 27" TFT for a quick look.

Below are a few of the example images using just 4bpp:

P1030937.JPG (79.41 KiB) Viewed 6221 times

P1030935.JPG (102.8 KiB) Viewed 6221 times

P1030934.JPG (111.43 KiB) Viewed 6221 times

Unfortunately, the composite video signal is not great for signal noise (however, it looks better in these photos).

Here are some images of the actual unit itself. Looks like this one may have been used by Universal Pictures at some point:

P1030943.JPG (109.72 KiB) Viewed 6221 times

P1030942.JPG (110.67 KiB) Viewed 6221 times

I think the images are very impressive for just 4bpp of colour information. However, I have found that unofficially, 2bpp can be used too (needs a generic file viewer that does not change the image; the DCTV software will NOT display it; I actually used Brilliance as can be seen further down).

Below are some of the 'standard' 4bpp images along with the 2bpp image below it for comparison:

P1030938.JPG (105.4 KiB) Viewed 6221 times

P1030944.JPG (135.96 KiB) Viewed 6221 times

This pair are easier to spot the difference on; you can see the coarser banding in the shape colour transitions:

P1030946.JPG (88 KiB) Viewed 6221 times

P1030945.JPG (93.62 KiB) Viewed 6221 times

As you can see, even using 2bpp is impressive and a ~8mhz 68000 would have been able to throw a lot of sprites around the screen at a high framerate with lots of colours. I cannot understand why this method was not licenced by Commodore to enhance the Amiga graphics.

The only downside that I can see is that the image needs the top (few?) raster to contain the 'magic' combination.

Animated images seem to be fine. The image below is animated very fast and is a fly through the canyon (unfortunately, you cant see the sheer speed of it in a still photo, just a bit of blur as it is changing the frame):

P1030936.JPG (83.62 KiB) Viewed 6221 times

I must apologise for the rather 'soft focus' of the image quality. Hopefully all the above images are not too bad. I had both a tempramental camera and a noisy composite output into my monitor. But I guess (excuse the pun) you get the picture!

I do actually have the RGB converter box with it and Im looking to dig out my 1084 monitor and hook it up to see how much sharper the images are (amongst other things which I have planned with this unit).

Unfortunately, thats a task for another window in time... Im actually meant to be looking after kids, finishing off a game, porting it to 68k AND producing a high colour TT display program, so it may have to wait for its turn again. (My life is like a multi-tasking OS with too many programs running!)

[Steve]

I don't fully grasp what it is, is it a kind of external video card? Does it not mix back into the Amiga frame-buffer, just a pure composite output I presume for television stuff?

[xyzzy76]

Here is a post that has lots more info and also technical details:

https://retrocomputing.stackexchange.co ... -dctv-work

[mrbombermillzy]

@Steve One of the downsides is that I didnt get any manual or even a box with it.

Thanks for the link @xyzzy76. I have seen that already. If anyone has a manual for one or a better understanding of the technical aspects of the PAL unit, I would be most grateful for any help!

[matt020]

I got a chance to play with one at high school in the 90's.

Its an external box that provides 16M colour output, but it would only do this using its own software.

So Workbench screens could not take advantage, for example.

I don't even think paint programs could take advantage of the extra colours, it was only the DCTV software that could do it.

In the 90's, if you had an ECS machine with a DCTV connected, it was mind blowing to be able to use that many colours with your artwork. But other than a proprietary DCTV paint and DCTV animation application, it couldn't be used for much more.

Happy to be proven wrong. This is from my experience and memory from using it around 1992...

[mrbombermillzy]

Well, the actual images can be used outside the app (as was shown in a post further up) with a normal image viewer, as long as it doesnt change the file at all and also the DCTV image standard was adopted by a fair few other art type apps too and some could playback the videos/anims, or raytrace render to DCTV format.

There is also a few nice apps for it that were made over the years, like a HAM8 viewer.

What would be really great though, was if I could harness the image format for some sort of playfield/sprite use, but Im not sure thats possible... yet.

[mrbombermillzy]

MINOR UPDATE:

So, (don't get excited) just as a minor clarification about using this on an Atari...

I've been researching the subject for a while. Despite a quite good technical description of how the results of the DCTV are achieved (see links posted above), there's no documentation about how this is achieved from a hardware standpoint.

Well, there are several competitors that use the same sort of technique (HAM-E and Colorburst being some notable examples) and fortunately, the M.A.S.T. guys (Colorburst) spilled the beans to some extent.

It appears that on MOST of the Amiga range, there is a RGBI TTL signal present on the monitor pins. (I can't imagine someone buying an Amiga back in the day and having to use a CGA type monitor with it...no HAM for you! lol) Anyway, these spare bits are used for the analog RGB data (in what exact manner is still unknown, although I would go as far as speculate it's for storing compressed data into 4+4=8 bitplanes)), but it's enough information to make the DCTV almost impossible to work on the ST(e).

There MAY be an option on the TT by using the ECL output as colour data, (or even some sort of collaboration with a VME GFX card, but if you have one of those, why bother?) but then there is the question mark of the exact 'magic data' position on the screen. That information might be attainable from a disassembly of the DCTV libs though. We will see.

To be continued...