@everyone.

In answer to the original question, "no".

It was the buffoons running the company (into the ground, that is!) that crippled the poor dear....

@Hypex

Hello.
I hope you do not mind me asking.
How can we determine what the limitations would be of a bit-plane system?

_________________
John 3:16

Quote:

Trekiej wrote: How can we determine what the limitations would be of a bit-plane system?

By comparing the numbers of read, write and masking steps needed on a chunky and a bit plane oriented system. Number of steps for writing of irregular shapes on bit plane oriented systems are big and increasing with the number of bit planes needed.

Last edited by OneTimer1 on 19-Apr-2020 at 02:51 PM.

@Trekiej

I don't mind. The main gripe seems to be with writing one pixel at a time, which requires masking out and writing out the pixel bits for every bitplane. Like as stated.

Now, if a rectangular block of pixels is written to, this isn't so much of a big deal. But if the pixels aren't on a 16 or 32 bit pixel alignment then masking and shifting work needs ot be done to insert the data into the bitmap. Usually the blitter does this but the CPU speed soon outgrew the blitter

8 bit depth is really the most practical you can go and the Amiga reached this. But at this point it is a lot of plane to manage. At this point packed or chunky is easier to work with. However, with alignment restrictions as above and optimising using interleaved bitplanes at 8 bit depth, the amount of bytes to write is the same as with chunky.

With rotation, warping and scaling of bitmaps, bitplanes are harder to work with. The Amiga never had any blitter support for this and this was where it was needed. So programs were forced to do this in software or use limited blitter support.

So, at the end of the day, bitplanes became too rigid. Now , this would have been fine, if there was hardware support for the little things like pixels or even being able to write chunky and have the chipset convert it on the fly. But it never did.

@Hypex
@ onetimer1

Thanks.
I think it would be great if the Amiga had a Chunky over Planer graphics or vice versa.
Maybe it could switch to a pure Chunky mode.

_________________
John 3:16

@Thread

Doom was perfectly playable on a 030/50 AGA machine as proved by the ADoom / DoomAttack conversions in 1998. The problem was that ID Software did not believe it was possible and Commodore did not throw the required money at them like they did with Origin for a Wing Commander conversion!

Yes, going forwards Commodore needed Chunky Pixel modes or on the fly conversion built into the hardware to convert chunky pixel coding for display as planar but if AGA had debuted on a 1991 A3000+ like was originally planned then the AAA should have been available in 1994 to pick up the slack on the graphics front ready for Doom 2, Duke Nukem etc.

Paula by comparison was never ever upgraded EVER which was far more of a disgrace for the AGA machines than the lack of chunky pixel modes! Sound / floppy storage capacity advantage over the PC were both key advantages than were just handed over to Commodore's competitors without a second thought. Scandalous! On paper the Atari Falcon wiped the floor with the A1200 other than price (though in practice the A1200 had better software, wasn't crippled by a 16bit data bus like the Falcon and had more upgrade potential).

Last edited by BigD on 20-Apr-2020 at 11:35 PM.
Last edited by BigD on 20-Apr-2020 at 11:32 PM.
Last edited by BigD on 20-Apr-2020 at 11:28 PM.

_________________
"Art challenges technology. Technology inspires the art."
John Lasseter, Co-Founder of Pixar Animation Studios

@Trekiej

In a way the Amiga did have chunky in the form of a graphic card. Of course you needed a big box Amiga. AFAIK it was in the early 90's that the Amiga got RTG. These had 8-bit chunky and most had 24-bit as well. Guess the writing was on the wall.

Last edited by Hypex on 29-Apr-2020 at 03:46 PM.

Deleted ...

Last edited by OneTimer1 on 28-Apr-2020 at 08:41 PM.

@BigD

Quote:

Doom was perfectly playable on a 030/50 AGA machine as proved by the ADoom / DoomAttack conversions in 1998. The problem was that ID Software did not believe it was possible and Commodore did not throw the required money at them like they did with Origin for a Wing Commander conversion!

I found DoomAttack to be the fastest. Though it may have been running in super "low" res.

The Mac had chunky by then and lots of 3d games of the like. I've found 68k Doom so they could have cross ported that. But I found a video and it doesn't look pretty. I've also read about other 68K machines with chunky that weren't up to the task, so it looks like the 68K got the blame for not being fast enough. When we know it is.

