Talk:Hold-And-Modify

Merge with what now?

The description of the control bits is wrong. I believe 01 changes the blue component and 11 changes the green component.

Maximum resolution on A4000 in HAM8

The maximum resolution available in HAM8 mode was 1440x576, it was useable if one had a 24bit source data. In case of a render (i.e. Lightwave) one could render straight into this resolution and convert to 1440x576 (Super Hi Res Overscan) HAM8 in ArtDepartamentPro. Alternatively it was possible to simply upscale image to 1440x576 and then convert to HAM8 to reduce fringing.

Such series of frames could then be displayed in SCALA and recorded frame-by-frame to BetaCam (required RS442 interface to control the video recorder). It was the poor man's frame buffer and at broadcast-quality it was indistinguishable from one.

I will update the HAM8 section in a week or so if there are no objections. —Preceding unsigned comment added by 84.9.164.63 (talk) 00:19, 3 March 2009 (UTC)

Animating HAM images

As far as I understand the concept of HAM when changing a section of the screen in the course of an animation at maximum the 3 pixels right of the animated part have to be recalculated: Changing to an arbitrary colour might need changing colour values for red, green and blue separately. But if a pixel retains the original color it had before drawing the animated part all pixels to its right (that depend on its color) schould work again automatically. As I understand it the article currently states that the whole image has to be recalculated once a thing at the left of the screen changes. --Peterpall (talk) 05:21, 5 April 2012 (UTC)

The problem is that it doesn't follow a set pattern of Index - modify red - modify green - modify blue - index - etc etc. Depending on the image content, you could have a single index at the start of a line (assuming the colour value can't be held from the end of one line to the start of the next), and then an unbroken run of "modify" commands across the entire line, maybe affecting only one channel even. EG, if it starts as a sort of peach colour, and then only changes the blue channel, varying between a medium brown (0 blue) to a pale magenta (15 blue) across the line. So you're not guaranteed of a changed pixel only affecting the following 2 or 3; potentially, an altered pixel near the left of a line could affect *all* of the rest of the line, or certainly a large chunk of it. (And, consider that a "modify" command could equate to a "change nothing", if there's no palette entry that directly matches it, and it's set to modify an arbitrary channel "to" the same value that it already holds... but changing a pixel to the left of a run of such "no change" commands would then mean the whole run changes colour, and not necessarily to the same colour as the one changed pixel if it sets a value on that channel that's different to the "modify" ones).

It is, actually, just as complex as originally claimed. You can of course make sure the HAM image in question is synthesised so to be built out of regular 4-pixel, index-modR-modG-modB blocks, but that's additional complication in of itself, and there's no reason why any given image would convert nicely to that kind of format. And you still end up having to dynamically alter enough of the underlying image, even if you're just patching in precalculated blocks using the blitter function (never mind recalculating from scratch using the CPU) to completely negate the performance advantage of the Copper, sprite engine etc. So your game or animation may look really nice, but it'll run slower and more jerkily than a plainer looking version on the ST or IBM PC, and one of the Amiga's main benefits, more than its enhanced colour abilities (enough games ran in basic 16-colour mode that use of 32- or 64-colour was sufficient for a box boast), was how silky smooth games ran when programmed to take full advantage of the hardware. By the time the computing side of things was even remotely powerful enough to carry out that kind of recalculation on the fly, the video hardware had advanced in kind and made HAM an irrelevance anyway.

