Hi guys.

One of the most common discussions in the past few decades is the Amiga bitplane graphics and the possibility of integrating packed pixel modes into the design. We know this was planned post AGA with AAA but could it have been possible with a hardware revision? I avoid terms like chunky because it's such a PC term. I am discussing Amiga here.

I've known about how the Amiga design works for a number of years like we all have. But one thing has stood out that lacks detail which I think could have been the key to adding a packed mode without major changes. That is the bitplane data registers known as BPLxDAT:

These registers receive the DMA data fetched from
RAM by the bitplane address pointers described
above. They may also be written by either
microprocessor. They act as a six-word parallel-
to-serial buffer for up to six memory bitplanes
(x=1-6). The parallel-to-serial conversion is
triggered whenever bitplane #1 is written,
indicating the completion of all bitplanes for
that word (16 pixels). The MSB is output first,
and is, therefore, always on the left.

http://amigadev.elowar.com/read/ADCD_2.1/Hardware_Manual_guide/node0023.html

Little else is said but it's obvious here that parallel chunks of 16 pixels are read in from the planes and then converted into some serial data stream for CLUT reference. Or, to put it another way a planar to chunky conversion. This, I believe, is the clue to adding packed pixel modes.

It's not explained greatly here but each pixel bit is reversed from being atomic elements to becoming a whole quantity. It doesn't specify if it is one pixel at a time or a whole stream of 16 pixels. But what is certain is that planar bits go in one end and packed bits come out the other.

So the hardware read 16 bits at once for the parallel to serial conversions. One word for each plane which is stored in BPLxDAT. I don't know how this was stored as there are no public registers with the result but this I believe would have been the key to adding packed modes.

Taking the above into consideration I think the best way to achieve it and be easily engineered into the design was a direct mode that skipped the parallel to serial conversion altogether and read it directly from the plane. This would have placed a direct colour index into the hardware. For 1 bitplane this would have been direct anyway with a 1:1 conversion. For more it just becomes multiples of 16 bits so two bytes per plane. So up to 6 planes the max pixel data is 96 bits wide or 12 bytes. 6 individual parallel 16 bit reads then become sequential 16 bit reads. Depending on hardware configuration a group of 16 bits could be read in parallel or serial. The point here is it could read the data directly and skip the conversion since the CLUT value is ready to go.

It makes sense if it would be restricted to powers of two so only supporting 2, 4 or 16 colours. Since that is also easier to manage in software. But, what's interesting is if you do the maths, oddly enough, any odd bpp like 3 and 5 can fit in the same space. That is, 16x3 bpp is 6 bytes and 16x5 bpp is 10 bytes. Even 6 bpp, with 16x6 is 12 bytes. No matter what is the pixel width it's always aligned to 16 bits.

It's been said an A500 could have displayed a 256 colour chunky screen. That the bandwidth was there. In this case though it would have needed 128 bits or 16 bytes to read in a max group of 16 pixels.

The implementation would have used one plane in linear format as each pixel is wider and spread across one plane. But still would have allowed modes such as dual playfield to exist as normal. As well as copper and sprites working as normal. The blitter modes would likely have been unchanged but would have needed extra width to accommodate for wider blits due to wider pixel data per line. A mask could work as usual but would have needed to be wider and be packed out to pixel width.

So, what do you guys think? Does that look like something that would have been feasible? Or is there something I have missed such as reading in blocks of 16 bits but still only processing each pixel one bit at a time? In any case that data is some where.

Comments will appear below.

Last edited by Hypex on 26-Nov-2024 at 03:14 AM.

@Hypex

An 030/50 board with EDO Ram and AGA ADoom modes ran Doom 1 just fine. They needed to bump CPUs across the AGA machines as well as including a multi button controller, 1.76MB full speed disk drive and upgraded 8 channel Paula! Chunky Pixel was a bridge too far for AGA!

Last edited by BigD on 25-Nov-2024 at 05:31 PM.

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

