OCS discussion

[freqmax]

The A501 expansion RAM and Zorro-II RAM all becomes slow-RAM in an A500 ..?

[commodorejohn]

A501, yes, as does (IIRC) all trapdoor-slot RAM on the A500. I'm not 100% clear on how Zorro II is implemented on the A500, but it's not through Agnus, so it doesn't suffer from chipset contention.

[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?

[freqmax]

Aha.. that's why A500 was SO slow..

Jpeg decode = 30 minutes/image..

[commodorejohn]

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?

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.

[fishy_fiz]

Aha.. that's why A500 was SO slow..

Jpeg decode = 30 minutes/image..

Classics does sucking,..... my os4/mos/aros box does it much quicker while making coffee and vacuuming my carpet cos it's the official update/its all shiny and polished/has fast hardware      :-P

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

[buzz]

I made a an old intro (never completed and rather basic), that had highres/laced in the top portion of the screen with some palette sliced images (black and 15 colours per line), and lowres/laced in the bottom with a sinus scroller. The pics looked pretty good considering. I think I used ham-lab or something to convert the images with dithering etc. It could also output PCHG format (http://aminet.net/package/dev/misc/PCHGLib14) for apps that supported that.

[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?

[mongo]

But why RAM that suffers chip accesses, but still can't be accessed by the same chips?

Because it was cheaper to use the RAM controller in Agnus than to add another one. Basically it was a hack that allowed you to add more RAM at a low cost.

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

[psxphill]

It's a quirk of Agnus/Fat Agnus, I believe. It was fixed in later versions, but unfortunately most/all stock 500s have it.

IIRC agnus didn't support slow ram, it was something that was added for fat agnus. I imagine they wanted to do 1mb chip when moving to fat agnus but the time frame didn't allow for adding another address line to everything. When they got round to it they should have at least supported 4mb or even 8mb. Especially when they shortly afterwards upped it to 2mb anyway.
 
Even though 1mb agnus turned up in a500's, it was really only in the a2000 that it was configured to support 1mb chip. Probably for compatibility as alot of software assumes that 1mb is at $c00000.

[commodorejohn]

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

Any chance of getting those in non-"crappy JPEG thumbnail" form?

[Hattig]

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

HAM4 would only have 2 bits for command data (as the other two bits are: select palette, change R, change G, change B). So you would have a four colour palette (full 4096 colours) and the ability to change a colour channel's top two bits (severely limiting the range of colours you could select). You simply wouldn't have been able to get any kind of smooth gradient or decent pictures, and you would have been better off with EHB with copper palette changes in most cases.

[vidarh]

A501, yes, as does (IIRC) all trapdoor-slot RAM on the A500. I'm not 100% clear on how Zorro II is implemented on the A500, but it's not through Agnus, so it doesn't suffer from chipset contention.

As far as I remember on the A500 it's is pretty much wired up directly to the CPU and RAM. Been about 18 years since I last saw an A500 PCB up close, though