@raddude9

Welcome!

@raddude9

Quote:

raddude9 wrote: Sorry for my late addition, but this needed quite a bit of thought...

Welcome. We are talking about an imaginary situation, but I just reply to a few things.
Quote:

Assuming that nobody is going to ask where I got the 8 billion pounds, I'd go back to about 1982 and invest in the early Amiga Inc. I'd let them develop the OCS chipset with just a few tweaks, 2 channels of 16-bit audio instead of 4 channels of 8-bit for example,

With only 2 channels you have to mix yourself samples to emulate multiple channels, which requires the CPU and waste its time.

More important, 16-bit samples wast much more memory (chipram usually), which was very low and expensive at the time.
Quote:

and adding a 6-bit chunky graphics mode.

This doesn't make sense. Maybe an 8-bit chunky mode.
Quote:

Speaking of which, hitting the hardware directly would not be possible and developers would have to use Amiga-OS libraries to access the functionality of the computer. Sure, this would prevent developers from pushing the machine to it's limits, but with more frequent hardware updates this would not be required.

This depends on the cost of the machines. At the time, they were expensive, and directly accessing the hardware was "mandatory" to squeeze the most of the hardware.
Quote:

In 1988 (for the high-end machines, 1989 for the low-end) I'd like to see a base machine with an upgraded and faster 16-bit chipset utilising VRAM, say with 512K of VRAM and 1024k of Fast Ram (For a 1.5MB total),

VRAM (chipram at the time) is much more important.
Quote:

this should allow more bitplanes to be shown, certainly up to 8-bit and maybe 12-bit,

Up to 8 bitplanes it makes sense. After that, no: it's better to switch to packed/chunky modes.

@bison

Quote:

bison wrote: @raddude9 With that much money in hand you could have bought MIPS, which started about the same time as Amiga.

There really wouldn't have been anything to buy back in 1982, and besides, the first iteration of MIPS, the R2000 (released in 1985), was too big a chip for the machine I had in mind, it was a full 32-bit chip with 110,000 transistors, which would have made it very expensive back then, the original ARM chip used only about a third of that number of transistors, making it much cheaper to produce.

@cdimauro

Quote:

cdimauro wrote: Welcome.

Thanks!

Quote:

cdimauro wrote: With only 2 channels you have to mix yourself samples to emulate multiple channels, which requires the CPU and waste its time.

With a decent RISC chip, the processing overhead of mixing 2 audio channels would have been relatively light, but I get your point, the main reason for for going 16-bit from the very beginning would be future-proofing, the Amiga had fantastic audio back in the 80's, but it never really progressed.

Quote:

More important, 16-bit samples wast much more memory (chipram usually), which was very low and expensive at the time.

Another good point, 16-bit audio is quite big when you're talking about a 512k machine. One solution would be use compressed audio, 4-bit ADPCM audio sounds roughly as good as 8-bit (IMHO), and, again, with a decent RISC CPU, it could easily be de-compressed to 16-bit on the fly, or on loading.

Quote:

Quote: and adding a 6-bit chunky graphics mode. This doesn't make sense. Maybe an 8-bit chunky mode.

I actually had a part-chunky part-planer screen mode in mind, say with three 2-bit planes, one for Red, one for Green and one for Blue. You're probably wondering Huh! right now, who would want this weird palette-less 64 color mode? Well, not many people, it would be kinda useful for 3D I think, but nothing special. The main reason for going this way would be as an introduction to a similar but 12-bit mode to be released in the follow-on 1998 machine. A 4096 colour 3D mode would be a very powerful feature in a late 80's machine and would give great graphics while still working well within the confinement of a 16-bit machine.

Quote:

Quote: Speaking of which, hitting the hardware directly would not be possible and developers would have to use Amiga-OS libraries to access the functionality of the computer. Sure, this would prevent developers from pushing the machine to it's limits, but with more frequent hardware updates this would not be required. This depends on the cost of the machines. At the time, they were expensive, and directly accessing the hardware was "mandatory" to squeeze the most of the hardware.

Very little software made the most out the the Amiga hardware in the mid to late 80's, it wasn't until 1989 or '90 that developers really went to town getting the most out of the Amiga hardware. If the dev's had improved hardware to work with that wouldn't have been necessary

