Missing Display modes

[sandruzzo]

@pandy71

yes, you can do 6 plane blit in one shot, but you use more dma cycles on cookie-cut operation, since blitter have to load mask every time.

- copper was good, but in my opinion with few tweak could have done more. Move operation waste to much time if you have to load sequencial register

[coder76]

AGA does have colorbank swap option via bplcon4, so you can swap colorbanks in sizes of 2^n with a single instruction in copperlist. That means you can preload 256 colors in color registers, and if you have eg. a 32-color display, you can have 7 other 32-color banks that can be swapped as active bank. This is handy as you dont need to write each color separately as in OCS, but there is of course a 256 color limit. This also puts an end to copper color clashes, as you can change anytime unused color banks, and have active bank untouched.

[pandy71]

Originally Posted by coder76

AGA does have colorbank swap option via bplcon4, so you can swap colorbanks in sizes of 2^n with a single instruction in copperlist. That means you can preload 256 colors in color registers, and if you have eg. a 32-color display, you can have 7 other 32-color banks that can be swapped as active bank. This is handy as you dont need to write each color separately as in OCS, but there is of course a 256 color limit. This also puts an end to copper color clashes, as you can change anytime unused color banks, and have active bank untouched.

True but seem some limitations exist and we talking on 15 or 16 bit address (so up to 256 banks of 256 color registers).
not sure if i recall correctly but Toni mention some limitations in HAM mode (BANK not work?). Sorry if i mixed something.

Btw - forgot to add to my list support to alternative colour space (something Like YCgCo) - it could accelerate video decoding but also (perhaps) improve HAM behaviour.

Another idea is 7 bit HAM mode where upper 3 bits works like RGB mask.

[FSizzle]

Originally Posted by sandruzzo

yes, you can do 6 plane blit in one shot, but you use more dma cycles on cookie-cut operation, since blitter have to load mask every time.

A single 6 plane interleaved blit with mask or 6 individual blits with mask takes the same amount of blitter DMA cycles. The interleaved blit requires that you duplicate all the lines in your mask so the modulo matches the source.

So the tradeoff is using a lot more memory (almost double) for the source data, but the saving is on blitter setup/wait loops.

It is a shame there is no way to have a mask that is re-used multiple times for the N lines of source data, as this would make masked blits use almost 25% fewer DMA cycles.

[sandruzzo]

Originally Posted by FSizzle

A single 6 plane interleaved blit with mask or 6 individual blits with mask takes the same amount of blitter DMA cycles. The interleaved blit requires that you duplicate all the lines in your mask so the modulo matches the source.

So the tradeoff is using a lot more memory (almost double) for the source data, but the saving is on blitter setup/wait loops.

It is a shame there is no way to have a mask that is re-used multiple times for the N lines of source data, as this would make masked blits use almost 25% fewer DMA cycles.

With 6 blits whiout cpu aid, you can chace mask and spare a lot of dma cicles

[FSizzle]

Originally Posted by sandruzzo

With 6 blits whiout cpu aid, you can chace mask and spare a lot of dma cicles

I'm don't understand what you mean. Do you mean there is some way to do this on current hardware? Or do you mean on some hypothetical hardware it would be possible?


Can you explain a bit more please?

[sandruzzo]

Originally Posted by FSizzle

I'm don't understand what you mean. Do you mean there is some way to do this on current hardware? Or do you mean on some hypothetical hardware it would be possible?


Can you explain a bit more please?

Only missed opportunity on OCS. It could be done very easly. If you use fixed mask, you can do it now

[nonarkitten]

I think the single biggest missed opportunity -- a feature I got Gunnar to add to his sprites and stolen from the Commodore 64 -- is Multi-Color Mode. MCM on the Amiga, whether enabled for a sprite or bit plane, could group two pixels together to provide double the color depth at the expense of doubling the horizontal width of the apparent pixel (at least at that bit plane).

You could have one 16 color sprite without attaching, a 64 color sprite by attaching an MCM sprite and non-MCM sprite or a 256 color sprite by having both be in MCM mode. This could be mixed with non-MCM planes to make virtually any bit depth all the way up to 12 bpp (6 bpp in MCM mode). A single play field in DPF mode could be up to 64 colors or any point in between to get both good resolution and good color depth.

The lookup table could still have been 32 colors with EHB at 64, then have direct modes at 7-bpp up to 12-bpp using 232, 233, 333, 343, 344 and then 444 RGB. I love HAM and all, but 12-bpp "super low-res" would have been MUCH, MUCH better.

In many ways, this would have exceeded what even AGA could do all without asking for one more bit of data from the chip RAM.

Combine that with the sprite tiling for extra layers and we might have ended up with something that could go toe-to-toe with the SNES or, dare I say, the NEO GEO? Because nothing is stopping the COPPER from reusing those sprites over, and over, and over again.