(another way to think of it is like trying to alter a single pixel within an RLE encoded image file, like a GIF, PNG, Packbits IFF, Atari Degas PC1, PCX, compressed BMP etc... depending on how the rest of the data is arranged, that one changed pixel may only affect itself, or it may affect 2 or 3 to the right, or it could end up screwing with a large block - maybe a whole line or more - in unpredictable ways. I don't know of any software that attempts such changes because of that unpredictability and the great amount of complex analysis and recalculation that would be required. It's much simpler, and, at least on average, no slower, to just recalculate the entire compressed version of the image for saving to disk from the uncompressed version in memory. HAM works somewhat similarly, just instead of losslessly compressing a fixed amount of image data to a variable amount of encoded data, it lossily compresses to a fixed size, keeps that data both on disk and in memory, and notionally decompresses to a variable amount of perceptual info on the fly... the best you could maybe do is keep an "uncompressed" 12bpp version in memory somewhere and use that as your template for regenerating the changed parts, but that would still demand quite a bit of extra memory - at least twice the actual framebuffer - and work to rebuild the 6bpp version that would mean shunting 3x the normal amount of data for that chunk of the image back and forth in memory as well as doing the actual calculations...) 146.199.0.169 (talk) 00:52, 7 May 2019 (UTC)

Aspect ratio

I remember creating some HAM graphics with a Photoshop export plug-in. It seemed HAM used a very wide pixel ratio. What was the screen resolution of HAM images?

The screen resolution was LoRes or LoRes-Laced. In PAL areas, this was 320x256 or 320x512. In NTSC areas, this was 320x200 or 320x400. HiRes (640 width) didn't support HAM, at least not on OCS/ECS Amigas, I believe that the AGA Amigas could do this though (I never had one, so can't be certain).

--193.120.178.201 16:46, 26 July 2006 (UTC)

AGA did allow HAM mode to be used on 70ns (HiRes) and 35ns (SuperHiRes and Productivity) resolutions. --Safalra 16:20, 19 December 2006 (UTC)

OCS and ECS did not have the bandwidth to support fetching more than 4 bitplanes in Hires mode, hence they could not support HAM in Hires or higher. AGA could display all 8 bitplanes in all modes, thus it could display HAM in any mode. 62.31.67.29 15:57, 16 February 2007 (UTC)

lossy compression?

I would say it's more quantisation than lossy compression. What do people think? 62.31.67.29 15:57, 16 February 2007 (UTC)

Isn't all computer graphics quantisation? I think that "lossy compression" is a better term. Val42 19:39, 17 February 2007 (UTC)

Since it takes 3 pixels to modify one color to another color, HAM effectively reduces the color resolution to 230 horizontal. DVDs also reduce color resolution (350 across) as does NTSC/PAL broadcasting (~160 across). All of these are lossy compression techniques that seek to squeeze the color information into a lower resolution that the original source. - Theaveng 16:58, 2 September 2007 (UTC)

Wouldn't it be easier to understand if it was called analogue lossy compression? It's digital, alright, but the principle are (as with PAL/NTSC) analogue. /LypsylateX 2017-03-19 — Preceding unsigned comment added by 79.136.72.85 (talk) 00:07, 19 March 2017 (UTC)

When I read analogue compression I'd think of something completely different. Note that it's also not only chroma subsampling like in MPEG-2 – originally, it was intended that way when the chipset was to use YCbCr – but also a reduction in luminosity resolution, so imho it's just 'lossy'.

Well, I suppose whether it is quantisation or compression depends precisely on which pixel you're looking at. HAM may produce a pixel that is exactly the desired color, slightly inaccurate due to quantisation, or one that is significantly inaccurate due to loss associated with data compression. I think that the term 'lossy compression' is best. HAM exists to save bus cycles and RAM, and ultimately everything that HAM is comes down to that, so I'd say it's a really specialised form of hardware compression. - Richard Cavell (talk) 11:24, 14 December 2008 (UTC)

Since HAM is a hardware format it would be missleading to call it "lossy compression". If you display a 16M colour image on a 256 colour VGA screen you wouldn't call that "lossy compression". // Liftarn (talk) 21:06, 14 December 2008 (UTC)

I don't see that the fact that it exists in hardware makes any difference to the question of whether it is compression or not. If you create images in HAM format with the intention of displaying them in HAM, then I suppose it is not compression. Since there is nothing to which the image can be decompressed, there is no compression going on. But if you rendered a 3D image into 4,096 colors, you would need to HAMify it in order to display it, and this means removing half the data in the original image while trying to preserve as much fidelity as you can. You could also do some serious programming and planning (and slicing with the copper) to try to do a better job of compressing the data to minimise the loss. I think that your latter example of displaying truecolor on a 256 color screen represents quantisation, not compression. - Richard Cavell (talk) 23:13, 14 December 2008 (UTC)

