New shifter implementation 'THOUGHTS'

[Badwolf]

Just chipping in on this as we spoke briefly about these boxes at Cyberlegends and I was interested in how they worked.

In more detail: Amiga had a frame buffer mode that displayed 736x483 pixels, but only 4-bits per pixel (16 colors). We used that mode, but re-interpreted the data. We combined alternate pixels so that we had 8-bits per pixel at half the rate. Even (I think) lines stored data as Y + (R-Y), Y - (R-Y), etc. [Luma +/- red color difference value, alternating] at a 7.159MHz sample rate. Odd lines stored data as Y + (B-Y), Y - (B-Y), etc. [Luma +/- blue color difference value, alternating], logically shifted by half a 7.159MHz sample. So every line would contain every other raw sample for an NTSC composite video signal. In order to reconstruct the missing data, it would generate the Y component by averaging the values left and right of the missing sample, and the chroma component by subtracting the two adjacent samples from the previous line. The final value was created by adding these values together.
...
Instead of a frame of 736x483 pixels of 16 colors, we got an effective resolution of about 368x483 pixels of full NTSC type color.

My interpretation of this is it does basically half horizontal (luma: read pixel) resolution and halves the vertical chroma (colour) resolution.

This would actually work very well with old component or composite video (he mentions NTSC, but PAL would be the same, I think) as the colour resolution is inherantly lower than the spacial (pixel) resolution. Think of how the old Spectrum colour attributes worked, but in slightly better fidelity.

I'm not convinced this would work so well with modern RGB displays, but you can fool the eye pretty well in the colour space, so it's possible.

Of course we don't have a 640x16 colour mode, so we'd be dropping down to 160x200 pixels and, I think, an effective 160x100 colour grid with about 32k colour options on average.

This relies on the unit remembering the previous scan line in order to do the maths and the ST-side software calculating the appropriate values for either the even or odds lines.

The overhead for the latter worries me. I'm not sure it would take any less computational effort than palette switching. Would be fine for static images, but then so is palette switching, albeit with only 512/4096 colour options then.

The former isn't really an issue with modern technology, but I still think the bottleneck would be ST-side.

For example, a scandoubler must remember a line at the very least. An upscaler likely a full frame. These already are doing half the work so output manipulation is almost trivial, but where do you want to spend the ST time?

• You can do 8 bit (true colour) 160x200 by just combining adajent pixels (not much overhead);
• You can do 8 bit 320x200 by having two framebuffers toggled each VBL for half the frame rate (more software overhead in maintaining the triple buffers now);
• You can do similar to what this is doing, which is a combination of the first approach with maths on adjacent scanlines (quite a bit of ST overhead, each 'pixel' has to be recalculated twice, I think);
• You could do a combination of the first and the second options and have 160x200 and up to 65k palette at half frame rate;
• Hell, you could do this for high-res mode and have 640x400 x 16 colours at 18Hz using an Amiga-style planar setup (four separate bitplanes).

I reckon all those are doable right now with a hardware dongle on the video cable only & a bit of fancy software. Which style of fancy software do you prefer to spend your CPU time on?

BW

[mrbombermillzy]

This relies on the unit remembering the previous scan line in order to do the maths and the ST-side software calculating the appropriate values for either the even or odds lines.

The overhead for the latter worries me. I'm not sure it would take any less computational effort than palette switching. Would be fine for static images, but then so is palette switching, albeit with only 512/4096 colour options then.

The former isn't really an issue with modern technology, but I still think the bottleneck would be ST-side.

I wish I had of brought *just* the Amiga with the DCTV unit to the show, as I could of shown that there is no computer side processing. Any information that is needed from the computer is encoded in the image in the form of data...as far as I'm aware, that's it.

I could have shown you a DCTV animation that runs at 50FPS in ~24bpp on an 8Mhz Amiga. There's no way even an 8bpp CLUT image has the bandwidth available for that by any other method that I can think of. This is a real cheat mode for getting this amount of colour! It even works in Workbench (no slowdown whatsoever...HONEST! )

Unfortunately, I'm not fully aware of the exact details of the HW side of the unit, or of the PAL/NTSC signal specifics. If you feel the itch to investigate further @Badwolf PM me

Also, regarding picture quality. I'm not sure if I took any pics of the unit outputting with a CVID>RGB converter on a 1084 (alas, that monitor has now been sold), but I will have a look for them. (Eventually, I will have my Aydin multisync RGB CRT wired up and I can take some pics).

But anyhow, what I DID remember about the images was the shocking crisp quality, rather than the jaggies, like I was expecting. Like you say, pixelisation is very much reduced by the PAL encoding/conversion. I don't know how it would fare with highly detailed/intricate images/small text, but then, if the new shifter is looking to go higher resolutions, then that's a problem that can be tackled too.

[Badwolf]

I wish I had of brought *just* the Amiga with the DCTV unit to the show, as I could of shown that there is no computer side processing. Any information that is needed from the computer is encoded in the image in the form of data...as far as Im aware, thats it.

