PACKED ZORRAM

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

@Karlos

Phase 5's PPC accelerator cards are not cost-effective and most Amiga 68K games don't work with Phase 5's PPC co-processor method and Hyperion's AmigaOS 4.x's transparent 68K emulator is only for "friendly" 68K Amiga software.


Both Genesi (with Phase 5/DCE/bPlan) and Hyperion (with Eyetech/ACube/A-Eon) followed Apple's OS-level legacy support method.


Many Amiga users didn't shift to the PowerPC direction and remained with 68K e.g. Hyperion's recent revenues are mostly from 68K AmigaOS 3.1.4/3.2.x sales.


Apollo-core's AC68080 attempted to be "AMD" for the 68K family and it was distracted from accelerating the 68K mission. Apollo-core attempted to fork with their own AmigaOS clone via customized AROS, AMMX extensions and compromised FPU. Another Genesi (with Phase 5/DCE/bPlan) wannabe. AMD didn't compromise the X87 FPU instruction set.


PiStorm+Pi3a (or Pi Zero 2W) method followed AMD K5 (with Am29K RISC-like core)/Transmeta Code Morph/NVIDIA Project Denver below the OS level methods. This method enables unfriendly 68K Amiga software to be transparently CPU accelerated.


For Doom and Quake-type games with sufficient CPU power, Commodore's 16-bit/32-bit AGA with 32-bit Chip RAM is superior when compared to IBM's original VGA.

AGA is sufficient for PC's Doom and Quake era games when coupled with sufficient CPU power. AGA is full motion video capable.

Last edited by Hammer on 04-Aug-2022 at 04:59 AM.

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

@Trekiej

Quote:

Trekiej wrote: @Karlos It looks like the Amiga does a Chunky to Planar to Chunky conversion. The magic happens in the Planar portion, I believe. I appears to me that an Engineer would use Chunky these days. It looks to be straight forward, faster, and simpler.

If you were designing a circuit using standard TTL chips etc. (not HDL) I think bitplanes would be easier. For a 2 color bitmap the circuitry is the same - fetch a word and shift it out 1 bit at a time to create the video. For 4 colors just duplicate the circuit and feed the separate bitstreams into a DAC (possibly through a CLUT) for analog, or straight out the video connector for digital. 8 colors, 16, 32 all are the same, just with more DMA channels and shift registers. You could produce a board with 1 bitplane, then for more colors simply wire more boards in parallel. 3 boards would give you 8 color RGB, the minimum for a 'true' color display.

The chunky method traditionally involved a 1 bitplane screen whose output bits were then combined in pairs or quads to produce more colors but at lower resolution. So if the data is fetched 8 bits at a time you could have 8 pixels per word in 2 colors, or 4 pixels in 4 colors, 2 pixels in 16 colors or 1 pixel in 256 colors. But the resolution would reduce accordingly, from eg. 640 to 320 to 160 to 80 256 color pixels per line. But that didn't work with pixel groupings that didn't pack into a single word, so you couldn't have 8, 32, 64 or 128 colors without wasting bits, and so couldn't take advantage of the potential memory savings.

On the software side you have a similar issue. Converting between different resolutions and packing pixels into words might not be a problem for modern systems, but what if you were designing the original Amiga today, with all the same constraints? Originally it was to have an 8 bit CPU and 128k RAM. Fortunately that was changed to a 68000 and 256k, but the 16 bit CPU and sophisticated GUI used more RAM. So you would want your fonts and other imagery to take up minimum space in single bitplanes, and be rendered without having to repack them for different color depths. With multitasking in limited RAM you also want to be able to use memory chunks that are not contiguous. Smaller individual bitplanes can be squeezed into spaces that a full chunky bitmap wouldn't fit.

If the Amiga used packed pixels you can bet that it wouldn't have had a 32 color mode. The next step up of 256 colors would be too expensive or too lo-res, so it would be stuck with 16 colors max like the ST, EGA, and numerous other home computers. With only 16 colors it probably wouldn't have been worth having a 4096 color palette either. Then we wouldn't have gotten those groundbreaking titles like Defender of the Crown and Deluxe Paint that showed off those extra colors. Plus we wouldn't have dual playfields, and games and demos wouldn't be able to use as many tricks to wow us. So instead of being amazing the Amiga would be meh.

