OCS discussion

[thedocbwarren]

I've always wondered about how the Amiga modes are derived.  Like for instance, we have EHB 320 mode, but no 640 32 colour EHB.  Or a form of HAM in 640 with 4 index and almost all control bits.

Someone mentioned ECS can handle 1280 in HAM.  Plus, any idea why 640 mode was not used more often since the Atari ST did a lot of 320x200x16 and Amiga can do the same in 640x200x16 with standard OCS?

Was is because 640 is buggered with 7MHz 68000s (or slow that is?)

[thedocbwarren]

All extremely interesting.  It does make sense there would be bandwidth limits to the graphics modes.  Nature of the beast I suppose.  If it weren't for that it seems the Amiga design is limitless with how much resolution and depth.

It's my understanding AGA can handle HAM in super high res, but then isn't HAM emulated and not really the same technology in AGA?

Do accelerators remove this memory bandwidth contention or do they sit on top of it?

[thedocbwarren]

I've played with copper-style scanline palette changes before (on the Atari STe) so I can agree you can get some really nice results.  That being 4 colours in 640 and 16 in 320 (per line.)  And then add interlace to it you get nice results.

So if you are stuck with the top bits for control in HAM and 640 mode would give you two bits (4 colours) you could still make a decent graphic I think, but perhaps the resolution would be two blurry and fringy to make it worth it.

I guess the same issue occurs with Extra Half Bright if you run out of bandwidth.  I suppose you could do stupid stuff like interlace to frames together but probably not worth it.

So why did ECS not improve this with the improved chipset and faster CPUs?  Did not the chip ram increase thus allowing 640x256(200) 32 EHB?

[thedocbwarren]

Interesting, though I don't find some classic systems slow.  I've done some stuff on other 68000-based systems that seem just fine.  I think the classic Amigas had some real bus contention issues.  Lots of chips to share ram and the bus.  Plus everything is timed together for scanlines and the 7MHz clock.  Very slow.  

But when used in the right way it's amazing.

It's a fascinating thing, what made the Amiga strong made it weak in some areas.  But that's true for every classic system.

[thedocbwarren]

Because ECS doesn't actually improve chip-RAM throughput; the CPU in the A3000 is faster, but not the chipset. That's why 1280px mode has a maximum of 4 colors - it's still working with the same amount of bandwidth.

As to why that is, I'd guess it's a cost consideration...oh well.

I see, that makes sense.  What exactly was the purpose of 1280x256/200 anyway?  Very odd resolution.  Most broadcast could not handle chroma that high, and not many monitors had decent enough dot pitch to really use it effectively.  

I get productivity since VGA was out and the higher sync was nice (even if it cost some cycles as I understand.)

I'm glad HAM was a chip hack rather than a screen hack (like CGA composite for instance.)  That way modern monitors can display it (given right sync or doubler.)


I wrote a retro graphic simulator in Java recently and produced a HAM mode.  It was awesome to see what it could do.  I think I'll try some their and try out the 2 colour index, 640 HAM idea.  Should prove interesting.
Jay was know for vchip hacks.  Imagine if HAM had been HSV?

[thedocbwarren]

I created an experimental 640 HAM mode in my simulator and ran a comparison to standard HAM and I'm shocked!  It's bloody awesome, as first glance it appeared to lose the resolution depth due to fringing, but compared to HAM in 320 mode, it's obvious it's much sharper!

I wish I could post here to demonstrate.

[thedocbwarren]

Wait, I can.  Check this out.  What might have been.

[thedocbwarren]

With only two bits per gun color you simply get 64 colors total. The four color base palette won't improve this much (if any). Therefore HAM4 is almost useless. Lores HAM6 will most certainly look better than HAM4 for colorful images, and hires lace 16 color with palette slicing will also look much better, and also works straight out of the box.

Then there's lores HAM6 sliced palette, and this is truly superior to Hires HAM4, even if the resolution is lower.

The best way to get many colors in hires is to use a 16 color screen and use palette slicing: You can use Floyd Steinberg dithering effectively, you can change 15 colors in the border without overscan, and you can get 12 more colors by placing sprites behind the bitmap (give bitmap pixels color 0 and the sprites will show through). Best of all, it's all done in software.

I know this doesn't matter, but I'd like to understand what you mean.  Why would a control shift not look nice in high res if you have four index colours?  You simply shift away as needed.  You have the ability to change the value of any of the rgbs per control so you could set an index on pixel one and the rest of the image could be a control in theory.

The image I produced assumed 2 colours index (is it really 4?) and uses control RGB changes for each adjacent pixel.  Looks pretty bloody nice to me.

[thedocbwarren]

@freqmax

An A501 is nothing more than some RAM chips, a battery and a clock chip. Since it's also limited to 512 KB there's not too much point in trying to adapt it to Z II.



A theoretical HAM4 mode would require 2 bits for mode control: 00 = use index palette color; 01 = hold GB, modify R; 02 = hold RB, modify G, 03 = hold RG, modify B. With the 2 bits left you'd be able to use 4 palette colors. In contrast to HAM6 where the modify value is 4 bits, i.e. you can change any of three subpixel full range, you'd only have 2 bits for modify as well. How'd you want to use them? Step up / down 1 or 2 little steps?

I got it, so without the four bits you only get 4 levels you can change from the previous pixel vs the full 16 levels.  It's more useful if you wanted to limit the colour range to 4 bits per rgb.  Makes sense.  I'm going to plug this into my simulator to try it out though.