[NorthWay]

It's been a while since I messed with it, but do I remember wrong or are there 160-wide modes when using DBLPAL or similar modes?
Not that it is very useful, but it could have been kinda logical if a 160 mode was implemented originally.

[mcgeezer]

The hardware sprites on the Amiga are simply awful to deal with.

However, if they'd added a lot more of them.. maybe to 64 it would have been a game changer. Just look at the Neogeo and what it does with sprites.

[mc6809e]

I think in the end the problem for Amiga graphcs was lack of appreciation for using page mode for DRAM accesses.

Sure, fmode came later, but it was still limited.

The key to maximizing bandwidth for graphics (and CPU, for that matter) is exploiting DRAM's ability to produce after a RAS an entire page of bits to be accessed with CAS.

Amiga's interleved DMA is great for random accesses by mutiple devices, but for sequetial accesses it just isn't the best idea.

Exploiting page mode is what helped VGA take off.

DRAM used in the a500 had a best case random access time of 260ns. (The Amiga DMA ran them with a 280ns cycle.)

But consider using page mode for the very same memory in 1987. After the initial RAS and first CAS, each additional access to the page takes just 75ns -- more than three times as fast.

The Amiga did get fmode later, but it was still limited. The page size for 41256 parts in the a500 was 512 bits. With 16 chips that gives 1k bytes per page. VGA cards could exploit this for the highest resolutions and bit depths.

What's interesting is just how little improvement there's been to random access times for DRAM in the past 30+years. A random DMA in 1985 for the Amiga was 280 ns. For today's CPUs and GPUs a completely random access takes about 60ns. The huge gains in memory bandwith you see today are mostly due to accessing the same page as quickly as possible and filling caches once a row is opened.

[Bruce Abbott]

Originally Posted by mc6809e

I think in the end the problem for Amiga graphcs was lack of appreciation for using page mode for DRAM accesses.

It wasn't a problem. By not using page mode the timing was easier to work out, alignment wasn't an issue, and any DRAM was compatible. Compatibility became an issue in 1988, when a world-wide DRAM shortage occurred as a result of anti-dumping laws. Commodore may have saved a lot of money because they could use whatever DRAM was cheapest at the time.

And it clearly wasn't a problem in practice because the Amiga was mind-blowing compared to other home computers of the time. A product doesn't have to be the best it could possibly be to be successful, it just has to be significantly better than the competition (which could mean - cheaper, nicer, more accessible etc., not necessarily technically superior).

The key to maximizing bandwidth for graphics (and CPU, for that matter) is exploiting DRAM's ability to produce after a RAS an entire page of bits to be accessed with CAS.

Amiga's interleved DMA is great for random accesses by mutiple devices, but for sequetial accesses it just isn't the best idea.

Typical perfectionist engineering talk. Have you seen the Lorraine prototype? Thousands of TTL chips spread over dozens of boards, which took years to create. Now imagine being told by some armchair engineer that that it 'just wasn't the best idea' because you didn't 'maximize bandwidth'. So you spend another year trying to create the 'perfect' design, and... the market has passed you by.

Yes, the Amiga's memory design is great for random access by multiple devices. So you can have plenty of stuff going on at once without having to worry about whether they will interfere with each other, important for multitasking and smooth gameplay. Contrast this with the C64, which has a pathetically slow disk drive because the display steals all the bandwidth on some lines (yet the C64 was the most successful home computer model of all time - because they shipped it like that rather than try to make it 'perfect').

Exploiting page mode is what helped VGA take off.

VGA took off because it was on the PC. The PC didn't have a unified memory structure. RAM on the VGA card was separate from main board RAM, so it could easily run whatever timing it wanted. The downside of course was that memory on the VGA card couldn't be used for programs or peripheral DMA. The A1000 came stock with only 256k RAM. To do it the VGA way it would have needed twice as much RAM, of which nearly half would be wasted much of the time.

The Amiga probably could have combined unified memory with page mode video access, but the timing would be much more complex and it might only work with certain DRAM chips. The Amiga's designers apparently felt that page mode was too risky, or simply not necessary because they already had enough bandwidth for what they wanted.

But consider using page mode for the very same memory in 1987. After the initial RAS and first CAS, each additional access to the page takes just 75ns -- more than three times as fast.

After the first access. Some kind of caching would be required to even out the timing, which might impact horizontal scrolling etc. Blitter and CPU access could also be a problem.

1987 was the year that IBM introduced VGA. By that time the Amiga's hardware design was mature, but had not yet been fully exploited. So what was mainly needed was not improved graphics, but software making better use of what was already there.

