ZORRAM

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

@Hypex

Quote:

Once you get used to it, you accept how things are, even though they are unacceptable.

I love this simple and succinct statement.

_________________
All the way, with 68k

@Hypex

Quote:

Hypex wrote: @cdimauro Quote: The problem with Windows is that Microsoft defined too many UI frameworks, and coders might be pissed-off because of this. Windows Phone was the worst example, here. For Windows internally it should have some consistency.

The fundamental Win32 widgets are the same and show the same if an applications set them in the same way. Which is the right thing to do, of course.
Quote:

Quote: So, no chance: you've the worse of the worlds... Once you get used to it, you accept how things are, even though they are unacceptable.

I accept the reality and the history. But this doesn't stop me to argue about the decisions made, if I recognize that they were bad.
Quote:

Quote: Well, you can have them, but then you've to say goodbye to all current 32-bit applications, since it (a 64-bit OS4) would be totally incompatible with them. A 64 bit OS would be a good start.

Well, it should be obvious.

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...
Quote:

Quote: Because it used a proper abstraction of data structures. Amiga o.s. was exactly the opposite, and that's why it's completely bounded to 31-bit address space. I imagine that running 32 bit user land apps under a 64 bit kernel would also need some MMU tricks that could also bog down process switching.

No, not needed for an o.s. with proper abstractions.

And no MMU trick can allow an Amiga/-like o.s. to run 32 and 64-bit applications at the same time, due to its bad design.
Quote:

Quote: No, there are no 64 bits on OS4. This was the false myth that its developers have spread around, to cheat their customers. It's quite common knowledge that won't change without a big announcement and proof so I see no point in marketing such terms as 64 bit.

The announcement was done only to impress OS4 customers. With a miserable lie, unfortunately...
Quote:

Quote: So, you can access up to 64GB of physical memory on a 32-bit system (by "bank swapping" some PMMU pages, on need). Bank swapping. Oh dear. Sounds like a jumped up bank switching. Though 64GB is rather huge. The next step after ExtMem.

ExtMem is using it, and it's the only thing possible with Amiga/-like o.ses. Nothing will and can change.
Quote:

Quote: There's no potential there, rather an unneeded complication. It had the potential to be expanded and simplified for the programmer. Compare with EGA bitmap format. And where they took it with VGA. All based on planes. And different organising of pixel data.

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 ).
Quote:

Quote: So, why do you need to support bitplanes when you've a superior format which can do almost always better? Only for this specific case? It doesn't deserve the effort (which means: you've to duplicate almost everything). It needs to be supported on Amiga as all Amiga have bitplanes but only a subset have packed with RTG hardware.

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.

Having bitplanes is just a consequence and historical fact that cannot be changed: they were developed with bitplanes. This is granted, and we can do nothing here. It was like it was done.

But in this part of the discussion the topic was about rejecting this decision that Jay Miner made, because it was a bad one.

I hope that it's clear now.
Quote:

Slightly off topic, but I was reading on the Apollo forums about Gunnar's dislike of AHI, because of the focus on software mixing. I didn't bother to join the forum only to be banned for pointing out his error.

Welcome to the club...
Quote:

But AHI doesn't solely rely only on software mixing, it's up to the driver to provide a hardware mixer. The Paula driver has hardware mixing modes as expected. So there is no reason why a Monica AHI driver couldn't be written to make use of it. (Or whatever it is called now.)

Correct.
Quote:

Of course trackers left AHI behind so maybe Gunnar is right. There's not exactly music software that makes of AHI.

But there are AHI players, at least.
Quote:

Hypex wrote: @Karlos Quote: That's not true, it just restricts the available widths that are possible. Let's say I decide I want to have RGB15 bits per pixel with no wasted bits. To pack those into bytes, I'd need a width that's a multiple of 8 pixels, each 8 pixels span being 15 consecutive bytes. That's above the 8 bits I'm talking about. Above that it's RGB and not CLUT so easily fits better. Quote: Or say I want an 8 colour screen. That's 3 bits per pixel. Packing those into bytes, I'd need a width that's a multiple of 8 pixels, each 8 pixel span being 3 consecutive bytes. Which it more to my point. But just to illustrate. This is the kind of format I'm thinking per byte. 3 bit - x321x311 x321x321 x321x321 7 bit - xx543210 xx543210 xx543210 In 3 bit above 1 bit is lost per byte, in 7 bits two bits are lost per byte. To pack it evenly in bytes.

You continue to miss the point, insisting to have always the packed graphic with "holes" when the bit size isn't matching a power of 2.

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.

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

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.

@Karlos

Quote:

Karlos wrote: @Hypex Quote: 3 bit - x321x311 x321x321 x321x321 7 bit - xx543210 xx543210 xx543210 In 3 bit above 1 bit is lost per byte, in 7 bits two bits are lost per byte. To pack it evenly in bytes I think you mean 6-bit in your second example. However, why would you pack it like this and not this? 3 bit - 32132132 13213213 21321321 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. 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. 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.

Exactly! I hope that HyperX gets it, finally.

@cdimauro

If contemporary tech is anything to go by, not having bit planes would mean very useless screen resolutions for productivity software. Or just monochrome as an alternative. I am glad that they landed on planar, which in the end gives user more freedom to configure display as is fit for his/her use case and monitor. Of course they could have added one 320x200 chunky mode for certain games, but really… who would have used it? Look at Atari Falcon…

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@cdimauro

Quote:

But the point is that it could have been something different, using packed graphic.

It could have. But it didn't happen. Nor did they expand on it in AGA with ideas like my extended pixel modes. So the Amiga remained as bitplaned and now it's history.

Quote:

I'm not talking about RTG cars here, but, as said before and above, to a packed graphic-based Amiga.

RTG cards were the only way to add packed modes to an Amiga. But that was five years after the A1000. And given Commodore did that instead of a new chipset looks like they drew the writing on the wall.

Quote:

It would have been famous for its packed graphic...

Being more common it wouldn't have stood out as anything particular.

Quote:

Karlos already replied, but let me add something: having packed without power of 2 would have had MUCH LESS gaps compared to bitplanes. So, much more efficient.

In theory, yes, but that's impractical on both hardware and software. In hardware that expects it to pack bit fields in different locations. It would need to keep track of it and mask it internally as reads the index for each colour. For the programmer they would be need mask off bit fields to write pixels in. That would overcomplicate it and it wouldn't be accessible like a linear framebuffer. Even two 4 bit values as nibbles per byte isn't the easiest to manage as the 1st pixel in the pair needs shifting left. So reserving a multiple of two size field to fit pixels up to a byte would be more practical.

Just to clarify what I mean. Say a 5 bpp screen. Where the pixels were packed end to end like:
43210432 10432104 32104321

More practical but with more gaps and enough bandwidth is needed:
00043210 00043210 00043210

Quote:

I think that you don't realize how wasteful it is.

I just think it's too late as no one can change it now.

Quote:

Guess what: it's EXACTLY what the Amiga's display controller did, and the Blitter in particular.

The blitter just needed to shove it all through the barrel shifter and mask off the edges. Which was fine for one bitplane. But inefficient for multiple pass on more.

I notice that there is a lot of talk about the CPU being faster then the blitter. Faster doing what? In real life it needs to shift the data along for other X/Y co-ordinates. That means the CPU then needs to rotate every word before it writes it in and mask off the edges. Sure it could be fast at that also but that's more complicated than a simple block image transfer with a MOVE.L loop.

Quote:

Why it should be different (and inefficient) for packed graphic? On the contrary, the display controller is much easier and WAAAAAAY more efficient. Again: math rulez..

I was thinking like in my 5 bit packed example above. That's why. When not packed in an even fashion.

Quote:

I don't know, but this isn't the point. The point is analyzing the facts and the data, and draw the proper conclusions.

Conclusions are fine but I like to know about different hardware was configured for the display.

Quote:

Do you mean with the dual-playfield? This, as I've said, it's the same if using the packed graphic for 2 playfields. Absolutely no difference here.

No I think what I mean is, when one playfield is set, but the scroll offsets are different. So it splits the odd and even planes.

I can't imagine this being practical with packed. It wouldn't make sense to hardware accelerate such an obscure operation. And using software to split odd and even bits then merge them back in at different offsets isn't the same when doing it manually. With more hardware layers it could be simulated. It was just cheap trick splitting even and odd planes.

Quote:

With packed graphic was the same, but easier and much more efficient.

I don't think packed would have needed any even and odd separation. Just two layers with scroll offsets. Simple.

Quote:

This is an artificial limit. AAA supported up to 10 bitplanes.

That's taking it too far.

Quote:

Well, Amiga engineers used the Blitter for that!

If they could use it to blit a pixel from a direct index split into different planes using one blit operation they knew something I didn't.

Quote:

Commodore... no comment.

LOL.

Quote:

Absolutely not: it was also packed.

I meant in EGA which used planes.

Quote:

Think about a screen with 4 (but can be any depth: it's exaclty the same) bitplanes and graphics to be moved: you CAN'T do it 16 pixels at the time! You need 4 blits to move 16 pixels.

If the planes are in separate blocks obviously. But what about an interleaved bitmap with all plane lines in a row, can it blit to all planes with one blit op?

Quote:

However, if you write down the operations needed and how many memory transfers are required, then packed graphic wins hands down. There's no comparison. And the wider are the fetches (AGA -> 64-bit!!!) the MUCH WORSE becomes the bitplanes solution.

Don't know who said it but over 20 years some Amiga programmer claimed that comparing planar with chunky that planar was best of all. And could do the same kind of 3d games. I didn't see much examples of these 3d games.

@Hypex

Again a 5 bit packed pixel is not a big problem for hardware designed for it. You have the situation that you need 5 consecutive bytes to encode 8 5-bit pixels, and in an analogous manner to the 3-bit example, there are only 5 permutations of the byte layout to worry about for software access. Now, if you want to have a 32-bit bus to access them rather than a byte bus, you again take this up in the allowed row widths.

The idea of packing with gaps into bytes is pointless, you'd be better off using all possible values and have 256 colours. It is definitely simpler to have power of 2 packing, e.g. 2,4,16,256 colour modes but it isn't rocket science to pack non power of two bits per pixel as has been shown. Hardware can still load spans of 32 bits, rotate them etc, and write mask them back into memory. The key difference is that you only have to do it once rather than once per plane.

Last edited by Karlos on 29-May-2022 at 05:02 PM.

_________________
Doing stupid things for fun...

@kolla

Quote:

kolla wrote: @cdimauro If contemporary tech is anything to go by, not having bit planes would mean very useless screen resolutions for productivity software. Or just monochrome as an alternative. I am glad that they landed on planar, which in the end gives user more freedom to configure display as is fit for his/her use case and monitor. Of course they could have added one 320x200 chunky mode for certain games, but really… who would have used it? Look at Atari Falcon…

You also didn't got the point, kolla. Planar/bitplane graphic was almost always inferior / less convenient compared to the packed graphic.

In fact, with packed graphic you have the SAME freedom to configure the display as you want/needed. There's absolutely no difference here, besides that... it's MUCH MORE efficient!

I really think that an article which better explains it is absolutely necessary, because it looks that amigans aren't able to understand something different from what they have learned about planar and packed graphics.

Maybe I stop here arguing about this topic, and I'll start writing it.

@Hypex

Quote:

Hypex wrote: @cdimauro Quote: But the point is that it could have been something different, using packed graphic. It could have. But it didn't happen. Nor did they expand on it in AGA with ideas like my extended pixel modes. So the Amiga remained as bitplaned and now it's history.

That's granted: it's history. It's how the things went. It's something that, of course, could not be changed.
Quote:

Quote: I'm not talking about RTG cars here, but, as said before and above, to a packed graphic-based Amiga. RTG cards were the only way to add packed modes to an Amiga. But that was five years after the A1000. And given Commodore did that instead of a new chipset looks like they drew the writing on the wall.

True, but I was talking of something different.
Quote:

Quote: It would have been famous for its packed graphic... Being more common it wouldn't have stood out as anything particular.

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

Quote: Karlos already replied, but let me add something: having packed without power of 2 would have had MUCH LESS gaps compared to bitplanes. So, much more efficient. In theory, yes, but that's impractical on both hardware and software. In hardware that expects it to pack bit fields in different locations. It would need to keep track of it and mask it internally as reads the index for each colour. For the programmer they would be need mask off bit fields to write pixels in. That would overcomplicate it and it wouldn't be accessible like a linear framebuffer. Even two 4 bit values as nibbles per byte isn't the easiest to manage as the 1st pixel in the pair needs shifting left. So reserving a multiple of two size field to fit pixels up to a byte would be more practical. Just to clarify what I mean. Say a 5 bpp screen. Where the pixels were packed end to end like: 43210432 10432104 32104321 More practical but with more gaps and enough bandwidth is needed: 00043210 00043210 00043210

Karlos have already clarified it, and I don't want to continue repeating exactly the same thing, because it's becoming boring.

Next time I'll write it on an article, with examples and data.
Quote:

Quote: I think that you don't realize how wasteful it is. I just think it's too late as no one can change it now.

Indeed. In fact, that wasn't my goal: the past couldn't be changed. Obviously.
Quote:

Quote: Guess what: it's EXACTLY what the Amiga's display controller did, and the Blitter in particular. The blitter just needed to shove it all through the barrel shifter and mask off the edges. Which was fine for one bitplane. But inefficient for multiple pass on more.

Exactly.
Quote:

I notice that there is a lot of talk about the CPU being faster then the blitter. Faster doing what? In real life it needs to shift the data along for other X/Y co-ordinates. That means the CPU then needs to rotate every word before it writes it in and mask off the edges. Sure it could be fast at that also but that's more complicated than a simple block image transfer with a MOVE.L loop.

It depends on how fast the CPU is for doing such shift, rotate, mask.

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.

Otherwise (16-bit chip-ram) the Blitter was generally faster.
Quote:

Quote: Why it should be different (and inefficient) for packed graphic? On the contrary, the display controller is much easier and WAAAAAAY more efficient. Again: math rulez.. I was thinking like in my 5 bit packed example above. That's why. When not packed in an even fashion.

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

Quote: I don't know, but this isn't the point. The point is analyzing the facts and the data, and draw the proper conclusions. Conclusions are fine but I like to know about different hardware was configured for the display.

No, it looks that aren't fine for you, because you still don't get the point with the packed graphics.
Quote:

Quote: Do you mean with the dual-playfield? This, as I've said, it's the same if using the packed graphic for 2 playfields. Absolutely no difference here. No I think what I mean is, when one playfield is set, but the scroll offsets are different. So it splits the odd and even planes. I can't imagine this being practical with packed. It wouldn't make sense to hardware accelerate such an obscure operation. And using software to split odd and even bits then merge them back in at different offsets isn't the same when doing it manually. With more hardware layers it could be simulated. It was just cheap trick splitting even and odd planes.

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

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:
- BPL1PT points to the start of the first packed playfield;
- BPL2PT points to the start of the second packed playfield.

Everything else is EXACTLY THE SAME!

Only one further improvement could have been introducing the possibility to define how many bits (per pixel) give to the second playfield. This would have allowed further flexibility.

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

Quote: With packed graphic was the same, but easier and much more efficient. I don't think packed would have needed any even and odd separation. Just two layers with scroll offsets. Simple.

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

Quote: Well, Amiga engineers used the Blitter for that! If they could use it to blit a pixel from a direct index split into different planes using one blit operation they knew something I didn't.

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...
Quote:

Quote: Absolutely not: it was also packed. I meant in EGA which used planes.

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

Quote: Think about a screen with 4 (but can be any depth: it's exaclty the same) bitplanes and graphics to be moved: you CAN'T do it 16 pixels at the time! You need 4 blits to move 16 pixels. If the planes are in separate blocks obviously. But what about an interleaved bitmap with all plane lines in a row, can it blit to all planes with one blit op?

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

However cookie cut is impossible to do in one shot (unless the mask is duplicated for each bitplane, but it would be a complete waste of memory).

That's one of the reasons why bitplanes were so inefficient.
Quote:

Quote: However, if you write down the operations needed and how many memory transfers are required, then packed graphic wins hands down. There's no comparison. And the wider are the fetches (AGA -> 64-bit!!!) the MUCH WORSE becomes the bitplanes solution. Don't know who said it but over 20 years some Amiga programmer claimed that comparing planar with chunky that planar was best of all.

I don't know who's the guy (and I don't want to know), but he clearly didn't know what he was talking about.

As I've said several times, math counts. And math shows the packed graphics was almost always better than planar graphics.
Quote:

And could do the same kind of 3d games. I didn't see much examples of these 3d games.

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

@Karlos

Quote:

Karlos wrote: @Hypex Again a 5 bit packed pixel is not a big problem for hardware designed for it. You have the situation that you need 5 consecutive bytes to encode 8 5-bit pixels, and in an analogous manner to the 3-bit example, there are only 5 permutations of the byte layout to worry about for software access. Now, if you want to have a 32-bit bus to access them rather than a byte bus, you again take this up in the allowed row widths. The idea of packing with gaps into bytes is pointless, you'd be better off using all possible values and have 256 colours. It is definitely simpler to have power of 2 packing, e.g. 2,4,16,256 colour modes but it isn't rocket science to pack non power of two bits per pixel as has been shown. Hardware can still load spans of 32 bits, rotate them etc, and write mask them back into memory. The key difference is that you only have to do it once rather than once per plane.

*

@cdimauro

Quote:

cdimauro wrote: Maybe I stop here arguing about this topic, and I'll start writing it.

Yes. Let's see it.

@bhabbott

To be honest, this idea of packed N-bit pixels is the perfect example of a self nerd-snipe. I might look at adding them to MC64K's host as alternative pixel modes to vanilla 8-bit and 32-bit.

I was planning to a add 4-bit palette mode at some point anyway.

Last edited by Karlos on 30-May-2022 at 01:26 PM.

_________________
Doing stupid things for fun...

@Hypex

Quote:

Hypex wrote: RTG cards were the only way to add packed modes to an Amiga.

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.

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.

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.

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.

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!).

Last edited by bhabbott on 31-May-2022 at 01:43 PM.

@kolla

Quote:

kolla wrote: I am glad that they landed on planar, which in the end gives user more freedom to configure display as is fit for his/her use case and monitor.

Me too. Packed pixels are so boring.

Quote:

Of course they could have added one 320x200 chunky mode for certain games, but really… who would have used it? Look at Atari Falcon…

It was the same old story, new machine with big improvements has very poor sales because people were bored with the old one and upgraded to PCs.

But on the PC it was a different story. VGA only had one 320x200 chunky mode for certain games, but when people got bored with their old PC they upgraded to... another PC! Previous PC graphics modes used for games were the awful CGA, which used packed pixels but only in 4 stink colors with 2 horrible palette choices, and EGA which used bitplanes with a better 16 colors but a still stink 64 color palette.

The lessons here for computer designers are:-

1. Make sure it's a PC.

2. Give it stink graphics so games suck. Don't worry - people will buy it because it's a PC, and great games like Defender of the Crown will be ported to it even though squashing the Amiga's awesome graphics into crappy 4 color CGA looks terrible.

3. Introduce a new graphics chip that manages to match the competition. Sales will skyrocket as PC owners finally get good graphics and everybody flocks to it. Fans will forcibly assert that PCs always had the best graphics - even CGA because it had packed pixels.

Last edited by bhabbott on 31-May-2022 at 02:55 PM.

@bhabbott

Quote:

HAMe that connected to the RGB port, and cards that plugged into the flicker fixer slot to produce 24 bit color.

Yes had to write some HAM6/8 to True color routines they work fine, you don’t need OCS/AGA/ECS to display HAM6/8.

Quote:

Me too. Packed pixels are so boring.

have you treied messing around with OR, XOR and AND, you can make really cool effects, not unlike Amiga OCS/ECS/AGA effects.

It’s also easy change color in palette lookup table at different Y positions, to make cooper effect. when you convert it to True Color.

Last edited by NutsAboutAmiga on 31-May-2022 at 04:08 PM.
Last edited by NutsAboutAmiga on 31-May-2022 at 03:56 PM.
Last edited by NutsAboutAmiga on 31-May-2022 at 03:55 PM.

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

@bhabbott

Quote:

VGA only had one 320x200 chunky mode for certain games, but when people got bored with their old PC they upgraded to... another PC! Previous PC graphics modes used for games were the awful CGA, which used packed pixels but only in 4 stink colors with 2 horrible palette choices, and EGA which used bitplanes with a better 16 colors but a still stink 64 color palette.

Some of us bit banged CGA, EGA and VGA into weird screenmodes just as much as we did to ECS. ;)

@bhabbott

Quote:

bhabbott wrote: @kolla Quote: kolla wrote: I am glad that they landed on planar, which in the end gives user more freedom to configure display as is fit for his/her use case and monitor. Me too. Packed pixels are so boring.

Boring? Care to explain why?

Actually I, as a game developer, am bored to repeat operations n times (with n = number of bitplanes) when one should be enough...
Quote:

Quote: Of course they could have added one 320x200 chunky mode for certain games, but really… who would have used it? Look at Atari Falcon… It was the same old story, new machine with big improvements has very poor sales because people were bored with the old one and upgraded to PCs. But on the PC it was a different story. VGA only had one 320x200 chunky mode for certain games,

That's wrong. 320x200x256 was the standard mode 13h, but you can create custom resolutions that goes from 256x200 (it's just an example) to 400x600 in Mode X or Mode Y (when height was greater than width).
Quote:

but when people got bored with their old PC they upgraded to... another PC! Previous PC graphics modes used for games were the awful CGA, which used packed pixels but only in 4 stink colors with 2 horrible palette choices,

Again wrong: CGA allowed 640x200x2, 320x200x4, or 160x200x16.
Quote:

and EGA which used bitplanes with a better 16 colors but a still stink 64 color palette.

Like ECS in Super-Hires mode.

But at least it had screen modes from 320x200 to 640x350 (more reprogramming the resolutions) in 16 colors, WITHOUT interlace, and without the display controller which was stealing a lot of color cycles (all with Amiga in hired mode and 16 colors).
Quote:

The lessons here for computer designers are:- 1. Make sure it's a PC. 2. Give it stink graphics so games suck. Don't worry - people will buy it because it's a PC, and great games like Defender of the Crown will be ported to it even though squashing the Amiga's awesome graphics into crappy 4 color CGA looks terrible.

https://www.mobygames.com/game/defender-of-the-crown/screenshots

You have the EGA version.
Quote:

3. Introduce a new graphics chip that manages to match the competition. Sales will skyrocket as PC owners finally get good graphics and everybody flocks to it. Fans will forcibly assert that PCs always had the best graphics - even CGA because it had packed pixels.

You're talking non-sense. And, more important, mixing things without a rational.

In fact, you're often citing the CGA, which a card from 1981: released even before the Commodore 64!

EGA was from 1984, so before the Amiga, but already had a lot of cool features that you could have found only on the Amiga.

VGA, well, you don't even its features.

So, why you're talking of things that you clearly have no or poor knowledge?

@cdimauro

https://www.reenigne.org/blog/1k-colours-on-cga-how-its-done/ Totally not possible. This is a lie! heheh

@cdimauro

Yes please, there are FPGA systems available on which you can literally implement whatever output mode you want. For fun, start out with Minimig core and replace the planar output with your packed modes and show it off with some simple code showing various screenmodes.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@Bosanac

Quote:

Bosanac wrote: @cdimauro https://www.reenigne.org/blog/1k-colours-on-cga-how-its-done/ Totally not possible. This is a lie! heheh

Impressive!!!

Here's the technical article, which has some more interesting information: https://int10h.org/blog/2015/04/cga-in-1024-colors-new-mode-illustrated/

@kolla

Quote:

kolla wrote: @cdimauro Yes please, there are FPGA systems available on which you can literally implement whatever output mode you want. For fun, start out with Minimig core and replace the planar output with your packed modes and show it off with some simple code showing various screenmodes.

I don't get it.

As I've said, I'm (in reality I was, because I don't do game coding from very long time) a game code.

Definitely NOT a hardware engineer neither a HDL/VHDL/Verilog/etc. engineer, which is what you're looking for.

So, what do you pretend from me? This isn't my expertise, as you should have clearly realized...

@cdimauro

Well, without any implementation to show for, there isn’t much value in these hypothetical “should have, could have” games, is there? And soon 40 years of hindsight.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@cdimauro

Quote:

cdimauro wrote: [quote]That's wrong. 320x200x256 was the standard mode 13h, but you can create custom resolutions that goes from 256x200 (it's just an example) to 400x600 in Mode X or Mode Y (when height was greater than width).

Yes, I am aware of these non-standard configurations that are variations on the standard 320x200x256 screen mode.

If we are going to be so pedantic then the Amiga also had hundreds of 'screen modes', even several at the same time! Do we have to list every possible combination to avoid being accused of being 'wrong'? How silly.

Quote:

Again wrong: CGA allowed 640x200x2, 320x200x4, or 160x200x16.

I am talking about the 320x200x4 CGA graphics mode typically used for games.

I don't know of any PC game that used 640x200 (I won't say there weren't any though, to avoid your dragging out some obscure game and screaming 'wrong again!'). Suffice to say that it was very stink and not worth talking about.

I Googled 160x200x16 CGA and could not find any information on this mode. Is it a modification of the 160x100 character-based 'pseudo-graphics' mode?

Quote:

Like ECS in Super-Hires mode.

Why bring up this irrelevant comparison?

Oh, I get it now. You are on a crusade to prove that PC graphics (even CGA) were better than Amiga graphics in every way that mattered. Pathetic.

Quote:

But at least it had screen modes from 320x200 to 640x350 (more reprogramming the resolutions) in 16 colors, WITHOUT interlace,

You do realize that the Amiga does 320x200 WITHOUT interlace, right? And to display EGA's 640x350 you need a special multisyncing monitor designed for it, right? Too bad if you only have a TV or 15kHz monitor.

Quote:

and without the display controller which was stealing a lot of color cycles (all with Amiga in hired mode and 16 colors).

Another irrelevant detail.

I could counter by saying that 80 column CGA text similarly uses all the video bandwidth, with the additional faux pas that the CPU has priority, which causes 'snow' if you access the screen during the active display period. But this is also irrelevant because games generally run in 320x200 (or similar) 'lores' graphics mode, not hires 16 color graphics or text.

Quote:

https://www.mobygames.com/game/defender-of-the-crown/screenshots You have the EGA version.

It looks stink even in EGA, but the CGA version is worse. Now ask yourself, why would anyone port Defender of the Crown to CGA (I mean 320x200 in 4 colors of course, just in case you are confused about that), when they know the result will be awful?

Quote:

In fact, you're often citing the CGA, which a card from 1981: released even before the Commodore 64!

Exactly. CGA was the graphics IBM expected people to use for games. And they did for many years, giving the PC a reputation for bad game graphics - and a big incentive to upgrade. The Amiga (and the C64 as well to a lesser extent) had excellent graphics so users were satisfied with it for many years.

Quote:

EGA was from 1984, so before the Amiga, but already had a lot of cool features that you could have found only on the Amiga.

'Cool features' like a garish 64 color palette instead of 4096 colors, right?

It's one thing to talk about the merits of packed pixels vs planar etc., but making it about who did what first is another matter. It's not the 1980's any more and most us are not interested in pissing contests. But some of us are still interested in what we can do with our (now retro) machines.

We are now seeing quite remarkable things being done in games like Metro Siege and Dread which show what it is capable of. These games aren't relying on tricky stuff that uses undocumented or poorly understood chipset features, just taking the time to get the best out of it.

@bhabbott

Quote:

bhabbott wrote: @cdimauro Quote: cdimauro wrote: That's wrong. 320x200x256 was the standard mode 13h, but you can create custom resolutions that goes from 256x200 (it's just an example) to 400x600 in Mode X or Mode Y (when height was greater than width). Yes, I am aware of these non-standard configurations that are variations on the standard 320x200x256 screen mode. If we are going to be so pedantic then the Amiga also had hundreds of 'screen modes', even several at the same time! Do we have to list every possible combination to avoid being accused of being 'wrong'? How silly.