@Hypex

given how simple the c2p logic in akiko was it would likely have been easy to implement into an AGA+ chip or something, would they have ever made such a thing.

_________________

@BigD

They could've should've a lot of things most not realistic with the constraints in place.

They did have AAA going and opening up Paula (and the CIA?)to double the floppy data rate was rather pointless as even in 92 floppies really shouldn't have been anything but install media.

Sure AIKIO was simple but also so slow that barely anything used it.
There might also be a good reason why they choose to not integrate into Alice was had already borderline timing.

If they had waaaaaay back decided to push the Ranger chipset and if they had designed that with chunky in mind, sure but in the AA timeframe just pointless.

_________________
- We don't need good ideas, we haven't run out on bad ones yet
- blame Canada

@Hypex: everything was already covered by my previous articles on this topic, included estimations about complexity & transistors count.

Specifically and limited to "just" adding a packed/chunky pixel mode, there's a single article about it: Beyond Akiko: grafica packed al minor costo usando i bitplane

This article is interesting because it shows how to add packed/chunky pixel yet using the bitplane pointerS (so, all 8), with very minimal changes to the display controller logic.

As a general argument about an Amiga (since OCS) with packed/chunky pixel, there's a very long series of articles. The last one is this: Amiga “packed� – 16: Endgame, which reports the list of all previous articles.

All of them are in Italian, unfortunately, but they can be easily translated with very good results using tools like DeepL.

@Hypex

Read "Commodore - The Final Years" by Brian Bagnall.

It shows the following items
1. Commodore's corporate politics.
2. Commodore f_ckups with names attached.

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

@Mobileconnect

Technical is easy. Corporate politics are harder.

For June 1991 and beyond,
1. Amiga group was under Jeff Frank's administration. This group includes Amiga chipset and Amiga systems R&D. Jeff Frank's administration canceled AA3000+ and AA1000+ with the backing from Bill Sydnes.

Jeff Frank argued for low-end ECS Amigas and mid-high PC clones product stack.

If you want to play texture-mapped 3D games, buy a Commodore's full 32-bit PC clone.

Mehdi Ali ordered pre-beta state AA for low-end Amiga in Feb 1992, hence overriding Jeff Frank's product stack argument.

Jeff Frank was from the failed Commodore PC group i.e. excess 386 inventory mistake before 486's 1989 release.



2. Akiko was under Jeff Porter's multimedia group administration. Due to limited R&D resources, Porter can only tinker around the edges. Commodore management supervises Jeff Porter's modifications.

Commodore management rejected Jeff Porter's 8 MB RAM-equipped CD32 specs.

AGA with packed pixels wouldn't address the Chip RAM only 68EC020 @ 14 Mhz (effectively operates like 7.1 Mhz 32 bit 68EC020).

Last edited by Hammer on 26-Nov-2024 at 04:37 AM.

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

@BigD

50 ns EDO has 20 Mhz equivalent. 68030 @ 50Mhz doesn't deliver 20 MIPS of fix point math power. You're wasting your money with the con job.

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

@BigD

Quote:

BigD wrote: An 030/50 board with EDO Ram and AGA ADoom modes ran Doom 1 just fine. They needed to bump CPUs across the AGA machines as well as including a multi button controller,

All Amigas can use a multibutton controller - just needed a standard protocol and driver to make it easier to integrate (or just publish the circuit diagram and example 'bare metal' code!).

As for the CPU, the A4000 already had a suitable one and the A1200 just needed an accelerator card (which companies like like GVP and Microbotics were happy to provide). However that would be much too expensive to put into the base model A1200.

While a 50MHz 030 with fast RAM does run Doom 1 'fine', it wasn't fast enough for John Carmack. Thus no Doom 1. Instead we got a variety of 3D games that ranged from abysmal to poor, because nobody had the talent and imagination to do something like Dread/Grind. By the time Doom came out in 1994 most of the real talent had already abandoned the Amiga, then Commodore went bankrupt before we had any chance of getting Doom before it went open-source in 1998.

