Amiga.org
Amiga computer related discussion => General chat about Amiga topics => Topic started by: mr_a500 on August 27, 2006, 06:34:59 PM
-
I remember reading a 1990 magazine with a small advertisment for "MacroPaint", a paint program which claimed to be able to display 4096 colours in high resolution without any add-on hardware. They showed two pictures and said "This is your Amiga on HAM...This is your Amiga on MacroPaint." The MacroPaint imaga did look like high-res HAM!
It sounded great, but I never heard anything about it after that and I couldn't find the program anywhere for 15 years. This year I finally got MacroPaint. The program isn't that great, but it does actually display 4096 colours in high-res (with some streaking). It's called "dynamic high-res" (also SHAM and PCHG) and is possible by changing palette on every line.
Then I found HamLab which can convert images to dynamic-highres. I started converting jpegs and gifs into dynamic high-res (and display with Visage) and it's amazing! Some pictures have problems with streaking, but about 90% of the images are waaay better than HAM or dithered 16 colour. Some pictures are so crisp and colourful, they look like 16bit! (now I'm converting most of my images to dynamic high-res on my A500)
So I'm wondering - why wasn't it popular? Why weren't there more paint programs or image converters to use dynamic-highres? AGA didn't come out until 1993 and dynamic-highres was around since 1990. It's unbelievable that for 3 years before AGA, there was the possibility to display 4096 colours in highres using software-only, but very few people were interested.
Was it the "dynamic-highres streaking" that turned people off? Digi-Paint allowed you to paint in HAM while minimizing HAM fringing, so it shouldn't have been hard to make a dynamic-highres paint program which minimized streaking. If you search Aminet now, there are a very small number of programs supporting dynamic-highres, SHAM or PCHG. Yes, AGA killed the need for dynamic-highres, but it had a whole 3 years to get popular and failed. Why?
-
@mr_a500
If you search Aminet now, there are a very small number of programs supporting dynamic-highres, SHAM or PCHG.
...and there ever fewer back then. There's your answer, I guess. Another thing is that the palette changes would take considerable system resources (I guess it was done by using the copper, but still it would suck time from other stuff).
BTW, PCHG is the name of the IFF chunk for the "Palette CHanGes".
-
Well I seem to remember displaying those SHAM pictures would bring my A500 to almost a standstill, and any pull down menus etc brought over the picture would trash the image completely.
I don't think it was usable for anything other than showing still images, for the same reason HAM wasn't used for many games, but it was very impressive at the time.
-
...and there ever fewer back then. There's your answer, I guess.
That's not my answer - it's my question. Why are there so few? You'd think it would become THE way to display 24bit high-res images on OCS/ECS.
Another thing is that the palette changes would take considerable system resources (I guess it was done by using the copper, but still it would suck time from other stuff).
Yes, maybe speed of conversion is one reason. Still, I recall that all image conversion back then was slow - and people then weren't as impatient as they are now. You'd think they wouldn't mind waiting a bit longer for a much better image.
BTW, PCHG is the name of the IFF chunk for the "Palette CHanGes".
Yes, I know. It was Sebastiano Vigna's attempt to make a "new standard" for multi-palette (dynamic highres) images. I guess it didn't really catch on.
Merc wrote:
Well I seem to remember displaying those SHAM pictures would bring my A500 to almost a standstill, and any pull down menus etc brought over the picture would trash the image completely.
Displaying them slowed it down? On my accelerated A500, displaying dynamic highres is about the same speed of displaying a regular IFF (or a couple microseconds slower). Maybe the program you used to display it wasn't very good. I think I'll try it on my unexpanded A500 to check the speed. About the trashing - that's one drawback to dynamic highres. I know it's no good for games (except maybe static-screen graphic adventure or title screens). I was saying it should have been used more for displaying static images, artwork or for slideshows (instead of HAM).
-
@mr_a500
Yes, maybe speed of conversion is one reason.
I was not talking about conversion speed, but displaying.
displaying dynamic highres is about the same speed of displaying a regular IFF (or a couple microseconds slower).
And how did you measure this? I don't mean the decoding the picture and writing it to memory... that is pretty much as fast as regular pictures. The slowdown comes from the copper banging the colour registers, for the whole duration the picture is displayed. With stock A500 this would take pretty much all time from CPU, especially when combined with the highres 4 planes DMA drain...
-
And how did you measure this? I don't mean the decoding the picture and writing it to memory... that is pretty much as fast as regular pictures. The slowdown comes from the copper banging the colour registers, for the whole duration the picture is displayed. With stock A500 this would take pretty much all time from CPU.
If that is the case, then I have no way to measure it. I would need to open a CPU load monitor on the dynamic highres screen I am viewing because flipping to another screen to view the CPU load would mean the image is no longer using CPU time, right? (..and I just tested this: I opened Scout CPU monitor and it showed no usage for background dynamic highres image)
If dynamic highres was used just for image display (like in slideshows or static title screens), do you really need to worry about CPU usage? If back in 1991 you were running a slideshow, you wouldn't think of also running a huge CPU intensive program in the background at the same time would you? Amiga was a "multitasking" computer of course, but with limited memory and CPU speed of the time, most people "monotasked". In this case, using most CPU for image display wouldn't be a problem.
-
Custom copper-lists were used extensively in games but typically only the background color and possibly some sprite colors were changed to keep the copper from hogging too much bandwidth. Also, the SHAM file format was hard-coded to a vertical resolution of 200 pixels IIRC and therefore didn't look right on a PAL screen.
Also, since AGA supported HAM8 in full super-high-resolution, the hardware solution solved much of the software kludging. Secondly, using TrueBrilliance on the AGA chipset combined both techniques for better 24-bit resolution images.
-
the problem was in the implementation. older programs sometimes changed more than 7 registers per scanline and that broke compatibility on some models. the copper has enough time to change 7 registers per scan line with no help other than setup from the cpu.
the problem with sham (sliced ham eg. lowres) was that it was designed for ntsc modes so it didnt work that great for pal.
when i frist found out about al this i thought it was great and downloaded developer docs and stuff on it but i didnt use them a real lot.
these images do look really good, but they cant do gradients very well.
pch was an effort to standardize pallete change stuff across all amiga models and display modes and it works really well. if you can find hamlab you can play around with it really easily because you can try different settings quickly and see how it all works.
-
@mr_a500
I would need to open a CPU load monitor on the dynamic highres screen I am viewing because flipping to another screen to view the CPU load would mean the image is no longer using CPU time, right? (..and I just tested this: I opened Scout CPU monitor and it showed no usage for background dynamic highres image)
This doesn't show up in CPU usage like that. The whole system is slowed down, it doesn't take CPU time for the task displaying the image.
-
Also, the SHAM file format was hard-coded to a vertical resolution of 200 pixels IIRC and therefore didn't look right on a PAL screen.
Yes, that's what I read, but I've been displaying SHAM images with 1024 vertical pixels on a scrolling screen with graphics overscan of 232 vertical height (NTSC). Maybe the program I'm using to display the images (Visage) is doing something to overcome the hard-coded limit. All I know is that the image 800x1024 displays perfectly fine.
Does anybody know of any games using static dynamic highres screens? The "Agony" title screens look like dynamic highres, but they might be just very well made 16 colour highres.
-
@SamuraiCrow
Also, the SHAM file format was hard-coded to a vertical resolution of 200 pixels IIRC and therefore didn't look right on a PAL screen.
That was likely to be bug of the application displaying the pictures. Copper needs special attention at vertical position 200 and beyond. Properly coded programs should have no problem with this, however.
-
@Mr_A500
The Copper is a separate processor unto itself. It has 3 kinds of instructions: move, skip, and wait. Wait is executed by allowing the blitter to have the time that the Copper would have used if it were executing another instruction until the raster reaches a certain screen position. Skip is usually used to skip over a wait instruction if the raster has already passed a certain position. Move is the most common one: it pokes values into the custom chip registers.
The reason the system doesn't seem to slow down is becuase the custom chips have a separate bus called the CHIP bus with their own CHIP memory. The FAST bus allows the CPU to continue processing regardless of the bandwidth conditions of the CHIP bus unless you have no FAST memory.
There are DMA channels on the Chip bus that are allocated according to usage. Dynamic highres inserts a lot of Move instructions into the Copper-list (program) that is being executed so more bandwidth is spent by the Copper to execute these moves than if it were simply executing a wait instruction. The more bandwidth is used by the bitplanes and the copper, the less bandwidth is left for the blitter and, if necessary, the CPU.
As a side-note: Copper-chunky is a form of screenmode that changes color palettes as fast as possible on a 0-bitplane (1 color) screen. Since there are no bitplanes in use, the blitter can execute its copy instructions directly on the Move instructions in the Copper-list which is much faster.
Unfortunately the Copper DMA only executes once every 8 lowres pixels on ECS therefore limiting Copper-chunky to 80x256x4096 PAL or 80x200x4096 NTSC. AGA has a faster copper so it can do 160x256x4096 PAL and so on.
IMHO the ideal modern Amiga chipset would do nothing but Copper-chunky all the time and just optimize the Copper instruction set to execute faster with byteruns so it could copy multiple pixels to a queue with a single instruction. It could even have a special byterun for emulating HAM8 mode if you wanted it to. The only problem with this idea is that we'd have to figure out a way around an NVidia patent on graphics streaming and we'd be in the clear.
-
This doesn't show up in CPU usage like that. The whole system is slowed down, it doesn't take CPU time for the task displaying the image.
Then the only way to measure it is to run a CPU intensive program in the background.
I know for sure that it has no effect on screen flipping and that's all I really need when displaying a bunch of images. I like to open 10 images or so on their own screens and flip between them. There is no (or minimal) difference in speed in opening 10 IFF or 10 dynamic-highres and flipping between them.
By the way, in case anyone's interested in dynamic highres: the best (only) conversion program is HamLab (version 2.1.0 has been made freely available by the author) and the best viewer is Visage. If you experience corruption when scrolling large images, try lowering the number of palette changes when creating the image (7 or less). Also, a different graphics overscan (for display) sometimes helps.
Other programs compatible:
Viewtek
AdPro (loads but does not save any dynamic highres format)
Mostra (doesn't seem to work with SHAM)
MacroPaint (does not load PCHG, does not save SHAM)
(please let me know if there are other good dynamic highres compatible programs ...except 2View, DynaShow, Shazam)
-
Piru wrote:
That was likely to be bug of the application displaying the pictures. Copper needs special attention at vertical position 200 and beyond. Properly coded programs should have no problem with this, however.
It's little caveats like this that make me wish I devoted time to hacking around the Amiga system. If only I had more hours in the day I would have a crack at it!
-
Wasn't Dynamic Hi-Res from NewTek? In Digi Paint from what I remember?
-
Were these formats not all the same though ? You have hires interlace 4 bitplanes with a sliced palette (reloading 15 new colours with the copper each frame) and also sliced ham modes with lowres interlaced but a sliced ham palette (less fringing) ?
I was coding on a intro advert for exotica back in 1998. I should really finish it. It has a few images in "dynamic hires) (or pchg) format at the top 2 3rds of the screen , and a lowres scroller (2 pixel), in the bottom. I'm sure I could do a 1 pixel, with some optimisation. I was going to do something with the 4 sprites available too..
The pics did look pretty good though..
-
Digipaint does interlaced ham. but its a good proggy for sure.
-
Digi-View 4.0 could create dynamic highres, but not Digi-Paint. It would have been awesome if Digi-Paint 3 could handle dynamic highres. I wonder why they didn't add it.
Were these formats not all the same though ?
The true "Dynamic Hi-Res (TM)" is by NewTek and does not display properly in Visage or Viewtek even though they display SHAM and PCHG. MacroPaint will only load SHAM and Dynamic and saves Dynamic. I think there are also a few other filetypes called AHAM, ARZ0 and ARZ1 (but they must be very old and obsolete because I've never heard them mentioned anywhere except in a HAM-E advertisement).
When I'm saying dynamic highres, I'm really talking about all the formats, not just the NewTek one.
-
It may not be possible with an OS friendly app to display dynamic hires. Or at least, not using an amigaos screen with custom copperlist anyway.
-
There's one of the NewTek Dynamic Hi-Res pictures on this site. Came from one of the NewTek demos.
http://www.amiga.org/gallery/index.php?n=282=30 (http://www.amiga.org/gallery/index.php?n=282=30)
AmigaHeretic
-
I just did some speed tests to see how much the system actually slows down while viewing dynamic highres. I converted a jpg (CPU intensive task, I assume) with HamLab from Workbench screen without viewing it, then I converted the same jpg while viewing a 594x594 dynamic highres image in Visage and timed with a stopwatch. I set HamLab to beep when finished so I would know when it finished while I was viewing the dynamic image. I did three tests:
(in seconds)
No dynamic: 34.81 Dynamic: 35.02
No dynamic: 34.88 Dynamic: 35.04
No dynamic: 34.71 Dynamic: 34.96
As you can see, there's only a slight difference and this could even have been caused by flipping to the dynamic highres screen.
Then I tried the same thing on my Amiga 1000 (stock except 1Mb RAM), except viewing a 640x400 image in Shazam (Visage doesn't work in WB1.3) and converting a smaller jpg in HamLab. It was a whole different story:
No dynamic: 2:48.01 Dynamic: 6:42.38
(I only did one test because it took too bloody long)
So, the lack of "dynamic highres slowdown" on my A500 must have something to do with my upgrade (maybe Fast RAM?). Still, viewing a 640x400 dynamic highres image on an A1000 took "only" 7 seconds (and looked totally amazing for a 1985 computer!), so I still think dynamic highres should have become the standard for viewing high-colour highres images on the OCS/ECS Amigas.
@SamuraiCrow
Thanks for the detailed info. :-)
-
Yes, but that image no longer displays on either of my a3000s (3.1). I have noticed that the newtek demos also have troube running and eventually crash. Is this a problem with 3.1 roms or the ECS? My original one also had problems with displaying dynamic highres.
I never had trouble on my A500.
Thoughts anyone?
-
Forget the NewTek demo. Lots of old NewTek stuff crashes on my upgraded A500. Just get a copy of HamLab and load any jpg or gif (or even the NewTek image) and you'll have no problem.
-
And how did you measure this? I don't mean the decoding the picture and writing it to memory... that is pretty much as fast as regular pictures. The slowdown comes from the copper banging the colour registers, for the whole duration the picture is displayed. With stock A500 this would take pretty much all time from CPU, especially when combined with the highres 4 planes DMA drain...
And on a stock amiga you normally run a bunch of programs at the same time you are watching still photos? I sure as hell would be interested in this if i knew about it back then.
I honestly dont care if the cpu and co processors is working at 90% capacity when i have nothing running in background that needs the power.
-
I just found another great use for dynamic highres: displaying screenshots containing copper "rainbows" (game or Workbench screenshots).
Example: my "Rainbow Mania" screenshots (on Amiga.org) have blue copper rainbows in the background. I had to take the screenshots with WinUAE because there is no possible way to capture the rainbow on a real Amiga. When I then try to display the screenshot on my real Amiga, it can't be displayed at the resolution it was taken at because the copper rainbow uses up more colours than should be possible at that resolution. So, I can only view the highres screenshot in lowres HAM.
But with dynamic highres, I can view it in highres and still see the copper rainbow. Converting with HamLab (dithering off), it is nearly perfect. I say nearly because the original must be saved as gif and gif uses fixed 256 colour palette missing some colours the Amiga has (and jpg is "lossy"). Oh I wish HamLab could load PNG!
Edit: What am I thinking? I can just save the original as 24bit ILBM. duh.
-
@mr_a500
jpg is "lossy"
Use jpeg quality setting of 100% ?
-
Use jpeg quality setting of 100% ?
I already did. It still had artifacts after converting to dynamic highres.
-
Continuing this thread... I just installed NewTek's DemoReel #3 on my Amiga 1000, and when the Dynamic HiRes image is supposed to be displayed, nothing happens - the demo moves on.
This is an NTSC Amiga 1000 with 512K CHIP, 2MB FAST, and EHB is supported, here.
Should this machine be able to display dynamic high res images?
bp
-
@mr_a500
Use jpeg quality setting of 100% ?
Even when you set jpeg quality to 100% the result is still lossy and damaged. Its a scam.
-
I can't remember which demo reel is which so I can't remember what year they came out so I can't remember how much chipram they required.
Here are the possibilities:
A. Needs 1MB Chipram
B. Needs 512k Chipram and somehow you have a program running on your Amiga that is using some of that. Like for example you probably have 4 floppy drives connected and each drive use chipram buffers. Or you have a hard drive connected which probably has very LARGE chipram buffers.
Reduce your chipram consumption and watch it start to work.
-
So I'm wondering - why wasn't it popular? Why weren't there more paint programs or image converters to use dynamic-highres? AGA didn't come out until 1993 and dynamic-highres was around since 1990. It's unbelievable that for 3 years before AGA, there was the possibility to display 4096 colours in highres using software-only, but very few people were interested.
AGA came out in 1992.
"Dynamic Hires" has been around since 1985. IIRC There are at least 3 different popular public versions of it. And who knows how many private versions.
Was it the "dynamic-highres streaking" that turned people off? Digi-Paint allowed you to paint in HAM while minimizing HAM fringing, so it shouldn't have been hard to make a dynamic-highres paint program which minimized streaking. If you search Aminet now, there are a very small number of programs supporting dynamic-highres, SHAM or PCHG. Yes, AGA killed the need for dynamic-highres, but it had a whole 3 years to get popular and failed. Why?
It didn't fail. Ppl still use it.
And you can do AGA Dynamic Hires better than you can do OCS Dynamic Hires since when you do it on AGA you get to easily have 256 colors on every scanline. More than 256 colors per scanline with extra effort.
Using the simple method: 256 colors per scanline beats 16 colors per scanline every time.
You can also do Dynamic HAM mode but it is limited to 320x512 resolution with 4096 colors on OCS. But on AGA, Dynamic HAM can be 1280x512 with 16,777,216 colors.
-
This type of method of enhancing still images was popular amongst a lot of the 80s home computers, at least on an app-by-app basis. The problem with the Amiga implementation was that nobody defined a definitive specification that all the applications could parse, understand and display consistently.
In addition, at the time, the Amiga was so far ahead that people weren't thinking about improving it even further!
-
This type of method of enhancing still images was popular amongst a lot of the 80s home computers, at least on an app-by-app basis.
Yep! I used the same type of method "rasterline interrupt color changes" on my C64 in 1983.
And it was very VERY useful on the Atari 800/400 computers which had a palette of 256 colors! And no HAM mode. So every good coder did "dynamic hires" on Atari 8-bit computers. These are the computers that competed against the C64 and Apple ][+
The Atari 400 and Atari 800 chipsets were designed by Jay Miner who then took the idea to the next level in the Amiga.
-
On the Atari VCS, you had to do this. It had no concept of a frame buffer, so you built the display up manually on each scanline.
Now that's hardcore. :)
-
If you are able to get NewTek Demo #3 to run you'll notice that the resolution of the music playing in the background drops way down when displaying the dynamic-highres image...
I think the reason its not used more commonly is because the copper is leaving the CHIP RAM bandwidth starved...
-
If you are able to get NewTek Demo #3 to run you'll notice that the resolution of the music playing in the background drops way down when displaying the dynamic-highres image...
That is either because you were using UAE or maybe they switched to lower res music because there wasn't enuff chipram laying around in the 512k chipram days.
I think the reason its not used more commonly is because the copper is leaving the CHIP RAM bandwidth starved...
Impossible on a real Amiga.
But I have seen and heard stuff like that happen lots of times on my WinUAE.
-
Dynamic High-Res was a very cool NewTek thing. I think someone else did something similar called Sliced HAM.
-
On the Atari VCS, you had to do this. It had no concept of a frame buffer, so you built the display up manually on each scanline.
Now that's hardcore. :)
You were literally "Chasing the Beam..."
bp
-
On the Atari VCS, you had to do this. It had no concept of a frame buffer, so you built the display up manually on each scanline.
IIRC That was another chip designed by Jay Miner.
-
Yep! I used the same type of method "rasterline interrupt color changes" on my C64 in 1983.
And it was very VERY useful on the Atari 800/400 computers which had a palette of 256 colors! And no HAM mode. So every good coder did "dynamic hires" on Atari 8-bit computers. These are the computers that competed against the C64 and Apple ][+
The Atari 400 and Atari 800 chipsets were designed by Jay Miner who then took the idea to the next level in the Amiga.
Although strong vertical design was stressed, changing color registers at the end of each scan line during horizontal blank was not always the best method.
Page flipping 2 screens offered more colors without the overhead. Just 4 load and stores for color and 1 load and store for the page flip. That left plenty of VBI time for other routines.
#6
-
I think the reason its not used more commonly is because the copper is leaving the CHIP RAM bandwidth starved...
On OCS/ECS the 4 bitplane hires will use all of the bandwidth in the displayable area & the copper will use all of the bandwidth in the non displayable area. The blitter and cpu will only be able to access chip ram during vblank. If you have no true fast ram to run code from then the cpu will barely be able to run at all.
http://amigadev.elowar.com/read/ADCD_2.1/Hardware_Manual_guide/node012B.html
-
That is either because you were using UAE or maybe they switched to lower res music because there wasn't enuff chipram laying around in the 512k chipram days.
Yes, real Amiga. quite certain the sample it plays during Bert's face is lower quality than the rest of the sample.
Hard to tell because it avoids playing any instruments other than drums if I recall...
NewTek demo reel #1 is the reason I bought my first A500, so those demos are very clear in my head :)
On OCS/ECS the 4 bitplane hires will use all of the bandwidth in the displayable area & the copper will use all of the bandwidth in the non displayable area. The blitter and cpu will only be able to access chip ram during vblank. If you have no true fast ram to run code from then the cpu will barely be able to run at all.
http://amigadev.elowar.com/read/ADCD_2.1/Hardware_Manual_guide/node012B.html
And I would imagine the the PAULA has to share that as well?
-
And I would imagine the the PAULA has to share that as well?
If you look on the diagram on the page I linked, you'll see that paula's slots are fixed and are always available.
-
And I would imagine the the PAULA has to share that as well?
Paula has its own 4 DMA channels that are permanently reserved for itself.
There is no such thing on Amiga as "oh no! The gfx are draining to much electronz! Its suxx0rizing all the quality out of the audio!" :D
That is the pc/mac way of doing things. Not the Amiga way.
If you heard degraded audio then it was either
A: Your opinion, which you are entitled to. (No one can like all bits of music equally)
B: It was degraded on purpose by the coder of the demo to save memory because that part of the demo was using all the chipram. It was probably doing some hardcore double buffering or triple buffering or preloading an anim that would be shown later or etc. There are a lot of reasons why it would run low on chipram and need to start using samples at a lower resoution.
> But I have tons of ram so that can't be it!
But it wasn't coded for your machine. It was coded exactly and specifically for the machines of the day and had to work on them 100% guaranteed.
I think it was coded to work on 1MB Amigas with only 0.5MB chipram.
C: It might all just be an accident where the coder accidentally turned on the audio filter. The audio filter makes everything sound "dead". This might be exactly what you are hearing.
-
If you look on the diagram on the page I linked, you'll see that paula's slots are fixed and are always available.
I guess its just a crappy sample :)
Sure sounds like it gets really muddy right then.
-
If you look on the diagram on the page I linked, you'll see that paula's slots are fixed and are always available.
However it requires CPU to initiate DMA transfer. While Paula has got it allocated slots it is possible it is just playing wrong note because CPU could not keep up.
-
If the CPU can't keep up then Paula would play whatever note it just played in a loop over and over until the cpu caught up. It sounds really horrible and jarring and obvious when it happens.
-
I just did a very quick interview with Rhett Anderson who made SHAM. He said the viewer slowed the system 10-15% but was not intensive. His first viewer was not multitasking friendly, and so people (including me) assumed it took loads of system resources. Apparently not. I am working on a post to detail the back and forth with the author.
-
Not in Digi-Paint, but in Digi-view 4.0 video capture software it was an option. I'm sure it was called Dynamic Hi-res (Dynamic HAM being 320x512 true HAM image with palette swap for HAM 16 base colours used on every scan line) but it's been decades since I've seen the box let alone used the software.
The problems with HAM fringing are not that bad if you use interlace AND you feed a very evenly lit and neutral/daylight temperature of lighting of image (or the TV output form a digital camera displaying a high quality JPEG is the most ideal today if you still have a Digi-view unit to use). Some images will be a problem of course but the fringing is also caused by bad lighting just as often.
It used to be a lot of fun, hopefully one day I will get a chance to mess about with it again as in my misspent hours of youth!
HAM has problems changing all three of the RGB components, if you get uneven lighting on the image then that means on every pixel the RGB has subtle changes to it at best, or totally inaccurate colours being seen by the camera at worst i.e. there was no need for the colour to change except due to poor uneven lighting of the original so you just make a clever shortcut in screen memory usage into an absolute nightmare of a compromise. HAM is supposed to be used on HSV values not RGB where the 'fringing' is less jarring due to the more subtle differences when HSV values are being manipulated on an image but Jay Miner decided it was better than nothing with RGB after seeing it in action on a Flight Simulator system.
Garbage in, garbage out as they used to say in 1980s computer courses heh!
-
HAM is supposed to be used on HSV values not RGB where the 'fringing' is less jarring due to the more subtle differences when HSV values are being manipulated on an image but Jay Miner decided it was better than nothing with RGB after seeing it in action on a Flight Simulator system.
The flight simulator is where he got the idea for HAM from, it wasn't an Amiga flight simulator. But when the Amiga output went from HSV to RGB as they pivoted from a games console to a desktop computer then they were going to take it out, but decided it would be extra work and they didn't have time to reuse the space for anything else anyway.
Photo realistic images was not even the goal, it was for fast horizontal line filling. Instead of setting each pixel to blue/red/green etc you could set the pixels where the color changes. I don't know if the HSV chipset worked better, but there doesn't seem to be a way of setting up memory with a NO-OP value. So it pretty much fails to be useful for the original intended use.