Amiga.org
Amiga computer related discussion => Amiga Hardware Issues and discussion => Topic started by: thedocbwarren on June 28, 2011, 05:47:19 AM
-
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?)
-
A lot of it has to do with chip-RAM throughput. The 6-plane 320px modes are pushing the limits of the bandwidth alotted to the bitplane-fetch channels. 640px mode requires twice as much data for the same bit-depth, so 6-plane 640px is well beyond its capabilities. (IIRC, 4-plane 640px takes all the video bandwidth on OCS.)
As for 640px being slow, that's because when running from chip RAM, the CPU has to compete with the chipset for RAM access, and the more the video takes up, the less chance the CPU has to fetch instructions and data, so it winds up just spinning its wheels more often than in less intensive modes. (This isn't a problem when you have some fast RAM, of course, but since none of the OCS home-computer models shipped with fast RAM, and the A500's default 512KB expander is "slow RAM" that's subject to the same restrictions as chip RAM, it's understandable why programmers shied away from it.)
-
Using hires (640px) uses twice the bandwidth of low res. Upping the color depth is proportionally less of a hit (from 4bit (16col) to 6bit (ehb) color is only a 50% jump (technically a little less, but for conversations sake)). The higher color depths (32colours through to HAM) are available in interlace modes though (320x400/512).
Additionally hardware sprites use colour registers 16 through 31, so even in 2-16 color modes regardless of resolution hardware sprites will use thier own colours.
There's no reason a stock ocs machine couldnt do games using higher resolutions, but being that required bandwidth at least doubles and moving gfx are twice the size (assuming same dimensions onscreen as a low res games) there'd typically have to be less moving gfx (ergo arcade style games arent really options). Put simply a game would have to be written and styled around these restrictions. RAM speed does play a part, but the amount of ram also comes into play here (bigger higher resolutions gfx require more RAM).
As for ECS being able to use super high res (1280px) in HAM, Im somewhat sceptical about that. So far as I know the super high res modes are restricted to 2bit colour for ECS. Feel free to correct me if Im wrong though someone.
-
IIRC, 4-plane 640px takes all the video bandwidth on OCS.
Actually, 4-plane Hires takes all the chip RAM bandwidth there is. (Excluding horizontal and vertical blanking times that is, but with severe overscan there's not too much left.)
8-plane Lores could bandwidth-wise be possible but there are no such modes.
-
As for ECS being able to use super high res (1280px) in HAM, Im somewhat sceptical about that. So far as I know the super high res modes are restricted to 2bit colour for ECS. Feel free to correct me if Im wrong though someone.
You're right ECS can only do 4 colours in super hires (1280 @15khz 640@31khz (640@31khz)). The colour registers need to be setup in a special way as well because it's a bit of a hack.
-
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?
-
Hires-HAM wouldn't made alot of sense as you can only use 4Bits.
2 for mode (R,G,B or direct color) leaves only 2Bits for data.
So you'd have 4 direct colors and set every gun to only 4 values.... not very usefull for a mode only sensible for displaying pictures ....
But there was a pseudo-HAM mode were a viever would let the copper set a new pallete on every new line. Quite impressive results ....
-
Do accelerators remove this memory bandwidth contention or do they sit on top of it?
Accelerators don't change anything about the chipset, only the CPU. (Matter of fact, they don't even affect fast RAM, which is why all the really good accelerators have on-board memory that runs as fast as the new CPU.) That's why RTG makes such a difference in performance: access to chip RAM is still constrained by the chipset speed and contention, whereas Z2/Z3 access is unconstrained (and, for Zorro III, faster in general.)
-
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?
HAM6 isn't emulated, it's still native to AGA. In addition to OCS/ECS's HAM6, AGA introduced HAM8 - 2^6=64 color palette or 6 bits of R/G/B variance. Since AGA quadruples video bandwidth (double clock & double width) it can run 8 bitplanes (planar or HAM8) even in SuperHires.
Do accelerators remove this memory bandwidth contention or do they sit on top of it?
Accelerators have no impact whatsoever on graphics capabilities, chip RAM bandwidth and such. For that you'll need to head the RTG route.
-
(double post, sorry)
-
What makes "slow RAM".. slow ?
-
What makes "slow RAM".. slow ?
It suffers the same contention with the chipset for access as chip RAM does.
-
But why RAM that suffers chip accesses, but still can't be accessed by the same chips?
-
It's a quirk of Agnus/Fat Agnus, I believe. It was fixed in later versions, but unfortunately most/all stock 500s have it.
-
The A501 expansion RAM and Zorro-II RAM all becomes slow-RAM in an A500 ..?
-
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.
-
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?
-
Aha.. that's why A500 was SO slow.. ;)
Jpeg decode = 30 minutes/image..
-
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.
-
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
-
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.
-
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.
-
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?
-
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.
-
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.
-
Wait, I can. Check this out. What might have been.
-
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.
-
Wait, I can. Check this out. What might have been.
Any chance of getting those in non-"crappy JPEG thumbnail" form?
-
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.
-
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 :)
-
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 see, that makes sense. What exactly was the purpose of 1280x256/200 anyway? Very odd resolution.
You need that pixel clock for productivity mode. The sync is programmable, so it would be harder to specifically block that mode than to let you use it.
-
The A501 expansion RAM and Zorro-II RAM all becomes slow-RAM in an A500 ..?
No.
With the original A500 Agnus you'd get the infamous 'slow RAM' at $C00000. This happens because the PLCC Agnus was expanded to allow for addressing of 1 MB (much cheaper than an extra RAM controller), but C= 'forgot' to upgrade the chipset registers with the neccessary address bit, so the chips themselves can't reach that high. To make sure that the RAM isn't configured as chip RAM (which simply wouldn't work) the highest address bit is swapped so the RAM appears at $C0 instead of $08.
Since the 'slow' RAM is accessed through Agnus and the chip bus, the CPU has to wait for the bus to be available - thus it isn't any faster than real chip RAM.
For ECS they made up their minds and added the missing address bit to the registers and voilá - 1 MB chip RAM were there.
The A3000's chip RAM is slightly different (similar to AGA) as the CPU can access it 32-bit wide - effectively the CPU's getting double bandwidth. It's no real surprise that Alice is somewhat pin-compatible to the A3k's Agnus and with AGA the 32 bit access can be used by video DMA as well.
However, the CPU's got its own bus with ROMs, CIAs - and fast RAM. This is usually Zorro II connected and it's never slowed down by the chipset!
-
A neat hack in the Amiga days would be to make a Zorro-II RAM of a A501 expansion with little or none support circutry. In essence an adapter.
-
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.
-
@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.
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.
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.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?
Yeah 4 bits is not enough to do anything meaningful.
It might be possible to play around with HAM in hires on the Amiga using copper for writing the additional bitplane data registers. The copper resolution isn't great but it might be possible to do some funky stuff with it. If you can enable HAM6 in hires but disable the dma for bitplane 0 & 1 then you'd effectively have HAM4. You might then be able to use the bitplane data registers to do brightness control from the copper, which would be interesting.
-
@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.