Quote:

1.76MB full speed disk drive and upgraded 8 channel Paula! Chunky Pixel was a bridge too far for AGA!

HD floppy was planned for Paula but didn't make the cut. No big loss IMO.

Not sure about 8 channels. That would require significant changes that could be tricky to get right. They couldn't just add another 4 DACs because they wouldn't fit on the chip, so they would have to go for some kind of multiplexing or combining signals in the digital domain. I am not aware of anything being attempted in this department. Again, not a big deal. 4 channel MODs were the standard, and a faster CPU could mix in another couple of channels with low overhead. The extra ChipRAM in AGA meant that larger samples could often be used to get around the 4 channel limitation.

My preference would be for an OPL3 synth chip so PC music could be easily ported. This only requires an 8 bit I/O port - eg. the A1200's clockport with spare chip select. OPL 3 was introduced in 1990 and used smd chips, ideal for the A1200. Another possibility might be to make an addon card that plugged onto the clock port. Versions for older Amigas could also be produced.

With OPL3 and Paula you have the equivalent of two Sound Blaster cards (minus recording, which was already covered by parallel port samplers etc.). It surprises me that no contemporary OPL sound cards were made for the Amiga by 3rd parties. Perhaps the chips weren't so easy for amateurs to get, or perhaps we were happy enough with Paula's 4 channel PCM sound.

The other thing slated for Paula was a buffered serial port. This would have been useful for upcoming 'high speed' modems. However AGA already had an advantage there because a 16 color hires screen didn't block the CPU like OCS did.

Chunky pixels could easily have been added to AGA - perhaps not so easily in a 'system friendly' manner, but then we only 'needed' it for games so...

Last edited by bhabbott on 26-Nov-2024 at 05:51 AM.
Last edited by bhabbott on 26-Nov-2024 at 05:49 AM.

@bhabbott

A1200.

>While a 50MHz 030 with fast RAM does run Doom 1 'fine', it wasn't fast enough for >John Carmack. Thus no Doom 1. Instead we got a variety of 3D games that ranged >from abysmal to poor, because nobody had the talent and imagination to do >something like Dread/Grind. By the time Doom came out in 1994 most of the real >talent had already abandoned the Amiga, then Commodore went bankrupt before >we had any chance of getting Doom before it went open-source in 1998.

I think a big issue here was for many commercial pc games companies
support of a system ALWAYS mean “of unmodified system�. Even today
when negotiating licences for amiga port i hear
“That is impossible on amiga�. Of people who are
aware turbocards and gfxcards exist.

Sometimes the misunderstanding gets resolved that
they mean “unmodified a1200�. I have been in
need to explain that nobody uses an unmodified
A1200 today. They all have at minimum a 030 board.

Back then? This way of thinking was even more in
the heads of these companies…

@BigD

I had a similar setup and it played Doom ok but it didn't play at 35 FPS like it is supposed to be. Doom is not really suitable for the Amiga as it wrote graphics to the screen with CPU, where as the Amiga was past that and used hardware acceleration including sprites. A decade later the Doom VGA way would be primitive and the Amiga way of accelerating graphics would be the future with 3d chipsets.

However, chunky isn't just useful for games, but for practical use with the OS. Take Productivity mode and DblPAL. Productivity at least should have been a chunky mode since it implied VGA compatibility and be used for productivity. The Amiga Workbench was slowed down from bitplanes. Even a four colour A500 Workbench was slow.

@Mobileconnect

For converting video formats, fine. As part of a display controller support chip, Akiko is a terrible idea. Needing conversion hardware is already a red flag for going about it the wrong way. But the Akiko way incurs even more penalty, needing to write a 32 pixel block into the registers, then read it out and write it to chip ram. It couldn't even use DMA.

@cdimauro