Quote:

VRAM (chipram at the time) is much more important.

I agree, but as far as I remember it was still quite expensive up until the 90's when it eventually dropped to a 20% or so premium over regular memory.

@raddude9

Quote:

raddude9 wrote: @cdimauro Quote: cdimauro wrote: With only 2 channels you have to mix yourself samples to emulate multiple channels, which requires the CPU and waste its time. With a decent RISC chip, the processing overhead of mixing 2 audio channels would have been relatively light, but I get your point, the main reason for for going 16-bit from the very beginning would be future-proofing, the Amiga had fantastic audio back in the 80's, but it never really progressed.

I share the same opinion. However as a coder I greatly preferred multiple DMA-driven 8-bit audio channels over few 16-bit ones which requires an heavy CPU processing.

The Amiga was so easy to program: a bunch of instructions to set the hardware registers, and you forget them.
Quote:

Quote: More important, 16-bit samples wast much more memory (chipram usually), which was very little and expensive at the time. Another good point, 16-bit audio is quite big when you're talking about a 512k machine. One solution would be use compressed audio, 4-bit ADPCM audio sounds roughly as good as 8-bit (IMHO), and, again, with a decent RISC CPU, it could easily be de-compressed to 16-bit on the fly, or on loading.

All that requires transistors and/or processing power. As I stated before, I liked to just set the registers, and let the chipset do the work, offloading as much as possible the CPU.
Quote:

Quote: This doesn't make sense. Maybe an 8-bit chunky mode. I actually had a part-chunky part-planer screen mode in mind, say with three 2-bit planes, one for Red, one for Green and one for Blue. You're probably wondering Huh! right now, who would want this weird palette-less 64 color mode? Well, not many people, it would be kinda useful for 3D I think, but nothing special.

Unfortunately it isn't useful even for 3D, because it required mask & shift operations to manipulate the graphics.

And 8-bit chunky mode (palettized) is much much better for 3D, ad well as for some 2D games. Since there was less space space in the registers bank for the color palette (only 32 entries were available), the best would have been to further extend the Extra-Half Bright mode (EHB) to produce 8 levels of intensity for each of the 32 "base" colors.

Quote:

The main reason for going this way would be as an introduction to a similar but 12-bit mode to be released in the follow-on 1998 machine. A 4096 colour 3D mode would be a very powerful feature in a late 80's machine and would give great graphics while still working well within the confinement of a 16-bit machine.

As for a 6-bit chunky mode, a 12-bit one required mask & shift operations, which are very slow for handling graphics. It's much much better to directly go for a 16-bit mode.

Quote:

Quote: This depends on the cost of the machines. At the time, they were expensive, and directly accessing the hardware was "mandatory" to squeeze the most of the hardware. Very little software made the most out the the Amiga hardware in the mid to late 80's, it wasn't until 1989 or '90 that developers really went to town getting the most out of the Amiga hardware. If the dev's had improved hardware to work with that wouldn't have been necessary

But that little software was impressive.

