02 April 2021, 20:47 | #1 |
Banned
Join Date: Sep 2011
Location: Cardiff, UK
Age: 51
Posts: 2,871
|
Dedicated CHUNKY MODE on Amiga: How feasible is it?
By the early 1990s, bitplane computers like the Amiga were (or should've been) going the way of the dodo, and smooth scrolling in all its forms and varieties were being superceded by textured 3D graphics.
It's been said many times that the Amiga should've incorporated a dedicated chunky mode to accommodate this upcoming trend within AGA, or the AAA chipset, and for it to be at least 256 colours in 8-bits. What I'm wondering is, how much of a redesign would this have meant for the AAA equivalent of Denise, which was the chip that managed the bitplane display? I'm just guessing here, but I would imagine the following would have to occur: The sprites should be unaffected, and so should the Copper, but the Blitter would have to be totally redesigned, and so would HAM, if it were still to be implemented. And of course, there could no longer be as few as 1 bitplane up to as many as 8, as it would be strictly byte-per-pixel. However, the palette registers would, I imagine, also be unaffected, and overscan would also work as normal. A chunky mode was a necessity in 1994 or even 1993, because the Amiga's bitplane system would require as many as eight separate operations in screen memory to write to eight bitplanes, to change ONE pixel, which would (and did) slow down Amiga graphics to one-eighth of the speed of a 1-bitplane mode. Faster processors and direct writing (bypassing the Blitter) can yield some good results, but the fast speed was needed on the standard "stock" Amiga A1200, and it was already underpowered compared to 386 and 486 PCs as it was, and that's even before the separate bitplane writes I mentioned before. I've programmed on PC in chunky modes, and it really is very neat and easy and simple how each pixel can be plotted with 1 out of 256 colours with just one byte written to memory - no wonder programmers switched to PC as soon as they could. In fact, looking at fancy 3D pre-rendered animation scenes on Amiga, it makes me cringe how much extra work is required by the custom chips just to draw the graphics on screen, compared to the lighter workload the PC does. So what do you think? Be as technical as you like, how would the Amiga custom chip designs be modified to include a dedicated 8-bit chunky mode? |
02 April 2021, 20:55 | #2 |
Registered User
Join Date: Jul 2015
Location: The Netherlands
Posts: 3,411
|
I don't think the Blitter would need all that many changes to be honest, it makes no difference to it whether it's copying planar or chunky data - memory is memory. The real change would be the data you offer it
Of course, you could make a few small improvements to the Blitter to make your life a bit easier, but it shouldn't really be all that necessary. |
02 April 2021, 21:03 | #3 |
Amiga user
Join Date: Nov 2008
Location: Sofia / Bulgaria
Posts: 459
|
There are some fake chunky modes for AGA amigas, which just use the copper http://aminet.net/package/dev/misc/chopper
These modes were used in Amiga games - Ambermoon used hybrid chunky mode for the floor/ceilings. Also check this thread - http://eab.abime.net/showthread.php?t=88990 |
02 April 2021, 21:54 | #4 | |
Registered User
Join Date: Jun 2020
Location: Brno
Posts: 90
|
Quote:
I'm looking forward to read some elaborate analysis what that AAA blitter would be like. P.S.: I think that bitplane graphics was not necessary already in late 80s, and definitely not in 90/91 as memory was getting cheaper and larger. I don't think 64kB per screen was such an issue for 1MB chip-RAM ECS machines. It's sad that ECS/AGA Amiga didn't have support for chunky graphics at least for low-res pixels. P.P.S.: Atari fans got chunky mode in 1993 in Falcon. Too late as well ;-) Last edited by defor; 02 April 2021 at 22:12. |
|
02 April 2021, 22:02 | #5 |
Zone Friend
Join Date: Apr 2006
Location: Gothenburg/Sweden
Age: 48
Posts: 339
|
I was hyped for chunky pixels back in the day.. But now, I'd probably have prefered tile-based screenmodes (a'la NES/SNES).
|
02 April 2021, 22:21 | #6 |
Banned
Join Date: Sep 2011
Location: Cardiff, UK
Age: 51
Posts: 2,871
|
I clean forgot about c2p routines when I started this thread, but then I was thinking of "what if" scenarios.
But if we're forced to use c2p routines, for any given specification of Amiga, how many frames per second do we lose if we use a c2p routine? |
02 April 2021, 22:27 | #7 |
Registered User
Join Date: Jul 2015
Location: The Netherlands
Posts: 3,411
|
It'd depend a bit on the CPU used. But in most cases (not counting 68060/vampire/etc), c2p has an upper limit of around 25FPS.
|
02 April 2021, 22:34 | #8 | |
Registered User
Join Date: Jun 2020
Location: Brno
Posts: 90
|
Quote:
For example, see this discussion. |
|
02 April 2021, 22:42 | #9 |
Registered User
Join Date: Jul 2017
Location: San Jose
Posts: 653
|
You lose in the ballpark of 11-20ms per frame, which is a whole frame worth of time and added latency.
I imagine that the needed changes for Denise would actually be small-ish. What we have in AGA is a regime fetching of up to 64 bit of data from up to 8 pointers in memory. Then the hardware does essentially a planar-to-chunky operation to determine the palette entries to be fetched from for each pixel. If this part would be instead changed to interpret each fetched byte directly as palette entry, then we’d have a chunky screen. A 4bit chunky screen would probably also be possible this way. |
02 April 2021, 23:51 | #10 |
Registered User
Join Date: Feb 2015
Location: Sweden
Age: 50
Posts: 2,953
|
@foebane You probably heard about SAGA and its chunky modes without breaking compatibility with legacy stuff (Apollo core / Vampire).
For a deep technical dive you could probably ask this guy ;-) http://www.apollo-core.com/knowledge.php?b=4¬e=369 |
03 April 2021, 00:13 | #11 | |
Registered User
Join Date: Jul 2015
Location: The Netherlands
Posts: 3,411
|
Quote:
So the barrel shifter then shifts between 0-1 pixels rather than 0-15 (which allows pixel by pixel addressing and in an easier way than currently as you only need to choose between odd/even). Minterms can mostly stay the same, though you can then use A+B+D blits rather than A+B+C+D blits to achieve transparancy, etc. However, I didn't consider line/fill mode - those would indeed need some changes (or need multiple calls in a row to function). Then again, fill mode might still be possible if you can combine it with a mask (which I don't know) and I'm not that certain how many things really used line mode (apart from intuition which I'd guess does use it). |
|
03 April 2021, 00:48 | #12 | ||
Registered User
Join Date: Mar 2018
Location: Hastings, New Zealand
Posts: 2,584
|
Quote:
Quote:
Another option would be to have a completely separate frame buffer and converter (like Akiko but full screen instead of only 32 bytes) that acts as a bridge between the CPU and ChipRAM busses. On the CPU side you would have fast chunky access, while the ChipRAM side would be read as bitplanes through the normal video DMA. This could be compatible with sprites, copper lists etc., as it would look like normal bitplanes to the custom chips. Finally there is the solution that could have been applied to any Amiga 'back in the day' - a card which produces a dedicated 320x200 chunky display whose output is combined with the Amiga's RGB video output. It could be switched in via a transparent color like a genlock does, allowing overly of sprites etc., and even take part in screen dragging. Of course the blitter can't touch it, but you don't need it because you will be doing all rendering via the CPU. A 320x200 8-bit frame buffer only needs 64kB. 128kB would give you double buffering, and is still a piddling amount of RAM. The controller could easily be implemented in a medium scale CPLD, which would probably be much easier than trying to redesign the AGA chipset to do it. In effect you would be integrating an RTG card which only has one screen mode. Next step after that is hardware texture-mapped 3D - imagine the Amiga with PlayStation graphics! Last edited by Bruce Abbott; 03 April 2021 at 00:54. |
||
03 April 2021, 04:06 | #13 |
Registered User
Join Date: Sep 2006
Location: New Sandusky
Posts: 942
|
Already explained this in another thread, but the whole chunky pixels issue was a bit of a red herring. Yeah c2p did slow things down, but the biggest problem was that chipmem is just plain slow. Converting to planar was only a problem for less CPU-intensive games like Wolf3D where the framerate could've potentially been very high on a slow CPU.
With Doom, you were not gonna get a playable framerate fullescreen on the 14Mhz 68020, even with a graphics card with chunky pixels. You needed a faster CPU. That CPU could then do fast c2p in fastmem, with the conversion being relatively less intensive compared to creating the image in the first place. The problem is that the CPU is stuck waiting half the time just copying the image into chipmem. AGA (and especially OCS) was never designed to have CPU-driven video. The idea was always to preload graphics into chip memory and then display them, with motion coming from sprites or small blitter objects, and scrolling around the playfield in memory. AGA is barely fast enough to do reasonable fullscreen video, but that's only if the CPU is doing not very much beyond copying into chipmem, leaving much fewer cycles for executing game code. This could have been fixed with some sort of fast writeback buffer on the bridge to the chipmem bus, but this was not implemented. Most of AGA was unchanged from ECS and still had its limitations. Consequently on a fast CPU you get stuck with tons of wait cycles just waiting for the copy to finish. The reason CPU-driven games performed much better on graphics cards was because it bypassed the chipmem bus. The faster the CPU, the more apparent it becomes. That's why even with an 040 Doom still sucks on an A2000 with a chunky graphics card -- Zorro 2 slows it down even worse than doing c2p to A3000-ECS/AGA chipmem. If you have a Zorro 2 graphics card in an A3000 or A4000, Doom will run faster using ECS/AGA rather than the graphics card. This is mentioned specifically in the ADoom readme: https://aminet.net/package/game/shoot/ADoom-1.3 |
03 April 2021, 05:00 | #14 |
Registered User
Join Date: Sep 2008
Location: Farnborough
Posts: 148
|
The AAA chipset had a native 16bit colour chunky mode and upto 16 bitplanes.
The Blitter was 8x faster than AGA and also had a pixel addressing mode. There are a large variety of pixel types supported in AAA. Along with the traditional bitplane-generated pixels (including HAM8 and HAM10), we have several kinds of chunky and compressed pixels. Half-Chunky Half-chunky pixels come in 2,4, or 8-bit depths. These indirect through the color lookup table like most planar modes do. Chunky Chunky pixels are 16-bits deep. They bypass the CLUT, providing 5 bits of red, S-bits of green, 5-bits of blue, and one genlock overlay directly. Hybrid Hybrid pixels are 24-bits deep, composed of separate chunky planes for Red, Green, and Blue. The genlock overlay is fixed at (R,G,B) = 0 for this mode. PACKLUT These compressed pixels are stored at 2 bits per pixel and decompress to 8-bit half-chunky pixels. This is done by dividing the screen into 4 x 4 pixel regions. Each region contains two colors (8-bit values indexed through the CLUT) and sixteen pixels. PACKHY These compressed pixels are stored at 4 bits per pixel and decompress to 24-bit direct pixels. This is done by dividing the screen into 4 x 4 pixel regions. Each region contains two colors (24-bit direct values) and sixteen pixels https://web.archive.org/web/20171229...x/docs/AAA.pdf The next Amiga chipset Hombre abandoned bitplanes altogether. It had 4 separate chunky playfields of 8 bit colour. They could be combined though for a 32bit colour screen. |
03 April 2021, 12:37 | #15 | |||
Registered User
Join Date: Apr 2017
Location: France
Posts: 581
|
Quote:
Quote:
Quote:
Last edited by TEG; 03 April 2021 at 12:44. |
|||
03 April 2021, 18:11 | #16 |
Registered User
Join Date: Jan 2018
Location: Hancock
Posts: 48
|
Just adding that EGA graphics was planar with a chunky mode so not counting all the discussion of agnus feature changes implementing chunky and planar existed in EGA iir.
|
03 April 2021, 18:38 | #17 | |
Registered User
Join Date: Jan 2019
Location: Germany
Posts: 3,233
|
Quote:
The reason why this is not suitable for the Amiga is that it makes the entire memory contents look different once the aperture map is changed. That is, all the structures that are held in chip memory (i.e. the vector table, and AbsExecBase) would be broken. |
|
03 April 2021, 23:45 | #18 | ||
Registered User
Join Date: Mar 2018
Location: Hastings, New Zealand
Posts: 2,584
|
Quote:
Quote:
|
||
04 April 2021, 11:03 | #19 | |
Registered User
Join Date: Dec 2019
Location: Ur, Atlantis
Posts: 1,914
|
Quote:
Even so, you can play DOOM on a 386. In a medium window with low detail you can get about ~17 fps, which for the time wasn't so bad. |
|
04 April 2021, 11:28 | #20 |
This cat is no more
Join Date: Dec 2004
Location: FRANCE
Age: 52
Posts: 8,200
|
I remember 486/66 was perfect for doom. But my 060 was also perfect for doom. I completed it on the 060/50. I had a Pixel64 (Picasso like board) but I don't remember if I used native graphics or RTG.
|
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Original dedicated games on Amiga | sparhawk | Nostalgia & memories | 26 | 24 January 2020 19:35 |
Dedicated Amiga emulator | XPD | New to Emulation or Amiga scene | 5 | 05 August 2019 04:29 |
Amiga CD, CD32 & CDTV Feasible in Gamebase Amiga ? | sut | project.GameBase Amiga | 4 | 09 July 2007 12:49 |
New italian Amiga dedicated site ;) | K|L|_eR | Amiga websites reviews | 12 | 24 March 2003 13:48 |
|
|