I was expecting you would chime in and here you are.

I was reading a comment (on FB) about adding Akiko or some expansion to an A500. And then suddenly waned to post a thread about it. But I have had the BPLxDAT idea floating in my head for a while.

So your idea uses multiple planes. Similar to the VGA way of splitting bytes across planes. In fact it's almost alike to the idea I used in my packed planar research discussion, where I had tested placing an 8 pixel block of sequential bytes in each plane. The visual result or confusion is displayed in each 8x1 pixel block. I also think of CBM/C64/C16 bitmap format where it's character based bitmaps placed a linear block of 8 bytes downward so each 8 byte block represented an 8x8 pixel character space across the screen.

The Amiga had chip ram all in one place so the traditional reasons for needing to split pixel data across planes didn't apply. It just adopted the format. And even an Amiga with an interleaved bitmap can format it so the lines are all linear unlike some packed VGA formats. Your idea makes use of the planar design with max 8 planes. What complicates it is AGA since then pixel data can be read in 16, 32 or 64 bit groups. My idea to hook in behind the BPLxDAT logic and directly program it, still using internal DMA, was to simplify it with a wider plane and avoid complications like needing hybrid byte planes.

It's been years but in the mid 90's sometime I recall some discussion or comment about planar and packed from a game developer. You would find this amusing and may recall if you read it. He made a comment that planar was the best of all as it provided the best of all worlds somehow. This guy also commented how he was making all these platform games that never came out. I don't quite remember but it may have been the Alien F1 guy or around that time.

Fox tends to translate only one article with Google beta. Why it's still beta I've no idea. But Chrome worked better so will Chrome it rest of the way.

@Hypex

Quote:

... packed pixel modes ... I avoid terms like chunky because it's such a PC term.

Packed pixel? That where IMHO the modes used in EGA/CGA where one byte had the color information for 2 Pixels (usually 4 bit deep) that GFX mode didn't made much sense to me.

From the Video DMA it should be even better if I read one byte after another for a 8-Bit color mode, instead of reading 8 Bytes on different addresses, but those burst read cycles where not used on the Amiga and it wasn't even very useful to have them if you have the CPU on the same address range, doing its own read write accesses.

If you ask me a chunky 8-bit GFX would have been possible, it may have needed more wiring in the custom chips but r/w speed video DMA and palette registers where available.

The Blitter wouldn't had made much sense, for such a GFX because it was tuned for planar GFX.

There where expansions like the Grafitti, that made it possible to have a chunky GFX in the Amiga, they where popular with Shapeshifter for faster GFX on the Apple emulation.
https://bigbookofamigahardware.com/bboah/product.aspx?id=498

So here a short overview.
1. (simple 8-Bit chunky)
Yes chunky as 8-Bit mode would have been possible, maybe it would have made the wiring more complex.

2. (better 8-Bit chunky)
For a really great chunky support the Blitter would have needed chunky support on the line modes

3. (perfect 8-Bit chunky, higher CPU speed better resolution )
To get all benefits from chunky mode you would have needed a total overhaul of the custom chips, but you would have got a 8 bit GFX without slowing down the CPU.

Last edited by OneTimer1 on 26-Nov-2024 at 06:25 PM.

@bhabbott

Quote:

All Amigas can use a multibutton controller - just needed a standard protocol and driver to make it easier to integrate (or just publish the circuit diagram and example 'bare metal' code!). As for the CPU, the A4000 already had a suitable one and the A1200 just needed an accelerator card (which companies like like GVP and Microbotics were happy to provide). However that would be much too expensive to put into the base model A1200. While a 50MHz 030 with fast RAM does run Doom 1 'fine', it wasn't fast enough for John Carmack. Thus no Doom 1. Instead we got a variety of 3D games that ranged from abysmal to poor, because nobody had the talent and imagination to do something like Dread/Grind. By the time Doom came out in 1994 most of the real talent had already abandoned the Amiga, then Commodore went bankrupt before we had any chance of getting Doom before it went open-source in 1998.