Another problem for direct hardware access was represented by free memory. The o.s. sucked some precious memory (and you don't know precisely how much: it depends on the o.s. version), which you, as a coder, wanted to use. That's why many games killed the o.s., and handled everything by themselves.
Quote:

Quote: VRAM (chipram at the time) is much more important. I agree, but as far as I remember it was still quite expensive up until the 90's when it eventually dropped to a 20% or so premium over regular memory.

If fact, up to the beginning of '90s it was better to use regular DRAM instead of VRAM, to cut the costs.

Anyway, on an Amiga the most important memory was the one accessible from the chipset: the chipram. That's why I greatly prefer an "unbalanced" memory configuration, with much more chipram instead of fastram. In reality, as a game coder, I prefer ONLY chipram.

@cdimauro

Quote:

I think we all agree that linear addressing of memory is the best thing, but see above: please, contextualize it.

Yes I did see it in context. I Imagine having a register for a high word would have been easier for the programmer.

Quote:

Of course, but it's always much better than planar graphic.

Personally I fell that planar format is the only true bitmap for,mat. Chunky is more of a chunk-map or byte-map[ in realty. And true colour formats don't really represent bits at all but whole numbers contains in bytes. Sure all the bits make up the bytes but it just isn't the same to me.

Apart form that chunky just doesn't have the depth perception of planar.

Quote:

I don't know how much time you have

Probably less than I think but I can make time.

Quote:

I don't remember of any update of the Blitter after the ECS chipset. Have you some information about it?

Sorry, it was ECS. I was thinking of the size extension but somehow thought it was introduced in AGA. I looked it up and it is ECS. Looks like ECS was a good update then.

Quote:

But at the time an 8-bit chunky mode was good because it required less space and bandwidth.

Less space than what?

Quote:

That's one of the AAA modes, which frankly speaking I didn't like at all.

Must have some residual memory of reading about it. Perhaps it could have aided in video playback If RGB8 planar was ever used. But mostly it would be good if was one way to get 24-bit within the limit of memory speed bandwidth.

@cdimauro

Quote:

Maybe an 8-bit chunky mode.

Yeah, that would be nice. 256-color graphics would have been a big deal in 1985.

_________________
"Unix is supposed to fix that." -- Jay Miner

@babsimov

Quote:

Yes i remember, but it's not cheap. What I proposed was a 640x512 color mode 2 in 31 kHz and a bit expensive monitor to go with.

After I sold my KS1.3 ECS A500 I found out after the fact that the hardware could display 640x480 at 31KHz in four colours.

Quote:

They say it have a 128 colors palette, the Amiga have 4096 colors. And, if i remember correctly, The C16 is not C64 compatible.

What I meant to point out was palette registers even though in this case there cannot be a direct comparison. The Amiga palette had 32 entries so with a normal screen like 320x200 could display 32 colours. The C16 could display 128 colours or rather ,121, on the same sized screen.

No, the C16 wasn't C64 compatible but, so what?

Quote:

ECS is a hack, AGA too (instead we go to AAA for high end).

I wouldn't say ECS was a hack. It was a logical upgrade and improved the blither.

Quote:

Even Jay Miner acknowledged that he should have gone directly to Chunky for the Amiga with hindsight.

it could be said this would have been more Commodore like since the C64/C16/C128 etc. used chunky in multicolour mode. But comparing the two they are worlds apart. The blitter is focused on bits and bit-masks. For chunky it would have been a totally different design. Perhaps the best idea would have been to include both to get the best of both worlds.

Quote:

I am not a technician and I can't follow on that land there, especially in English (it's not my language). But my readings here and there on the internet about the Amiga, on forums, allowed me to understand that having keep the 16 bits blitter and copper from OCS in AGA and not to move to Chunky were the main mistakes

Your English looks good to me. I was mainly wondering what you meant by "blitter and copper chunky 32-bit".

Quote:

AAA include the Mary sound chip (8 channel 16 bit)

Okay I understand. Or SoftMary it was called in AudioLabJr.

Quote:

I think i made an edit to my original post to include these modification and information about the sound with ACS (the two paula thing).

Okay. Thanks.

@raddude9

Quote:

I'd let them develop the OCS chipset with just a few tweaks, 2 channels of 16-bit audio instead of 4 channels of 8-bit for example,

Instead of? As well of sure but not instead of. Those extra channels allowed music to play and games to play sound efects. Sure only two per stereo channel but it made a difference.

One 16-bit stereo channel would have been okay for professional use like multi-tracking where the CPU renders the output. But not for general use. The Amiga was about hardware acceleration. This would have gone against that and forced the programmer to try and mix it together.

Mixing by hand isn't easy; you have to read in different channnel samples, in this case two, that are in different rates, and combine them with distorion control. So you have to select a target frequency, resample the incoming samples at dfferent rates to match, which most likely involves stretching it upwards and using a Fixed number or FP math using integers. You have to modify amplitude to match the volume. All that plus the mixing. And if you need it fast you lose quality. If you have heard an OctaMED 8 channel module using orginal replayer and associated CPU use you will know what I mean.

Quote:

and adding a 6-bit chunky graphics mode.

That sounds awkward. Sure you can just put the LSB on bit 0 so you plonk in a normal byte value up to 63. But it takes more RAM than 6 bitplanes. Chunky is really only suitable for multiples of two. Planar is good for odd depths. Memory wise.

Quote:

At the same time, I'd set up a small CPU development team and begin developing a new cpu.

Commodore did have MOS. But that was stuck in the 80's. In any case, why? The 68000 was fine piece of CPU.

Also, would you have made it big or little endian?

Quote:

8-bit and maybe 12-bit

For planar I don't see the point of going beyond 8-bits. Even if it wasn't going to a 4096 CLUT bitmap and instead direct palette vales. After a 256 entry palette table it's diminishing returns so might as well plug the RGB values in direct.

Quote:

all machines would come with a IDE interface

Blah! As an optional cheap interface sure but without the DMA mode of SCSI there is no point. Also, only two devices per bus compared to 7 on SCSI.

Last edited by Hypex on 19-Sep-2015 at 04:24 AM.
Last edited by Hypex on 18-Sep-2015 at 06:14 PM.

@Hypex

Quote:

Hypex wrote: @babsimov Quote: Yes i remember, but it's not cheap. What I proposed was a 640x512 color mode 2 in 31 kHz and a bit expensive monitor to go with. After I sold my KS1.3 ECS A500 I found out after the fact that the hardware could display 640x480 at 31KHz in four colours.

Yes i know, but ECS came in 1990. Maybe a 640x480 4 colors mode can be included from the start in 1983. But my main goal with a 640x512 2 color mode at 31 khz is to have a very cheap monitor for office work (like Atari ST at the time). I want all the market from Atari ST for the Amiga. Remember the Atari ST sold more or less 6 to 7 millions units. Amiga sold 6 millions. So with no Atari ST on market (remember my original post), Amiga can sold, at minimum 12 to 13 million. My goal is to make the Amiga succefull in all market. Priority to Office market, second personnal computing, and as a bonus game market.

Quote:

Quote: They say it have a 128 colors palette, the Amiga have 4096 colors. And, if i remember correctly, The C16 is not C64 compatible. What I meant to point out was palette registers even though in this case there cannot be a direct comparison. The Amiga palette had 32 entries so with a normal screen like 320x200 could display 32 colours. The C16 could display 128 colours or rather ,121, on the same sized screen.

I can't follow you here, it became too technical, sorry.

Quote:

No, the C16 wasn't C64 compatible but, so what?

To me, in reality, release the C16 as not compatible with the successfull C64 is a waste of money and a bad idea for Commodore.

So in my dream reality. Commodore release the C64 as an entry level personnal computer. But my focus is Amiga. So all the research and developpment money go to Amiga. No upgrade for the Commodore 8 bit generation, after Amiga release. Let the C64 as it is and sell it for a cheap price to achieve the guiness book record (25 million sell) and get easy money to invest in new chipset upgrade for Amiga.

Quote:

Quote: ECS is a hack, AGA too (instead we go to AAA for high end). I wouldn't say ECS was a hack. It was a logical upgrade and improved the blither.

Well, i remember the Amiga 3000 release back in 1990... All of us expect a chipset with more of everything... (color, sound) and we get ECS.... no more color, no more sound.... disapointing...
And now we know that the AAA design is ready on paper in 1988, and Dave Haynie said, if Commodore had invest enough money, it can be released at 1990 with the 3000 instead of ECS....
For me, ECS is not and upgrade but a joke, and AGA that follow latter, at minimum what have might be released at 1990 instead of ECS. So i see both ECS and AGA as minimal upgrade and both disapointing. So i choose the ACS way, 256 color in 1987, way better than ECS at 1990 or AGA (256 color at 1992).... Remember at 1987 VGA exist on PC and MAC (but with no blitter/copper). I always want the Amiga to be better than PC/MAC for the office market.

Quote:

Quote: Even Jay Miner acknowledged that he should have gone directly to Chunky for the Amiga with hindsight. it could be said this would have been more Commodore like since the C64/C16/C128 etc. used chunky in multicolour mode. But comparing the two they are worlds apart. The blitter is focused on bits and bit-masks. For chunky it would have been a totally different design. Perhaps the best idea would have been to include both to get the best of both worlds.

I can't follow on the blitter bit and bit-mask.
But, i agree with you, it's better to have both (Planar and Chunky). It's why there is AAA :)
For ACS in 1987, i think have both is way to expensive. Remember Dave Haynie had said that AAA is very expensive to produce. It was one of the reason why Commodore postpone it's release from 1990 to 1992 and after 1994. The main one is lack of investment in reasearch and design.
By the way, i have made a little edit of my original post, about ACS display capabilities.

