Since HAM mode is only for static images or animations in best case, there must be a lot of ways to produce better images on an Falcon. By just flicking between two 64k images you get millions of colors and takes no CPU speed at all.Are there any viewers that do this or did all of them just settle with 64k images?

Zamuel_a wrote:Since HAM mode is only for static images or animations in best case, there must be a lot of ways to produce better images on an Falcon. By just flicking between two 64k images you get millions of colors and takes no CPU speed at all.Are there any viewers that do this or did all of them just settle with 64k images?

Since HAM mode is only for static images or animations in best case, there must be a lot of ways to produce better images on an Falcon. By just flicking between two 64k images you get millions of colors and takes no CPU speed at all.Are there any viewers that do this or did all of them just settle with 64k images?

The image is rendered onto the screen using an advanced 24-bit 'emulation' mode which uses software trickery to increase the Falcon's colour limit beyond 16-bits to a much smoother looking 24-bit display.

Support: * Any standard YCbCR-IDCT-Huffman based JPEG format. * Works only on Falcon030 machines.

Zamuel_a wrote:HAM was a clever idea to get more colors on screen on an Amiga 500, but for the 1200 it's less than optimal.

I am not sure but I think that they want in one point of time to remove HAM from silicon (not sure why) but it would leave whole in chip (maybe it is an urban legend but I am pretty sure that I read this somewhere)

I am not sure but I think that they want in one point of time to remove HAM from silicon (not sure why) but it would leave whole in chip (maybe it is an urban legend but I am pretty sure that I read this somewhere)

Yes it's true. I read a interview with the creator once and he said that the original idea for HAM was not like it turned out. It was not based on RGB but on HSV (I think) and designed to be more easy to use. But after the rest got finished the HAM mode wasn't useful anymore and he wanted to remove it, but it would cost to much and they left it in. It turned out to be useful in some situations, but not like it was thought of.

mc6809e wrote:At least the hardware sprites are still usable, though small -- just 128 pixels of sprite data per scanline.

Had sprites been 32 pixels wide instead of just 16 there might have been a few more HAM games.

64 wide I believe and not 128. How many are available with scrolling extra fetch and fmode set to max? One 3 colour (3 + transp) I think?My memory is fuzzy on the topic.

I'm mean on OCS. There are eight sprites per scanline that are each 16 pixels wide. Each pair of sprites share a group of three palette entries. That gives a total of 128 pixels of sprite data per scanline and 12 colors.

Pairs of sprites can also be attached. Attached sprites, where they overlap, select from 15 palette entries. That typically gives four, 16 pixel-wide, 15-color sprites. That might be where you're getting the 64 pixel number from.

Partial overlap of attached sprites is possible, too, giving wider sprites with some limits on colors. For example, two attached sprites can be partially overlapped to create a 24 pixel-wide sprite with the left four pixels selecting from three colors, the center 16 pixels selecting from 15 colors, and the right four pixels selecting from a second set of three colors. Such a scheme would give 96 pixels of sprite on a line and in most cases allow 15 color sprites.

Sprites can also be repositioned with the copper or CPU during the scanline allowing them to be reused with some limitations.

I'm not sure what the absolute limit on the total number of sprites obtained per scanline. A MOVEM.L d0-d7/a0-a7, sprites should be able to rewrite the entire set of sprites each scanline. That would give a limit of 16 sprites per scanline combining DMA fetch and CPU writes. In HAM sprites are still available, although there are fewer DMA slots available for tricks. The practical limit in any case is probably 10-12 sprites per scanline.

It's a mystery to me why someone didn't bother to try writing some simple galaga-style game using sprites on a HAM background. HAM is also fully vertically scrollable, BTW (also horizontally scrollable but care must be taken to hide artifacts). Vertical scrolling over static terrain with sprites overlaid probably had some potential. Perhaps memory limits were an issue (one HAM screen is 40K).

This discussion is actually connected somewhat to the mention of the extra address bus. Anyone that's done Atari 2600 programming knows that playfield and sprite data must be written manually by the processor every scanline. The separate address bus on the Amiga is what allows the chipset to do similar writes to arbitrary register locations. As the one of the designers of the 2600 also designed the Amiga chipset, this extra bus was seen as a great advantage, allowing the CPU to be bypassed and sprite data to be automatically loaded.

As far as scrolling goes, on OCS, the last sprite can be controlled by the copper or CPU if hard scrolling a 320 pixel wide screen with normal centering (a 304 pixel wide screen doesn't have that problem if you're willing to accept a narrower screen). Sprites don't become unusable with wider, overscan, and hardware scrolled screens. They simply must be programmed manually by the CPU or copper as the DMA slots normally used for some of the sprite are reallocated to bitplane DMA.

It's also possible to reuse sprites in the vertical by just using DMA and no tricks. DMA will automatically read in new position and control values for a new sprite at the end of the old sprite. This uses one scanline. Of course the copper can also do this if the programmer doesn't want one scanline to separate the new sprite from the old. This shifting position on a per scanline basis can also make sprites look much wider. A tree standing at a slant might span a total of 32 pixels, but if it's only 16 pixels wide at any one point, the copper and slant it.

I'm really not that familiar with AGA. Those sprites are wider I believe.

This discussion about sprites, HAM, blitter area fill for 3D, etc, reveals a big reason why, in practice, the Atari ST and Amiga were often nearly the same.

What programmer that needed to feed himself was going to invest all that time learning enough about the Amiga to perform all those special tricks? Fact is it took an Amiga expert to program all those Amiga-specific features.

It's one thing to program as a hobby. One can waste time with demos, etc. A professional programmer back then just couldn't, though.

The virtue of the ST was its simplicity. The history of the PC with chunky VGA+CPU in 1987 doing everything up until the late 90s, shows it was time for simplicity.

[quote="Zamuel_a"]Many games were developed on the Atari first and after that, ported to the Amiga. It was easier to port an Atari game to the Amiga than the opposite and the makers wanted to earn money fast.[/quote

That is true. There wasn't much revenue to earn by using resources in the Amiga port of games in the beginning iI think. Very few Amiga's was sold during the first two years. Before the A500 came along with a more affordable price tag and larger number of units was sold.

galahad wrote:Its not that people don't take the A1200 seriously as a stock machine, its still pretty capable,

No so pretty. The main problem is the limited RAM size for a prodution work in workbench. It was limited like 512kB A500 before.

Er, that wasn't a problem at all. Unless you were seriously into productivity software, how much ram was available for Workbench and system was irrelevant.

If you were seriously into productivity software and were able to afford to buy some of the VERY expensive programs to use, you certainly could and would be able to afford to upgrade your Amiga A1200 to best take adavantage of it.

Very few Amiga owners have an 060 card. I would say the most common configuration is A1200+Fastram+030card+hard drive, and thats decent enough.

I know very few Amiga users which don't have 060 or at least 040. 030 + FastRAM was typical 1990s setup.

I'm not sure why you bothered to respond, you've basically said in a roundabout way, exactly what I said.