1. Doom was released on December 10, 1993.

2. Doom previews have appeared in PC magazines since May 1993, hence building the hype.

3. In 1994, the PC's Doom was reverse-engineered on the Amiga and released on SNES with Super FX2 in 1995. Nintendo supported this project.

In 1989, six years into his programming activities, Randal Linden created a version of Dragon's Lair for the Amiga.

In 1988, Linden created a Commodore 64 emulator for the Amiga, which was named "The 64 Emulator.

This emulator, co-written with David Foster and published by ReadySoft, might have been the first of its kind to be commercially available. Focusing on accuracy rather than speed, the emulator utilized interpretative emulation techniques. The emulator's design, which included support for connecting Commodore 1541, Commodore 1571 and Commodore 1581 floppy disk drives to an Amiga via a specially designed parallel port cable,[1][3][4] enabled it to faithfully recreate the Commodore 64 system environment, facilitating the accurate execution of Commodore 64 software on the Amiga. Notably, the retail units of said parallel port cable were hand-assembled by enthusiasts in a Toronto basement.[1] Later on, a successor of the emulator was released under the title "The 64 Emulator 2."

Linden went on to develop the Amiga version of "Dragon's Lair: Escape from Singe's Castle,"[2][12] published by Bethesda Softworks in 1990.


Linden joined Sculptured Software in 1994 as a Super NES video game developer, later shifting his focus to development tools. During this period, Linden attended a conference aimed at Nintendo developers, where he was introduced to Argonaut Games' "Super FX" co-processor and witnessed its potential through a demonstration of "Star Fox," a title that utilized the chip. Linden's employer at the time, Sculptured Software, itself impressed by the chip's capabilities, decided to develop its own Super FX-based video game. The title was named "Dirt Trax FX," with John Morgan serving as its programmer.


Nintendo's bundled SuperFX2 for the SNES Doom port has reduced 3rd party development risk.