Quote:

Your English looks good to me.

Thanx, but with google translate help.

Amiga/QNX AND BeOS would have happened.


Plaz

@Hypex

Quote:

Hypex wrote: @cdimauro Quote: I think we all agree that linear addressing of memory is the best thing, but see above: please, contextualize it. Yes I did see it in context. I Imagine having a register for a high word would have been easier for the programmer.

Basicly is what you have with the x86 segmentation.

Quote:

Quote: But at the time an 8-bit chunky mode was good because it required less space and bandwidth. Less space than what?

A comparable 8-bit bitplane-based system. Read my explanations at amigacoding.de for more detailed information.

Quote:

Quote: That's one of the AAA modes, which frankly speaking I didn't like at all. Must have some residual memory of reading about it. Perhaps it could have aided in video playback If RGB8 planar was ever used.

I don't think so. Such mode was introduced only because it was cheaper to recycle the existing bitplane pointers, compared to changing the display logic to directly accept a 32-bit packed format (or, worse, a 24-bit one).

Quote:

But mostly it would be good if was one way to get 24-bit within the limit of memory speed bandwidth.

It helped, for sure, but it was cumbersome to use.

Quote:

Hypex wrote: @babsimov What I meant to point out was palette registers even though in this case there cannot be a direct comparison. The Amiga palette had 32 entries so with a normal screen like 320x200 could display 32 colours. The C16 could display 128 colours or rather ,121, on the same sized screen.