In 1982-84 when the Amiga was designed, 256 colors with 1 pixel per byte was considered an extravagance. A single 320x200 screen would have taken up half the RAM, leaving precious little for anything else (forget about double buffering!). Most computers of the time used 16k or less, trading resolution for colors and/or using tiling and attribute colors to save memory and reduce CPU load. The Amiga dropped all of that for the simplicity of multiple bitplanes.

Last edited by bhabbott on 04-Aug-2022 at 09:34 AM.
Last edited by bhabbott on 04-Aug-2022 at 09:33 AM.

@bhabbott

Quote:

A single 320x200 screen would have taken up half the RAM, leaving precious little for anything else

Well, 64000 bytes. Exactly the same memory as 16 colour hires (640x200) planar needs.

Quote:

If the Amiga used packed pixels you can bet that it wouldn't have had a 32 color mode.

We'll never know given that it never happened. I have to concede it doesn't seem likely but it's not impossible they could've implemented non-power of two sized packed pixels in the manner described in this thread (or the one it came from). It all comes down to whole row alignment to make it work sensibly.

The point of this thread is to understand with the benefit of hindsight whether or not the display hardware, with all its cool quirkiness could've been implemented using something different. Not to say the original chipset designs were wrong, they were a product of their time.

I'm sure that as AGA was being designed the performance issues with planar pixels would've become more and more obvious. Try doing some productivity work in any kind of hires 256 colour mode, especially at 640x400 or 640x512 resolution. It's telling that initial thoughts on the native chipset compatibility in later designs tended to stop at ECS.

I remember my first encounter with a Picasso IV equipped machine, using a 256 colour workbench at 1024*768 and marvelling how smooth it all was, even before messing with RGB modes.

If there was a missed opportunity, it was probably AGA. It could've kept the ECS compatible modes up to 6 bitplanes and just added chunky 8 bit and maybe a nybble packed 4 bit too. Things like HAM8 would still be achievable, nothing about the format was dependent on planar.

Last edited by Karlos on 04-Aug-2022 at 11:07 AM.

_________________
Doing stupid things for fun...

@Karlos

Quote:

Karlos wrote: If there was a missed opportunity, it was probably AGA. It could've kept the ECS compatible modes up to 6 bitplanes and just added chunky 8 bit and maybe a nybble packed 4 bit too. Things like HAM8 would still be achievable, nothing about the format was dependent on planar.

Was there even such an opportunity?

Noone at C= fully understood OCS and that why they "just" added some more planes and upped the speed to match.

Even with full understanding and a budget to develop a proper chunky mode most of the internal logic would have be so different that it would have been like a 2nd chipset.

Those chips would have been bigger and rather costly not fitting into the planned pricing for the A1200/CD32Bit.

At that point (1992) it would have been much better to focus on an official RTG solution, chip the A4000 with both AGA and a VGA chip and make it clear that whatever would have come after AGA would NOT be backward compatible at HW and lower SW level.

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

What good’n cheap packed pixel VGA chips were available in 1993?

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@kolla

Quote:

kolla wrote: What good’n cheap packed pixel VGA chips were available in 1993?

Dunno, plenty of decent VGA at that time, early 3D only a year or two out ...

If you are replying to my "idea", the A4000 wasn't cheap so the extra cost for something like an ET4000 just for high res (for real) 8Bit (and even 16Bit) wouldn't have been an issue.

Same for a potential A1200 successor in 1994 or 95.


IMO the real question never was planar vs. chunky, that question had been answered when 8Bit became feasible, the real question was shared memory or dedicated VRAM.

OCS(ECS/AGA) only made sense when paired with the "always 1 or more waitstate" 68000, once you move to the 68020 it killed CPU performance.
Pretty sure an A1200 with 1MB proper FastRAM and a 0.5 or 1MB VGA with some brains (like the ET4000) would have stomped all over the A1200 we got in all productivity and even most of the hard coded games without costing more.
Problem is that would have killed most SW compatibility even with AmigaOS itself and there just weren't the resources nor the will to do such a cold cut in the later C= years.

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

@Karlos

I guess you might done packed format like this:

0,1,2,3 ref the bits.

0000 0000 – 2 colors, 8 pixels per byte. (Just lilke planar)
1010 1010 – 4 colors, 4 pixels per byte. (just like std MacOS gfx)
3210 3210 – 16 colors, 2 pixels per byte. (just like std MacOS gfx)

then you do this, you take 2 images and put the images on top of etch other,
this gives you dual playfield or foreground background chunky image.