AGA install base with 1993-1994 CPU acceleration potential greater than 40 Mhz 030
44,000 (the UK has 30,000 during its launch),
100,000 (AF50, Sep 1993),
170,000 (AF56, Feb 1994),
3,800 (Germany's A4000/040),
Total 317,800 units.

What are the attached rates for 030 @ 40 Mhz or greater CPU accelerator for A1200?
There's a higher investment risk, if you can't answer this question.

GVP was liquidated in July 1995.

Many 030 @ 50Mhz accelerators for A1200 were released in 1994, they didn't exist or were too late during Doom's development.

https://amiga.resource.cx/dir/a1200proc

https://amiga.resource.cx/exp/blizzard1230mk1
Phase 5's 68EC030 @ 40Mhz accelerator for A1200 from about H2 1993.


https://amiga.resource.cx/exp/derringer1250
Derringer 1250 68030 @ 40Mhz accelerator for A1200 existed from about July 1993.


https://amiga.resource.cx/exp/gvp1230mk1
Great Valley Products' 68EC030 @ 40Mhz accelerator for A1200 existed from around March 1993.

John Carmark's 1994 statement on the C2P issue was a repeated remark from Commodore's CD32 team.


https://bigbookofamigahardware.com/bboah/product.aspx?id=1604

The “chunky to planar� logic was thought out in a lunchtime conversation between Beth Richard (system chip design), Chris Coley (board design), and Ken Dyke (software) over Subway sandwiches on a picnic table in a nearby park one day, because Ken was telling us how much of a pain it was to shuffle bits in software to port games from other platforms to the Amiga planar system. We took the idea to Hedley Davis, who was the system chip team manager and lead engineer on Akiko and he said we could go ahead with it. I showed him the “napkin sketch� of how I thought the logic would work and was planning on getting to it the next day as it was already late afternoon by that point. I came in the next morning and Hedley had completed it already, just from the sketch!



https://en.wikipedia.org/wiki/Alien_Breed_3D
According to Martyn Brown, by February 1996, the game sold 11,000–12,000 copies, with 15 percent being for the CD32

Last edited by Hammer on 26-Nov-2024 at 09:28 PM.
Last edited by Hammer on 26-Nov-2024 at 09:26 PM.
Last edited by Hammer on 26-Nov-2024 at 08:56 PM.
Last edited by Hammer on 26-Nov-2024 at 08:52 PM.
Last edited by Hammer on 26-Nov-2024 at 08:49 PM.

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

@Hypex

Quote:

Hypex wrote: @cdimauro I was expecting you would chime in and here you are.

You got my attention because it's an argument that I'm particularly loving and for which I've spent a incredible amount of my (little) time.
Quote:

I was reading a comment (on FB) about adding Akiko or some expansion to an A500. And then suddenly waned to post a thread about it. But I have had the BPLxDAT idea floating in my head for a while. So your idea uses multiple planes. Similar to the VGA way of splitting bytes across planes.

Similar only at a very high level. My idea was split AND group bytes across planes, which is quite different from VGA's chained mode.
Quote:

In fact it's almost alike to the idea I used in my packed planar research discussion, where I had tested placing an 8 pixel block of sequential bytes in each plane.

This matches my model with 64-bit data bus size.
Quote:

The Amiga had chip ram all in one place so the traditional reasons for needing to split pixel data across planes didn't apply. It just adopted the format. And even an Amiga with an interleaved bitmap can format it so the lines are all linear unlike some packed VGA formats.

Amiga interleaved bitmaps are homogenous from a line perspective, but they are still far from being efficient, compared to the packed VGA formats.
Quote:

Your idea makes use of the planar design with max 8 planes. What complicates it is AGA since then pixel data can be read in 16, 32 or 64 bit groups.

It's not complicated: it just takes full use of whatever the data bus size is. Exactly like AGA works with the new 32 and 64 bit fetch modes.

I'm "just" (!) using the same chipset logic which AGA implemented, with the (notable) difference of use the fetched data in a different way. But everything works as usual, from an Amiga chipset perspective.
Quote:

My idea to hook in behind the BPLxDAT logic and directly program it, still using internal DMA, was to simplify it with a wider plane and avoid complications like needing hybrid byte planes.

As I've said, my idea isn't complicated: it's the most simple (and effective and efficient) way to introduce packed graphics on a system which is completely planar.

There are only three simple things to be changed.
First, you don't need to extract & combine the data acquired from each bitplane to form the index to the CLUT: you just mask off the 8 bits that you need, and that's it.
Second (and after the above), you have to shift the BPL1DAT by 8 instead of 1.
Third, once BPL1DAT is empy, the next DAT register should provide the new set of data.
Quote:

It's been years but in the mid 90's sometime I recall some discussion or comment about planar and packed from a game developer. You would find this amusing and may recall if you read it. He made a comment that planar was the best of all as it provided the best of all worlds somehow. This guy also commented how he was making all these platform games that never came out. I don't quite remember but it may have been the Alien F1 guy or around that time.

I don't know who was that guy, but being honest I don't even care, because he has written a big load of b@alls.

In fact, I've mathematically proved on my articles that packed graphics is almost always better (takes less space. Takes less bandwidth. It's easier to handle) compared to the planar graphics.

And here I'm talking about any pixel depth: not only power of twos. With power of twos it's ALWAYS better and much, much, much more efficient.
Quote:

Fox tends to translate only one article with Google beta. Why it's still beta I've no idea. But Chrome worked better so will Chrome it rest of the way.

