Talk:Hold-And-Modify - Knowledge (XXG)

565:(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...) 1403:

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.

1157:

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.

554:

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

560:

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.

830:(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...) 1446:

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.

827:

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.

1382:

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.

1393:

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.

746:

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. -

1450:

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

80: 53: 148: 22: 1372:

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.

446: 1423:

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

1156:

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

1038:

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

783:

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

1449:

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

1412:

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

538:

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. --

1371:

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

1342:

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

844:

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

826:

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

762:

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,

553:

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

1445:

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

1402:

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

1361:

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

500:

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

716:

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

559:

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

803:

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

664:

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

537:

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

1381:

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

745:

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

1392:

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

1319:

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

589:

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

1422:

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

1106:. 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. 504:

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.

1140:

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.

621:

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.

717:

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. -

1062:

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.

731:

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". //

1453:

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...

1009: 804:

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

674:

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

1496: 1362:

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

953:— 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, 1261: 1257: 1243: 763:

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

703:

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'.

585:

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?

1320:

understood, but the description was not sufficiently clear to understand the details of this scheme. Could somebody go through it and make it understandable?

138: 1391:

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: -->

1481: 128: 1476: 104: 1491: 162: 961:. Neither of these has the words 'IBM', 'IBM-compatible' or 'VGA' in the title. Also, please discuss whether we want hyphens in the title. - 845:

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

1046: 808:

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. -

1486: 1454: 1424: 1327: 1158: 1063: 852: 831: 566: 288: 1229: 896:

article just redirects to here, so this article should take that name. At least, it should be renamed to "Hold-and-Modify (Amiga)". —

681: 284: 87: 58: 1239:

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

515: 324: 1501: 1013: 33: 794:

We need external references to add this information to the article. If you can find such references, go ahead and add it. —

175: 157: 63: 365: 492:

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

1304: 1129:

Subsequent comments should be made in a new section on this talk page. No further edits should be made to this section.

919:

Subsequent comments should be made in a new section on the talk page. No further edits should be made to this section.

1193: 1111: 1260:

to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the

1050: 39: 21: 1458: 1428: 1331: 1162: 856: 835: 570: 1295: 1221: 1067: 974: 966: 813: 751: 722: 685: 1323: 1181: 1042: 848: 677: 519: 511: 1217: 594: 471: 372: 100: 1279:

If you have discovered URLs which were erroneously considered dead by the bot, you can report them with

1267: 1107: 1103: 946: 606:

AGA did allow HAM mode to be used on 70ns (HiRes) and 35ns (SuperHiRes and Productivity) resolutions. --

389: 378: 103:

on Knowledge (XXG). If you would like to participate, please visit the project page, where you can join

1220:. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit 349: 990:

Feel free to state your position on the renaming proposal by beginning a new line in this section with

644: 623: 1146: 393: 1230:

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

764: 539: 1081: 768: 543: 479: 269: 397: 970: 962: 809: 747: 718: 700: 345: 341: 301: 1264:

before doing mass systematic removals. This message is updated dynamically through the template

359: 305: 1280: 866:

Thanks for pointing that out. I have rewritten the section with a more accurate description. --

736: 653:

Isn't all computer graphics quantisation? I think that "lossy compression" is a better term.

478:

Please help fix the broken anchors. You can remove this template after fixing the problems. |

1233: 937: 696: 458: 263: 1287: 1348: 1213: 1189: 1142: 1099: 1095: 950: 929: 893: 871: 319: 1246:, "External links modified" talk page sections are no longer generated or monitored by 1077: 1286:

If you found an error with any archives or the URLs themselves, you can fix them with

1253: 1470: 785: 666: 732: 640: 607: 384: 933: 147: 79: 52: 1344: 1252:. No special action is required regarding these talk page notices, other than 1185: 897: 867: 795: 654: 501:

simply upscale image to 1440x576 and then convert to HAM8 to reduce fringing.

401: 508:

I will update the HAM8 section in a week or so if there are no objections.

96: 337:

Phase5 accelerator boards; the 1230/1240/1260 blizzards and the PPC boards.

1136:

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

