Amiga.org
Amiga computer related discussion => General chat about Amiga topics => Topic started by: woof on June 02, 2016, 12:41:43 PM
-
At some points in the 90s engineers at Amiga inc had planned the future with AGA, Super-AGA...
But certainly some engineers said "we will need a chunky mode": it will be simpler to program, more efficient, etc...
And then at this point some director said "it will cost too much" "bitplanes are enough for a game engine" "they can buy a graphic card" and other oddities
What is the name of this stupid man ?
Alain Thellier
-
At some points in the 90s engineers at Amiga inc had planned the future with AGA, Super-AGA...
But certainly some engineers said "we will need a chunky mode": it will be simpler to program, more efficient, etc...
And then at this point some director said "it will cost too much" "bitplanes are enough for a game engine" "they can buy a graphic card" and other oddities
What is the name of this stupid man ?
Alain Thellier
It was planned for AAA. (See Dave Haynie)
Kamelito
-
What is the name of this stupid man ?
Alain Thellier
Medhi Ali?
Why Amigas never had a chunky mode ?
At least CD32 had Akiko chip and chunky modes was planned for next generation chipset but commodore were bankrup before that, you know
-
Because every ceo and upper management needed the highest salary possible complete with golden parachutes as they left the company.
Insane that they had a 256 Color C=64 in the works by 1991 and didn't even release that.
256 colors should have been standard by the time the A500/2000 came out at the earliest and by the release of the CDTV / A3000 the very latest. ESC should have had 256 colors out of 4096 / 32000, 262000 or 24 bit palette.
Instead... they waited until...1992... forget about C2P.
-
Because every ceo and upper management needed the highest salary possible complete with golden parachutes as they left the company.
Insane that they had a 256 Color C=64 in the works by 1991 and didn't even release that.
256 colors should have been standard by the time the A500/2000 came out at the earliest and by the release of the CDTV / A3000 the very latest. ESC should have had 256 colors out of 4096 / 32000, 262000 or 24 bit palette.
Instead... they waited until...1992... forget about C2P.
Your right. The 256 colour CD32 AGA version of Wing Commander should have been the standard Amiga version in 1992 (already 2 years behind the PC) and the chunky screenmode enabled Amiga A1200/4000 released in Christmas 1992 it time for Doom in 1993/94.
-
Aren't the 1bit screen modes chunky? ;)
-
and the CD32... I really liked it. BUT come on, a main selling point was the 32bits...they used a NINE year old 32 bit CPU. (the 020) came out in 84.
-
You know smerf, best jokes on this site are better if left unsaid. The Media police are watching, and I had a really good slam dunk for Haynie. Sorry Dave but this old Commode rep, just can't say it.
-
At some points in the 90s engineers at Amiga inc had planned the future with AGA, Super-AGA...
But certainly some engineers said "we will need a chunky mode": it will be simpler to program, more efficient, etc...
Historical accident. At the time the Amiga chipset was designed, the available RAM bandwidth with technology available back then was not sufficient to allow a 256 chunky mode, and the planar mode had the nice property that you could the same blitter engine regardless of the number of colors in the screen. Hence, it allowed a bit-depth independent unified design.
At the time the bandwidth became available, CBM already left the road of sane management, was cutting costs and only made minimal investments to keep the platform alive. It was planned, but it required too many changed in the system - a new blitter would have been required, for example.
-
Only if you have 256 colours, you don't waste precious RAM in a chunky mode. Planar never wastes even a single bit. The Amiga was designed when 256 or 512kb of RAM were very expensive. In addition the RAM wasn't fast enough to give you the required bandwidth for a chunky mode with reasonable resolution. So planar graphics was a perfectly logical choice in the mid-80s. When they eventually did AGA they probably realised that with now 256 colours they could have done a chunky mode without wasting RAM or bandwidth but they just considered it too much work and decided to do just a lazy patch job of ECS changing only the screen DMA engine. At that time they would not only have had to add chunky gfx but also 16 bit audio and a 32 bit blitter to have kept it competitive.
-
and the CD32... I really liked it. BUT come on, a main selling point was the 32bits...they used a NINE year old 32 bit CPU. (the 020) came out in 84.
odd number 68K CPUs indicated a change to architecture more so than performance and most of those improvements in architecture simply would not benefit a game console, so unless they were going to put an a 040, 020 CPU was the only one that made sense.
-
Only if you have 256 colours, you don't waste precious RAM in a chunky mode.
You don't waste RAM, but you waste computing power and bandwidth when manipulating the display. Even with a blitter, modifying an eight-bitplane display requires (unless you are lucky) eight separate accesses to the RAM, once per bitplane. Chunky requires only one. Plus, you save all the computations to extract individual bits.
When they eventually did AGA they probably realised that with now 256 colours they could have done a chunky mode without wasting RAM or bandwidth but they just considered it too much work and decided to do just a lazy patch job of ECS changing only the screen DMA engine.
Well, I wouldn't generalize it by that, especially "they". As far as the engineering department was concerned, people there were well aware that a major revision of the hardware architecture was urgently necessary, but CBM was short of money and resources, and a management vision.
At that time they would not only have had to add chunky gfx but also 16 bit audio and a 32 bit blitter to have kept it competitive.
A couple of these ideas (and much more) was planned for AAA, but CBM went down under just before this was completed.
-
Even with a blitter, modifying an eight-bitplane display requires (unless you are lucky) eight separate accesses to the RAM, once per bitplane.
Per pixel, but you can access 16 pixels at a time.
Well, I wouldn't generalize it by that, especially "they". As far as the engineering department was concerned, people there were well aware that a major revision of the hardware architecture was urgently necessary, but CBM was short of money and resources, and a management vision.
They relied on the A500 to prop up the company while the chip guys went off down the wrong road of AAA.
A couple of these ideas (and much more) was planned for AAA, but CBM went down under just before this was completed.
Chunky pixels were suggested for AA and would likely have made it into it's successor (generally referred to as AA+). They ran out of time for AA because they had started it too late and then put the project on hold. AA+ didn't happen due to lack of cash.
AAA was nowhere near ready when CBM went down. The Nyx motherboard wasn't production ready, the chips didn't work and there was no software. I wouldn't be surprised if it would have taken them another 12 months.
-
Can the color registers be modified fast enough to emulate chunky mode?
-
Per pixel, but you can access 16 pixels at a time.
Only if you have a 1 bit per pixel mode, obviously. There's also the problem that the Amiga blitter accesses memory at 16 bit boundaries, which means you need to blit 16 bits extra for positioning. A chunky blitter that accesses memory at 8 bit boundaries doesn't need the extra bits when blitting to an 8 bit screen.
Can the color registers be modified fast enough to emulate chunky mode?
Yes, but you can't do full screen 1x1 pixel mode that way.
-
Maybe if Commodore had not refused the RANGER chipset, the 256 colors would have been available.
-
Copper Chunky has been done in demo, sure it's not real chunky but show how versatile the Amiga chipset are.
Kamelito
-
At some points in the 90s engineers at Amiga inc had planned the future with AGA, Super-AGA...
But certainly some engineers said "we will need a chunky mode": it will be simpler to program, more efficient, etc...
And then at this point some director said "it will cost too much" "bitplanes are enough for a game engine" "they can buy a graphic card" and other oddities
What is the name of this stupid man ?
Alain Thellier
Reason Amiga's never had a chunky mode is because they didn't have a bloated Operating System running them.
-
You don't waste RAM, but you waste computing power and bandwidth when manipulating the display.
Did you really read what I wrote? I wrote: "Only if you have 256 colours, you don't waste precious RAM in a chunky mode."
An 8-colour chunky mode would need e.g. 640x256x1 bytes while an 8-colour planar mode takes only 640x256x3/8 bytes, i.e. in each chunky byte some of the bits would be "don't care" and thus wasted. Hence, a chunky mode would have been a waste of precious RAM unless it would have been a 256-colour chunky mode (there are 16-colour chunky modes in some PC gfx cards where each pixel takes on nibble). 256-colour modes were hardly feasible in 1985. When they eventually were, Commodore were too cheap or lazy or stupid to add them.
-
In the age when all PCs had 4 planes max, the Amiga supported 5 or 6 counting EHB mode. The AGA chipset was just an incremental kludge on that since the AAA chipset was taking too long. It was important in the beginning to support odd-numbered bits-per-pixel to get 32 or 8 colors without wasting RAM. By the time AGA came out, they just came out with a hack without even updating the blitter for fast-page mode much less chunky as well.
-
Only if you have a 1 bit per pixel mode, obviously.
You are moving 16 bits of one plane, so after operating on all 8 planes you have moved 16 bytes which corresponds to 16 pixels. Which is the same number you move with chunky pixel mode.
There's also the problem that the Amiga blitter accesses memory at 16 bit boundaries, which means you need to blit 16 bits extra for positioning. A chunky blitter that accesses memory at 8 bit boundaries doesn't need the extra bits when blitting to an 8 bit screen.
That is the only situation where planar does require extra bandwidth. While it's nice to have everything as fast as possible, it would usually only be statistically significant on small blits whose time is mostly taken up by the blitter startup.
The tl;dr reason it was planar was that memory was so expensive when they designed the chipset and by the time memory prices dropped, it was too late to change. It was hard enough to get it out there "let's redesign everything because we can make it 1% faster" would not ever happen.
For the longer version...
https://www.youtube.com/watch?v=RXKcMFoRsN4
https://www.youtube.com/watch?v=DOo1HA66BWw
https://www.youtube.com/watch?v=dRNsKvGwKOM
AA was where chunky pixel should definitely have happened, but that project was mishandled by management (and besides it should have been started in 1989 instead of AAA).
-
You are moving 16 bits of one plane, so after operating on all 8 planes you have moved 16 bytes which corresponds to 16 pixels. Which is the same number you move with chunky pixel mode.
16 bits of one plane only equals 16 pixels in 1 bit per pixel mode. If you have more than 1 bit per pixel, you're handling parts of pixels. Part of pixel != pixel :p
That is the only situation where planar does require extra bandwidth.
Which is a very common situation: Blitter based sprites (bobs).
While it's nice to have everything as fast as possible, it would usually only be statistically significant on small blits whose time is mostly taken up by the blitter startup.
It's absolutely NOT insignificant. When you're blitting 16 pixel wide bobs (quite common), you're wasting half the blitter time on the 16 extra bits per bob.
Anyway, assuming AGA chunky, I was wrong, because the blitter would still have to access whole 32bit words in memory to get to the individual bytes. That it would get rid of the need for extra shift bits is irrelevant. Only a faster blitter would make sense.
-
1/5 of 16 pixels for 5 bit planes.
What is the limitation of a bit-plane system?
It seems to be a flexible system.
It looks as one could design a chip to move almost any number of bits at a time.
-
16 bits of one plane only equals 16 pixels in 1 bit per pixel mode. If you have more than 1 bit per pixel, you're handling parts of pixels. Part of pixel != pixel :p
Every word transferred in 256 colour planar mode is 16 * 1/8's of a pixel, in chunky it's 2 * 8/8's of a pixel. The maths works out the same, the fewer the bitplanes the more planar wins in terms of speed.
It's absolutely NOT insignificant. When you're blitting 16 pixel wide bobs (quite common), you're wasting half the blitter time on the 16 extra bits per bob.
Sure, but the overall time of those small blits is then not the blitter bandwidth but the CPU time driving the blitter. The bandwidth itself becomes more important on larger bobs, when the cpu and planar overhead decreases.
Anyway, assuming AGA chunky, I was wrong, because the blitter would still have to access whole 32bit words in memory to get to the individual bytes. That it would get rid of the need for extra shift bits is irrelevant. Only a faster blitter would make sense.
Yes the blitter could be exactly the same if AA was chunky as you still need to shift by 0/8/16/24 pixels, or you would only be able to move bobs on 4 pixel boundaries.
A 32 bit blitter would have been the only practical way to make it faster and the time and money to do that would be difficult to justify, when everyone was saying AAA was the future. Although I'd have probably left the 2d blitter to work with 16 bits for compatibility and added texture mapping, which coupled with chunky pixels would have it easy to write doom clones for the amiga. The 3do was started around the same time as AA was in development, so the idea of a 3d games machine wasn't particularly exotic.
What is the limitation of a bit-plane system?
It seems to be a flexible system.
It looks as one could design a chip to move almost any number of bits at a time.
Yes you could do 32 bit true colour displays with bitplanes, however it wouldn't be worth it.
The main limitation is manipulating images with a cpu is more complex. In 256 colour chunky pixel mode you can use a single byte write to set one colour. In planar mode you need to read 8 bytes, mask the pixel out of each and or in the individual bits of the pixel and write it back. Once you get to 256 colours it makes far more sense to use chunky pixels. The blitter overhead is also a factor, but nowhere near as much as the cpu.
-
The progression seems to be toward chunky anyway. :)
The C64 and eventually the C65 would benefit from the Planar System.
-
What prevents darn fast planar modes on on modern FPGA? :)
-
Every word transferred in 256 colour planar mode is 16 * 1/8's of a pixel, in chunky it's 2 * 8/8's of a pixel. The maths works out the same, the fewer the bitplanes the more planar wins in terms of speed.
You said:
Per pixel, but you can access 16 pixels at a time.
And that's only correct when you have a 1 bit per pixel mode.
Sure, but the overall time of those small blits is then not the blitter bandwidth but the CPU time driving the blitter.
Is that an estimate or experience?
Yes you could do 32 bit true colour displays with bitplanes, however it wouldn't be worth it.
Just like those ridiculous 24 bit iffs :lol:
-
What prevents darn fast planar modes on on modern FPGA? :)
What's the use? With fast hardware and lots of memory you just don't need planar. More annoying to program, and no advantages.
-
And that's only correct when you have a 1 bit per pixel mode.
Ok rain man. We both know I was talking about one plane of 16 pixels.
Is that an estimate or experience?
Don't take my word for it, get an unexpanded a1200 and test it. Just compare an aligned blit to an unaligned one. That gives you the raw starting numbers, then come up with a reason for moving all of those bobs around as static bobs are rather pointless. Then come back and tell us what you found.
More importantly would fixing that particular issue have stopped the amiga from being killed by pc's and game consoles?
Delaying the launch would just have cost them more money. If AA had been started sooner then chunky 256 colour pixels & 32 bit blitter would have been easier to justify, but even then it would have ultimately made no difference.
2d blitting was no longer important. The mega drive had multiple layers of tiles and large number of sprites, the next generation was 3d.
Commodore would have needed 16 bit sound and video with texture mapping hardware, essentially hombre. Unfortunately they had wasted too much time and money on other projects and there was no time to do it, let alone do it properly and have it backward compatible. Although a half way house of 8 bit chunky pixels with non shaded texture mapping even as late as 1992 may have given them a couple of years breathing space (they could probably have done texture mapping in planar but it wouldn't be worth the complexity).
What prevents darn fast planar modes on on modern FPGA? :)
Nothing. While more memory bandwidth and faster cpu and blitter will improve the speed of planar, they would also improve the speed of chunky pixels. Obviously for backward compatibility the focus has been on planar. My hope is that the future holds chunky and true colour extensions to AA so all screens can be hardware drag-able. Currently the RTG extensions on FPGA appear to be targeted at separate display subsystems that are more suited to Picasso/CyberGFX etc.
-
>In 256 colour chunky pixel mode you can use a single byte write to set one colour.
Of course the original question was intended for 8 bits
"Why Amigas never had a 8bits chunky mode?"
In fact I have all the time asked myself "why when they did AGA with 256 colors didnt they do it as a chunky mode ?" They (the smart engineers at Amiga) certainly realise that 4/5/6 bitplanes got sense in A1000 era but 8 bitplanes didnt have sense anymore...
Of course modifying the blitter would have been a big task ... but even without an updated blitter an A1200 with 8bits chunky would have been a good idea for games like doom/quake that used mostly the cpu for drawing at that time
Alain Thellier
-
Of course the original question was intended for 8 bits
"Why Amigas never had a 8bits chunky mode?"
In fact I have all the time asked myself "why when they did AGA with 256 colors didnt they do it as a chunky mode ?" They (the smart engineers at Amiga) certainly realise that 4/5/6 bitplanes got sense in A1000 era but 8 bitplanes didnt have sense anymore...
Time and money. Pandora was started late as an emergency project by a couple of engineers to stop the company from collapsing, it wasn't a particularly popular project as people needed to justify all the money that had already been spent on AAA. It was put on hiatus part way through development.
The leaked amiga os source code had a future document from the time before AA was released and chunky pixels were mentioned in there.
Of course modifying the blitter would have been a big task
The blitter wouldn't necessarily have needed any changes at all. Although this would require you to have 8 bit masks, which would be slower and take more memory. I doubt that adding the ability to expand a 1 bit mask would be amazingly hard, but if it couldn't be justified then chunky pixels would still have been worthwhile. You would probably also add the ability to create the mask from the source or destination as well. Blitter line drawing and area fill would need more work, but again it's probably not that much and wouldn't be a huge problem now if it wasn't done.
-
There's also the problem that the Amiga blitter accesses memory at 16 bit boundaries
Is this also the case on the 32bit Amigas ? A4000 / A1200 ?
N.
-
and the CD32... I really liked it. BUT come on, a main selling point was the 32bits...they used a NINE year old 32 bit CPU. (the 020) came out in 84.
The Amiga 1000 was released in 1985 with a processor (the 68000) that had been first released in 1979. Sometimes it takes time for a chip to get affordable enough for it to start finding its way into home equipment (i.e. a sub-$300 game console like the CD32).
-
Hi,
There's a lot of talk about "Hazy" Dave Haynie's work but no URL.
See http://www.thule.no/haynie/
"Advanced Amiga Architecture (AAA) overview (PDF)"
Regards, Michael
aka rockape
-
What prevents darn fast planar modes on modern FPGA? :)
Learning to walk before you can run. The FPGA projects has so far had enough to do with getting stable, compatible and feature complete. (Well, available too for that matter.)
Next, getting the cpu part up to speed(hah!) is typically also more important as users might be used to faster solutions from back in the day, and because compatibility is good across different cpu versions and speeds.
Throw compatibility to the wind and you can go as fast as you can make it. The overarching(?) problem is the fixed clock and access slots in the chip architecture. Modern memory likes to do sequential access to get effective bandwidth but you can change pointers every 2(IIRC) lowres pixels with original timings which ruins what your memory can do for you. If you make a chipset you can access faster then it just gets "worse".
Any new chipset wants to be both modern and compatible and so it has to abide by the original rules and also present its own new ones - and these new rules have to be less flexible necessarily, much like AGA probably. The logic that was so clear with OCS starts falling apart when a register update doesn't take effect before long after when many many more probably have been done.
The only through-and-through high-end solution for a modern chipset would probably be SRAM based which is deterministic for any access but still has the same problems with price and memory size as it has always had...
-
What's the use?
To run Amiga applications, of course :hammer:
-
Is this also the case on the 32bit Amigas ? A4000 / A1200 ?
Unfortunately so, they only changed the display to use 32 or 64 bit fetches. This does mean that even a 256 colour 15khz screen has plenty of chip ram bandwidth available to the cpu and blitter, but the blitter is a bit of a waste.
I don't think they changed copper either. It's traditional commodore though, the C64 was rushed and so was AA, the difference is that the later didn't need to be (the C64 was pretty cutting edge).
-
The Atari 600/800 were cutting edge in 1979.
Kamelito
-
The Atari 600/800 were cutting edge in 1979.
Kamelito
It was expensive, only had 8k of ram, the sound chip is horrible. It had lots of colours (like the Atari 2600), but limited sprites.
The Atari 800XL was better because it had 64k of ram, the sound chip was just as bad and the games still looked as horrible as they did in 1979. That may not have been a problem but they couldn't make enough of them, which led to the rumour they were stopping manufacture. And they couldn't compete on price and still make a profit. Once the software developers realised that people weren't buying them, they stopped writing games for them.
The only game that I have ever seen that blows away the c64 was the recent space harrier port. I know technically there are some good things about the Atari 800 design and poor about the c64, but in practice they don't matter enough.
-
Rescue on Fractalus come to mind.
Kamelito
-
Rescue on Fractalus come to mind.
I played it on the c64, I don't remember if I played the Atari version. How different is it?
-
It was planned for AAA. (See Dave Haynie)
Kamelito
Why would you want to see Dave Haynie, he is still working on the Super AAA chip set.
smerf
-
I played it on the c64, I don't remember if I played the Atari version. How different is it?
I'd say faster and more colorfull check on YouTube.
Kamelito
-
Why would you want to see Dave Haynie, he is still working on the Super AAA chip set.
smerf
?
Kamelito
-
It was expensive, only had 8k of ram, the sound chip is horrible. It had lots of colours (like the Atari 2600), but limited sprites.
POKEY has a distinctive sound and well used usually beats the Texas or GI rivals. It's just a matter of taste but it's far from horrible :)
Miner's chipset design was mindblowing from the beginning, I'm not going to say that it's superior that VICII+SID (that I really believe it's not); but given the date, it's an extremely powerful design.
Last years we've been enjoying developments pushing the architecture to its limits and are truly amazing for a 79' dated machine.
-
and the CD32... I really liked it. BUT come on, a main selling point was the 32bits...they used a NINE year old 32 bit CPU. (the 020) came out in 84.
Well the '020 was still being produced in 1993 so it's not like C= picked them up at some yard sale..
Back then, old CPU models stuck around for much longer, at a lower price, while new models were introduced. For exmaple, the 68000 started in 1979 as a super high-end chip in expensive workstations etc., then in expensive arcade machines, then it filtered down to the A500, A600, Atari ST etc 8 - 10+ years later. Same thing happened to a lesser extent with the '020 and '030.
It's easy to see the CD32 as underpowered today, but tech moved incredibly fast in the 90's, more so than the 80's IMO. What was fine in 1993 was outdated in 1994 and worthless in 1995. At launch in 1993, the A1200 and CD32 were not cutting edge, but great machines at their pricepoints. While Doom also came out in 1993, it required a £1000+ PC to run. Even with a chunky mode and '030, the CD32 wouldn't have handled 3D games that well compared to later consoles like the Playstation, because it had no dedicated 3D hardware. It was built for 2D, with lots of support chips to handle 2D graphics, sprites, smooth scrolling etc. C= had Hombre which would have been in their 3D-capable console if things had worked out.
-
Well the '020 was still being produced in 1993 so it's not like C= picked them up at some yard sale..
The EC020 they used was essentially the cheapest cpu they could get. It was for embedded designs, it was not really aimed at desktops. 14mhz was probably a bit slow as well. They would have been limited by the chp ram speed though.
-
I played it on the c64, I don't remember if I played the Atari version. How different is it?
Faster, better. The Ataris had a very canonical screen layout which made it very easy to draw graphics, i.e. a simple rectangular screen array. x position shifted, plus y times bytes per row = screen address.
The C64 was good at character map graphics and sprites, but as soon as you had to render graphics for any kind of simulation (Rescue, soloflight, FS-II, the Eidolon, ...) it was quite horrible due to its non-canonical screen-addressing. You first had to find the 8x8 block on the screen the pixel lies in, then compute its address, then compute the position within the 8x8 block. This plus the lower CPU frequency typically slows such games down to a crawl.
-
Faster, better. The Ataris had a very canonical screen layout which made it very easy to draw graphics, i.e. a simple rectangular screen array. x position shifted, plus y times bytes per row = screen address.
The C64 was good at character map graphics and sprites, but as soon as you had to render graphics for any kind of simulation (Rescue, soloflight, FS-II, the Eidolon, ...) it was quite horrible due to its non-canonical screen-addressing. You first had to find the 8x8 block on the screen the pixel lies in, then compute its address, then compute the position within the 8x8 block. This plus the lower CPU frequency typically slows such games down to a crawl.
In other words, the C64 version is a very good port. :)
ROF used to scare me to near death when I was a kid! As a kid I never figured out that the aliens had green heads when approaching your ship. But, even so, sometimes they're out of sight when walking towards your ship, so can still suprise the player.
Fantastic game, fantastic atmosphere - my favourite C64 game I think.
-
i.e. in each chunky byte some of the bits would be "don't care" and thus wasted. Hence, a chunky mode would have been a waste of precious RAM unless it would have been a 256-colour chunky mode (there are 16-colour chunky modes in some PC gfx cards where each pixel takes on nibble). 256-colour modes were hardly feasible in 1985. When they eventually were, Commodore were too cheap or lazy or stupid to add them.
The wasted ram isn't the biggest problem, it's the wasted ram bandwidth. A lores screen would be as slow as 16 colour hires turned out as and hires itself would be impossible. You could do packed nibbles when you used 16 or less colours, but that has it's own issues.
Commodore management didn't really want AGA in the first place, they then tried to kill it, but when they couldn't kill it they managed to starve it of development so it was as small an upgrade as they could get away with.