Go to deepl.com, register, and take the advantage of translating up to 5000 characters with the best translator around ('til now).

@OneTimer1

Quote:

OneTimer1 wrote: @Hypex Quote: ... packed pixel modes ... I avoid terms like chunky because it's such a PC term. Packed pixel? That where IMHO the modes used in EGA/CGA where one byte had the color information for 2 Pixels (usually 4 bit deep)

The haven't such format. EGA used 4 bitplanes, like the Amiga, to display graphics with 4 bits depth.
Quote:

that GFX mode didn't made much sense to me.

It has most sense, instead: it's way better than having the graphics spread over 4 planes.
Quote:

If you ask me a chunky 8-bit GFX would have been possible, it may have needed more wiring in the custom chips but r/w speed video DMA and palette registers where available.

In fact, it's very easy to implement it.
Quote:

The Blitter wouldn't had made much sense, for such a GFX because it was tuned for planar GFX.

In reality the Blitter was implemented as a 16-bit / word processor.
Quote:

There where expansions like the Grafitti, that made it possible to have a chunky GFX in the Amiga, they where popular with Shapeshifter for faster GFX on the Apple emulation. https://bigbookofamigahardware.com/bboah/product.aspx?id=498 So here a short overview. 1. (simple 8-Bit chunky) Yes chunky as 8-Bit mode would have been possible, maybe it would have made the wiring more complex.

No, it's very simple: see above.
Quote:

2. (better 8-Bit chunky) For a really great chunky support the Blitter would have needed chunky support on the line modes

As I've written in my articles (also the last ones about what could have been possible), Blitter's line mode almost supports packed graphics, and requires a bunch of very very very simple changes to fully achieve it.
Quote:

3. (perfect 8-Bit chunky, higher CPU speed better resolution ) To get all benefits from chunky mode you would have needed a total overhaul of the custom chips, but you would have got a 8 bit GFX without slowing down the CPU.

No, you don't. My articles have already shown how to implement it at a very little cost.

@OneTimer1

Quote:

Packed pixel? That where IMHO the modes used in EGA/CGA where one byte had the color information for 2 Pixels (usually 4 bit deep) that GFX mode didn't made much sense to me.

In 1987, Commodore engineers dismissed IBM VGA as slow and didn't factor in the fast VGA/SVGA clones.

IBM VGA is slow, but it sets the standard for faster VGA clones.

ET4000AX was released in 1989.

ATI Mach 8 was released in 1990. Graphics Vantage has FP DRAM and Graphics Ultra has VRAM.

Diamond Speedstar 24X (WD90C32) was released in 1992.

Trident 8900CL was released in 1992.

Jeff Porter was impressed with Wing Commander's CES 1990 demo at the same time Jeff Port was promoting C65 with 3rd party developers. CSG group's C65 has 256 colors and 2 microns fabs ahead of the Amiga's older 5-micron fabs and ECS.

Blame Jeff Porter for "8 bitplanes with 16 million colors" argument during 1987-1988. After June 1991 and without control over Amiga chipset R&D, Jeff Porter can only allow hardware patches like Akiko C2P for AGA.

Jeff Frank was the project manager for A1200 and A600. Jeff Frank governed the Amiga group from June 20, 1991. Jeff Frank governed the money-losing Commodore PC group.

Jeff Porter was the project manager for CD32 under the multimedia group.

The development of the AA+ wish list was delayed.

Commodore - The Final Years book includes information on Jeff Frank's repeated mistakes.

Last edited by Hammer on 27-Nov-2024 at 12:41 AM.
Last edited by Hammer on 27-Nov-2024 at 12:39 AM.
Last edited by Hammer on 27-Nov-2024 at 12:39 AM.
Last edited by Hammer on 26-Nov-2024 at 10:08 PM.
Last edited by Hammer on 26-Nov-2024 at 10:05 PM.

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

@bhabbott

Quote:

HD floppy was planned for Paula but didn't make the cut. No big loss IMO.

Should have been there already. But it needed two changes. First was to change from Shugart bus, to PC floppy bus, which is trivial since PC floppies had taken over and would be cheaper to source. The second was Paula and the CIAs could work at double speed. Both were needed really so Commodore could simply drop a standard floppy in without needing to hack it.

Quote:

Not sure about 8 channels. That would require significant changes that could be tricky to get right. They couldn't just add another 4 DACs because they wouldn't fit on the chip, so they would have to go for some kind of multiplexing or combining signals in the digital domain. I am not aware of anything being attempted in this department. Again, not a big deal. 4 channel MODs were the standard, and a faster CPU could mix in another couple of channels with low overhead. The extra ChipRAM in AGA meant that larger samples could often be used to get around the 4 channel limitation.

That raises a good point about the DACs. The expectation is not only double channels but double width at 16 bits as well and dynamic balancing would be nice. However, there is the digital side of Paula and then the analogue side. Lots of people like the "Paula crunch" sound which was a side effect of PCM implementation. Each channel needs an independent period and volume. A possible extension would be to double channels, similar to the audio attach feature of one channel modifying another, where each channel has a twin which shares same period and volume but different samples. This would allow more static drum tracks that don't need melody but restrict instruments needing melody. Another possibility is to reduce hardware to a stereo DAC or just one DAC per speaker, then increase channels by doing all mixing in digital, and finally sending it to DAC.

Quote:

My preference would be for an OPL3 synth chip so PC music could be easily ported.

They were planning a DSP so I suppose a synth chip isn't far off. But the original PCM design was obviously for simplification. Where as almost everyone else was putting in complex synths and samples were a side effect or side feature if supported, the Amiga design simplified all this by just offering straight PCM. It was obviously a best type of compromise, as it lacked all the complex synth features and multiple channels, but offered real sounds to get the job done. With only limited AM and FM options rarely used. And at the end of the day a real sound offered the most with least complexity it looks.

@OneTimer1

Quote:

Packed pixel? That where IMHO the modes used in EGA/CGA where one byte had the color information for 2 Pixels (usually 4 bit deep) that GFX mode didn't made much sense to me.

Yes. In CGA in was 2-bit packed. So 2-bit chunky. For some reason they changed this in EGA and went planar. So EGA is planar like Amiga. But, like all PC video cards, it's designed around RGB. So there was a plane for red, green, blue and intensity. VGA went back to chunky but also built on the idea as it has byte planes but linear mode was more common.

At 8-bit it's obvious that using a direct byte is practical. But under that in bits like or 2 or 4 it needs to be split. At this point, regardless of using 2-bit packed or 4-bit planar, pixels still have to be split. For packed the whole pixel bits have to be shifted and masked into bytes before writing. For planar the split pixel bits have to be written to all planes.

Quote:

From the Video DMA it should be even better if I read one byte after another for a 8-Bit color mode, instead of reading 8 Bytes on different addresses, but those burst read cycles where not used on the Amiga and it wasn't even very useful to have them if you have the CPU on the same address range, doing its own read write accesses.

Well for the A500 it did read in 16 bits or two bytes at once per plane. On AGA it had 32-bit and 64-bit fetch modes. This could have been used as a direct colour index as per my idea.

Quote:

The Blitter wouldn't had made much sense, for such a GFX because it was tuned for planar GFX.

Depending on packed format the same blitter logic could be used for both packed and planar. It would rely on a linear pixel buffer. The bliiter would just need to process wider width since packed pixels are wide by comparison. Would be useful for the Workbench. But games designed to redraw screen would likely not need blitter as much.

Quote:

There where expansions like the Grafitti, that made it possible to have a chunky GFX in the Amiga, they where popular with Shapeshifter for faster GFX on the Apple emulation.

It works by using a graysscale palette and hires. So that the confused planar output of the packed pixels can be decoded easily. With a customised palette.

A similar idea is implemented by modern AGA chunky modes. Where a super hires mode is used which provides 4x pixels per 1x low res pixel. The quadruple pixel is then palette mapped so when a chunky value is written in the planar effect looks like the chunky pixels.