ZORRAM

_________________
I HAVE ABS OF STEEL
--
CAN YOU SEE ME? CAN YOU HEAR ME? OK FOR WORK

@Hypex

Quote:

What hardware supports such an obscure arrangement?

None that I know of. Nevertheless, for the purposes of nerdsniping, I've just invented it. It has a 32-bit wide bus and requires bitmaps are aligned such that entire rows are a whole number of 32-bit words. Individual pixels on a row may span word boundaries.

_________________
Doing stupid things for fun...

@MEGA_RJ_MICAL

Quote:

ZORRAM

How do you stop it chafing your Farmer Giles?

@Bosanac

Actually, he bumped the tread, so I can read Hypex comments.

Last edited by NutsAboutAmiga on 05-Jun-2022 at 07:14 PM.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

@NutsAboutAmiga

Is that something he charges a subscription for or is it a free service?

Last edited by Karlos on 05-Jun-2022 at 07:40 PM.

_________________
Doing stupid things for fun...

@Hypex

Quote:

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.

These things are only problematic for software, not hardware circuitry. You can rearrange bit lanes however you want in a circuit. For example, if you want to expand nybbles to two bytes, there's literally no rotating or shifting to do, you just demultiplex.

_________________
Doing stupid things for fun...

@cdimauro

Quote:

And here you're wrong: nobody used the packed graphics as I've described it. So, yes: it would have been particular.

What packed tightly? Your argument is it would have stood out because any bpp width could be used? Is there evidence Jay would have done this if he implemented "pixel graphics" as he calls it?

Quote:

The CPU MIGHT be faster than the Blitter, but only on the Amiga 3000, 1200, and 4000 due to the 32-bit access to the chip-ram.

And a faster clock speed for sure. A faster CPU is always alleged to be faster at blitting. But as stated lacks details as to what that exactly means.

Quote:

See above and Karlos' comment: you continue to don't understand how packed graphic could be efficiently used even in this case.

I understand fine. I just don't see it making any practical sense in a real life implementation.

Quote:

You can't imagine it because you continue to be stuck with your idea of bitplanes and packed graphics.

I can't imagine it because I see no sense in packed hardware splitting off odd and even bits in pixel data and displaying them as different offsets. When it could just overlay two packed fields with a simple field offsets. It would be an obscure feature that an Amiga does because of the bitplane setup.

I'm starting to think you've become some kind of anti bitplane bigot hating on those planes at every turn.



Quote:

You don't understand that a dual playfield mode using packed graphic would have been EXACTLY the same in terms of hardware setups (Amiga registers included) with ONLY ONE EXCEPTION:

And what if the hardware only had one field?

Quote:

Did you finally got it, or do you need some other explanation?

You need some other explanation. I said single field. How would packed hardware split even and odd bits and display them at different scroll offsets in hardware using only one framebuffer?

Or is your point that packed with two fields could simulate the single field Amiga scroll split trick?

Not saying it's a great trick, a cheap trick, that doesn't need dual playfield mode. Technically it would make use of the dual features even if not using the mode. The RKM warns about it but doesn't say why.

Quote:

You still need the even and odd separation, because you have two playfields, and both require their modulo and scrolling.

Even and odd separation of packed pixel data?

Quote:

No, they simply were wrong (again!). I really don't understand how it was possible to use the Blitter for writing single pixels: it was like shooting to a fly with a gun...

It wouldn't be very efficient including register setup. The only real use case I can see is drawing lines. The blitter and biplanes for that matter are really only suitable for working with blocks of pixels and optimising palette and images to use as least planes as possible.

Quote:

OK. I was talking about CGA, which had packed graphics.

From 1984?

Quote:

Depends on the Blitter operation to be performed: just copying blocks of data can be done in one shot with all bitplanes.

Limited use cases then.

Quote:

We had few for the Amiga, because those kind of games are better / more efficient on packed graphics.

We had a few in the beginning. Obviously using the blitter to fill flat faced polygons. And using a texture for cartoon 3d effects. That's as close as the Amiga got to 3d hardware. Adding warped blitting would have helped or hardware scaling. But the idea eventually made it to 3d hardware.

By the description VirtualGP looks to be one of the few real 3d games on the Amiga actually designed for the hardware. Making use of the 68020 bitfield features. And knowing the plane setup.

Unfortunately Doom games took over which are not suited for the hardware and hardly used the hardware for it's intended purpose. They hacked it on with chunky to planar routines. The copper used to simulate super low res chunky. Or the blitter used to convert data to planar.

@Hypex

I don't understand how planar or "bitpacked" as I am now calling it makes a difference for dual playfield. Instead of assigning a set of N bitplanes to each playfield, you just have a single N-bpp bitpacked layer for each playfield.

_________________
Doing stupid things for fun...

@Hypex

Quote:

Hypex wrote: @Karlos 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.

Only a Blitter is a little bit more complicated, but the display logic implementation is much simpler than compared to using planar graphics.

However this applies to ANY packed pixel-size: power and non-power of 2.
Quote:

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.

It's odd only because you (maybe nobody before) are not used to think about it.

You don't need any padding and digital computers don't need pixel size in power of two to work the best with.