I personally am fine with the word "lossy compression": You save a certain amount of bandwidth and loose a bit of information. Besides that HAL works a little bit similar to runlength- or delta coding. But I have to admit it is no typical compression scheme. "Quantisation" isn't a bad word, either, but normally implies that some colour values cannot be reached at all (as opposed to HALs limitation that every colour can be reached within the range of 3 pixels). --Peterpall (talk) 05:29, 5 April 2012 (UTC)

Sliced HAM (SHAM or SHM)

No discussion about Sliced HAM? This was a technique used on the original Amigas to use all 4096 colors without the "blur" of HAM. It required the full attention of the CPU (i.e. minimal multitasking), but the pictures were beautiful and crystal-clear. I stopped using HAM after I discovered Sliced HAM mode. - Theaveng 17:02, 2 September 2007 (UTC)

We need external references to add this information to the article. If you can find such references, go ahead and add it. — Val42 16:07, 3 September 2007 (UTC)

The CPU wasn't the chip that did the slicing, it was the copper. The CPU set up the copperlist but otherwise did no work to enable slicing. A very clever programmer could create dynamic sliced HAM images by using the CPU to intelligently recompile the copperlist every frame, but I'm not aware of anyone having done that. There are no real applications for it. An AGA Amiga could be programmed to produce output as good as modern 24-bit colour chunky graphics card, but you'd be caning the CPU. You'd be caning the copper as well, but the copper can't be used for general purposes so you might as well use the bus cycles. - Richard Cavell (talk) 11:13, 14 December 2008 (UTC)

Also unless you were doing something akin to Spectrum mode on the ST (continually updating the palette indices as fast as possible even during the active part of the image, literally "racing the beam" a la Atari 2600), which thanks to the increased bus contention on the "chip" side of the system (6 bitplanes means half of the "CPU", and also Copper, memory cycles are "stolen" by the simple task of transferring data from the framebuffer to the DAC) probably can't reach the same extent (the ST manages about 45 colours, from the same 16-colour palette; Amiga in HAM mode might manage 30?), you won't be able to build any but the most synthetically HAM-suitable picture "without the blur". SHAM will just *reduce* the blur, by letting you pick the 16 most suitable index colours per line, instead of having to share them across the entire frame... And heck, even getting 30 or so indices per line may not be enough for the most demanding images. I've seen HAM8 images with discernable artefacting after all.

