@NutsAboutAmiga

To paraphrase a famous Simpson's quote:

The instruction cache. Won't somebody think of the instruction cache!

Of course, it remains to be seen how difficult this is for N-bit packed pixels for non power of two N. I can see the most optimal implementation would use a per depth, at least.

_________________
Doing stupid things for fun...

@QBit

Quote:

QBit wrote: @cdimauro From now on I ignore you.

It would be a pleasure.

However I don't understand why are still continuously replying me: just to satisfy your violated ago?

If you want to ignore me... just do NOT write to me, right? It's simple logic / good sense.
Quote:

You are an enemy of Amigaland!

Here's another very common logical fallacy of blind fanatics: any critics to the faith makes someone an enemy AKA infidel.
Quote:

#### off Amiga Enemies!

And here's the actions to be taken: infidels should be banned.

As I've said on the other thread, Censorship flows strongly on the Amiga land.

Fortunately here it's not a place like EAB, where you can get banned because you dared to criticize the faith...
Quote:

Planar Grafix with Bitplanes were the ####ing first Technology to display 4096 Colors at the same Time you ####ing fool!

At the internet time ignorance is not a mitigating circumstance, rather an aggravating factor:

GPU History: Hitachi ARTC HD63484. The second graphics processor.
https://www.computer.org/publications/tech-news/chasing-pixels/gpu-history-hitachi-artc-hd63484
Hitachi did NEC one better and introduced their HD63484 ACRTC Advanced CRT Controller chip in 1984.

The ARTC introduced 12k — (4096 × 4096 pixels) screen resolution; that is 8 times bigger than HD (1920 ×1080); however, it was only 1-bit deep, but it offered a unique (at the time) interleaved access mode for “flashless” displays. If you wanted 16-bit color (which it supported) than you would have to drop down to 1024 × 1024 resolution, which was astounding at the time and only a few monitors could support it.

https://archive.org/details/bitsavers_hitachidatitachi1984_10286622/page/n77/mode/2up?view=theater
Graphic Bit Mode
1, 2, 4, 8, 16 bits per pixel: 2, 4, 16, 256, 65536 colors.

From 4096x4096 to 1024x1024. From 2 to 65536 colors. In 1984! For PCs!
Quote:

Logic and truth is not YOURS You Idiot!

Personal attacks. The only way for you to satisfy your violated ego.
Quote:

The difference between me an you is I know when I am making an Idiot of myself..

The only thing where I fully agree with you.
Quote:

but YOU DON´T!!

No, believe me: I know very well how you are!
Quote:

How many Bits does a Pixel have on 24 Bit or 32 Bit Grafix! I don`t know how to Program Computers. I don`t know how Computers work I am really silly.

Then why don't you stop writing since you have no knowledge.
Quote:

But you fool cannot admit your own weaknesses. You always want to be the winner and you fool think you can`t ever lose!

PROVE IT!
Quote:

That`s the definition of a real Idiot!

Again, personal attacks.
Quote:

Put your salary up your Ass and your closed Source Products too. You wanna know what miseriness is? You speak German? GEIZ! Steck Dir Dein scheiß Geld in den Arsch! Ich unterstütze Kalamatee wann ich will OK! Eu supporto kalamatee quando eu quero! OK! Je supporte kalamatee quand je veux! OK! Und ich scheiße auf Deine Meinung! I am a Loser, Baby, so why don`t you kill me!

And to close your attacks, here's also indecency. You miss nothing, eh!

I've already reported your post to moderators before that you edited. Because I think that your behaviour is unqualifiable and totally against the site's TOS.

I'm publicly asking moderators to take actions against you (and the hamster has well, because he did similar attacks and personal offences in other threads) because I think that this isn't acceptable.

@Karlos

Quote:

Karlos wrote: @NutsAboutAmiga To paraphrase a famous Simpson's quote: The instruction cache. Won't somebody think of the instruction cache!

Well, if we take into account caches are well... it's even worse for bitplanes, because of data cache trashing (which is more important than code cache trashing which is coming for the additional instructions).
Quote:

Of course, it remains to be seen how difficult this is for N-bit packed pixels for non power of two N. I can see the most optimal implementation would use a per depth, at least.

The logic is similar to the bitplanes and to what was implemented by the Amiga's display controller and Blitter.

It's all about shifting and masking.

But much less than for packaged.

@all

Jesus Christ!, Buddha, Mohammed! I ####ing love EAB! hahahhahahahhaha



I have no skills.. but others have and they seem to develop what they like nowadays!

And others are spending their Money the Way they like!

0 Bit Quantum Computers AKA The Universe seems to allow very strange things!

Last edited by QBit on 02-Jun-2022 at 11:57 AM.
Last edited by QBit on 02-Jun-2022 at 11:55 AM.
Last edited by QBit on 02-Jun-2022 at 11:29 AM.
Last edited by QBit on 02-Jun-2022 at 11:15 AM.

@cdimauro

Quote:

However I don't understand why are still continuously replying me: just to satisfy your violated ago?

How long ago did you violate qbit? Why are you bragging about it? Do you have some weird kind of sick perversion?

_________________
Support AROS sponsor a developer.

"AROS is prolly illegal ~ Evert Carton" intentionally quoted out of context for dramatic effect

People are getting very bent out of shape over a very silly argument.

Jay Minor reflected that with hindsight packed pixels were more practical than planar. He also said that planar was faster for some operations. Whether or not he was correct about that last statement is subjective because it's possible to think of operations that are better suited to planar. For example, if I wanted to do do a logical operation like clearing or setting a single bit for all pixels on the display, I can just write fill the whole bitplane with the desired value. With a packed display, doing this requires read/write access unless the memory supports write masking.

For all of the most common simple rasterisation jobs it's difficult to conceive how planar is faster.

We'll never know how oddly packed sized pixels compare because they were never implemented. We can only hypothesise.

Last edited by Karlos on 02-Jun-2022 at 12:25 PM.

_________________
Doing stupid things for fun...

@Karlos


I’m not bent out of shape… I did eat myself out of shape. 🤣🤣🤣🤣

_________________
Support AROS sponsor a developer.

"AROS is prolly illegal ~ Evert Carton" intentionally quoted out of context for dramatic effect

@terminills

Didn't we all?!

_________________
Doing stupid things for fun...

The planar v packed argument can be settled easily at least from a software perspective.

All we need as a coding challenge!

_________________
Doing stupid things for fun...

@Karlos

Quote:

The planar v packed argument can be settled easily at least from a software perspective.

Or fool AGA (and its users) into thinking it can do chunky natively after all and forget about the heated debate altogether!
(Sorry for for the shameless plug, I just couldn't resist ).

Last edited by saimo on 02-Jun-2022 at 09:27 PM.

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

@terminills

Quote:

terminills wrote: @cdimauro Quote: However I don't understand why are still continuously replying me: just to satisfy your violated ago? How long ago did you violate qbit?

Ego, is should have been ago and not ago. It's a typo.
Quote:

Why are you bragging about it? Do you have some weird kind of sick perversion?

This is something that you should ask to your new friend, since he's spending his time attacking me.

I'm just defending myself. Or shouldn't I?

If he stops bashing me I'll not reply him anymore. Simple, isn't it?

@Karlos

Quote:

Karlos wrote: Jay Minor reflected that with hindsight packed pixels were more practical than planar. He also said that planar was faster for some operations. Whether or not he was correct about that last statement is subjective because it's possible to think of operations that are better suited to planar. For example, if I wanted to do do a logical operation like clearing or setting a single bit for all pixels on the display, I can just write fill the whole bitplane with the desired value. With a packed display, doing this requires read/write access unless the memory supports write masking. For all of the most common simple rasterisation jobs it's difficult to conceive how planar is faster.

Exactly.

Special and rare cases aren't enough to justify the use of planar graphics.
Quote:

We'll never know how oddly packed sized pixels compare because they were never implemented. We can only hypothesise.

I don't see differences between non-power-of-two and the power-of-two pixel sizes.

If you take the cookie-cut method to render BOBs in a framebuffer (which is the most complicated, but also the most common use case on Amigas), it requires shift & masking anyway, whatever is the pixel size.

@Karlos

Quote:

Karlos wrote: The planar v packed argument can be settled easily at least from a software perspective. All we need as a coding challenge!

Then cookie-cut is perfect for it.

@saimo

Quote:

saimo wrote: @Karlos Quote: The planar v packed argument can be settled easily at least from a software perspective. Or fool AGA (and its users) into thinking it can do chunky natively after all and forget about the heated debate altogether! (Sorry for for the shameless plug, I just couldn't resist ).

I saw it when you've opened the thread. Great achievement for an A1200.

@cdimauro

Quote:

I don't see differences between non-power-of-two and the power-of-two

Conceptually, no. Practically however, power of two is better suited to the everyday datatypes supported by hardware and software. You'll get a simplification in the implementation, even if the theoretical operation is the same for any value of N.

_________________
Doing stupid things for fun...

@cdimauro

Quote:

cdimauro wrote: All of this super-complications for just setting a pixel. And you're still light years behind packed...

Enough of the 'super' hyperbole, let's see some real numbers.

Quote:

Now imagine the above common scenarios that I've reported, and think about implementing them with bitplanes.

This discussion is supposed to be about porting OS 4 to x86. Seems to have strayed a bit off topic - not that I'm complaining because the original topic was very boring.

Quote:

On Amigas common cases were/are "cookie-cut" (rendering BOBs), filling AKA restoring the background (which was made dirty by rendering a BOB, for example), moving rectangular regions AKA windows, filling rectangular regions with a color and/or pattern, drawing lines with a color/pattern, etc.

Someone mentioned a 'coding challenge'. Anybody want to submit their planar and/or packed code for the above 'common' scenarios?

@Karlos

Quote:

Karlos wrote: @cdimauro Quote: I don't see differences between non-power-of-two and the power-of-two  Conceptually, no. Practically however, power of two is better suited to the everyday datatypes supported by hardware and software. You'll get a simplification in the implementation, even if the theoretical operation is the same for any value of N.

The only case when the implementation is simpler (it doesn't require shifs & masking) is when both the source (BOB) and target (framebuffer) graphic has a pixel size of 8, 16, or 32 bit. For obvious reasons.

However it wastes memory bandwidth if the pixel size is less than the data bus size. In this case shifts & masks are still required.

Anyway, you can check yourself the above with a pixel size of 2 or 4 bits, and you can see that there's no difference with odd pixel sizes when you've to do an operation like cookie-cut.

@bhabbott

Quote:

bhabbott wrote: @cdimauro Quote: cdimauro wrote: All of this super-complications for just setting a pixel. And you're still light years behind packed... Enough of the 'super' hyperbole, let's see some real numbers.

np: this is exactly the goal of the article that I'll write.
Quote:

Quote: Now imagine the above common scenarios that I've reported, and think about implementing them with bitplanes. This discussion is supposed to be about porting OS 4 to x86. Seems to have strayed a bit off topic - not that I'm complaining because the original topic was very boring.

It's interesting that you complaint about off-topic only on this thread, when there were many others where it happened the same (and even worse).

Are you invoking censorship for an embarrassing (for you) argument, or do you prefer to continue on a proper thread?
Quote:

Quote: On Amigas common cases were/are "cookie-cut" (rendering BOBs), filling AKA restoring the background (which was made dirty by rendering a BOB, for example), moving rectangular regions AKA windows, filling rectangular regions with a color and/or pattern, drawing lines with a color/pattern, etc. Someone mentioned a 'coding challenge'. Anybody want to submit their planar and/or packed code for the above 'common' scenarios?

It'd nice to see it, if you like to see code for this.

I prefer to focus on my article, because I want to give a mathematical prove for the controversy, which is more solid and doesn't require concrete implementations (which I could do, anyway: I'm still a coder).

Last edited by cdimauro on 04-Jun-2022 at 06:12 AM.

@bhabbott

Quote:

This discussion is supposed to be about porting OS 4 to x86. Seems to have strayed a bit off topic - not that I'm complaining because the original topic was very boring

That can be traced to a side discussion regarding the relative strength and weaknesses of the approaches taken by Amiga and PC. An inevitable consequence of talking about x86, it seems.

@cdimauro
Quote:

Anyway, you can check yourself the above with a pixel size of 2 or 4 bits, and you can see that there's no difference with odd pixel sizes...

Sure, except that I don't need to deal with the particular case that a given pixel's bits span the boundary of whatever word size I am using. This is what I mean about a simplification of the implementation.

Last edited by Karlos on 04-Jun-2022 at 09:51 AM.

_________________
Doing stupid things for fun...

@Karlos

Quote:

Karlos wrote: @cdimauro Quote: Anyway, you can check yourself the above with a pixel size of 2 or 4 bits, and you can see that there's no difference with odd pixel sizes... Sure, except that I don't need to deal with the particular case that a given pixel's bits span the boundary of whatever word size I am using. This is what I mean about a simplification of the implementation.

OK, got it. It doesn't happen often on the above use case, because scrolling graphics implies working with not aligned data.

Maybe it matters more on a software implementation. Just an idea.

@agami

Quote:

I love this simple and succinct statement.

Thanks. No point complicating it any further. It it what it is.

@bhabbott

Quote:

bhabbott wrote: @cdimauro Quote: cdimauro wrote: All of this super-complications for just setting a pixel. And you're still light years behind packed... Enough of the 'super' hyperbole, let's see some real numbers. ... Someone mentioned a 'coding challenge'. Anybody want to submit their planar and/or packed code for the above 'common' scenarios?

Let battle commence!

_________________
Doing stupid things for fun...

@Karlos

Quote:

I think you mean 6-bit in your second example. However, why would you pack it like this and not this?

Sorry yes I meant 6 bits and can't blame my phone this time.

Quote:

I think you mean 6-bit in your second example. However, why would you pack it like this and not this?

For my earlier reasons that it become impractical. It's harder to manage in software and would complicate hardware designs.

Quote:

Why does it matter if an individual pixel spans a byte boundary? That's software engineer thinking and ignores that hardware can do pretty much anything it's circuitry is configured for.

It's odd. Computers aren't usually designed for such odd combinations. Digital computers as logic devices work best in powers of two. Bitplanes being the odd one out. The ability to pack odd amounts in would not outweigh optimising the hardware to provide reasonable limits. If 3 bpp is wanted might as well round up to 4 bpp and do better.

Quote:

The above represents the only three byte permutations you need to consider for an 8 colour scheme, so you can even devise lookup based methods of isolating a pixel if you don't have fast barrel shifters at your disposal.

To put this in more perspective we are discussing 1980's era computers. And we also have to take into consideration the limits of CPU power. Therefore, it would have been less practical at the time, for something more obscure than it would be useful.

Quote:

Now I know what you're thinking, but it's 3 byte alignment per 8 pixels and I want a 32 bit bus. Well, all you need to do there is recognise 3 * 4 is 12 and increase the final screen width alignment requirements accordingly.

Actually, what I was really thinking is single pixel access, a main objection to planar. I see no point in supporting odd bpp if it's almost as complicated as managing planar bitmap images. Even 4 bit isn't a free lunch since nibbles have to be managed.

But to demonstrate my point. Calculating a 4 bit packed screen offset:
B = bits, W = screen byte width.
(Y*W)+((X*B)/8)
=
(Y*W)+(X/2)

Then inserting a nibble in place.

@cdimauro

Quote:

However I don't see any chance for OS4, because it was bounded to 31-bit, and there was no sign at all of Hyperion to move ahead of it. And due to the current situation, I think that a 64-bit OS4 is just a dream for its customers: I dream that cannot be realized...

Even in years past the kernel developers were annoyed at limitations like 32-bit tag lists where they needed to circumvent the limit to support 64 bit types. And other obstacles. I got the impression they would be happy to drop 68K support it it meant they could move it forward without hold backs.

Quote:

I think that you haven't got the point. The point is that bitplanes were almost always inferior compared to packed graphics, so there was no "potential" on having bitplanes AND packed graphics together. As I've said, it was just an useless complications (unless you like complications ).

That's because you've narrowed the bitplanes to just bits. By themselves they are independent bitmaps. But expand them to be packed planes and then you have multiple layers.

Quote:

You didn't got this point as well. The idea was about to have The Amiga (so, the original machines) with packed graphics (like I've shown) instead of bitplanes. So, designed from the beginning WITHOUT bitplanes.

Do you know what a main objection to the AmigaOne was? It didn't have planar graphics to support those Amiga games.

And you know what they did with the Vampire? Yews they spent work implementing planar graphics in a FPGA!

Not that gamers really care about bitplanes. But the Amiga used them. So that's what they want.

Quote:

But there are AHI players, at least.

There are, but what AHI players support OMSS multi track modules or PC formats, using AHI to mix? Most AHI players, at least ones playing modules over AHI like OS4 players, don't even use AHI features and softmix stuff themselves. Going above 4x8 bit tracked modules is obscure on Amiga.

Quote:

That's wrong: you're bounded to the same idea since the beginning. It seems that you're not able to conceive nothing else than that pixel formats should be aligned to powers of 2.

As I've said to Karlos it isn't practical otherwise. It's harder to program solo pixels. And the extra logic required in hardware to manage such a dynamic layout is not worth the result.

Quote:

You should exit from this loop and think out of your order: pixels can be packed WITHOUT respecting the power-of-2 alignment.

What hardware supports such an obscure arrangement?

Quote:

Only after that you can finally understand why packed graphics was/is almost always better than bitplanes. And why Jay Miner's decision was plainly wrong.Only after that you can finally understand why packed graphics was/is almost always better than bitplanes. And why Jay Miner's decision was plainly wrong.

I was just talking about packed format in this case.

But for odd amounts might as well use bitplanes, Since 3 bpp is odd. And easy enough for doing block images.