Take a display with 2 bits / pixel, and think about how a display controller fetches and display the graphic when you're hardware scrolling it, and you'll see there's no difference doing the same with 3, 4, 5, 6, 7, etc. bits / pixel.
Quote:

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.

It's the exact opposite: it's MORE practical for a CPU to use such packed graphics, instead of bitplanes.

You already saw some examples in this thread, and more could come on the specific one which Karlos opened.
Quote:

Hypex wrote: @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.

Nothing changes if you drop the 68K support, because you've exactly the same problem with 32-bit PowerPCs (because OS4 is linked to a 32-bit system)
Quote:

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.

It doesn't matter: layers are completely orthogonal to biplanes and packed graphics. Don't confuse the two different concepts.
Quote:

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.

Does it matter to this part of the discussion? Absolutely no. The past is the past, as I've said, and people complaining about lack of planar graphics is because they are just users (or used to it).
Quote:

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.

This looks like an implementation issue rather than an AHI problem-
Quote:

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.

As I've said, there's NO difference with power-of-two pixel sizes.

What you think is very different from the reality.
Quote:

And the extra logic required in hardware to manage such a dynamic layout is not worth the result.

See above: there's an extra complexity with the Blitter. But the rest is much easier (and efficient).
Quote:

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?

Irrelevant: the existence of not of a concrete implementation means absolutely nothing of the goodness or not of packed graphics (of any pixel size).

