From Wikipedia, the free encyclopedia
Jump to: navigation, search
WikiProject Computing / Amiga (Rated Start-class, Low-importance)
WikiProject icon This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
Start-Class article Start  This article has been rated as Start-Class on the project's quality scale.
 Low  This article has been rated as Low-importance on the project's importance scale.
Taskforce icon
This article is supported by WikiProject Amiga (marked as Mid-importance).

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[edit]

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 (talk) 00:19, 3 March 2009 (UTC)

Animating HAM images[edit]

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)

Aspect ratio[edit]

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).
-- 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. 15:57, 16 February 2007 (UTC)

lossy compression?[edit]

I would say it's more quantisation than lossy compression. What do people think? 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)
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)[edit]

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)

Rename this article[edit]

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[edit]

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-ModifyHold 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)


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.


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 (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. (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?[edit]

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)

Third party hardware section[edit]

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