They were 121, because you had 8 shades for the black (which is... still black).

Quote:

The blitter is focused on bits and bit-masks. For chunky it would have been a totally different design. Perhaps the best idea would have been to include both to get the best of both worlds.

Too much complicated. The Blitter was simply to design because it was only bitplane-oriented.

@cdimauro

Quote:

Too much complicated. The Blitter was simply to design because it was only bitplane-oriented.

Remember, you have "eight billion pounds".

@pavlor: yes, but you're still constrained by the technology processes of that time. You cannot pack whatever amount of transistors that want in the chips, and such chip cannot be expensive to produced, otherwise they had no market.

Let's avoid to make other mistakes: Commodore management and engineers already did a lot.

@cdimauro

Quote:

and such chip cannot be expensive to produced, otherwise they had no market.

With "eight billion pounds" you can subsidise your products until cheap enough technology is available.

@babsimov

Quote:

Yes i know, but ECS came in 1990

It didn't seem it like then that I got my A500 for Christmas. I had an A500 Starter Kit. And before then my first computer was a C16.

Quote:

But my main goal with a 640x512 2 color mode at 31 khz is to have a very cheap monitor for office work

Have you heard of MagicTV? It was a software deinterlacer for running on a TV. I ran it on my A1200. It did something to the palette colours. Okay not exactly the same.

Quote:

Remember the Atari ST sold more or less 6 to 7 millions units.

Mr parents gave me a choice in the shop of Atari or Amiga. And I must say, the Atari looked better! It looked cooler on the box. Trendy geey color. And around 20 colourful games were included. OTOH, by comparsion the Amiga was in the dated looking beige case and only had about four games. I was tempted to get the Atari but I thought the Amiga was the right choice. Brand recognition really, a logo on the box. I liked the Commodore brand. Damn machine has cursed me ever since!

We must also remember that Jay designed chipsets for Atari and the Amiga was destined to be the next Atari. Good subject for a thread.

Quote:

I can't follow you here, it became too technical, sorry.

And here I thought I made it simple. The A500, for example, as standard could display 32 colours on screen in low-res. The C16 could display 121 colours on screen in low res.

Quote:

To me, in reality, release the C16 as not compatible with the successfull C64 is a waste of money and a bad idea for Commodore.