Silly is the only thing on which I agree on, because you continue to mix different things: apples with oranges.

Mode 13h is called standard mode because it's one that you can select using the standard Set Video Mode APs: https://en.wikipedia.org/wiki/INT_10H
To make a parallel, it's the equivalent of Intuition's OpenScreen on Amiga: http://amigadev.elowar.com/read/ADCD_2.1/Includes_and_Autodocs_2._guide/node0237.html

Non-standard modes are created by reprogramming the display controller, and here the equivalent is the new set of registers that ECS introduced (but on '90!). However nothing weird: EGA/VGA registers are used as per their specs / official documentation.

The difference with the Amiga is that with PCs you're able to define new display modes (text or graphic) which could be used by all users. In fact, games (and demos) used them.

Amiga is different because everything was already documented by Commodore, and there was/is nothing "special" / "hidden" that can be made and which can used by all users.

This clarified, please show me the "hundreds of 'screen modes'" that were possible with the Amiga (and usable by all users).
Quote:

Quote: Again wrong: CGA allowed 640x200x2, 320x200x4, or 160x200x16. I am talking about the 320x200x4 CGA graphics mode typically used for games. I don't know of any PC game that used 640x200 (I won't say there weren't any though, to avoid your dragging out some obscure game and screaming 'wrong again!'). Suffice to say that it was very stink and not worth talking about.

Do you understand that you are talking of video card from 1981? Stinky? What do you've expected, a Silicon Graphics at the time?
Quote:

I Googled 160x200x16 CGA and could not find any information on this mode. Is it a modification of the 160x100 character-based 'pseudo-graphics' mode?

My mistake, I was recalling wrong: it was the latter.
Quote:

Quote: Like ECS in Super-Hires mode. Why bring up this irrelevant comparison?

Let me understand: you're making comparisons all ways around, and if I do the same... it's not ok for you?!?

Perfect logic...
Quote:

Oh, I get it now. You are on a crusade to prove that PC graphics (even CGA) were better than Amiga graphics in every way that mattered. Pathetic.

This is another logical fallacy (the Straw man): I never stated this, which is YOUR lie that you invented to discredit me.

It's a clear sign that you aren't able to sustain the discussion.
Quote:

Quote: But at least it had screen modes from 320x200 to 640x350 (more reprogramming the resolutions) in 16 colors, WITHOUT interlace, You do realize that the Amiga does 320x200 WITHOUT interlace, right?

I'm not a native speaker, as you already know, but either you don't read what I wrote or you've functional illiteracy issues.

What's not clear to you about this:
it had screen modes from 320x200 to 640x350
?
Quote:

And to display EGA's 640x350 you need a special multisyncing monitor designed for it, right?

Right, and what was the problem? Weren't games developed for EGA only because of that?
Quote:

Too bad if you only have a TV or 15kHz monitor.

Indeed, and again: what's the problem?
Quote:

Quote: and without the display controller which was stealing a lot of color cycles (all with Amiga in hired mode and 16 colors). Another irrelevant detail.

For you!
Quote:

I could counter by saying that 80 column CGA text similarly uses all the video bandwidth, with the additional faux pas that the CPU has priority, which causes 'snow' if you access the screen during the active display period.

I wonder when you'll stop changing topic and jumping to another one, trying to prove something which, of course, doesn't apply, since the original topic is different...

Specifically, in this part of the discussion I was talking about the EGA. So, and definitely, NOT about the CGA. Do you understand the difference? I know that's only one changed letter, but... it MAKES the difference!

Anyway, the snow effect was due to the fact that the game (or application) was badly written (something not new in the Amiga land, BTW: there are thousands of games/demos that needed fixes via WHDLoad for this reason).
In fact, it was enough to check pag.25 of this http://minuszerodegrees.net/oa/OA%20-%20IBM%20Color%20Graphics%20Monitor%20Adapter%20(CGA).pdf to see how easy it was to avoid those issues (bit 0 of CGA's Status Register should be clear enough. Right?)
Quote:

But this is also irrelevant because games generally run in 320x200 (or similar) 'lores' graphics mode, not hires 16 color graphics or text.

Here's a game that used EGA's high-res resolution (640x350x16): https://www.mobygames.com/game/dos/cyrus Year: 1985.
Screenshot: https://www.mobygames.com/game/dos/cyrus/screenshots/gameShotId,24141/

When do you stop to report false statements? You clearly have no idea of what happened with PCs.

Maybe you were too much involved with the Amigas to see what was happening outside of your cave...
Quote:

Quote: https://www.mobygames.com/game/defender-of-the-crown/screenshots You have the EGA version. It looks stink even in EGA, but the CGA version is worse. Now ask yourself, why would anyone port Defender of the Crown to CGA (I mean 320x200 in 4 colors of course, just in case you are confused about that), when they know the result will be awful?

Obviously because there was ALSO a videogame market for PCs. Do you have other silly questions?
Quote:

Quote: In fact, you're often citing the CGA, which a card from 1981: released even before the Commodore 64! Exactly. CGA was the graphics IBM expected people to use for games.

LOL. PCs were sold as Personal Computers by IBM, and certainly NOT for games! Do you know what the B stands for in IBM? I don't think so...
Quote:

And they did for many years, giving the PC a reputation for bad game graphics - and a big incentive to upgrade.

That's completely wrong as per above. Graphic improved according to the BUSINESS needs which grew as well.

This is the reason why EGA was born and REQUIRED a multisync monitor for its high-res graphic mode.

Graphic cards explicitly suited for games were developed and sold after MANY YEARs.

You don't know even elementary history of computers...
Quote:

The Amiga (and the C64 as well to a lesser extent) had excellent graphics so users were satisfied with it for many years.

C64 was a game machine. And Amiga had a chipset devoted to games. What do you expected from them? Games!

Now take a look at the PCs: their chipset was NOT devoted to games. Rather for business. They evolved ALSO for better supporting the games, only because there was a market for that as well. People liked to play even on businesses machines.
Quote:

Quote: EGA was from 1984, so before the Amiga, but already had a lot of cool features that you could have found only on the Amiga. 'Cool features' like a garish 64 color palette instead of 4096 colors, right?

No, I was referring to these:
- (hardware) smooth scrolling;
- possibility to display the screen from any part of the video memory;
- dual / triple buffering (consequence of the previous one);
- vertical blank interrupt;
- possibility to check if the display controller was showing the screen or not (horizontal or vertical blanking periods);
- logical operations on bitplanes (included the chained bitplaned on Mode-X et similar), albeit limited to some horizontal pixels portion (absolutely not flexible as with the Blitter);
- split screen (you can set a raster line, and the display controller reaches it, then it begins displaying the graphics starting from location 0 of the video memory. Useful to simulate fixed screens of a certain height at the bottom of the display);
- programmable resolutions (up to 800x600 with 16 colors. Up to 400x600 with 256 colors on VGA);
- no interlace.

You continuously stressed that smooth scrolling was a super cool feature, which in your opinion PCs lacked. But only because of your ignorance, because you clearly had no knowledge about PCs hardware.

But this was only ONE feature which was suitable for games: the above list is self-evident. For people which wants to see it...
Quote:

It's one thing to talk about the merits of packed pixels vs planar etc., but making it about who did what first is another matter.

Then let's discuss them separately...
Quote:

It's not the 1980's any more and most us are not interested in pissing contests.

Then why do you continue this discussion? Stop it and do something else that you like!
Quote:

But some of us are still interested in what we can do with our (now retro) machines. We are now seeing quite remarkable things being done in games like Metro Siege and Dread which show what it is capable of.

And? What's the problem? Enjoy them!
Quote:

These games aren't relying on tricky stuff that uses undocumented or poorly understood chipset features, just taking the time to get the best out of it.

Who cares? The PC hardware was documented, but nobody cared to tinker and squeeze it because... rolling drum... it was mainly used for business applications. Games were just "extra staff".

Nevertheless, what's important (and what was about this part of discussion, that you clearly "forgot"), was if it was suitable or not for games. And it was, as PROVED. Whether you like it or not.