http://www.google.com/url?q=https://www.youtube.com/watch%3Fv%3DP7A8VYw_ncM&sa=U&ved=2ahUKEwj1iOLTrpDpAhVBWH0KHSZdAccQtwIwBXoECAQQAQ&usg=AOvVaw3xosrzoMnn4Fqkx3rAGkqu

Another problem is that Doom is unsuitable for the Amiga. It's somewhat "backwards" in that the Doom engine is all about software rendering. I don't even think it makes use of VGA hardware scolling features. The on screen characters are called spirtes, but this is technically incorrect as they are not hardware sprites. Sprites imply hardware sprites. They aren't even blitter objects. They are soft sprites like you do on a Commodore C16 that was considered backwards. But it was optimised to use that new VGA chunky mode with the funny pixel offsets.

The Amiga was all about hardware acceleration. Sprites. BOBs. Copper. Playfields. Doom has scrolling clouds, text overlays and a big gun. But they are rendered in software. That is not the Amiga way. The Amiga way is using the hardware to do these things. Even the Doom ports wouldn't do it that way. Compare with the Breed and Fears and the like. You can see they use real Amiga features as the guns look good, smooth and aren't pixelated. So Doom wasn't a game that could be properly ported, since the guts would need to be ripped out to be really optimised for the Amiga. I doubt any super "low" res chunky to planar or 12 bit RGB copper chunky would have cut it at iD Software.

Quote:

Yes, going forwards Commodore needed Chunky Pixel modes or on the fly conversion built into the hardware to convert chunky pixel coding for display as planar but if AGA had debuted on a 1991 A3000+ like was originally planned then the AAA should have been available in 1994 to pick up the slack on the graphics front ready for Doom 2, Duke Nukem etc.

They just needed to use the bandwidth they had, creating a new one bitplane mode, where the data was packed across. Or indeed, dividing the depth between packed bitplanes.

Quote:

Paula by comparison was never ever upgraded EVER which was far more of a disgrace for the AGA machines than the lack of chunky pixel modes! Sound / floppy storage capacity advantage over the PC were both key advantages than were just handed over to Commodore's competitors without a second thought. Scandalous! On paper the Atari Falcon wiped the floor with the A1200 other than price (though in practice the A1200 had better software, wasn't crippled by a 16bit data bus like the Falcon and had more upgrade potential).

It needed 16-bit either way. Even PCs apparently used software mixing later on. The Falcon wipes the floor even with that crippled bus. With all the features it had. It also has 16-bit sound, 8 channels, midi and damned chunky true colour modes. It was everything the Amiga A1200 should have been! In the end both Commodore and Atari would loose out. In this instance, I think Atari won the battle, but lost the war..

Last edited by Hypex on 30-Apr-2020 at 03:58 PM.

@Hypex

I do like the idea of the Graffiti graphics card.

Being able to change the two bottom colors (0 and 1) on the fly would be cool,
or just the bottom color.

_________________
John 3:16

@ppcamiga1

Quote:

ppcamiga1 wrote: Parallel write was trick used in good old times of 80 by almost every hardware company that use bitplanes. SGi, Apollo Workstations ... And of course IBM in EGA. It allows to have all bitplane advantages like less memory used simpler hardware with drawing almost as fast as on chunky pixels. 640x480 16 colors EGA mode use 4 bitplanes but is very fast. Unfortunately Commodore after buying Amiga does not invest in R&D and Amiga chipset was almost unchanged after its initial design in 1983. Parallel write will help a lot but we don't have it on Amiga.

IBM's EGA offered 640×350 resolution with 16 colors from 64 color palette.

IBM also released PGC(PGA) in 1985. PGC supports 640 × 480 with 256 colors from a palette of 4,096. PGC was a target for PGC clones that used TIGA (Texas Instruments Graphics Architecture). The PGC's matching analog RGB monitor display was recycled for 1987-era VGA.

EGA/VGA cloners have superior chip integration that enables IBM's standards to reach lower price points.

640x480 with 256 colors use case is recycled for IBM 8514 (1987), IBM XGA (1990, 8514 successors), and 8514/SVGA clones e.g. ET4000 (1989), Ati Mach8 (1991), Chips&Technologies F82C480 B EIZO (1990), IIT AGX, and 'etc'.

PGC --> 8514 --> XGA (clones has SVGA)
EGA --> VGA --> XGA (clones has SVGA)