954: 92: 1462: 1432: 1352: 1335: 1309: 1197: 1166: 1150: 1115: 1085: 1071: 1054: 978: 941: 900: 875: 860: 839: 817: 798: 788: 772: 755: 740: 726: 689: 669: 657: 647: 626: 610: 597: 574: 547: 523: 221:{{WikiProject Computing|class=|importance=|amiga=yes|amiga-importance=}} 466:

This article links to one or more target anchors that no longer exist.

315: 309: 958: 329: 913:

The following discussion is an archived discussion of the proposal.

1123:

The above discussion is preserved as an archive of the proposal.

1094:

Looking at the history sections, back in 2005, the article was at

665:

information into a lower resolution that the original source. -

354: 260:

Articles of high-importance that needs expanding or improvements:

1076:

WTF do the above two comments have to do with the proposed move?

470:] The anchor (#Truecolor) is no longer available because it was 440: 15: 146: 1224:

for additional information. I made the following changes:

1234:

http://www.amiga-hardware.com/showhardware.cgi?HARDID=481

201: 196: 191: 186: 1102:. Then in 2007, it was moved to the current location, 254:

Improving the accuracy and updating dates about events

91:, a collaborative effort to improve the coverage of 1256:using the archive tool instructions below. Editors 1012:, please explain your reasons, taking into account 257:Improving the clarity and the quality of articles 1242:This message was posted before February 2018. 695:When I read analogue compression I'd think of 643:than lossy compression. What do people think? 240:for easier navigation of a given topic, e. g. 8: 1497:Start-Class Amiga articles of Mid-importance 19: 1321: 1212:I have just modified one external link on 1010:polling is not a substitute for discussion 846: 675: 170: 47: 419:missing Amiga related images/screenshots. 49: 366:Amiga Multimedia Convergence Computer 113:Knowledge (XXG):WikiProject Computing 7: 1014:Knowledge (XXG)'s naming conventions 85:This article is within the scope of 496:Maximum resolution on A4000 in HAM8 296:Creating/Expanding missing articles 38:It is of interest to the following 969:) 11:03, 14 December 2008 (UTC) — 14: 1482:Low-importance Computing articles 1216:. Please take a moment to review 444: 325:Hollywood (programming language) 78: 51: 20: 924:The result of the proposal was 699:. Note that it's also not only 236:Tagging Amiga related articles 225:Tagging Amiga related articles 214:Tagging Amiga related articles 133:This article has been rated as 1477:Start-Class Computing articles 1315:Rewrite the description of HAM 697:something completely different 116:Template:WikiProject Computing 1: 1492:Mid-importance Amiga articles 1353:07:18, 10 December 2018 (UTC) 1336:04:50, 10 December 2018 (UTC) 1116:17:16, 26 December 2008 (UTC) 1086:11:59, 27 December 2008 (UTC) 1072:15:00, 21 December 2008 (UTC) 1055:01:50, 21 December 2008 (UTC) 1002:, then sign your comment with 979:11:03, 14 December 2008 (UTC) 901:19:12, 3 September 2007 (UTC) 818:11:13, 14 December 2008 (UTC) 799:16:07, 3 September 2007 (UTC) 789:17:02, 2 September 2007 (UTC) 756:23:13, 14 December 2008 (UTC) 741:21:06, 14 December 2008 (UTC) 727:11:24, 14 December 2008 (UTC) 670:16:58, 2 September 2007 (UTC) 658:19:39, 17 February 2007 (UTC) 648:15:57, 16 February 2007 (UTC) 627:15:57, 16 February 2007 (UTC) 611:16:20, 19 December 2006 (UTC) 238:with a relevant Link template 155:This article is supported by 107:and see a list of open tasks. 1310:20:26, 5 November 2017 (UTC) 1173:Third party hardware section 876:05:53, 3 February 2020 (UTC) 861:02:58, 3 February 2020 (UTC) 942:20:11, 2 January 2009 (UTC) 1518: 1487:Start-Class Amiga articles 1273:(last update: 5 June 2024) 1209:Hello fellow Wikipedians, 690:00:07, 19 March 2017 (UTC) 139:project's importance scale 1198:22:27, 30 July 2011 (UTC) 1039:on regular AGA chipset. 773:05:29, 5 April 2012 (UTC) 598:16:46, 26 July 2006 (UTC) 548:05:21, 5 April 2012 (UTC) 524:00:19, 3 March 2009 (UTC) 169: 154: 132: 73: 46: 1126:Please do not modify it. 1032:Any additional comments: 916:Please do not modify it. 779:Sliced HAM (SHAM or SHM) 227:into relevant categories 1463:00:22, 7 May 2019 (UTC) 1433:23:48, 6 May 2019 (UTC) 1205:External links modified 1167:23:24, 6 May 2019 (UTC) 1151:11:54, 3 May 2009 (UTC) 840:23:18, 6 May 2019 (UTC) 575:00:52, 7 May 2019 (UTC) 340:Computers (expanding): 1502:All Computing articles 639:I would say it's more 373:Denise (computer chip) 218:by adding the template 151: 101:information technology 28:This article is rated 1343:preceeding pixels. -- 1177:No mention of DCTV? 1104:Amiga Hold-And-Modify 947:Amiga Hold-And-Modify 489:Merge with what now? 390:Alice (computer chip) 379:Paula (computer chip) 364:Hardware prototypes: 150: 88:WikiProject Computing 32:on Knowledge (XXG)'s 1254:regular verification 533:Animating HAM images 394:Lisa (computer chip) 229:, for example adding 174:Things you can help 1244:After February 2018 1098:, and was moved to 888:Rename this article 306:Haage & Partner 270:Workbench (AmigaOS) 266:(missing dates etc) 1298:InternetArchiveBot 1249:InternetArchiveBot 701:chroma subsampling 635:lossy compression? 302:Amiga Technologies 279:Expanding articles 152: 119:Computing articles 34:content assessment 1338: 1326:comment added by 1274: 1201: 1184:comment added by 1045:comment added by 863: 851:comment added by 692: 680:comment added by 514:comment added by 486: 485: 472:deleted by a user 461:in most browsers. 439: 438: 435: 434: 431: 430: 427: 426: 350:AmigaOne Micro-A1 176:WikiProject Amiga 158:WikiProject Amiga 1509: 1308: 1299: 1272: 1271: 1250: 1200: 1178: 1128: 1108:Martijn Hoekstra 1057: 1006: 1000: 994: 918: 526: 480:Reporting errors 448: 447: 441: 264:AmigaOS versions 244: 233: 222: 216:into the project 171: 121: 120: 117: 114: 111: 82: 75: 74: 69: 66: 55: 48: 31: 25: 24: 16: 1517: 1516: 1512: 1511: 1510: 1508: 1507: 1506: 1467: 1466: 1443: 1413:register space. 1317: 1302: 1297: 1265: 1258:have permission 1248: 1222:this simple FaQ 1214:Hold-And-Modify 1207: 1179: 1175: 1138: 1133: 1124: 1100:Hold-And-Modify 1096:Hold And Modify 1040: 1028: 1004: 998: 992: 986: 951:Hold And Modify 930:Hold-And-Modify 914: 908: 894:Hold-and-Modify 890: 781: 637: 595:193.120.178.201 583: 535: 509: 498: 482: 464: 463: 462: 445: 242: 231: 220: 206: 118: 115: 112: 109: 108: 67: 61: 29: 12: 11: 5: 1515: 1513: 1505: 1504: 1499: 1494: 1489: 1484: 1479: 1469: 1468: 1442: 1441:Sprites vs HAM 1439: 1438: 1437: 1436: 1435: 1417: 1416: 1415: 1414: 1407: 1406: 1405: 1404: 1397: 1396: 1395: 1394: 1386: 1385: 1384: 1383: 1376: 1375: 1374: 1373: 1366: 1365: 1364: 1363: 1356: 1355: 1316: 1313: 1292: 1291: 1284: 1237: 1236: 1228:Added archive 1206: 1203: 1174: 1171: 1170: 1169: 1137: 1134: 1132: 1131: 1119: 1118: 1091: 1090: 1089: 1088: 1059: 1058: 1047:158.38.160.150 1035: 1034: 1027: 1024: 1023: 1022: 1019: 1018: 993:*'''Support''' 985: 982: 971:Richard Cavell 963:Richard Cavell 922: 921: 909: 907: 906:Requested move 904: 889: 886: 885: 884: 883: 882: 881: 880: 879: 878: 828: 821: 820: 810:Richard Cavell 801: 784:HAM mode. - 780: 777: 776: 775: 760: 759: 758: 748:Richard Cavell 729: 719:Richard Cavell 713: 712: 711: 710: 709: 708: 707: 706: 705: 704: 636: 633: 632: 631: 630: 629: 616: 615: 614: 613: 601: 600: 591: 582: 579: 578: 577: 562: 561: 556: 555: 534: 531: 529: 497: 494: 488: 484: 483: 477: 476: 475: 459:case-sensitive 453: 452: 451: 449: 437: 436: 433: 432: 429: 428: 425: 424: 423: 422: 421: 420: 408: 407: 406: 405: 404: 368: 362: 338: 332: 322:(filesystem), 312: 293: 292: 291: 289:Start articles 276: 275: 274: 273: 272: 267: 258: 255: 247: 246: 245: 241: 234: 230: 223: 219: 205: 204: 199: 194: 189: 183: 180: 179: 167: 166: 163:Mid-importance 153: 143: 142: 135:Low-importance 131: 125: 124: 122: 105:the discussion 83: 71: 70: 68:Low‑importance 56: 44: 43: 37: 26: 13: 10: 9: 6: 4: 3: 2: 1514: 1503: 1500: 1498: 1495: 1493: 1490: 1488: 1485: 1483: 1480: 1478: 1475: 1474: 1472: 1465: 1464: 1460: 1456: 1455:146.199.0.169 1451: 1447: 1440: 1434: 1430: 1426: 1425:146.199.0.169 1421: 1420: 1419: 1418: 1411: 1410: 1409: 1408: 1401: 1400: 1399: 1398: 1390: 1389: 1388: 1387: 1380: 1379: 1378: 1377: 1370: 1369: 1368: 1367: 1360: 1359: 1358: 1357: 1354: 1350: 1346: 1341: 1340: 1339: 1337: 1333: 1329: 1328:130.233.97.85 1325: 1314: 1312: 1311: 1306: 1301: 1300: 1289: 1285: 1282: 1278: 1277: 1276: 1269: 1263: 1259: 1255: 1251: 1245: 1240: 1235: 1231: 1227: 1226: 1225: 1223: 1219: 1215: 1210: 1204: 1202: 1199: 1195: 1191: 1187: 1183: 1172: 1168: 1164: 1160: 1159:146.199.0.169 1155: 1154: 1153: 1152: 1148: 1144: 1135: 1130: 1127: 1121: 1120: 1117: 1113: 1109: 1105: 1101: 1097: 1093: 1092: 1087: 1083: 1079: 1075: 1074: 1073: 1069: 1065: 1064:76.66.195.159 1061: 1060: 1056: 1052: 1048: 1044: 1037: 1036: 1033: 1030: 1029: 1025: 1021: 1020: 1017: 1015: 1011: 1003: 999:*'''Oppose''' 997: 991: 988: 987: 983: 981: 980: 976: 972: 968: 964: 960: 956: 952: 948: 944: 943: 939: 935: 931: 927: 920: 917: 911: 910: 905: 903: 902: 899: 895: 887: 877: 873: 869: 865: 864: 862: 858: 854: 853:47.206.72.121 850: 843: 842: 841: 837: 833: 832:146.199.0.169 829: 825: 824: 823: 822: 819: 815: 811: 807: 802: 800: 797: 793: 792: 791: 790: 787: 778: 774: 770: 766: 761: 757: 753: 749: 744: 743: 742: 738: 734: 730: 728: 724: 720: 715: 714: 702: 698: 694: 693: 691: 687: 683: 679: 673: 672: 671: 668: 663: 662: 661: 660: 659: 656: 652: 651: 650: 649: 646: 642: 634: 628: 625: 620: 619: 618: 617: 612: 609: 605: 604: 603: 602: 599: 596: 592: 588: 587: 586: 580: 576: 572: 568: 567:146.199.0.169 564: 563: 558: 557: 552: 551: 550: 549: 545: 541: 532: 530: 527: 525: 521: 517: 513: 506: 502: 495: 493: 490: 481: 473: 469: 468: 467: 460: 456: 450: 443: 442: 418: 414: 413: 412: 409: 403: 399: 395: 391: 387: 386: 381: 380: 375: 374: 369: 367: 363: 361: 357: 356: 351: 347: 343: 339: 336: 335: 333: 331: 327: 326: 321: 317: 313: 311: 307: 303: 299: 298: 297: 294: 290: 286: 285:Stub articles 282: 281: 280: 277: 271: 268: 265: 262: 261: 259: 256: 253: 252: 251: 248: 243:{{AmigaOS 4}} 239: 235: 228: 224: 217: 213: 212: 211: 208: 207: 203: 200: 198: 195: 193: 190: 188: 185: 184: 182: 181: 177: 173: 172: 168: 164: 161:(assessed as 160: 159: 149: 145: 144: 140: 136: 130: 127: 126: 123: 106: 102: 98: 94: 90: 89: 84: 81: 77: 76: 72: 65: 60: 57: 54: 50: 45: 41: 35: 27: 23: 18: 17: 1452: 1448: 1444: 1322:— Preceding 1318: 1296: 1293: 1268:source check 1247: 1241: 1238: 1211: 1208: 1180:— Preceding 1176: 1139: 1125: 1122: 1031: 1007: 1001: 995: 989: 945: 925: 923: 915: 912: 891: 847:— Preceding 805: 782: 682:79.136.72.85 676:— Preceding 641:quantisation 638: 584: 581:Aspect ratio 536: 528: 507: 503: 499: 491: 487: 465: 457:Anchors are 454: 416: 410: 398:Mediator PCI 385:Copper (OCS) 383: 377: 371: 353: 323: 295: 278: 249: 237: 226: 215: 209: 156: 134: 86: 40:WikiProjects 1041:—Preceding 645:62.31.67.29 624:62.31.67.29 516:84.9.164.63 510:—Preceding 346:AmigaOne XE 342:AmigaOne SE 300:Companies: 30:Start-class 1471:Categories 1305:Report bug 1143:TiagoTiago 1026:Discussion 415:Uploading 402:Clock port 360:The Access 334:Hardware: 314:Software: 283:Expanding 1288:this tool 1281:this tool 1078:Nil Einne 765:Peterpall 590:certain). 540:Peterpall 110:Computing 97:computing 93:computers 59:Computing 1324:unsigned 1294:Cheers.— 1194:contribs 1182:unsigned 1043:unsigned 1008:. Since 955:Mode 13h 849:unsigned 786:Theaveng 678:unsigned 667:Theaveng 512:unsigned 250:Articles 1218:my edit 733:Liftarn 608:Safalra 474:before. 370:Other: 316:AmiDock 310:Eyetech 210:Tagging 192:history 137:on the 984:Survey 959:Mode X 934:JPG-GR 806:caning 411:Images 330:Warp3D 99:, and 36:scale. 1345:Zac67 1186:Bofum 898:Val42 868:Zac67 796:Val42 655:Val42 417:legal 355:DraCo 202:purge 197:watch 178:with: 64:Amiga 1459:talk 1429:talk 1349:talk 1332:talk 1190:talk 1163:talk 1147:talk 1112:talk 1082:talk 1068:talk 1051:talk 1005:~~~~ 975:talk 967:talk 957:and 938:talk 926:move 892:The 872:talk 857:talk 836:talk 814:talk 769:talk 752:talk 737:talk 723:talk 686:talk 571:talk 544:talk 520:talk 455:Tip: 320:JXFS 287:and 187:edit 1262:RfC 1232:to 928:to 129:Low 1473:: 1461:) 1431:) 1351:) 1334:) 1275:. 1270:}} 1266:{{ 1196:) 1192:• 1165:) 1149:) 1141:-- 1114:) 1084:) 1070:) 1053:) 996:or 977:) 949:→ 940:) 932:. 874:) 859:) 838:) 816:) 771:) 754:) 739:) 725:) 688:) 593:-- 573:) 546:) 522:) 400:, 396:, 392:, 388:, 382:, 376:, 358:, 352:, 348:, 344:, 328:, 318:, 308:, 304:, 165:). 95:, 62:: 1457:( 1427:( 1347:( 1330:( 1307:) 1303:( 1290:. 1283:. 1188:( 1161:( 1145:( 1110:( 1080:( 1066:( 1049:( 1016:. 973:( 965:( 936:( 870:( 855:( 834:( 812:( 767:( 750:( 735:( 721:( 684:( 569:( 542:( 518:( 232:] 141:. 42::

Text is available under the Creative Commons Attribution-ShareAlike License. Additional terms may apply.