I don't see a need for it to be compatible. It's not meant to be a C64. It was for a different market. For one thing, it only has 16KB RAM, so it couldn't be compatible anyway. But, looking at the PET, VIC-20 and C64; the VIC-20 wasn't fully compatible with the PET. And the C64 certainly wasn't fully compatible with the VIC-20. So I didn't see the problem here. A logo doesn't have to mean one thing and nothing else.

Quote:

So i choose the ACS way, 256 color in 1987, way better than ECS at 1990 or AGA (256 color at 1992).... Remember at 1987 VGA exist on PC and MAC (but with no blitter/copper). I always want the Amiga to be better than PC/MAC for the office market.

If anything ECS was a slight update. That broke my A500 from playing some games and software. I do agree that AGA was hack. Keeping the RGB 4-bit nibbles and using bank switching to support 256 entries with 24+1 bit colour. Sorry got technical.

It would have been better if had AGA earlier. And even better if AGA was skipped and AAA shipped in its place. Don't get me wrong, compared to OCS/ECS the 24-bit AGA pallette is super crisp along with all those full size hi res modes. But it should have been better with a simpler hardware design rather than trying to fit it into the rigid design of ECS.

Quote:

I can't follow on the blitter bit and bit-mask.

Well, the blitter works on 16 pixels at a time, on a per bitplane basis. So, it works with 16-bit words in memory. Like so:
0000111111110000

Say we want to blit that to a bitmap but only the 8 pixels in the middle. The mask wil protect the bits of the destination bitmap we want to leave as is. So as the blitter reads in the bitmap data to proces it, it read the destination word, mask it then OR the source with it and write it back to the desination. So the pixels are only combined where they are wanted. A mask like so:
1111000000001111

The other thing was blitting to any X/Y coordinate. For this the blitter had to shift or rather rotate the data to write it in between the 16 pixel aligment it worked with. So a mask would hide the left edge and right edge and a simple rotate took care of the middle.

To cut it short, planar data is real bitmap data, as it is all split into seperate bits per pixel. And the blitter was optimsed to work with this arrangement.

Last edited by Hypex on 19-Sep-2015 at 05:07 PM.

@Hypex

Quote:

Have you heard of MagicTV? It was a software deinterlacer for running on a TV. I ran it on my A1200. It did something to the palette colours. Okay not exactly the same.

As someone who used both A1200/C1085S monitor with MagicTV and Atari ST with SM124 monitor I can assure you, difference is enormous. PAL still flickers even with MagicTV hack. Nothing beats good monitor - like SM124 or 19" TFT my Amiga has right now.

Quote:

Mr parents gave me a choice in the shop of Atari or Amiga. And I must say, the Atari looked better! It looked cooler on the box.

So I´m not alone? I also like Atari ST case design far more than "boring" A500.

Quote:

AGA was skipped and AAA shipped in its place

AAA was never intended for low-end models (like A500/1200) - too much complex, too much expensive. It sounds hard from me, but I think concept of AAA was dead end. However, with "eight billion pounds", it wouldn´t be hard to make AAA reality.

@cdimauro

Quote:

Basicly is what you have with the x86 segmentation.

For years I thought the "Real mode" was the 32-bit linear mode but I looked it up and it's like the complete opposite of what I thought! I must have associated "Real" with a linear address space.Since you have a handle on x86, does it have a 32-bit+ linear mode and what is it called?

Quote:

A comparable 8-bit bitplane-based system. Read my explanations at amigacoding.de for more detailed information.

Give me a link. With seperate bitplanes I can see slightly more memory even if the bitmap data combined is the same given it is split over memory. But an 8-bit interleaved bitmap will take exactly as much space as an 8-bit chunky byte map and likwise as a complete block for the whole screen.

Quote:

I don't think so. Such mode was introduced only because it was cheaper to recycle the existing bitplane pointers, compared to changing the display logic to directly accept a 32-bit packed format (or, worse, a 24-bit one).

Sounds like AGA really needed it. Or even ECS in an RGB4 version. It would surely have been faster and easier than HAM. Today I came across SHAM, Sliced HAM (haha), that used copper to change palettes. Sounds like a rather obvious thing to do. Don't know if any programs supported this.

Quote:

They were 121, because you had 8 shades for the black (which is... still black).