(I also wonder if you could even switch all 16 colours in the available blanking area - the Amiga has somewhat less border/overscan, and can do less stuff per unit width of that space. Besides the actual video data, you can transfer, what... 8 words of sprite data, 2 of audio, and another 2 of memory refresh? With any but the most minimal overscan eating into those. And updating a palette index requires MOVing a word apiece, or the equivalent of it mediated by the Copper. You'd have to be pretty smart about your timing and what overlaps where in order to manage more than 12 new colours per line, maybe restricting what registers could be used in the last 16~32 pixels of one line and the first 16~32 of the next, say... before we even start to think about progressively updating them, at a slower rate, with absolute to-the-pixel accuracy, along each scanline itself...) 146.199.0.169 (talk) 23:18, 6 May 2019 (UTC)

The horizontal blanking area along with the left boarder area for each scanline allows enough time for the copper to change 14 registers if naively waiting for HPOS=0. 16 changes are possible if the copper moves are begun just after the end of display fetch and before horizontal blanking begins. In any event, the process described in the article is wrong for the Amiga, but common on other machines (interrupting the CPU to do the work). — Preceding unsigned comment added by 47.206.72.121 (talk) 02:58, 3 February 2020 (UTC)

Thanks for pointing that out. I have rewritten the section with a more accurate description. --Zac67 (talk) 05:53, 3 February 2020 (UTC)

Rename this article

The Hold-and-Modify article just redirects to here, so this article should take that name. At least, it should be renamed to "Hold-and-Modify (Amiga)". — Val42 19:12, 3 September 2007 (UTC)

Requested move

The following discussion is an archived discussion of the proposal. Please do not modify it. Subsequent comments should be made in a new section on the talk page. No further edits should be made to this section.

The result of the proposal was move to Hold-And-Modify. JPG-GR (talk) 20:11, 2 January 2009 (UTC)

Amiga Hold-And-Modify → Hold And Modify — There is no other article that could be called 'Hold And Modify', and the word 'Amiga' is implicit when talking about HAM. I compare this article to the VGA equivalents, Mode 13h and Mode X. Neither of these has the words 'IBM', 'IBM-compatible' or 'VGA' in the title. Also, please discuss whether we want hyphens in the title. - Richard Cavell (talk) 11:03, 14 December 2008 (UTC) — Richard Cavell (talk) 11:03, 14 December 2008 (UTC)

Survey

Feel free to state your position on the renaming proposal by beginning a new line in this section with *'''Support''' or *'''Oppose''', then sign your comment with ~~~~. Since polling is not a substitute for discussion, please explain your reasons, taking into account Wikipedia's naming conventions.

Discussion

Any additional comments:

• The section that starts with "The total number of pixels in a HAM8 image cannot exceed 414,720 (720*576)" is just plain bogus - HAM8 is not limited to the screensize of PAL super-hires interlaced with full overscan. One can for example use 912x624 with Super72, or even 1024x768 with HighGFX, all this on regular AGA chipset. —Preceding unsigned comment added by 158.38.160.150 (talk) 01:50, 21 December 2008 (UTC)

• Actually "Mode X" should not be without a modifier, since there are Mode-X's in things other than VGA, and it's unlikely that Mode-X for VGA is most common or primary meaning in the world at large. 76.66.195.159 (talk) 15:00, 21 December 2008 (UTC)
  • WTF do the above two comments have to do with the proposed move? Nil Einne (talk) 11:59, 27 December 2008 (UTC)

• Looking at the history sections, back in 2005, the article was at Hold And Modify, and was moved to Hold-And-Modify. Then in 2007, it was moved to the current location, Amiga Hold-And-Modify. I haven't gone back to see if I can still find the reasonings for those moves, but I would like to include it in the discussion, and also note that at some point, some people believed that Hold-And-Modify was preferable over the current name, and over Hold And Modify. Martijn Hoekstra (talk) 17:16, 26 December 2008 (UTC)

The above discussion is preserved as an archive of the proposal. Please do not modify it. Subsequent comments should be made in a new section on this talk page. No further edits should be made to this section.

picture showing clearly the artifacts that might happen with this format?

I think it would be good to have image(s) showing clearly the potential issues with this format, the animation linked in the bottom, at least for me, make it seem that the format is capable of relatively high quality results with animation. --TiagoTiago (talk) 11:54, 3 May 2009 (UTC)

There's maybe a terminology confusion in play. "Animation" in this context can both mean the pre-baked (and pretty computationally intensive - I doubt even the heavily accelerated machine used to make it would have managed more than one frame every few seconds) animation behind the link, and the much more "live", instantly generated moving images of a game. It's entirely possible to stack up a bunch of individual HAM images in memory and rapidly flick between them to produce a full-frame but not particularly interactive animation, that's not in question. But the matter of producing a dynamic and interactive game or other application using HAM is something quite different, and much more challenging, especially given the relatively weak general purpose computing hardware attached to the video chipset (which is entirely specialised for decoding, not generating new HAM images). Regular 32- or 64-colour games already routinely push the limits of what the machine can handle; throwing in all the extra calculations, data moves, and moving-object traces that HAM would require would go very much over the edge unless you dramatically restricted the resolution... which kinda misses the point of what the mode is for in the first place, and would make it much easier to achieve much the same effect using a simpler and more conventional one. 146.199.0.169 (talk) 23:24, 6 May 2019 (UTC)

Third party hardware section

No mention of DCTV? — Preceding unsigned comment added by Bofum (talk • contribs) 22:27, 30 July 2011 (UTC)

External links modified

Hello fellow Wikipedians,

I have just modified one external link on Hold-And-Modify. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

• Added archive https://web.archive.org/web/20061102132148/http://www.amiga-hardware.com/showhardware.cgi?HARDID=481 to http://www.amiga-hardware.com/showhardware.cgi?HARDID=481

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 20:26, 5 November 2017 (UTC)

Rewrite the description of HAM

I read the description of HAM, and would not understand it very well (I have a PhD in CS!) So some information is dynamically provided for each scan line, and this information determines which 32 colors are displayed on that line. Each scan line can have different 32 colors. This is what I understood, but the description was not sufficiently clear to understand the details of this scheme. Could somebody go through it and make it understandable? — Preceding unsigned comment added by 130.233.97.85 (talk) 04:50, 10 December 2018 (UTC)

Essentially, a HAM pixel either directly addresses one of the first sixteen color registers or Holds any two of its predecessor's RGB values And Modifies the third to any value. HAM can display any of 4096 colors in any scanline but may need three pixels to reach the desired value, depending on the preceeding pixels. --Zac67 (talk) 07:18, 10 December 2018 (UTC)

I've just committed a wholescale edit to a particular couple of paragraphs that looked like they were written by a young child. Don't know if that's the parts you had in mind, but maybe? I'll have another run through and see if the actual concept of the mode is properly explained anywhere, as it's familiar enough to me that it's not something I would have particularly looked for (I came here seeking a reminder on how HAM8 worked, rather than the technique in general).

In any case, you seem to have grasped how the general Amiga graphics hardware (as well as that of any other similar framebuffer based computer, regardless of colour depth - the IBM graphics cards, Atari ST, etc) works, but not HAM. To boil it down, the regular indexed-colour modes allow upto 5 bits per pixel (or 32 individual palette registers) to directly set colours, out of a 12-bit (4096-value) master palette. EHB mode pushes this to 6bpp, but the extra 32 colours (64 total) are just simulated by halving the intensity of the first 32; even so, this is still an otherwise conventional indexed colour mode, the number assigned to a pixel directly maps to a particular colour in the palette.

HAM works somewhat differently; using the same 6 bits per pixel (the bandwidth limit in low rez mode, which already slows the CPU down some; going to 8bpp, equivalent to the 4bpp possible in the hi-rez mode intended more for word processors et al, would make everything run way too slowly for a playable game), it produces the near equivalent of a 12bpp mode (free choice of 4096 colours per pixel) by using the data in memory as more of a coding system than just a straight stream of colour values, with its history (pre switch from HSV to RGB colour model) as a way of emulating the colour decimation modes used by most digital video systems evident in its design. This code divides the six bits of data per pixel (more correctly, six bitplanes, which are held separately in memory, and read in blocks of 16 pixels by 1 plane at a time, just fast enough to keep up with the rate the recombined pixels are streamed to the monitor) into two blocks: a 2-bit code block, and a 4-bit value block.

The code is deciphered, for "00", as "set pixel to palette index in the value block"; for 01, 10 and 11, it is instead "change the <red, green, blue> channel to the intensity given by the value block, and carry over the values for the other channels from the previous pixel". The four bits of the value block map directly to the 4-bit (16-level) intensity value of each colour channel (thus 12 bits, and 16x16x16 = 4096 possible values for 3 channels), and allow a choice between 16 directly settable colours in the index registers. This allows a reasonable compromise between the simple and clear, but sometimes colour-limited, 320x200 16-colour mode common to several other machines, and the more colourful but harder to program for, generally lower-horizontal-rez, and artefact-prone hold-and-modify idea (which without the indices could have had something more useful like "adjust intensity of all channels up/down by 1~8 steps" for its fourth code) - without taking the otherwise obvious and more common route of just reducing the horizontal resolution directly to increase the per-pixel colour depth.

For example, dividing it in two would allow a 160-pixel wide mode with 8 bits per pixel, and the highest possible system performance for the architecture; or somewhere around 213 pixels (likely 208, or 224 with overscan) with a 1.5 divider (more simply, one-third the hi-rez clock) with a full 9bpp with the same performance as EHB or HAM. However, these would give a decidedly coarse appearance, more in line with an older 8-bit computer or console, and without the potential for drawing the more detailed but less colourful parts of the image in full 320-pixel resolution. Also, to make full use of these modes, the video chip would have to be supplied with a great many more palette registers - not just 32, but at least 128, maybe even 256 or 512, depending on how halfbrite mode etc could be leveraged, and it simply wasn't possible with the technology of the time to squeeze that much "static" memory into an otherwise general purpose video chip. An alternative for the 9bpp mode would be to directly set the upper 3 bits of each channel, but as demonstrated by the "Spectrum" software-trick modes on the Atari ST, the benefit of RGB direct colour doesn't really come into its own until you have at least 12bpp to play with; a 512-colour palette still has somewhat too-obvious quantisation steps even if you can use each colour more or less freely, and the main way of working around that is to use dithering... which itself is a bit too obvious with resolutions of 256 or below.

So HAM, whilst flawed, is a quite innovative and effective alternative to the traditional method of simply trading off resolution for colour depth in a fixed-bandwidth system, especially where you're already able to set a higher pixel bit depth than can be entirely supported by the available palette register space.

What I don't know at the moment, and came to the Talk page to ask, is how it interacts with the sprites. Does the "playfield" background continue to be updated, including for HAM, "behind" the sprites? Or does the colour value of each (2bpp/4bpp, thus 4- or 16-colour, and more usually 3+transparent/15+transparent) sprite's pixel directly affect the part of the DAC that HAM acts on, thus becoming the colour which the background HAM pixels end up working on? (after 3 or 4 pixels you'd expect the effect to be wiped out anyway, but they could still end up leaving colour streaks/trails to their right...) 146.199.0.169 (talk) 23:48, 6 May 2019 (UTC)

Sprites vs HAM

Given that sprites are mentioned as a way of achieving dynamic/interactive "animation" in HAM, and that would probably have been a primary aim of the mode in the original games console design (for e.g. a mostly static, maybe scrolling background with sprites moving over it)... how do they actually interact? Do the (4 or 16-colour) sprites share the same palette as the indexed part of the HAM, or a separate half of the total 32? (Which would admittedly be at odds with e.g. Dual Playfield mode which just has two sets of 8) ... and does the background/playfield data continue being processed HAM-style "behind" the sprites, with the sprite pixel data having no effect on the calculated output value, or do they interact with the sprite's colour value then feeding into the HAM? The way the mode work sounds rather like the DAC value is updated either wholly from the palette or partially using the single-channel data from the bitplanes... the question is where the sprite value gets switched in and if the playfield value is held separately to the actual final DAC output.

It's not like a typical console sprite engine after all where the chipset switches where it's reading pixel data from (and the palette in use) on the fly, instead it pre-reads all the sprite data into the Copper during the preceding HBlank, so it could well have a parallel processing setup where the playfield framebuffer keeps being read even whilst hidden behind a sprite... but that then means there's two places where data is read out of the palette, decoded to a 12-bit output value and then held and switched between... and the palette must be dual ported to allow a different value to be read by the HAM hardware and the sprite hardware simultaneously (or at least, dual-banked, so the sprite and the HAM can each read from a different set of 16 at the same time).

Otherwise, you necessarily end up with the sprite colours overriding those from the playfield framebuffer, thus affecting any held/modified values in pixels further along the line... 146.199.0.169 (talk) 00:22, 7 May 2019 (UTC)