PCs were a different story. The limitations of CGA and EGA were painfully obvious, and PC gamers were hanging out for something better. That is what made VGA so popular in the PC world. Ironically the Amiga was constantly dismissed by PC users as being a mere 'games machine', until their own platform got suitable hardware. Then they immediately started crowing about how great their games machine was, when Amiga users had been experiencing its greatness for years.

What's interesting is just how little improvement there's been to random access times for DRAM in the past 30+years. A random DMA in 1985 for the Amiga was 280 ns. For today's CPUs and GPUs a completely random access takes about 60ns. The huge gains in memory bandwith you see today are mostly due to accessing the same page as quickly as possible and filling caches once a row is opened.

Yes, and the circuitry to do this is extremely complex.

In my own designs I use SRAM. 70ns SRAM has been available for many years and is very cheap today (when you don't need huge quantities). Even back in the 80s I found the simplicity of SRAM made up for the increased price.

[Thomas Richter]

IBM avoided the slowness of DRAMs on VGA by using four bitplanes that could be accessed in parallel, so you got four times the RAM bandwidth. Unlike in the Amiga, these are four independent RAM-banks of (originally) 64K in size. The transputer vendor INMOS got around this problem also by a parallel design based on VRAM, RAM that contains a shift register that can read an entire row at once, and then shift it out bit by bit. The register is part of the RAM, not part of the VGA chip (or sequencer, to be precise).

Amiga sprites are just a PITA due to their many modes, and due to its complexity, the Os integration is also rather poor. There is the horizontal sprite resolution which is configured in the simple sprite structure (or rather an extension of it), and the vertical resolution which is configured completely elsewhere, namely in the color map through VideoControl(). Intuition and graphics go through hoops to keep this system working (in particular the pointer.class of intuition), and all this logic isn't still quite right as of Os 3.2.

[pandy71]

Technically Page Mode didn't exist in Amiga time - it was introduced in some 41256 and later in 4464 DRAM's, FPM mode existed (safe assumption) in most of 44256 DRAM's - so technically next generation of DRAM (i.e. 1Mbit) provided such functionality, All Commodore could was interleaving and increase width of DRAM bus (from 16 to 32 bit - it was introduced on A3000 thanks to quite complex logic based on 74646).
Amiga was introduced in no proper time from technological perspective slightly too early you can say but at the same time it was also slightly too late...
After many years some techniques are obvious but in 80's they was not feasible on PC world too - on board cache memories (level 2) was introduced at the beginning of 90's with newer 386DX/386SX CPU's motherboards.
On bitsave.org there is many datasheets from those years available - TI, Motorola offer comparable technology - it is very interesting to observe what was available in 1983 and in for example 1988 - huge improvement.
Btw efficiently using FPM will require some buffering on Agnus/Denise/Paula i.e. probably make them difficult to fit in CBM MOS technology.

[mc6809e]

Page mode certainly did exist at the time. The Acorn Electron (1983) used it to cleverly reduce the number of dram chips from eight to four. It actually had a four bit bus. Page mode was exploited to grab two nibbles to create each needed byte.

Not sure what you mean by buffering, but Denise and Paula already store multiple bytes before they're needed. Paula stores two byes per channel and Denise stores up to six words for display.

Interestingly the Atari ST has a video memory organization that combines both the idea of bitplanes and linear organization with a bitplane words interleaved with each other sequentially in memory.

Look, I'm not bashing the Amiga. I love it. There were just a few regrettable choices made.

[defor]

I wish OCS had separate values for number of bitplanes for Agnus (to fetch) and Denise (to display). That it was possible is demonstrated by famous 7-bitplanes bug. :-)

[pandy71]

Originally Posted by mc6809e

Page mode certainly did exist at the time. The Acorn Electron (1983) used it to cleverly reduce the number of dram chips from eight to four. It actually had a four bit bus. Page mode was exploited to grab two nibbles to create each needed byte.

Dig then for 4164 technology as it was common when Amiga become WIP:

(1981) Fairchild 4164 - support Page Mode
(1980) TI 4164 - support Page Mode
(1981) Toshiba 4164 - support Page Mode
(1982) OKI 4164 - support Page Mode
(1980) Mostek 4164 - support Page Mode
(1980,1981/1982) Motorola (MCM6664) 4164 - doesn't support Page Mode
(1982) Motorola (MCM6664A) 4164 - does support page mode

Page Mode was also unavailable in some 41256 DRAM's - my impression is that Amiga designers avoided exploring this due few reasons - one of them was that Page Mode was not industry standard before 1984 and they willing to avoid situation being too dependent but also adding Page Mode require more complex design (more FETCH logic, higher complexity etc), also i think they anyway considered Amiga design as impressive so no need to increase memory bandwidth.

Originally Posted by mc6809e