That's what I don't get, why would they stick black in there in the first place!? It just looks so stupid. Even a light or dark gray would be better. Even though light and dark should lose meaning when there are different brighness levels.

Quote:

Too much complicated. The Blitter was simply to design because it was only bitplane-oriented.

When you think about it some things are common like working across. But that's probably where it ends. The mask would have a different meaning. Sure it could do tricks by bits. But a bitmask would have instead specified whole pixels or bytes to erase. Perhaps it wasn't needed as mich as for a bitmap. But still some masking would be needed to transparently keep some pixels and write over others.

@Hypex

Quote:

Hypex wrote: @cdimauro Quote: Basicly is what you have with the x86 segmentation. For years I thought the "Real mode" was the 32-bit linear mode but I looked it up and it's like the complete opposite of what I thought! I must have associated "Real" with a linear address space.Since you have a handle on x86, does it have a 32-bit+ linear mode and what is it called?

Wait a moment: the 8086 mode isn't linear, because it used "overlapping segments" (with a 16 byte granularity), like I explained in the older comments. (FAR) pointers are 32-bit, splitted in offset + segment, but it wasn't a linear address and the memory addressable for each segment was still 64KB maximum.

Starting from the 80386, the segment limit is raised to 20 bits, so it was possible have up to 1MB per segment. Enabling the granularity bit, the segment size is raised to 4GB (with a 4KB granularity instead of a single byte).

Last but not really least, an 80386 allowed to address 4GB of memory (only for the data: code was still limited to the first MB of RAM) using the so called "unreal mode". The 4GB were fully linearly addressable.
Quote:

Quote: A comparable 8-bit bitplane-based system. Read my explanations at amigacoding.de for more detailed information. Give me a link. With seperate bitplanes I can see slightly more memory even if the bitmap data combined is the same given it is split over memory. But an 8-bit interleaved bitmap will take exactly as much space as an 8-bit chunky byte map and likwise as a complete block for the whole screen.

The argument was more general and much more complex.

This post shows you a concrete example, and proves that a packed mode is always much better than a planar one, giving you some numbers too.

The discussion was restarted on another thread, with several comments on the argument, starting from page 2 and going to page 4 (which shows other very important thoughts about it).

BTW, in both threads I explained how to implement a new Blitter which goes well beyond the limits of the existing and proposed (32-bit for AAA and Natami) implementations, allowing to maximize the speed and the usage of the memory bandwidth.
Quote:

Quote: I don't think so. Such mode was introduced only because it was cheaper to recycle the existing bitplane pointers, compared to changing the display logic to directly accept a 32-bit packed format (or, worse, a 24-bit one). Sounds like AGA really needed it. Or even ECS in an RGB4 version. It would surely have been faster and easier than HAM.

HAM is a different thing, and it's also more compact, albeit handling it was a nightmare.
Quote:

Today I came across SHAM, Sliced HAM (haha), that used copper to change palettes. Sounds like a rather obvious thing to do. Don't know if any programs supported this.

I recall that some supported it, but I don't remember which one.
Quote:

Quote: They were 121, because you had 8 shades for the black (which is... still black). That's what I don't get, why would they stick black in there in the first place!? It just looks so stupid. Even a light or dark gray would be better. Even though light and dark should lose meaning when there are different brighness levels.

Because they simply took the 16 colors palette used by the Commodore VIC 20 and 64, and added an 8 levels (3 bits) brightness control. It was cheaper to implement, and very effective.
Quote:

Quote: Too much complicated. The Blitter was simply to design because it was only bitplane-oriented. When you think about it some things are common like working across. But that's probably where it ends. The mask would have a different meaning. Sure it could do tricks by bits. But a bitmask would have instead specified whole pixels or bytes to erase. Perhaps it wasn't needed as mich as for a bitmap. But still some masking would be needed to transparently keep some pixels and write over others.

Yes, but it was handled in a much easier and efficient way. Take a look at my comments on the given threads on amigacoding.de.

@pavlor

Quote:

pavlor wrote: @cdimauro Quote: and such chip cannot be expensive to produced, otherwise they had no market. With "eight billion pounds" you can subsidise your products until cheap enough technology is available.

A company has to make profits...