4bit+1bit = 5bit 32 colors, or 16 + 2 colors.
4bit+2bit = 6bit 64 colors, or 16 + 4 colors.
4bit+4bit = 8bit 256 colors, or 16 + 16 colors mode.

almost no masking needed, and two layers, so don’t need to restore background.
you get major memory saving, by being able to use 32,64 colors modes instead of 256 color mode. you won’t get the 8 colors or 128 colors mode, but pretty close, to all modes Amiga has. seting 5bit,6bit colors is bit complicated but not as complicated as 5/6 bitplanes modes, and you can do the cool transpareacny palette effects, without a sweet.

and then you have the normal 8bit / 256 colors chunky mode for 3D.

As pointed out HAM modes work on palette lookup table, and does effect how color index are stored in the image. I keep the Cooper as it can set start position of pixel clock, and can change width of data fetch, and place sprites and so on, like normal.

when display it, will work pretty well with a dual shift register, shift in image with highest number bits first, then sift in bit lowest bits, and or the result, into mixed color index, fetch rate will different for two images, but should not be a issue.

I guess this how chunky based Amiga chipset can be designed in the 80’s, instead of OCS / AGA. and then in alternative past 90’s they might have slapped on 15bit or 16bit, and 32bit true color graphics.

Last edited by NutsAboutAmiga on 04-Aug-2022 at 07:42 PM.
Last edited by NutsAboutAmiga on 04-Aug-2022 at 07:37 PM.
Last edited by NutsAboutAmiga on 04-Aug-2022 at 07:34 PM.
Last edited by NutsAboutAmiga on 04-Aug-2022 at 07:33 PM.
Last edited by NutsAboutAmiga on 04-Aug-2022 at 07:30 PM.
Last edited by NutsAboutAmiga on 04-Aug-2022 at 07:29 PM.
Last edited by NutsAboutAmiga on 04-Aug-2022 at 07:19 PM.
Last edited by NutsAboutAmiga on 04-Aug-2022 at 07:18 PM.
Last edited by NutsAboutAmiga on 04-Aug-2022 at 07:12 PM.
Last edited by NutsAboutAmiga on 04-Aug-2022 at 07:11 PM.
Last edited by NutsAboutAmiga on 04-Aug-2022 at 07:10 PM.
Last edited by NutsAboutAmiga on 04-Aug-2022 at 07:09 PM.
Last edited by NutsAboutAmiga on 04-Aug-2022 at 07:06 PM.

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

@Hammer

Quote:

AGA is sufficient for PC's Doom and Quake era games when coupled with sufficient CPU power. AGA is full motion video capable.

All AGA 3D demos, use 320x256 modes, and not higher 640x480 modes, only images in between the effects, you might see higher mode, but most often, its interlaced 320x512 ham mode or something like that, ham most likely look better in 640x256 mode, as reduce artifact and flicker.

640x480 modes need 4 x the CPU power compared to the 320x256 mode, to do the P2C convention. So when it comes 640x480 mode demos, they are all RTG/Chunky demos.

The elephant in the room is of cause the 0.5 MB / 2 MB of chip ram limit, need to use low resolution to save memory, or due to storage space, having to stick 880kb floppy disk. Its also true you get 3D on 320x256, but also lower refresh rate compared to VGA graphics, it does not really compare.

Last edited by NutsAboutAmiga on 04-Aug-2022 at 08:56 PM.
Last edited by NutsAboutAmiga on 04-Aug-2022 at 07:59 PM.
Last edited by NutsAboutAmiga on 04-Aug-2022 at 07:58 PM.
Last edited by NutsAboutAmiga on 04-Aug-2022 at 07:53 PM.

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

Karlos Quote:

If there was a missed opportunity, it was probably AGA. It could've kept the ECS compatible modes up to 6 bitplanes and just added chunky 8 bit and maybe a nybble packed 4 bit too. Things like HAM8 would still be achievable, nothing about the format was dependent on planar.

Kronos Quote:

Was there even such an opportunity? Noone at C= fully understood OCS and that why they "just" added some more planes and upped the speed to match.