I could have shown you a DCTV animation that runs at 50FPS in ~24bpp on an 8Mhz Amiga. Theres no way even an 8bpp CLUT image has the bandwidth available for that by any other method that I can think of. This is a real cheat mode for getting this amount of colour! It even works in Workbench (no slowdown whatsoever...HONEST! )

Encoded as data, sure -- how is that data generated? Something has to compute it.

If it's done it in advance, fair enough. But you mentioned full colour games. Harder.

If you're doing the encoding in real-time there has to be an overhead somewhere. You say it works with Workbench -- something must be performing the maths on the fly when you move the cursor.

BW

[mrbombermillzy]

And here is where I falter on the details

I'm sorry, but I mentioned this unit primarily for the benefit of those working on the shifter remake as a possible enhancement, but if we had to wait for me to give an in depth analysis, the Phoenix platform would probably be done and dusted already. (Hence my offering to loan the unit out to those who *can* put the time in to research this).

So, apart from the fact that I am literally 5 projects behind really testing this device out (not including learning the Amiga screen/sprite coding necessary), that testing I would have done would have been aimed at rendering with primarily sprite based screen movement rather than what I suspect the actual case may be; a whole frame rendered for any form of animation on the unit. (More research needed here). DPaint style animations can be run very fast from CHIP RAM. An ST with far more CHIP RAM (or the equivalent ST RAM) should fare better than the Amiga in this regard. So with this being the case, the games would be more Monkey Island in style than, say, Xenon 2. However, I don't want to speculate that the sprite based system is not possible until proven so.

