Talk:Hold-And-Modify

message: 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)
thread_title:  Maximum resolution on A4000 in HAM8 

message: 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)
replies: text: AGA did allow HAM mode to be used on 70ns (HiRes) and 35ns (SuperHiRes and Productivity) resolutions. --Safalra 16:20, 19 December 2006 (UTC)
replies: text: 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)
thread_title:  Aspect ratio 

message: 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)
thread_title: Rename this article

message: 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)
replies: text: 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)
thread_title:  picture showing clearly the artifacts  that might happen with this format? 

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

message: 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.
Cheers.—InternetArchiveBot (Report bug) 20:26, 5 November 2017 (UTC)
thread_title:  External links modified 

message: 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)
thread_title:  Sprites vs HAM