Anway, I've never heard/read about "odd" pixel sizes. But I don't know if I was (because it's from very long time) the only one stating / supporting it.
Quote:

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.

And for dual-playfields graphic on OCS/ECS...
Quote:

Hypex wrote: @cdimauro Quote: And here you're wrong: nobody used the packed graphics as I've described it. So, yes: it would have been particular. What packed tightly? Your argument is it would have stood out because any bpp width could be used?

Yes.
Quote:

Is there evidence Jay would have done this if he implemented "pixel graphics" as he calls it?

No, but this, AGAIN, isn't the point for this discussion.
Quote:

Quote: The CPU MIGHT be faster than the Blitter, but only on the Amiga 3000, 1200, and 4000 due to the 32-bit access to the chip-ram. And a faster clock speed for sure. A faster CPU is always alleged to be faster at blitting. But as stated lacks details as to what that exactly means.

A fast CPU might not be fast enough to fully emulate what the Blitter is doing. Again, take a look at the cookie-cut method / algorithm.
Quote:

Quote: See above and Karlos' comment: you continue to don't understand how packed graphic could be efficiently used even in this case. I understand fine. I just don't see it making any practical sense in a real life implementation.

This shows that you don't understand packed graphic works. In reality AKA in a real implementation if someone implements it.
Quote:

Quote: You can't imagine it because you continue to be stuck with your idea of bitplanes and packed graphics. I can't imagine it because I see no sense in packed hardware splitting off odd and even bits in pixel data and displaying them as different offsets. When it could just overlay two packed fields with a simple field offsets. It would be an obscure feature that an Amiga does because of the bitplane setup.

Same as above: you cannot imagine. So, it's YOUR limit.

And if continue to see no sign of understand, after all this time and all explanations, than there's no point on continuing to argue about it.

My article is needed...
Quote:

I'm starting to think you've become some kind of anti bitplane bigot hating on those planes at every turn.

This is an Ad Hominem + Straw man attack: pretty common logical fallacies that you combined in one sentence.

You clearly have no arguments to sustain this discussion. Better to stop it? As you said above, you can't imagine packed graphics like I've described...
Quote:

Quote: You don't understand that a dual playfield mode using packed graphic would have been EXACTLY the same in terms of hardware setups (Amiga registers included) with ONLY ONE EXCEPTION: And what if the hardware only had one field?

Then it's EXACTLY like Amiga having a single playfield.
Quote:

Quote: Did you finally got it, or do you need some other explanation? You need some other explanation. I said single field. How would packed hardware split even and odd bits and display them at different scroll offsets in hardware using only one framebuffer? Or is your point that packed with two fields could simulate the single field Amiga scroll split trick? Not saying it's a great trick, a cheap trick, that doesn't need dual playfield mode. Technically it would make use of the dual features even if not using the mode. The RKM warns about it but doesn't say why.

The solution is very simple: you have TWO framebuffers for implementing a dual playfield in packed graphics.

And I've already told you how it could be implemented mimicking the Amiga hardware: the first bitplane pointer points to the first playfield AKA framebuffer, and the second bitplane pointers points to the second one.
Quote:

Quote: You still need the even and odd separation, because you have two playfields, and both require their modulo and scrolling. Even and odd separation of packed pixel data?

No! The first pointer has only the graphic of the first playfield. And the second pointer the graphic from the second playfield.

I don't know how can I tell you that the hardware setup is EXACTLY like the Amiga one, but with the only exception that the first bitplane pointer points to the (packed) graphic of the first playfield, and the second pointer to the one of the second playfield.

The rest (hardware registers) is EXACTLY the the same.

I'll not repeat it again, because it's getting boring + surreal...
Quote:

Quote: OK. I was talking about CGA, which had packed graphics. From 1984?

No, CGA was introduced on 1981.

EGA on 1984 (and it had planar graphics. Plus everything from CGA, of course).
Quote:

Quote: Depends on the Blitter operation to be performed: just copying blocks of data can be done in one shot with all bitplanes. Limited use cases then.

Yes. And you've to thank it anyway, because it helped to improve the performances.

BTW, if you want to continue the packed vs planar graphics discussion, then I suggest to join the new thread opened by Karlos.

And maybe WAIT a little bit, when some examples are shown, BEFORE replying to this message. Because maybe you can (finally!) understand something about the querelle.

@bhabbott

Quote:

The native Amiga chipset could easily have been enhanced to do packed modes with relatively simple circuitry. The only reason it wasn't done was lack of demand - bitplanes worked well enough and the application for packed pixels was limited. However there were several addons that took pixel data from multiple bitplanes and converted them to a different format, such as DCTV and HAMe that connected to the RGB port, and cards that plugged into the flicker fixer slot to produce 24 bit color.

I would tend to disagree there was no demand. Certain games could have benefit from it. And anything needing single pixel access. Anyone who used a Workbench found out how dog slow it was. Even on the A1200 you were limited in colours because it made it too slow to use. A packed Productivity mode would have worked better than VGA timings in planar.

Quote:

With a small box plugged into the RGB port you could turn a 1 bitplane hires screen into a chunky screen with lower resolution and more colors. 640x256 in 2 colors could become 320x200 in 4 colors (2 bits per pixel) or 160x200 in 16 colors (4 bits per pixel). With ECS and AGA you have Super-Hires, which outputs 160 bytes per line. So a 1 bitplane 1280x256 screen could produce a packed pixel 640x256 screen in 4 colors, 320x256 in 16 colors, or 160 x 256 in 256 colors.

That looks like what the Grafitti could do. More useful if it was built in. But if it was common as a silver VGA box it would have been good.

Quote:

These screen modes are similar to those of many home computers that had packed pixels, such as IBM CGA, Amstrad CPC, BBC micro / Electron, Tandy Color Computer, Atari 400 etc., so they could be useful for emulation or porting programs from those platforms.

And other general speed up.

Quote:

Another easy addition is the much missed Text Mode. Turn those 8 pixels per byte into an 8 bit index into a character ROM, and serialize its output at the pixel clock frequency just like all those text displays did, counting lines to address each row of the text patterns. Color attributes could be interleaved with the characters with 80 characters per line in Super-Hires. This gives you the other type of packed pixels, character graphics.

Ha. Yes, the Amiga only had a simple bitmap, like the Mac. It left behind the remnant of the 80's, text modes. Though for simple text display faster. I read somewhere text modes could be simulated with a copper list programming the blitter. But it would task the hardware.

Quote:

Even more flexibility is possible if you snoop the data before it goes into Denise/Lisa. Sit on the ChipRAM bus via a custom chip or the trapdoor slot (A500/600), or even have a chunky frame buffer in ChipRAM. The buffer could be written to by the CPU or Blitter in chunky mode, and read out as bitplanes for display (goodbye c2p!).

If only someone did it, made it popular and it became standard.

@cdimauro

Quote:

It's the exact opposite: it's MORE practical for a CPU to use such packed graphics, instead of bitplanes.

So what? This point is discussing packed data management, not bitplanes. So I don't know why you brought bitplanes back.

Quote:

Nothing changes if you drop the 68K support, because you've exactly the same problem with 32-bit PowerPCs (because OS4 is linked to a 32-bit system)

It allows them to drop some legacy. But since OS4 native apps inherited that legacy also to some extent it can only go so far. The sort of thing that needs to be done sooner rather than later. I suggested they prepare the OS for mutil-core before even attempting it. I was asked how. I told them, in brief terms, to address the flaws such as direct list management and port access, where the whole global system is halted for a local operation. But, it is kinda late, even though the warning was there in 1999 to stop Forbid()'ing. However, it was a contradiction, as they warned to stop using Forbid but provided no system functions in their place. There are legitimate use cases and they are littered all over RKM examples.

Quote:

It doesn't matter: layers are completely orthogonal to biplanes and packed graphics. Don't confuse the two different concepts.

I'm not confusing them. I'm just saying a pixel mode could have been added that allowed to select pixel bits to spread on the Z plane (planar) or go across the X axis (packed ). Compared to an interleaved bitmap things like a modulo would be equal, say for a 320 pixel width screen, and the whole framebuffer could take up the same space and dimensions but be optimised for direct pixel data.

Quote:

As I've said, there's NO difference with power-of-two pixel sizes.

There's no difference between a pixel that fits into a byte and another that is split across bytes? Huh?

Quote:

What you think is very different from the reality.

You haven't cited any actual examples of tightly packed pixels in real chipsets. So your point is rather blunt here. Unless you can provide examples in reality and not what you think your claim is false.

Quote:

See above: there's an extra complexity with the Blitter. But the rest is much easier (and efficient).

Well, the blitter is programmed for on demand, but the display hardware would be more important as it needs to read each pixel in real-time as it displays.

Quote:

No, but this, AGAIN, isn't the point for this discussion.

I thought his discussion arose out of a potential packed pixel oriented Amiga instead? A hypothetical Amiga with pixel graphics. Given the difference, I think it would be quite relevant how Jay would have implemented this in the hardware, and the technicalities of it.

Quote:

Same as above: you cannot imagine. So, it's YOUR limit.

So what? When I suggested expanded pixel modes you refused to imagine it because it built on bitplanes.

Quote:

My article is needed...

Theory is nice. But what about practice? How about a modified UAE, FPGA or some other device that can implement these packed formats?

Quote:

This is an Ad Hominem + Straw man attack: pretty common logical fallacies that you combined in one sentence.

Actually, no, that would be the serious argument fallacy.

Serious argument fallacy: Some banter intended as humour was interpreted as a serious argument when no argument was even made.

Quote:

You clearly have no arguments to sustain this discussion. Better to stop it? As you said above, you can't imagine packed graphics like I've described...

I can imagine it fine. Whether it is practical in actual use is another story. I clearly have argued my points against the practicality of it as I see it, so dismissing them doesn't mean I have no arguments, and I have no need to reiterate them.

Quote:

I don't know how can I tell you that the hardware setup is EXACTLY like the Amiga one, but with the only exception that the first bitplane pointer points to the (packed) graphic of the first playfield, and the second pointer to the one of the second playfield.

Well, I am afraid you will need too because I still don't see how it could work exactly the same, since it is a bitplane quirk. In this case, the odd bits of packed pixels would need to be isolated and masked out, then merged with even bits of packed pixels. So there is splitting of bits into two fields, similar to how chunky to planar is converted. In order to duplicate a single field split scroll trick. Simply using a dual field packed mode wouldn't duplicate it because the pixel bits are split in the operation unless the palette can be modified to suit. But I don't know what this trick is called nor where any examples would be. I'm sure it's used in State of the art but without seeing the source I cannot be certain of that.

Quote:

No, CGA was introduced on 1981.

I was talking about EGA.

Quote:

EGA on 1984 (and it had planar graphics. Plus everything from CGA, of course).

Yes, that's why I said from 1984, in this thread of discussion when I stated in 1984 the PC had just gone planar.

Quote:

Yes. And you've to thank it anyway, because it helped to improve the performances.

I would think so, since optimisations should be made, to work around limitations of hardware.

Quote:

BTW, if you want to continue the packed vs planar graphics discussion, then I suggest to join the new thread opened by Karlos.

I've got some ideas to propose but I'd prefer to test them with code so I can share results and stuff,

Quote:

And maybe WAIT a little bit, when some examples are shown, BEFORE replying to this message. Because maybe you can (finally!) understand something about the querelle.

I wouldn't say it's that bad. I don't tend to wait. I do it when I have time which can be delayed.

@Hypex

Quote:

Hypex wrote: @cdimauro Quote: It's the exact opposite: it's MORE practical for a CPU to use such packed graphics, instead of bitplanes. So what? This point is discussing packed data management, not bitplanes. So I don't know why you brought bitplanes back.

I've remarked that packed graphic is anyway better than bitplanes, even on those problematics.
Quote:

Quote: Nothing changes if you drop the 68K support, because you've exactly the same problem with 32-bit PowerPCs (because OS4 is linked to a 32-bit system) It allows them to drop some legacy. But since OS4 native apps inherited that legacy also to some extent it can only go so far. The sort of thing that needs to be done sooner rather than later. I suggested they prepare the OS for mutil-core before even attempting it. I was asked how. I told them, in brief terms, to address the flaws such as direct list management and port access, where the whole global system is halted for a local operation. But, it is kinda late, even though the warning was there in 1999 to stop Forbid()'ing. However, it was a contradiction, as they warned to stop using Forbid but provided no system functions in their place. There are legitimate use cases and they are littered all over RKM examples.

Indeed. And changing something now to introduce SMP support will break compatibility with the existing apps, which is the actual and only value for OS4.

OS4 is at a dead end: it's stuck to its current implementation, and no big improvements are possible anymore.
Quote:

Quote: It doesn't matter: layers are completely orthogonal to biplanes and packed graphics. Don't confuse the two different concepts. I'm not confusing them. I'm just saying a pixel mode could have been added that allowed to select pixel bits to spread on the Z plane (planar) or go across the X axis (packed ). Compared to an interleaved bitmap things like a modulo would be equal, say for a 320 pixel width screen, and the whole framebuffer could take up the same space and dimensions but be optimised for direct pixel data.

You're further complicating the situation trying to use such hybrid bitplane / packed formats.
Quote:

Quote: As I've said, there's NO difference with power-of-two pixel sizes. There's no difference between a pixel that fits into a byte and another that is split across bytes? Huh?

Indeed. If you understand how the display controller and Blitter work with the regular bitplanes, and apply the same operations with packed graphics, you'll see that there's absolutely no difference whatever is the pixel size: you always need shift & masking when there are scrolling playfields to be displayed, or operations like the cookie-cut.
Quote:

Quote: What you think is very different from the reality. You haven't cited any actual examples of tightly packed pixels in real chipsets. So your point is rather blunt here. Unless you can provide examples in reality and not what you think your claim is false.

First you have to prove that a concrete implementation is absolutely needed in this case.

I think that math is enough to prove that packed graphic is almost always better than planar.

You don't need to touch a black hole to prove its existence...
Quote:

Quote: See above: there's an extra complexity with the Blitter. But the rest is much easier (and efficient). Well, the blitter is programmed for on demand, but the display hardware would be more important as it needs to read each pixel in real-time as it displays.

Correct. And if you understand how the display controller works when it has to render a scan line, pixel by pixel, then you might finally get why its implementation would have been MUCH easier with packed graphics (sprites included).
Quote:

Quote: No, but this, AGAIN, isn't the point for this discussion. I thought his discussion arose out of a potential packed pixel oriented Amiga instead? A hypothetical Amiga with pixel graphics. Given the difference, I think it would be quite relevant how Jay would have implemented this in the hardware, and the technicalities of it.

We don't know how Jay could have implemented it. Maybe the same way that I've thought about it (because to me it looks logical and effective). But not 100% sure.
Quote:

Quote: Same as above: you cannot imagine. So, it's YOUR limit. So what? When I suggested expanded pixel modes you refused to imagine it because it built on bitplanes.

I've not refused it. I've just said that supporting bitplanes AND placked graphics is an unusefull complication.
Quote:

Quote: My article is needed... Theory is nice. But what about practice? How about a modified UAE, FPGA or some other device that can implement these packed formats?

See above: NOT needed. Unless you prove that an implementation is absolutely necessary.

I think that math is and should be enough.
Quote:

Quote: This is an Ad Hominem + Straw man attack: pretty common logical fallacies that you combined in one sentence. Actually, no, that would be the serious argument fallacy. Serious argument fallacy: Some banter intended as humour was interpreted as a serious argument when no argument was even made.

That was a tease, my friend: not humour...
Quote:

Quote: You clearly have no arguments to sustain this discussion. Better to stop it? As you said above, you can't imagine packed graphics like I've described... I can imagine it fine.

Well, you said exactly the opposite before...
Quote:

Whether it is practical in actual use is another story. I clearly have argued my points against the practicality of it as I see it, so dismissing them doesn't mean I have no arguments, and I have no need to reiterate them.

Everything was already rebutted. And examples were also given which clearly shown that bitplanes have no points on the common graphic primitives.
Quote:

Quote: I don't know how can I tell you that the hardware setup is EXACTLY like the Amiga one, but with the only exception that the first bitplane pointer points to the (packed) graphic of the first playfield, and the second pointer to the one of the second playfield. Well, I am afraid you will need too because I still don't see how it could work exactly the same, since it is a bitplane quirk.

You don't see it because you're not able to distinguish the display controller SETUP (I've highlighted it) for one or two playfields to be shown (which is absolutely the same, besides the differences with the one or two pointers to the graphic) with the RUNTIME operation of such controller.

I think that you've no clue on how the Amiga hardware was programmed AND how effectively it worked color clock by color clock. This could explain your problems.
Quote:

Quote: In this case, the odd bits of packed pixels would need to be isolated and masked out, then merged with even bits of packed pixels. So there is splitting of bits into two fields, similar to how chunky to planar is converted. In order to duplicate a single field split scroll trick. Simply using a dual field packed mode wouldn't duplicate it because the pixel bits are split in the operation unless the palette can be modified to suit. But I don't know what this trick is called nor where any examples would be. I'm sure it's used in State of the art but without seeing the source I cannot be certain of that. See above. Because there's absolutely no trick needed: it's "just" a matter of understanding how the display controller worked. Quote: [quote]BTW, if you want to continue the packed vs planar graphics discussion, then I suggest to join the new thread opened by Karlos. I've got some ideas to propose but I'd prefer to test them with code so I can share results and stuff,

np: there's the new thread for it.
Quote:

Quote: And maybe WAIT a little bit, when some examples are shown, BEFORE replying to this message. Because maybe you can (finally!) understand something about the querelle. I wouldn't say it's that bad. I don't tend to wait. I do it when I have time which can be delayed.

OK. As I've said before, please use the new thread for it: it's the right place where the discussion can continue.

@Hypex

Quote:

Hypex wrote: @bhabbott Quote: The native Amiga chipset could easily have been enhanced to do packed modes with relatively simple circuitry. The only reason it wasn't done was lack of demand - bitplanes worked well enough and the application for packed pixels was limited. However there were several addons that took pixel data from multiple bitplanes and converted them to a different format, such as DCTV and HAMe that connected to the RGB port, and cards that plugged into the flicker fixer slot to produce 24 bit color. I would tend to disagree there was no demand. Certain games could have benefit from it. And anything needing single pixel access.

'Certain' games perhaps, but for most the problem was moving large objects around quickly - and nobody was thinking about doing that 1 pixel at a time.

An ISA CGA, EGA or VGA card can easily be interfaced to the A500, but the idea never caught on - perhaps because there were plenty of awesome games for the A500 that didn't need any extra hardware. Games like Doom that could have benefited from it also needed a much faster CPU, a hard drive, and lots more RAM.

Quote:

Anyone who used a Workbench found out how dog slow it was.

This has nothing to do with using planar graphics.

Quote:

Even on the A1200 you were limited in colours because it made it too slow to use. A packed Productivity mode would have worked better than VGA timings in planar.

Ever tried using a 16MHz 386-SX with 256 colors in Windows? Dog slow doesn't begin to describe it.

I use 8 colors on my A1200 because it's plenty enough and saves precious ChipRAM. Anything that needs more colors opens its own screen where it has full control over the palette and doesn't have to compete with other apps for screen space.

Quote:

Ha. Yes, the Amiga only had a simple bitmap, like the Mac. It left behind the remnant of the 80's, text modes. Though for simple text display faster. I read somewhere text modes could be simulated with a copper list programming the blitter. But it would task the hardware.

There is a demo of text mode using the copper that works only in QL DOS. I never got it to work because setting up the QL emulation was too much hassle.

On an AGA machine text display is fast enough anyway so it doesn't matter. If you are running an A500 in WB1.x then Fastfonts makes the rendering of 8 point text fonts much faster. It does this by using the CPU instead of the Blitter! When using the OS to print text most of the overhead is in the translation. CED displays text very fast on a 4 color screen using its own custom rendering code.

The Mac had a very nicely done monochrome GUI, but was let down by the tiny screen. The Amiga could also have used monochrome like the Mac and C64 (GEOS) but I'm glad they didn't. Those 2 extra colors (plus another 3 for the mouse pointer) made it look more exciting without taxing the machine too much.

Quote:

Quote: Even more flexibility is possible if you snoop the data before it goes into Denise/Lisa. Sit on the ChipRAM bus via a custom chip or the trapdoor slot (A500/600), or even have a chunky frame buffer in ChipRAM. The buffer could be written to by the CPU or Blitter in chunky mode, and read out as bitplanes for display (goodbye c2p!). If only someone did it, made it popular and it became standard.

It could have, but didn't because most users were happy enough with what they had - which mostly meant a machine that could run all those awesome pirated games. But few were willing to spend more than the price of a blank disk, (or maybe a trapdoor RAM expansion) to do it.

Imagine if Doom was released for the Amiga in 1993, complete with a video port dongle that did 256 chunky colors. Amiga fans would buy it in droves - not. The only reason Doom was so popular in the first place was that it was shareware, so you could try it out for free and then upgrade your machine if you wanted a better experience. Having to buy the dongle first was a non-starter for miserly Amiga fans. Most couldn't run it anyway. Hell, many PC users couldn't run Doom when it first came out, because the average PC back then didn't have enough memory. It also needed 24MB of hard drive space to install the full game.

But this is all off topic. We are supposed to be talking about porting AmigaOS 4 to x86. Modern PC hardware is so powerful that we have nothing to worry about when it comes to supporting legacy Amiga programs that work with bitplanes. Adding support in the OS for chunky bitmaps etc. shouldn't be hard.

Last edited by bhabbott on 14-Jun-2022 at 06:43 AM.
Last edited by bhabbott on 14-Jun-2022 at 06:41 AM.

@Hypex

Quote:

Hypex wrote: It allows them to drop some legacy. But since OS4 native apps inherited that legacy also to some extent it can only go so far. The sort of thing that needs to be done sooner rather than later. I suggested they prepare the OS for mutil-core before even attempting it. I was asked how. I told them, in brief terms, to address the flaws such as direct list management and port access, where the whole global system is halted for a local operation. But, it is kinda late, even though the warning was there in 1999 to stop Forbid()'ing. However, it was a contradiction, as they warned to stop using Forbid but provided no system functions in their place. There are legitimate use cases and they are littered all over RKM examples.

The answer is simple. Provide a means for legacy code to think it's doing it, but in reality is being sandboxed.

I have never been a fan of forbid/permit, and only use them where absolutely necessary. Similarly I avoid playing with system structures. But all this is pretty irrelevant when the code needs to be recompiled anyway. While you are doing that you will of course make the few changes necessary to suit the new platform.

I am not an OS 4 user so I have to ask all of you - what exactly would you want to preserve when porting it to x86, that would be a problem? Seem to me the only real impediment is that the source code is proprietary.

@bhabbott

Quote:

bhabbott wrote: @Hypex Quote: Hypex wrote: Anyone who used a Workbench found out how dog slow it was. This has nothing to do with using planar graphics.

Planar graphics was ALSO responsible for that. Do you know how graphic composition was made? How windows / layers were moved / rendered?

You need to use the Blitter, with the infamous cookie-cut method in some cases, which required to load the mask each time, again, for EACH bitplane.
Quote:

Quote: Even on the A1200 you were limited in colours because it made it too slow to use. A packed Productivity mode would have worked better than VGA timings in planar. Ever tried using a 16MHz 386-SX with 256 colors in Windows? Dog slow doesn't begin to describe it.

This processor was introduced on 1988, and it was super economic at the time.

On 1992 there was the 33Mhz version available, which was the super economic version of the time.

Regarding Windows, it didn't worked at 320x200 with 256 colors: 640x480 was the bare minimum, and WITHOUT interlace.

Anyway, it wasn't that bad. The 25Mhz version with Wing Commander and Windows 3.11: https://www.youtube.com/watch?v=TXdfDef0BUw
Quote:

I use 8 colors on my A1200 because it's plenty enough and saves precious ChipRAM. Anything that needs more colors opens its own screen where it has full control over the palette and doesn't have to compete with other apps for screen space.

8 (EIGHT) colors. In 640x200 I assume. On 1992. Great...
Quote:

Quote: Ha. Yes, the Amiga only had a simple bitmap, like the Mac. It left behind the remnant of the 80's, text modes. Though for simple text display faster. I read somewhere text modes could be simulated with a copper list programming the blitter. But it would task the hardware. There is a demo of text mode using the copper that works only in QL DOS. I never got it to work because setting up the QL emulation was too much hassle. On an AGA machine text display is fast enough anyway so it doesn't matter. If you are running an A500 in WB1.x then Fastfonts makes the rendering of 8 point text fonts much faster. It does this by using the CPU instead of the Blitter! When using the OS to print text most of the overhead is in the translation. CED displays text very fast on a 4 color screen using its own custom rendering code. The Mac had a very nicely done monochrome GUI, but was let down by the tiny screen. The Amiga could also have used monochrome like the Mac and C64 (GEOS) but I'm glad they didn't. Those 2 extra colors (plus another 3 for the mouse pointer) made it look more exciting without taxing the machine too much.

The Mac had higher resolution without interlace. On 1984...

@cdimauro

Quote:

cdimauro wrote: Planar graphics was ALSO responsible for that... You need to use the Blitter, with the infamous cookie-cut method in some cases, which required to load the mask each time, again, for EACH bitplane.

This is total nonsense, but irrelevant to the subject we are supposed to be discussing. Please stop with the derail.

Quote:

This processor was introduced on 1988, and it was super economic at the time.

Your PC fandom is getting tiresome, but again it's irrelevant. We are talking about porting OS 4 to modern PCs, not to under-powered 'super-economic' retro PCs from the 90's.

Quote:

Regarding Windows, it didn't worked at 320x200 with 256 colors: 640x480 was the bare minimum, and WITHOUT interlace.

Er, wot?

http://ftp.lip6.fr/pub/pc/garbo/windows/drivers/wdl.txt Quote:

*MCGA Driver MMDISP.EXE 4/6/92 VGA (320x200, 256 colors)

AGA Amigas do Workbench in 320x200 with 256 colors too, and WITHOUT interlace!

Quote:

Quote: I use 8 colors on my A1200 because it's plenty enough and saves precious ChipRAM. Anything that needs more colors opens its own screen where it has full control over the palette and doesn't have to compete with other apps for screen space. 8 (EIGHT) colors. In 640x200 I assume. On 1992. Great...

You assume wrong.

Quote:

The Mac had higher resolution without interlace. On 1984...

... in a non-standard scan rate on a tiny 9" built-in CRT with no external monitor option, a miserable non-upgradable 128k RAM, and a 400k disk that nothing else could read. The machine was almost useless.

Exactly how is this relevant to anything? What does it have to do with OS 4 on x86?

@bhabbott



All I will say about this topic is this. Hyperion officials have very plainly stated that they have no intention of porting OS4 to the PC or to
arm. Furthermore, Trevor Dickenson(who most likely would have to finance such a port) has said it was very unlikely that he would finance such a port.

Therefore any discussion about porting OS4 is moot in my opinion.

@bhabbott

Quote:

bhabbott wrote: @cdimauro Quote: cdimauro wrote: Planar graphics was ALSO responsible for that... You need to use the Blitter, with the infamous cookie-cut method in some cases, which required to load the mask each time, again, for EACH bitplane. This is total nonsense,

FOR YOU!
Quote:

but irrelevant to the subject we are supposed to be discussing.

I quote YOURSELF:

"This has nothing to do with using planar graphics."

So, YOU were off topic!
Quote:

Please stop with the derail.

First ask to YOURSELF next time.

BTW, the topic was already derailed long time ago. And other threads as well. But you only care about this one: guess why...
Quote:

Quote: This processor was introduced on 1988, and it was super economic at the time. Your PC fandom is getting tiresome, but again it's irrelevant.

No, it's simply a logic fallacy combo: Ad Hominem attack + the Red herring.
Quote:

We are talking about porting OS 4 to modern PCs, not to under-powered 'super-economic' retro PCs from the 90's.

I quote YOURSELF:

"Ever tried using a 16MHz 386-SX"

So, YOU were off topic!
Quote:

Quote: Regarding Windows, it didn't worked at 320x200 with 256 colors: 640x480 was the bare minimum, and WITHOUT interlace. Er, wot? http://ftp.lip6.fr/pub/pc/garbo/windows/drivers/wdl.txt Quote: *MCGA Driver MMDISP.EXE 4/6/92 VGA (320x200, 256 colors)

Take a better look on your link:
*CGA Driver CGA.EXE 4/6/92

It doesn't mean that Windows could use a CGA resolution. Drivers support CGA for applications (games, specifically).

Otherwise you could show me how to use the File Manager (see 4:50 on the video that I've posted) on a 320x200 display (which means... 40 columns!).
Quote:

AGA Amigas do Workbench in 320x200 with 256 colors too, and WITHOUT interlace!

Of course: it was a really good resolution to be used for productivity on '92...

Have you tried 640x480 with 256 colors without interlace on your Amiga 1200?
Quote:

Quote: 8 (EIGHT) colors. In 640x200 I assume. On 1992. Great... You assume wrong.

Then why don't you clarify?
Quote:

Quote: The Mac had higher resolution without interlace. On 1984... ... in a non-standard scan rate on a tiny 9" built-in CRT with no external monitor option, a miserable non-upgradable 128k RAM, and a 400k disk that nothing else could read. The machine was almost useless.

Again: FOR YOU! I was able to use it with good productivity.

Maybe the problem is that you never used this machine. But it's your problem. And you're spreading false statements!
Quote:

Exactly how is this relevant to anything?

I quote YOURSELF:

"The Mac had a very nicely done monochrome GUI, but was let down by the tiny screen."

So, YOU were off topic!
Quote:

What does it have to do with OS 4 on x86?

You've to ask to yourself, since YOU are the one which continuously went off-topic: see above!

It's quite clear that you do NOT like critics to Amigas, and you react this way: trying to change the discussion. A very common logical fallacy.

As I've already said several times, logic is lacking on the Amiga land...

@Neuf

Quote:

Neuf wrote: All I will say about this topic is this. Hyperion officials have very plainly stated that they have no intention of porting OS4 to the PC or to arm. Furthermore, Trevor Dickenson(who most likely would have to finance such a port) has said it was very unlikely that he would finance such a port. Therefore any discussion about porting OS4 is moot in my opinion.

Thanks for that. I can understand why they would think that way. OS 4 was designed for PPC, so it's of interest to owners of those systems. PC users not so much. We already have AROS which is fully open source, and porting (and maintaining) OS 4 to the PC would be lot of work that's of no benefit to PPC users.

In that light I guess there is little point continuing the discussion, except to feed the trolls....

@cdimauro

Quote:

cdimauro wrote: BTW, the topic was already derailed long time ago. And other threads as well. But you only care about this one: guess why...

I don't own a PPC card or Next Gen 'Amiga', so OS 4 itself is of little interest to me. That's why you won't see me posting in most threads here. However I am interested in Amiga stuff in general, including the idea of a 'modern' Amiga-like OS for x86.

In the usual wallowing negativity of Amiga 'fans', there has been some discussion about 'flaws' in Amiga OS that supposedly make this impossible. I was hoping that this time it might be different and we could have a technical discussion on how these 'flaws' could be addressed. However some people just want to pointlessly rant about how (in their opinion) the Amiga is and always was no good.

Quote:

Otherwise you could show me how to use the File Manager (see 4:50 on the video that I've posted) on a 320x200 display (which means... 40 columns!).

40 columns? Windows has variable width and proportional fonts. It doesn't use text mode!

Sure the MCGA 320x200 256 color driver was only meant for 'multimedia' (games etc.), but you didn't say anything about the desktop. The point is that Windows 3.x is not limited to any particular resolution, it just needs a driver for the screen mode you want. Did you know there was no official 8086 compatible driver for VGA? This is an issue for me because I have an Amstrad PC2086 (which has VGA on-board) complete with Windows 3.1 manuals, but can't even run it in the standard VGA resolution of 640x480 with 16 colors.

Quote:

Have you tried 640x480 with 256 colors without interlace on your Amiga 1200?

Yes. But I don't run that resolution on my current setup because my TV can't handle it on the composite input. And I don't need it, because the TV does an excellent job of displaying interlace WITHOUT flicker. IBrowse works well in 640x512. The only issue is that most websites are encrypted now, which makes large images very slow to load even with a 50MHz 030. Therefore I usually run IBrowse in 8 colors with images off for speed. This isn't a big deal for me because I use the Web on my A1200 to get information and download stuff, not for eye candy.

Quote:

Maybe the problem is that you never used this machine. But it's your problem. And you're spreading false statements!

Again you assume wrong. I had a 512k Mac back in the 90's, and it was a pain just getting the OS installed on the hard drive (luckily my Amiga was able to help there). I eventually dismantled it because it was too limited and frustrating to use. I had so many old computers back then that were worthless to me - wish I had kept them though because anything retro is worth heaps now!

As for false statements, perhaps you should read some of the press around the time of the Mac's launch.

Quote:

I quote YOURSELF: "The Mac had a very nicely done monochrome GUI, but was let down by the tiny screen." So, YOU were off topic!

Er, excuse me. I was responding to you dragging Macintosh into the conversation, apparently for the sole purpose of 'proving' that the Amiga was inferior to it. Of course in 1984 it was, since the Amiga didn't exist. In 1985 however...

Quote:

It's quite clear that you do NOT like critics to Amigas, and you react this way: trying to change the discussion. A very common logical fallacy.

In case you didn't notice, this website is called Amigaworld, and the thread title is about AmigaOS. So yeah, I don't like someone coming in here just to trash it. Do you do that on other forums too? "Oh the C64 / Amstrad CPC / ZX Spectrum is so crap it can't even do 640x480 in 256 colors WITHOUT interlace!".

You are not adding anything useful to the conversation, just derailing it with your anti-Amiga fandom. There's a word that describes a person who does that - troll.

Quote:

As I've already said several times, logic is lacking on the Amiga land...

You are right. So many butt-hurt ex Amiga fans complaining about it not fulfilling their fantasies. In Spanish, Amiga means 'girlfriend'. Which is oddly appropriate because some 'fans' seem to treat the Amiga like an ex that they broke up with after realizing she wasn't 'perfect', and now have to constantly trash to her friends at every opportunity. And just like in the social scene it gets tired quickly.

Last edited by bhabbott on 15-Jun-2022 at 04:19 PM.