Commodore management has a "read my lips, no new chips" directive during A3000's R&D phase.

_________________
Ryzen 9 7900X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB
Amiga 1200 (Rev 1D1, KS 3.2, PiStorm32lite/RPi 4B 4GB/Emu68)
Amiga 500 (Rev 6A, KS 3.2, PiStorm/RPi 3a/Emu68)

@Hypex
Quote:

I t needed 16-bit either way. Even PCs apparently used software mixing later on. The Falcon wipes the floor even with that crippled bus. With all the features it had. It also has 16-bit sound, 8 channels, midi and damned chunky true colour modes. It was everything the Amiga A1200 should have been! In the end both Commodore and Atari would loose out. In this instance, I think Atari won the battle, but lost the war

Baseline Falcon's 16-bit color chunky is a hi-color display that is limited by 16 Mhz 16-bit shared bus.

True color is 24 bit color display.

Deep color is 30 bit color display.

PC VLB has 32 bits with clock speeds up to 50 Mhz (486DX-50). 486DX2-66 has 33 Mhz FSB, hence its VLB is also 33 Mhz.

It's too bad A1200 couldn't maximize the 14 Mhz 32-bit bus.

Any software ported to dead-end Motorola 56K DSP is boat anchored to it.

Amiga's 68K target scales with hardware performance.

_________________
Ryzen 9 7900X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB
Amiga 1200 (Rev 1D1, KS 3.2, PiStorm32lite/RPi 4B 4GB/Emu68)
Amiga 500 (Rev 6A, KS 3.2, PiStorm/RPi 3a/Emu68)

Necronposting...

Actually the real question should have not been this:

"Could lack of parallel bitplane writes crippled the Amiga?"

rather this:

"Could use of bitplanes crippled the Amiga?"

@Hypex

A better solution than parallel writes would have simply been bypassing the planar-to-chunky stage in Lisa, i.e. having Lisa use the bytes received directly as color register indices. The most complex change would have been adjusting the bitplanes data fetching, but, given that Alice was new as well, that could have been done - it was not rocket science. Of course, for backward compatibility such chunky mode should have been made optional (a bypass bit in BPLCON3 would have sufficed).
That said, PED81C shows that AGA can actually do chunky natively (albeit with certain limitations)

EDIT: using -> use

Last edited by saimo on 27-Feb-2024 at 10:24 PM.

_________________
RETREAM - retro dreams for Amiga, Commodore 64 and PC

@saimo: that's what I've analyzed and I've proposed a solution on an article which I've published some months ago.

Here is it: Beyond Akiko: grafica packed al minor costo usando i bitplane (in Italian).

@cdimauro

Quote:

@saimo: that's what I've analyzed and I've proposed a solution on an article which I've published some months ago. Here is it: Beyond Akiko: grafica packed al minor costo usando i bitplane (in Italian).

I quickly skimmed through the article (sorry, no time), basically looking at the pictures. From them, it looks like one of your (commendable) goals was to minimize the changes to Alice.
But I was thinking of something different, as I didn't like the idea of wasting bitplanes pointers for accessing a linear memory space (it's redundant and that reflects also on code) - I didn't mention it because due to (again) lack of time; I couldn't afford discussing it and also all the doors that it would open...