With that framebuffer based animation assumption being the case, decoding the colour data can easily be outsourced to the DCTV device by encoding the screen buffer accordingly; the unit then grabs the data (from the Amiga's CHIP RAM), interprets the data and outputs its own image data onto the RGB lines.

As for processing delay; of course, something has to pay the price somewhere, but I believe it's processed by the unit 'on the fly' with a 1 or 2 raster delay (if what I understand from the comments of the designer is correct) which doesn't seem too bad to me.

[Badwolf]

And here is where I falter on the details

I'm sorry, but I mentioned this unit primarily for the benefit of those working on the shifter remake as a possible enhancement, but if we had to wait for me to give an in depth analysis, the Phoenix platform would probably be done and dusted already. (Hence my offering to loan the unit out to those who *can* put the time in to research this).

I think we can see how the unit works, if that were your aim. I don't think it even needs any additional work with the shifter to have the technology applied to the ST. My question is whether it offers the benefit to an ST in 2023 that it did an Amiga in 1995.

With that framebuffer based animation assumption being the case, decoding the colour data can easily be outsourced to the DCTV device by encoding the screen buffer accordingly; the unit then grabs the data (from the Amiga's CHIP RAM), interprets the data and outputs its own image data onto the RGB lines.

As for processing delay; of course, something has to pay the price somewhere, but I believe it's processed by the unit 'on the fly' with a 1 or 2 raster delay (if what I understand from the comments of the designer is correct) which doesn't seem too bad to me.

I think I've missed something in your framebuffer-based assumption.

It sounds like we're talking crossed purposes a bit. You've kind off assumed the framebuffer work is 'free'. I don't see how it's free. The hardware side isn't an issue.

Let's imagine you have a pre-computed static background. No overhead here as you worked it out in advance. It's the chroma equivalent of pre-shifting, if you like.

Now you want to draw Guybrush and his sword. For each pixel of his icon/sprite you have to do arithmetic between him and the adjacent pixels and pixels on the line above (possibly below) rather than simply overwriting the values in memory.

If he moves left on pixel, that's a whole different set of calculations. If he moves up one pixel it's a completley different algorithm.

Now if you want to animate him you're doing that several times a second.

How many pixels can you do this for before you can't hit your desired frame rate?

It sounds an interesting technology, but unless I'm missing something blindingly obvious, I think it's of its time & would have only very niche applications. Maybe it'd work with Monkey Island, but I don't think it would be viable on the desktop, for example, or for anything else that wasn't specifically targeted for pre-rendering.

Just to re-emphasise, none of this is about the hardware, BTW. I think I see how that works and it's not the issue.

BW

[mrbombermillzy]

You've kind off assumed the framebuffer work is 'free'. I don't see how it's free..//.. No overhead here as you worked it out in advance...

THAT'S your 'free' isn't it? So for image flipping the screen, viewing pictures, etc can you see the simplest application example now?

Now you want to draw Guybrush and his sword. For each pixel of his icon/sprite you have to do arithmetic between him and the adjacent pixels and pixels on the line above (possibly below) rather than simply overwriting the values in memory.

If he moves left on pixel, that's a whole different set of calculations. If he moves up one pixel it's a completley different algorithm.

Well that's the bit that needs more research. I would have said this side of things was not possible with the above reasoning (i.e. the system is just a full frame pre rendered flip screen), had it not been for the fact that you *CAN* draw to the screen quickly with small pixel precise colours (e.g. like a paint package) and at least a mouse pointer can be used over an image, so sprites shouldn't be too far out of the question and must be possible.

I would like to think you can blit/CPU move blocks over the background to provide sprite based animation, providing those blocks have been converted to the DCTV required data format, but like I said before, I'm not at the stage where I have explored whether the image is encoded as a whole, or with individual (perhaps 2x pixlel?) granularity. (I'm assuming the latter, or some form that is not the former).

Perhaps this YT video from Guru Meditation might provide more insights:

The video signal part at 21:05 seems to show the NTSC signal being changed in realtime when painting to the screen, so it seems what you are asking may be possible.

Again, apologies for not knowing all the answers or the full technical details about how it all works.

[Badwolf]

You've kind off assumed the framebuffer work is 'free'. I don't see how it's free..//.. No overhead here as you worked it out in advance...

THAT'S your 'free' isn't it? So for image flipping the screen, viewing pictures, etc can you see the simplest application example now?

What sort of game do you want where everything has to be precomputed and flipped in, though? It'd be like god awful FMV games from the mid 90s!

Anything actually dynamic, like player driven actions, needs a boatload of processing in real time.

Well that's the bit that needs more research. I would have said this side of things was not possible with the above reasoning (i.e. the system is just a full frame pre rendered flip screen), had it not been for the fact that you *CAN* draw to the screen quickly with small pixel precise colours (e.g. like a paint package) and at least a mouse pointer can be used over an image, so sprites shouldn't be too far out of the question and must be possible.

That's maybe a 16x16 grid of pixels, though. So perhaps 250 pixels per redraw. Dungeon Master would work. Would Wolfenstein?

I would like to think you can blit/CPU move blocks over the background to provide sprite based animation, providing those blocks have been converted to the DCTV required data format

The 'format' isn't so much a format but an algorithm, though. At least around the edges.

Perhaps you could blit a pre-converted graphic and maybe only tidy up the top and bottom edges?

In the video you linked you can actually see the mouse cursor changing colour around the edges as they move it, so perhaps this is merely just blitted on and they've taken the view the edge pixels aren't important?

Perhaps this YT video from Guru Meditation might provide more insights:

That was worth a watch, thanks. It's reinforced what I think I understand about it anyway. Very static image based. Even the animations that they were very impressed by are simply preconverted frames played back. The mouse moving was the 'good bit', IYSWIM and the artefacts are there to my eye.

I think it was certainly clever for its day, but I don't think it's going to do what you hope it'll do. The (new) hardware really isn't the limiting factor.

Cool to think about, though.

BW

[mrbombermillzy]

Well, look, Digital Creations is certainly not paying me to sell their product and I'm sure everyone's probably had enough of hearing about this damn thing, so I will let it go now!

If I can just fire one last salvo though:

Even with the apparent limitations you have stated, the unit is still good for so many other fields (barring fast action gaming allegedly ). There's lots of productivity software that can benefit from this (i.e. Video/DTP/Image editing/raytracing, etc) without the screen being redrawn at a treacle slow speed. Consider just the file size reduction on its own, being that its just a 4bpp image file.

You mentioned about the use of the device on an Atari in 2023 vs an Amiga in 1995, well, there's not going to be that much difference even today. You are still going to feel the crunch of millions of colours on the relatively similar bus/CPU speeds. (I could point you to another video of an A1200 with an 060 showing a slow anim with HAM8 vs a fast one with DCTV, but I guess the point is taken.)

What I would do regardless of any limitations of the device, is take the good parts of it and blend with what is needed if it's absolutely not possible to do the required gaming stuff fully contained in the unit.

For example, as gaming is an important factor, if the above discussed sprite style movement cannot be realised on just the unit, then perhaps there is a way of overlaying sprite images onto the background from the unit. (You could probably do this 'as is' as the device plus the RGB converter is genlockable, but I was thinking more of a non pre-millenial broadcast standard version of it.)

IMHO its worth more than a cursory glance as the savings in data travelling around the system alone is phenomenal for the images displayed, but there's precious few who know how this thing really works and can point out any benefits/limits and its true method of operation for certain. (I'm certainly not much help here).

Anyway, unless anyone else has a new take on all this, perhaps we need to move on.

[Badwolf]

There's lots of productivity software that can benefit from this (i.e. Video/DTP/Image editing/raytracing, etc) without the screen being redrawn at a treacle slow speed. Consider just the file size reduction on its own, being that its just a 4bpp image file.

DTP at 160x200 with NTSC levels of spacial colour resolution and its own pre-converted GUI?!

I think it's a really interesting bit of history, but i genuinely don't think it does what you think it does.

Anyway, unless anyone else has a new take on all this, perhaps we need to move on.

BW

[mrbombermillzy]

DTP at 160x200 with NTSC levels of spacial colour resolution and its own pre-converted GUI?!

Well, you got me there! Oops!