27 March 2019, 11:12 | #61 |
Registered User
Join Date: Feb 2011
Location: Italy/Rome
Posts: 2,344
|
@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 |
27 March 2019, 12:07 | #62 |
Registered User
Join Date: Dec 2016
Location: Finland
Posts: 168
|
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.
|
27 March 2019, 19:30 | #63 | |
Registered User
Join Date: Jun 2010
Location: PL?
Posts: 2,867
|
Quote:
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. Last edited by pandy71; 27 March 2019 at 19:35. |
|
28 March 2019, 02:52 | #64 | |
Registered User
Join Date: Nov 2017
Location: Los Angeles
Posts: 49
|
Quote:
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. Last edited by FSizzle; 28 March 2019 at 02:53. Reason: clarity |
|
30 March 2019, 02:17 | #65 | |
Registered User
Join Date: Feb 2011
Location: Italy/Rome
Posts: 2,344
|
Quote:
|
|
30 March 2019, 02:21 | #66 | |
Registered User
Join Date: Nov 2017
Location: Los Angeles
Posts: 49
|
Quote:
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? |
|
30 March 2019, 02:23 | #67 |
Registered User
Join Date: Feb 2011
Location: Italy/Rome
Posts: 2,344
|
Only missed opportunity on OCS. It could be done very easly. If you use fixed mask, you can do it now
|
22 April 2022, 04:41 | #68 |
Registered User
Join Date: Jun 2018
Location: Calgary/Canada
Posts: 247
|
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. |
22 April 2022, 12:48 | #69 |
Registered User
Join Date: May 2013
Location: Grimstad / Norway
Posts: 852
|
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. |
23 April 2022, 00:38 | #70 |
Registered User
Join Date: Oct 2017
Location: Sunderland, England
Posts: 2,702
|
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. |
23 April 2022, 03:11 | #71 |
Registered User
Join Date: Jan 2012
Location: USA
Posts: 372
|
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. |
24 April 2022, 08:39 | #72 | |||||
Registered User
Join Date: Mar 2018
Location: Hastings, New Zealand
Posts: 2,708
|
Quote:
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). Quote:
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'). Quote:
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. Quote:
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. Quote:
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. |
|||||
24 April 2022, 10:58 | #73 |
Registered User
Join Date: Jan 2019
Location: Germany
Posts: 3,302
|
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. |
25 April 2022, 17:39 | #74 |
Registered User
Join Date: Jun 2010
Location: PL?
Posts: 2,867
|
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. |
26 April 2022, 14:50 | #75 |
Registered User
Join Date: Jan 2012
Location: USA
Posts: 372
|
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. |
26 April 2022, 17:00 | #76 |
Registered User
Join Date: Jun 2020
Location: Brno
Posts: 90
|
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. :-)
|
26 April 2022, 22:50 | #77 | ||||
Registered User
Join Date: Jun 2010
Location: PL?
Posts: 2,867
|
Quote:
(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. Quote:
Quote:
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). Quote:
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 |
||||
27 April 2022, 12:48 | #78 | |||||
Registered User
Join Date: Mar 2018
Location: Hastings, New Zealand
Posts: 2,708
|
Quote:
Acorn’s would-be ZX Spectrum killer, the Electron Quote:
Quote:
Quote:
Quote:
|
|||||
27 April 2022, 19:11 | #79 | |
Registered User
Join Date: Jan 2019
Location: Germany
Posts: 3,302
|
Quote:
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. |
|
28 April 2022, 01:18 | #80 |
Registered User
Join Date: Jun 2010
Location: PL?
Posts: 2,867
|
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...
|
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Indivision AGA all Display modes test and problems | doble07 | support.Hardware | 9 | 03 December 2009 08:56 |
Multisync CRT monitors that will display all Amiga modes? | mingle | support.Hardware | 7 | 21 December 2008 19:08 |
Problem with display modes (VGA) | Zombie13 | New to Emulation or Amiga scene | 4 | 01 July 2005 18:12 |
Custom display modes with RivaTuner | §ane | support.WinUAE | 6 | 02 October 2002 06:54 |
Custom Display Modes... | P-J | support.WinUAE | 3 | 15 July 2001 11:23 |
|
|