Not sure what you mean by buffering, but Denise and Paula already store multiple bytes before they're needed. Paula stores two byes per channel and Denise stores up to six words for display.

Single WORD is not so much - i case of the FPM you will need to at least double this size or even more - this is like FMODE coding rules with AGA - also alignment need to be considered and avoiding page crossing at all cost.

Originally Posted by mc6809e

Interestingly the Atari ST has a video memory organization that combines both the idea of bitplanes and linear organization with a bitplane words interleaved with each other sequentially in memory.

But this can be explained by simpler bitplane organization - you have only 1, 2 or 4 bitplanes where Amiga may have 1,2,3,4,5, and 6 bitplanes also
with Dual Playfield in action... as such it was way easier to design chunky-planar ST organization than pure planar (Amiga of course at a cost of additional logic could introduce similar but then at least some limitations need to be introduced).

Originally Posted by mc6809e

Look, I'm not bashing the Amiga. I love it. There were just a few regrettable choices made.

it is not about bashing, i can regret those choices same as you but trying to understand way of thinking and also see some limitations - if Amiga could be designed after 1985 i'm quite sure that it will use FPM, perhaps interleaving, more RAM, more colors etc. So it will be like Ranger from very beginning...
We must see both sides of problem...
Even simple DRAM refresh - check Toni very interesting information - how inconsistent was Commodore in terms of DRAM refresh - this DRAM feature was not also industry standard till at least 1985 - so many versions across those times.
http://eab.abime.net/showpost.php?p=...&postcount=290
http://eab.abime.net/showpost.php?p=...&postcount=294

[Bruce Abbott]

Originally Posted by mc6809e

Page mode certainly did exist at the time. The Acorn Electron (1983) used it to cleverly reduce the number of dram chips from eight to four. It actually had a four bit bus. Page mode was exploited to grab two nibbles to create each needed byte.

Not that clever. It made the Electron's RAM twice as slow as the BBC Micro. That, combined with removing mode 7 (teletext mode) and the sound chip, made the Electron much slower than the previous model as well as making it largely incompatible - not a great idea.

Acorn’s would-be ZX Spectrum killer, the Electron

“The problem was, of course, that the BBC Micro architecture only had 32KB, so if you were using 64Kb DRAM chips, you’d need four of them to give you 32KB and then you’d have to be double-accessing them for every byte you wanted,” Furber says. “That basically drove the Electron architecture: the recognition that for cost reasons we had to go that way. There were inevitable performance compromises as a result of that. We couldn’t do double-access at 4MHz - the memory wasn’t fast enough for that - so we had to accept we were going to have to live with lower total memory bandwidth, which we didn’t like.”

And squeezing all the circuitry required into a single custom chip wasn't wasn't the 'cleverest' idea either...

Acorn marketing manager Tom Hohenberg would many years later place the blame for the slow production ramp on Ferranti - later GEC Plessey - for failing to punch out sufficient working ULAs. Only one in ten worked, he claimed.

Typical how a stupid design from another manufacturer is described as 'clever', while Commodore's (actually Jay Miner's) decisions were called 'regrettable'.

Not sure what you mean by buffering, but Denise and Paula already store multiple bytes before they're needed. Paula stores two byes per channel and Denise stores up to six words for display.

Yes, but the memory cycle timing is the same as the display timing so the buffering is relatively simple. With page mode you have to buffer everything that goes into and out of the RAM, with variable latency. The bandwidth gain isn't great unless you have multiple page mode accesses in sequence, which requires even more buffers and results in even greater latency. Just what you don't need in an already complex design.

Interestingly the Atari ST has a video memory organization that combines both the idea of bitplanes and linear organization with a bitplane words interleaved with each other sequentially in memory.

The Amiga's linear bitmap layout is simpler and more logical.

[Thomas Richter]

Originally Posted by Bruce Abbott

The Amiga's linear bitmap layout is simpler and more logical.

Well... it is the logical consequence of depending on a bit-based blitter. Thus, no matter the color depth, the blitter can always be used in the same way, but potentially requires multiple runs - once for each bitplane. With the ST design (also shared by some INMOS chips) a potential blitter would need to adjust to the organization of the memory. Consider how a line-drawer in the "interleaved"( (ST) design would look like compared to the "planar" (Amiga) design - a lot of additional complexity.

Disadvantage of the Amiga design: You (typically) also need to fire the blitter multiple times, thus performance isn't ideal.

Super-VGA never cared about planar blitting later on, just chunky or hi/true color, so in a sense the planar Amiga model died out as being to limited, and all what remained was a "interleaved" model where units were entire bytes, and bit-addressing was disregarded.

[pandy71]

Planar mode of was of course tradeoff between graphic capabilities and amount of memory - original Amiga was designed to use 128KiB of RAM in total...