Anyway (I know I'm going to regret this), very concisely, this is what I was hinting at and what I omitted:
* single pointer for a single byteplane;
* Alice and Lisa adapted to fetch and process data sequentially using a single pointer (no big deal);
* at that point, technical and economic restrictions permitting (and ditching HAM8, if that helped ), with some work and transistors, it would have been possible to implement also 2, 3 and 4 playfields in LORES and 2 playfields in HIRES (where each playfield is a byteplane), remaining within the AGA bandwidth capabilities (of course, multiple playfields would slow things down - e.g. a 4 playfields LORES screen would require as much bandwidth as a regular 256 colors SHRES screen);
* and then, given that we are in a fantasy world, let's go wild: how about adding BYPLALP0-BYPLALP3 registers in Lisa that indicate the transparency/opaqueness of the byteplanes with value between 0 and 256? Lisa would mix the byteplanes producing a 24 bit result to be sent directly to the video out...

Crazy ideas aside, not implementing chunky in AGA with the bypass method was really a missed opportunity. I really wonder whether the engineers, so focused on making AGA a mostly compatible, simply bigger version of ECS, just didn't think about it.

SIde note: now I'm just hoping that AGA hides a bug somewhere that stops Alice from fetching data for some bitplanes while Lisa unknowingly keeps on using the last latched data (a bit like what the 4/6 bitplanes trick does on OCS/ECS) - that would allow to make PED81c use half the bandwidth it currently needs!

_________________
RETREAM - retro dreams for Amiga, Commodore 64 and PC

@saimo

Quote:

saimo wrote: I really wonder whether the engineers, so focused on making AGA a mostly compatible, simply bigger version of ECS, just didn't think about it.

That's pretty much it. Or to be more precise, they avoided thinking about it. The Amiga was originally designed to have up to 8 bitplanes. AGA was simply the fulfillment of that.

AAA was going to have 8/4/2 bit chunky mode, but that chipset was too complicated and never got finished. AGA was developed in parallel with AAA when it looked like they might need something with intermediate capabilities sooner - which they did.

They deliberately avoided making big changes to the way AGA worked to simplify the design and maintain compatibility with OCS/ECS and the OS. IMO this was generally a good idea, but they should have found a way to squeeze chunky 8 bit chunky mode in there for compatibility with VGA - even if only as a marketing gimmick.

If I was going to drop anything it wouldn't be HAM8 - which was excellent - but 'promotable' high scan rate modes, as making them compatible was a huge headache. The vast majority of users would be using a TV or 15kHz monitor (which all previous software was designed for), and any high scan rate solution would require an expensive multisync monitor. The idea of being able to use a VGA monitor for everything didn't pan out. Commodore wasted a lot of effort trying to do it - effort they could have put towards a chunky mode.

@saimo

Quote:

saimo wrote: @cdimauro Quote: @saimo: that's what I've analyzed and I've proposed a solution on an article which I've published some months ago. Here is it: Beyond Akiko: grafica packed al minor costo usando i bitplane (in Italian). I quickly skimmed through the article (sorry, no time), basically looking at the pictures. From them, it looks like one of your (commendable) goals was to minimize the changes to Alice.

Exactly, and that's because I've taken into account the constraints that Commodore had on developing the new chips. Basically the transistors budget and, hence, the complexity of the chips.

All my proposals (included the ECS+ which I've reported on another two articles) have the same goal: keeping the transistors budget to a level which was within Commodore's ability.
Quote:

But I was thinking of something different, as I didn't like the idea of wasting bitplanes pointers for accessing a linear memory space (it's redundant and that reflects also on code) - I didn't mention it because due to (again) lack of time; I couldn't afford discussing it and also all the doors that it would open...

It's waste of bitplanes, yes, but if the goal was/is have just one playfield in packed/chunky mode... then who cares if all 8 bitplanes had to be loaded? In fact, the proposed change is really minimal in terms of implementations costs, and that's the most important factor here.
Quote:

Anyway (I know I'm going to regret this), very concisely, this is what I was hinting at and what I omitted: * single pointer for a single byteplane; * Alice and Lisa adapted to fetch and process data sequentially using a single pointer (no big deal); * at that point, technical and economic restrictions permitting (and ditching HAM8, if that helped ), with some work and transistors, it would have been possible to implement also 2, 3 and 4 playfields in LORES and 2 playfields in HIRES (where each playfield is a byteplane), remaining within the AGA bandwidth capabilities (of course, multiple playfields would slow things down - e.g. a 4 playfields LORES screen would require as much bandwidth as a regular 256 colors SHRES screen); * and then, given that we are in a fantasy world, let's go wild: how about adding BYPLALP0-BYPLALP3 registers in Lisa that indicate the transparency/opaqueness of the byteplanes with value between 0 and 256? Lisa would mix the byteplanes producing a 24 bit result to be sent directly to the video out...

Maybe up to 2 x 8-bit packed/chunky playfields it could have been possible (my idea can also be extended with little cost for supporting 4 x bitplanes for each of the two playfields both in packed/chunky mode) remaining within a reasonable budget, but that's just a guestimate (it requires a deeper analysis, like a I did on my above article).

However, everything else would have made the transistors budget exploding (especially supporting the transparency) and made it unrealistic for the time.
Quote:

Crazy ideas aside, not implementing chunky in AGA with the bypass method was really a missed opportunity. I really wonder whether the engineers, so focused on making AGA a mostly compatible, simply bigger version of ECS, just didn't think about it.

Maybe because such engineers lacked creativity. I really don't see anything smart, innovative which they've realized after the work of the original Amiga team.

Even the ECS was big missed opportunity, much worse than AGA, as I've proved on my other two articles.
Quote:

SIde note: now I'm just hoping that AGA hides a bug somewhere that stops Alice from fetching data for some bitplanes while Lisa unknowingly keeps on using the last latched data (a bit like what the 4/6 bitplanes trick does on OCS/ECS) - that would allow to make PED81c use half the bandwidth it currently needs!

AFAIR it requires SHRES, right? Then it consumes a heck of bandwidth... :-/


@bhabbott

Quote:

bhabbott wrote: @saimo Quote: saimo wrote: I really wonder whether the engineers, so focused on making AGA a mostly compatible, simply bigger version of ECS, just didn't think about it. That's pretty much it. Or to be more precise, they avoided thinking about it. The Amiga was originally designed to have up to 8 bitplanes. AGA was simply the fulfillment of that.

It should have been ECS, instead.
Quote:

AAA was going to have 8/4/2 bit chunky mode, but that chipset was too complicated and never got finished. AGA was developed in parallel with AAA when it looked like they might need something with intermediate capabilities sooner - which they did. They deliberately avoided making big changes to the way AGA worked to simplify the design and maintain compatibility with OCS/ECS and the OS. IMO this was generally a good idea, but they should have found a way to squeeze chunky 8 bit chunky mode in there for compatibility with VGA - even if only as a marketing gimmick.

It was NOT marketing, and you know it. And a packed/chunky mode which was 100% compatible with the OCS/ECS would have been absolutely possible (taking also into account the transistors budget), as I've proved on my above article.

They "simply" (!) lacked creativity. They worked on just patching the ECS, and in a horrible way...
Quote:

If I was going to drop anything it wouldn't be HAM8 - which was excellent -

Oh, yes: keep the HAM8 which was used by... how many applications? Are you serious?!?

How many applications and games could have used the packed/chunky, instead of HAM8?
Quote:

but 'promotable' high scan rate modes, as making them compatible was a huge headache. The vast majority of users would be using a TV or 15kHz monitor (which all previous software was designed for), and any high scan rate solution would require an expensive multisync monitor. The idea of being able to use a VGA monitor for everything didn't pan out. Commodore wasted a lot of effort trying to do it - effort they could have put towards a chunky mode.

That was already implemented on ECS, so AGA just borrowed it! And it wasn't expensive to implement, so what do you want to cut here?

BTW, even the MDA and CGA had programmable video modes using the very old Motorola 6845 chip (10 years BEFORE the ECS!). And you wanted to miss the opportunity to support multisync monitors on 1992, when they were already widespread?!?

@cdimauro

Quote:

They "simply" (!) lacked creativity. They worked on just patching the ECS, and in a horrible way..

And Cesare Di Mauro, is again bitching against the Developers Designers.
Does is make you happy to bitch and insult real developers?



Quote:

* Alice and Lisa adapted to fetch and process data sequentially using a single pointer (no big deal);

No big deal is very easy to say - for someone who someone outside who not did anything.


Yes I think we all agree that it would have been VERY cool if AGA would have had a Chunky Mode.
For DOOM like 2D games this would have made a big difference.

And such BYTE mode was planned for AAA.

AGA did unfortunately not had it.
We have to mind here that all these developments always were done under time pressure.

Maybe you guys recall when you at school had to write an exam in a certain time limit.
The same is true for all Amiga chipset developments.
They had a number of ideas, plans and wishes ...
And they had a Management closing the door at some point.
This is very normal in development.

In my opinion the Amiga designers did a very good job.
The Amiga developers did something real.
The Amiga were used by millions of people and they shaped a whole computer generation.


I think its very unfair from outside to look at any hardware development or any development and to start bitching.

Last edited by Gunnar on 28-Feb-2024 at 06:22 AM.

@Cesare

Quote:

They "simply" (!) lacked creativity.

Cesare why are you always insulting the Amiga developers?
How many posts did you write here in which you call the Amiga designers, stupid or uncreative or not good?

Are you not a person who never did anything in his life and has no skill for developing anything...
What gives you the right to "LOOK DOWN" on the Amiga inventors and to bash them?