Nobody at CBM understood OCS as well as Jay Miner but there were engineers which understood it enough to make changes. Jay Miner praised CBM for suggestions which made changing from YUV to RGB Denise output easier (Jay wanted RGB because he wanted a computer which CBM also wanted after the video game market crashed). I believe CBM did most of the Amiga custom chip engineering to add PAL support as well. I believe there is evidence CBM understood the Amiga chipset well enough to make changes when they believed the changes were in their best interest like converting to RGB and adding PAL support. Their vision was to cost reduce the Amiga into a C64 for the masses so they didn't want the custom chips to grow. Jay's vision was the Ranger chipset which could compete with the X68000, Mac II and later VGA cards which were using more expensive VRAM to double the memory bandwidth of the Amiga SoC. Jay's vision turned out to be correct when VRAM prices dropped to just 20% more than DRAM prices which was very much worth it for a 100% increase in memory bandwidth. The Amiga suffered from a lack of memory bandwidth which applied to the whole SoC as CBM not only used the cheapest and slowest chip memory DRAM but Amigas often lacked fast memory to offload CPU memory bandwidth requirements. The lack of memory bandwidth, especially for the Amiga chipset, was more of a problem than the choice of planar support over chunky graphics support. The lack of chipset memory bandwidth was apparent even with AGA which was perceived as being slow even with moderate chipset memory bandwidth improvements still using cheap DRAM. CBM using cheap 68k processors and often no fast memory also added to the handicap while even low AGA memory bandwidth was shown to be adequate to avoid a C2P bottleneck at lower gaming resolutions like 320x200x8. Later FPGA hardware using planar graphics doesn't feel sluggish even at higher resolutions supported by AGA as memory bandwidths are greatly increased. I believe CBM thought planar was adequate up to 8 bit planes as AA+ did not add an 8 bit semi-chunky CLUT mode but did add 16 bit true chunky modes. This not only shows that CBM was capable of adding non-planar Amiga chipset support but also believed 8 bit planar as delivered with AGA was competitive. Breaking the vision and mindset to cost reduce the Amiga 68000+ECS into a C64 died hard only as Amiga 1200 68020+AGA computer sales outperformed Amiga 600 sales which was too late.

Kronos Quote:

Even with full understanding and a budget to develop a proper chunky mode most of the internal logic would have be so different that it would have been like a 2nd chipset. Those chips would have been bigger and rather costly not fitting into the planned pricing for the A1200/CD32Bit. At that point (1992) it would have been much better to focus on an official RTG solution, chip the A4000 with both AGA and a VGA chip and make it clear that whatever would have come after AGA would NOT be backward compatible at HW and lower SW level.

I disagree. Chunky is relatively simple and cheap to add to the chipset. The AA+ chipset added 16 bit chunky, 16 bit sound, support for up to 8 MiB of chip memory (requires wider address lines internally) and other minor changes yet would fit in 2 chips with a total of 200,000 transistors (compared to ECS using 60,000 transistors in 3 chips, AGA Lisa using 80,000 transistors alone and AAA using 750,000 transistors in 4 chips). I expect AA+ with chunky would have been cheaper to produce than AGA and Amiga motherboards would have been smaller and cheaper to produce due to the lower chip count. A full move to CMOS could have lowered the cost of power supplies and fans. The cost of chunky in FPGA Amiga hardware today is cheap as even most small FPGA devices support it with RTG and in an ASIC the cost is insignificant. The Amiga chipset legacy blitter does not work with chunky and more CPU performance, memory and memory bandwidth is needed for 16 bit chunky in AA+ but that could have been easily remedied by CBM using higher performance CPUs provided they could change their vision (Lew Eggebrecht VP of Engineering at CBM who was developing AA+ seemed to have the necessary understanding but too many mistakes were made before and above him). Integrating the CPU and GPU has the potential to improve performance, power efficiency and cost as can be seen by the move back to it with SoCs today.

@Karlos , bhabbot

I guess I still trying to understand the versatility of the planar arrangement.

Chunking looks still straight forward to me and I am thing of a more modern machine that has more hardware to use.

I guess a Transputer is still above this design.

_________________
John 3:16

On the original Minimig, access to chipram is about 3 times faster than on real ECS Amiga systems. Likewise, AGA on MiST and especially MiSTer, access to chipram is a lot faster than on "real" Amiga, and it does make a difference. What I hoped for with SAGA wasn’t new chinky modes, but rather old planar AGA modes, only faster, scandoubled/flickerfree, and (optionally) with more chipram - the ultimate DeluxePaint workstation :)

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@kolla

THEA500 Mini AMiNIMiga distro (V200 beta) has been tweaked/DPV patched to work flawlessly now!

We just need an Amiberry 3.4 firmware update to add serial support and hence Graphics Tablet support and it would be unmatched!

Last edited by BigD on 05-Aug-2022 at 10:33 AM.

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

Trekiej Quote:

I guess I still trying to understand the versatility of the planar arrangement. Chunking looks still straight forward to me and I am thing of a more modern machine that has more hardware to use.

Karlos and bhabbot sum up planar vs chunky pretty well in post 83 and 84 of this thread. Chunky is easier for a human programmer but the hardware logic for planar is simple and consistent as the number of colors increases. The down side is that performance drops due to increased memory accesses as the number of colors increases. Chunky is most efficient when pixel accesses are always naturally aligned as misaligned pixels can be 2 memory accesses and requires extra shifting logic in hardware.

Chunky graphics with naturally aligned pixels
2^1=2 colors
2^2=4 colors
2^4=16 colors
2^8=256 colors (OCS/ECS bandwidth inadequate)

Planar Amiga graphics
2^1=2 colors
2^2=4 colors
2^3=8 colors
2^4=16 colors
2^5=32 colors
2^6=64 colors (HAM6, EHB)
2^7=128 colors (AGA bandwidth required)
2^8=256 colors (AGA bandwidth required)

Instead of a chunky Amiga only offering 2, 4 or 16 color graphic modes, the planar Amiga is more colorful and flexible/scalable with 2, 4, 8, 16, 32 and HAM6 modes. Increasing chip memory bandwidth was very expensive up until about 1987 when VRAM prices dropped allowing for double the memory bandwidth for only about a 20% increase in price and this would have made 256 color chunky possible in low resolution. CBM was focused on making the cheapest possible mass produced and standard Amiga to replace the C64 so offered no options for upgraded bandwidth. This wasn't a problem with early PC hardware where IDE and even EIDE buses restricted bandwidth more but when (S)VGA cards with VRAM and faster buses, Mac IIs with VRAM and the x68000 with VRAM started showing up with 256 color modes and higher resolutions then it was a problem starting in about 1987. AGA in 1992 increased the bandwidth in the cheapest possible way with some restrictions which reduced compatibility but by then high end PC graphics boards put AGA to shame even though the average PC card wasn't much better. Then DOOM came about 1994 and PC owners started realizing their cheap graphics cards were bottlenecks and started upgrading. Today, even a $10 FPGA has several times the memory bandwidth of even AGA and this changes the perspective of slow planar graphics. It was just a CBM cheapness bandwidth issue and now we can enjoy the flexibility of planar AGA with an insignificant performance reduction compared to chunky. Most FPGA devices are adding chunky RTG too as that is cheap enough in even a $10 FPGA. If only a 68k CPU in FPGA was as efficient as the Amiga chipset we would be set but CBM was so cheap on CPUs that a $10 FPGA outperforms most original Amigas while only offering a tiny fraction of ASIC performance.

@NutsAboutAmiga

Quote:

NutsAboutAmiga wrote: @Hammer Quote: AGA is sufficient for PC's Doom and Quake era games when coupled with sufficient CPU power. AGA is full motion video capable. All AGA 3D demos, use 320x256 modes, and not higher 640x480 modes, only images in between the effects, you might see higher mode, but most often, its interlaced 320x512 ham mode or something like that, ham most likely look better in 640x256 mode, as reduce artifact and flicker. 640x480 modes need 4 x the CPU power compared to the 320x256 mode, to do the P2C convention. So when it comes 640x480 mode demos, they are all RTG/Chunky demos. The elephant in the room is of cause the 0.5 MB / 2 MB of chip ram limit, need to use low resolution to save memory, or due to storage space, having to stick 880kb floppy disk. Its also true you get 3D on 320x256, but also lower refresh rate compared to VGA graphics, it does not really compare.

I have experience with IBM PS/2 Model 55SX's IBM VGA and it's garbage.

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

@matthey

Amiga 3000 wasted 32-bit Chip Ram (DRAM) with ECS.

PC ET4000AX ISA comes with either 16-bit VRAM or 32-bit DRAM.

Doom was released on December 10, 1993, but the game-related PC upgrade cycle has its started with 1990 Wing Commander.

John Carmack made big deal about the existing installed base that can run Doom.

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

@kolla


Quote:

What good’n cheap packed pixel VGA chips were available in 1993?

https://archive.org/details/bub_gb_hqQJaNzN9IcC/page/n603/mode/2up
PC Mag 1992-08, page 604 of 664,
Diamond Speedstar 24 (ET4000AX ISA) has $169

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

@Karlos

Quote:

Are you talking about 3D "effect", or actual texture mapped 3D?

Just a 3D effect. So not live rendering. Using pre built images.

The images may be 3d rendered but they would be pre-rended. So would just be frames of images like in traditional 2d games. In fact the display technique would be pretty much like a standard 2d game but using 3d animated frames.

A live demo has the burden of being expected to do live effects. But a game has more freedom to create a good effect with pre rendered graphics.

Also:
Quote:

I remember my first encounter with a Picasso IV equipped machine, using a 256 colour workbench at 1024*768 and marvelling how smooth it all was, even before messing with RGB modes.

Compared to even an AGA screen mode of 720x576x8 it is fast.

Quote:

If there was a missed opportunity, it was probably AGA. It could've kept the ECS compatible modes up to 6 bitplanes and just added chunky 8 bit and maybe a nybble packed 4 bit too. Things like HAM8 would still be achievable, nothing about the format was dependent on planar.

I think extending to 8 planes made sense and the chipset was designed to take 8 planes to the max. AGA did complicate it with extra fetch modes, bank switching 12 bit palette for 24-bit colour and extending sprites. By then these were needed, but did build a 32 bit chipset on a 16 bit design, which some what made updating the chipset more complex than a fresh design. However, we can read how they planned features like HAM chunky in AA+ as well as RGB planar. Planar did survive in formats like YUV planar. Bit planar became a relic like the Amiga bitplanes, but packed planar lived on.

Last edited by Hypex on 06-Aug-2022 at 04:41 AM.

@Kronos

Quote:

At that point (1992) it would have been much better to focus on an official RTG solution, chip the A4000 with both AGA and a VGA chip and make it clear that whatever would have come after AGA would NOT be backward compatible at HW and lower SW level

That's what you get with a A4000 when you add a graphics card!

In fact there was an official RTG solution. The Commodore Commodore A2410. Which could plug into an A2000 and A3000.

However, even though it's common in laptops today to feature dual graphic chipsets, adding VGA to Amiga would have complicated it and added to expense. We have to consider that VGA is a complex graphical device. It may lack sprites and other Amiga features but it is way complicated in other ways. Would have adding that complication been worth it? What did it provide that we needed? VGA offered 6-bit RGB and was also planar based. But pixel planar in VGA modes. Straight linear framebuffer modes had limitations and the "Doom" mode wasn't know about until later. Also, VGA wasn't the only chunky hardware around, other computers like Acorns and Apples featured chunky modes without needing any extra VGA chip.

It is also foreign so I imagine hard to integrate. Adding VGA to an Amiga tends to control the Amiga as Amiga modes get second classed. For a proper Amiga solution I think the Amiga would need to be in control of VGA so the copper could control VGA passthrough and allow screen dragging of RTG modes. No RTG solutions did this AFAIK. RTG screen dragging was emulated through legacy raster interrupts or blitting like on OS4.

If what we wanted from VGA was a straight out chunky mode I think we would have been better if it was just added to the chipset. At the end of the day, it reads data, combines it and feeds it into a DAC. We just needed modes that provided it with a direct CLUT index and could skip any serial/parallel conversion. Being able to read the data sequentially should have optimised the operation even if it needed alignment.

@NutsAboutAmiga

Quote:

4bit+4bit = 8bit 256 colors, or 16 + 16 colors mode. almost no masking needed, and two layers, so don’t need to restore background. you get major memory saving, by being able to use 32,64 colors modes instead of 256 color mode. you won’t get the 8 colors or 128 colors mode, but pretty close, to all modes Amiga has. seting 5bit,6bit colors is bit complicated but not as complicated as 5/6 bitplanes modes, and you can do the cool transpareacny palette effects, without a sweet.

I read somewhere they do dual playifield on chunky like this. So two 16 colour fields. The scrolling can't be independent since it's using one framebuffer. But the method was to load in one field using the upper nibbles then logical or on the other field into the lower nibble. For ease of processing the upper field would have all images in top nibble and lower field have all images in lower nibble. Then no masking needed. Unless it was adding sprite objects to a field. Of course the palette then has to be calculated so only max 32 colours appears in 256 colour mode.

Oscar has a PC port. Don't know if it does it this way. But it looks similar in videos.

Aside from that I would have imagined writing background layer, then overlaying foreground layer and sprites on top. Lots of writing and processing by hand so slightly wasteful. But would have less colour limits.

Last edited by Hypex on 06-Aug-2022 at 05:28 AM.