Should I get an Indivision ECS for my Amiga 3000?

[Tom]

Hi,

 

I've got an Amiga 3000 here, for which I'm looking for a monitor solution...I've got a 1935 Monitor which I originally got together with the A3000, but I hate it: it's huge, ugly and its ringing drives me mad.

 

What are my options to connect it to a modern VGA display? Should I get an Indivision ECS? Are they any good?

 

Cheers

Tom

[FastRobPlus]

I’m a bit confused. Your Amiga 3000 outputs 60hrz VGA so it should work with just about any VGA CRT display.

 

The only thing to avoid might be flat panel LCD monitors, but only because the display resolution of the Amiga may look muddy on a fixed pixel monitor.

 

The Indivision gives deinterlaced video to an ECS Amiga, but the Amiga 3000 has a deinterlacer built in (and is the only Amiga to have this.) Indivision is a bit more advanced and versatile, but not enough IMO to merit getting one for an A3K

[Tom]

I’m a bit confused.

 

So am I, apparently. I tried all VGA monitors I had, none of them displayed anything useful. One of them quickly displays a garbled workbench before deciding there's no signal. I'm pretty sure the A3000 is OK. It used to work with the 1935 monitor, although I don't have it around right now to test it.

[+save2600]

You try diddling the fine tune screw in the back, next to the VGA port yet? Failing that, yes - the Indivision is loads more compatible than Amber.

[FastRobPlus]

Agree with the advice above.

If you original A3K battery is still there, it's also possible that battery damage has taken out the amber deinterlacer while your Amiga has sat around.

If that's the case, the Indivision ECS is the way to go.

 

@Save2600:

 

I know the Indivision ECS has some "graphiti" color enhancemnts, sort of similar to DCTV or something? Do you know what things (games, picture viewers, apps) have been made that use it?

[Tom]

Your Amiga 3000 outputs 60hrz VGA so it should work with just about any VGA CRT display.

 

It's a European model, wouldn't that be 50 Hz then?

[Tom]

If you original A3K battery is still there, it's also possible that battery damage has taken out the amber deinterlacer while your Amiga has sat around.

If that's the case, the Indivision ECS is the way to go.

 

Good point, will check the battery immediately when I get home today...apparently with the Indivision I have to remove or replace it anyway because it's too high. I've heard from people having trouble with A3000's that don't have a battery anymore. Does anybody have experiences with that?

[+save2600]

@Save2600:

 

I know the Indivision ECS has some "graphiti" color enhancemnts, sort of similar to DCTV or something? Do you know what things (games, picture viewers, apps) have been made that use it?

AFAIK, no... it doesn't do anything like that. Has an extended resolution though, not native to the Amiga. HighGFX it's called. Maybe that's what you were thinking...

 

 

 

[FastRobPlus]

@Save2600:

 

I know the Indivision ECS has some "graphiti" color enhancemnts, sort of similar to DCTV or something? Do you know what things (games, picture viewers, apps) have been made that use it?

AFAIK, no... it doesn't do anything like that. Has an extended resolution though, not native to the Amiga. HighGFX it's called. Maybe that's what you were thinking...

 

Check out the Individual Computers website:

Another novelty is the built-in Graffiti emulation. Software that makes use of the Graffiti modes can display 256 out of 4096 colours without HAM artefacts.

 

I've never used Graffiti - I can only assume it's similar techinlogy to HAM-E and DCTV - a "cookie" based color inserter

[FastRobPlus]

Your Amiga 3000 outputs 60hrz VGA so it should work with just about any VGA CRT display.

 

It's a European model, wouldn't that be 50 Hz then?

Sorry - yeah, it'd be 50hz for you, meaning some VGA monitors will not work. You'll want to make sure the specs explicitly say it supports 31kHz 50Hz. You may want to ping a European forum like A1K.org to see what European monitors they recommend.

 

Good point, will check the battery immediately when I get home today...apparently with the Indivision I have to remove or replace it anyway because it's too high. I've heard from people having trouble with A3000's that don't have a battery anymore. Does anybody have experiences with that?

 

I seem to remember that without a battery, the on-board SCSI controller settings reset to their default settings. That means that if your SCSI topology matches what the 3000's SCSI defaults to, you should be fine. But SCSI behaves in seemingly random ways, so if you do remove the battery, it's probably best to replace it with a modern battery.

[+save2600]

Check out the Individual Computers website:

Another novelty is the built-in Graffiti emulation. Software that makes use of the Graffiti modes can display 256 out of 4096 colours without HAM artefacts.

Hmm.... well I'll be dipped. Funny how that's not mentioned in the sales literature on distributors websites such as Amigakit. Not that I've seen anyway. Interesting. I too have never fooled around with a Graffiti box, but I have the DCTV. Neat little box that thing is.

[kool kitty89]

@Save2600:

 

I know the Indivision ECS has some "graphiti" color enhancemnts, sort of similar to DCTV or something? Do you know what things (games, picture viewers, apps) have been made that use it?

AFAIK, no... it doesn't do anything like that. Has an extended resolution though, not native to the Amiga. HighGFX it's called. Maybe that's what you were thinking...

 

Check out the Individual Computers website:

Another novelty is the built-in Graffiti emulation. Software that makes use of the Graffiti modes can display 256 out of 4096 colours without HAM artefacts.

 

I've never used Graffiti - I can only assume it's similar techinlogy to HAM-E and DCTV - a "cookie" based color inserter

Hmm, so it's definitely NOT adding more bitplanes and color registers? (ie not 256 indexed colors from 12-bit RGB like the TT SHIFTER can do -or as the C65 was supposed to)

Edited April 28, 2011 by kool kitty89

[Tom]

OK, the A3000 can be jumpered to be PAL or NTSC, so I quickly set it to NTSC and it works fine on my flatscreen, and it doesn't even look as bad as some people claim. At least to me the space savings and no 15khz beeping are worth far more.

 

The battery hasn't leaked yet, so whatever I do with the display I'll certainly try to replace the battery...any recommendations for replacement batteries?

[+save2600]

The battery hasn't leaked yet, so whatever I do with the display I'll certainly try to replace the battery...any recommendations for replacement batteries?

eBay Auction -- Item Number: 220775148701

 

...best solution to replace NiCad's with. Diode built into the base too, disabling the recharge circuitry.

 

 

[Chilly Willy]

@Save2600:

 

I know the Indivision ECS has some "graphiti" color enhancemnts, sort of similar to DCTV or something? Do you know what things (games, picture viewers, apps) have been made that use it?

AFAIK, no... it doesn't do anything like that. Has an extended resolution though, not native to the Amiga. HighGFX it's called. Maybe that's what you were thinking...

 

Check out the Individual Computers website:

Another novelty is the built-in Graffiti emulation. Software that makes use of the Graffiti modes can display 256 out of 4096 colours without HAM artefacts.

 

I've never used Graffiti - I can only assume it's similar techinlogy to HAM-E and DCTV - a "cookie" based color inserter

Hmm, so it's definitely NOT adding more bitplanes and color registers? (ie not 256 indexed colors from 12-bit RGB like the TT SHIFTER can do -or as the C65 was supposed to)

 

Graffiti actually gives the Amiga ModeX graphics, exactly like VGA on the PC. The way it works is the Graffiti has four shift registers that connect to the digital RGBI lines on the video port. With the appropriate palette on the Amiga, this allows you to use 8 bit chunky data in four bitplanes - each bitplane steered to one of the digital lines. Like ModeX, those bytes in the planes represent four interleaved columns. The graffiti has a RAMDAC on board to provide the palette and analog RGB out needed.

 

The first few lines of the video are used to trigger the Graffiti and load the palette in the RAMDAC, after which all the data is a "standard" ModeX display. Having a Graffiti makes ports of old ModeX VGA games really easy.

 

Note that 320 wide ModeX means four bitplanes of 80 bytes per line. 80 bytes => 640 wide bitplane, or hires on the Amiga. So a single 640x200 16 color display gives the 320x200 ModeX display. Now remember that 16 color hires uses all available memory access slots in the active display on OCS/ECS systems. So Graffiti on OCS/ECS means full DMA contention, and the associated slow-down when updating graphics. On AGA, it means 0 contention... one of the nice things about AGA.

[FastRobPlus]

@Save2600:

 

I know the Indivision ECS has some "graphiti" color enhancemnts, sort of similar to DCTV or something? Do you know what things (games, picture viewers, apps) have been made that use it?

AFAIK, no... it doesn't do anything like that. Has an extended resolution though, not native to the Amiga. HighGFX it's called. Maybe that's what you were thinking...

 

Check out the Individual Computers website:

Another novelty is the built-in Graffiti emulation. Software that makes use of the Graffiti modes can display 256 out of 4096 colours without HAM artefacts.

 

I've never used Graffiti - I can only assume it's similar techinlogy to HAM-E and DCTV - a "cookie" based color inserter

Hmm, so it's definitely NOT adding more bitplanes and color registers? (ie not 256 indexed colors from 12-bit RGB like the TT SHIFTER can do -or as the C65 was supposed to)

 

Graffiti actually gives the Amiga ModeX graphics, exactly like VGA on the PC. The way it works is the Graffiti has four shift registers that connect to the digital RGBI lines on the video port. With the appropriate palette on the Amiga, this allows you to use 8 bit chunky data in four bitplanes - each bitplane steered to one of the digital lines. Like ModeX, those bytes in the planes represent four interleaved columns. The graffiti has a RAMDAC on board to provide the palette and analog RGB out needed.

 

The first few lines of the video are used to trigger the Graffiti and load the palette in the RAMDAC, after which all the data is a "standard" ModeX display. Having a Graffiti makes ports of old ModeX VGA games really easy.

 

Note that 320 wide ModeX means four bitplanes of 80 bytes per line. 80 bytes => 640 wide bitplane, or hires on the Amiga. So a single 640x200 16 color display gives the 320x200 ModeX display. Now remember that 16 color hires uses all available memory access slots in the active display on OCS/ECS systems. So Graffiti on OCS/ECS means full DMA contention, and the associated slow-down when updating graphics. On AGA, it means 0 contention... one of the nice things about AGA.

 

But do any games take advantage of the modes offered by Graffiti? Do Ham-E, DVTV, and FunCclor use this same technique?

[+save2600]

But do any games take advantage of the modes offered by Graffiti? Do Ham-E, DVTV, and FunCclor use this same technique?

Not that I'm aware of. If there are *any*, I bet there's fewer than that, that were made for the X-Specs.

 

Handful of cool demos however.

[Chilly Willy]

But do any games take advantage of the modes offered by Graffiti? Do Ham-E, DVTV, and FunCclor use this same technique?

Not that I'm aware of. If there are *any*, I bet there's fewer than that, that were made for the X-Specs.

 

Handful of cool demos however.

 

I'm not aware of any, either. It was just too little, too late when it came out. PC video cards had taken over the market. I did add Graffiti support to FUSION (the Mac emulator for the Amiga). However, it needed SuperHiRes (1280 wide) sixteen color mode to make the Mac 640 wide display, so it didn't help OCS/ECS folks, just AGA folks. We were going to add support for the Graffiti to our PC emulator (PCx), but the Amiga market was dead by then, so it never happened.

 

Personally, I think Amiga should have made something like Graffiti part of AGA. It would have made it much easier for PC programmers than AKIKO.

[amiman99]

But do any games take advantage of the modes offered by Graffiti? Do Ham-E, DVTV, and FunCclor use this same technique?

Not that I'm aware of. If there are *any*, I bet there's fewer than that, that were made for the X-Specs.

 

Handful of cool demos however.

New ADoom port supports Graffiti as well as Indivision ECS, some people got ADoom working on A600 with ACA630 and Indivision ECS.

[kool kitty89]

Graffiti actually gives the Amiga ModeX graphics, exactly like VGA on the PC. The way it works is the Graffiti has four shift registers that connect to the digital RGBI lines on the video port. With the appropriate palette on the Amiga, this allows you to use 8 bit chunky data in four bitplanes - each bitplane steered to one of the digital lines. Like ModeX, those bytes in the planes represent four interleaved columns. The graffiti has a RAMDAC on board to provide the palette and analog RGB out needed.

 

The first few lines of the video are used to trigger the Graffiti and load the palette in the RAMDAC, after which all the data is a "standard" ModeX display. Having a Graffiti makes ports of old ModeX VGA games really easy.

Interesting, did that actually come out before AGA? (it definitely seems like a nice upgrade path to make as a true standard -same for the ST for that matter . . . I'd actually thought the TT SHIFTER had used packed pixels, but apparently it was just 8 bitplanes like AGA -but with 12-bit rather than 24-bit RGB . . . which also makes the lack of the BLiTTER in the TT even stranger -if it was 8-bit packed pixels, ditching the blitter in favor of software 68030 manipulated graphics would make more sense)

 

Note that 320 wide ModeX means four bitplanes of 80 bytes per line. 80 bytes => 640 wide bitplane, or hires on the Amiga. So a single 640x200 16 color display gives the 320x200 ModeX display. Now remember that 16 color hires uses all available memory access slots in the active display on OCS/ECS systems. So Graffiti on OCS/ECS means full DMA contention, and the associated slow-down when updating graphics. On AGA, it means 0 contention... one of the nice things about AGA.

It uses all the available slots at full 7.16 MB/s bandwidth, or normal interleaved 3.58 MB/s bandwidth? (if the former, that would mean the CPU and blitter could only work in vblank in those modes . . . and given displaying 640x200x4 would take 5 MB/s, that would seem to be the case -actually, going below that bandwidth should end up with graphical garbage or tearing and not slowdown)

 

You could avoid contention by working with the CPU in fastRAM and copying to chipRAM only in vblank. (which would only mean 28 kB per frame in NTSC -so 20 FPS max- or 42 kB in PAL for 25 FPS, assuming 320x200x8 in both cases -and also assuming the Amiga's OCS/ECS DRAM controller didn't support page mode -otherwise you could have up to double the bandwidth for burst accesses -block copy with source and destination on separate banks/buses caters to page mode very well)

 

 

 

 

 

I'm not aware of any, either. It was just too little, too late when it came out. PC video cards had taken over the market. I did add Graffiti support to FUSION (the Mac emulator for the Amiga). However, it needed SuperHiRes (1280 wide) sixteen color mode to make the Mac 640 wide display, so it didn't help OCS/ECS folks, just AGA folks. We were going to add support for the Graffiti to our PC emulator (PCx), but the Amiga market was dead by then, so it never happened.

 

Personally, I think Amiga should have made something like Graffiti part of AGA. It would have made it much easier for PC programmers than AKIKO.

AGA Amigas didn't even have AKIKO though, wasn't that only used in the CD32? (normal Amiga 4000s/1200s had to rely on CPU/blitter driven packed to planar conversion)

[Chilly Willy]

Graffiti actually gives the Amiga ModeX graphics, exactly like VGA on the PC. The way it works is the Graffiti has four shift registers that connect to the digital RGBI lines on the video port. With the appropriate palette on the Amiga, this allows you to use 8 bit chunky data in four bitplanes - each bitplane steered to one of the digital lines. Like ModeX, those bytes in the planes represent four interleaved columns. The graffiti has a RAMDAC on board to provide the palette and analog RGB out needed.

 

The first few lines of the video are used to trigger the Graffiti and load the palette in the RAMDAC, after which all the data is a "standard" ModeX display. Having a Graffiti makes ports of old ModeX VGA games really easy.

Interesting, did that actually come out before AGA? (it definitely seems like a nice upgrade path to make as a true standard -same for the ST for that matter . . . I'd actually thought the TT SHIFTER had used packed pixels, but apparently it was just 8 bitplanes like AGA -but with 12-bit rather than 24-bit RGB . . . which also makes the lack of the BLiTTER in the TT even stranger -if it was 8-bit packed pixels, ditching the blitter in favor of software 68030 manipulated graphics would make more sense)

 

Yes, it came out before AGA. There had been talk it would be part of AGA, but talks broke down between CBM and the makers of the Graffiti. If they HAD built Graffiti into the AGA, they could have had it run in 8 bitplane mode, giving two independent chunky playfields. That would have RULED games of the time.

 

 

Note that 320 wide ModeX means four bitplanes of 80 bytes per line. 80 bytes => 640 wide bitplane, or hires on the Amiga. So a single 640x200 16 color display gives the 320x200 ModeX display. Now remember that 16 color hires uses all available memory access slots in the active display on OCS/ECS systems. So Graffiti on OCS/ECS means full DMA contention, and the associated slow-down when updating graphics. On AGA, it means 0 contention... one of the nice things about AGA.

It uses all the available slots at full 7.16 MB/s bandwidth, or normal interleaved 3.58 MB/s bandwidth? (if the former, that would mean the CPU and blitter could only work in vblank in those modes . . . and given displaying 640x200x4 would take 5 MB/s, that would seem to be the case -actually, going below that bandwidth should end up with graphical garbage or tearing and not slowdown)

 

The former. Just like 16 color hires on OCS/ECS, things would grind to a halt when trying to access chip ram during the active display. You would have definitely wanted some fast ram with such a system.

 

 

You could avoid contention by working with the CPU in fastRAM and copying to chipRAM only in vblank. (which would only mean 28 kB per frame in NTSC -so 20 FPS max- or 42 kB in PAL for 25 FPS, assuming 320x200x8 in both cases -and also assuming the Amiga's OCS/ECS DRAM controller didn't support page mode -otherwise you could have up to double the bandwidth for burst accesses -block copy with source and destination on separate banks/buses caters to page mode very well)

 

Page mode was added to AGA. Remember my explanations of the fetch mode? The OCS/ECS did regular FULL cycles. At least it interleaved custom and 68000 accesses for realtively free CPU accesses on most commonly used video modes.

 

 

I'm not aware of any, either. It was just too little, too late when it came out. PC video cards had taken over the market. I did add Graffiti support to FUSION (the Mac emulator for the Amiga). However, it needed SuperHiRes (1280 wide) sixteen color mode to make the Mac 640 wide display, so it didn't help OCS/ECS folks, just AGA folks. We were going to add support for the Graffiti to our PC emulator (PCx), but the Amiga market was dead by then, so it never happened.

 

Personally, I think Amiga should have made something like Graffiti part of AGA. It would have made it much easier for PC programmers than AKIKO.

AGA Amigas didn't even have AKIKO though, wasn't that only used in the CD32? (normal Amiga 4000s/1200s had to rely on CPU/blitter driven packed to planar conversion)

 

AKIKO was only on the CD32, which limited it's usefulness. That's why I said CBM would have been better off with something like Graffiti in the AGA. AKIKO was added later to get past the fact that they couldn't get a license on Graffiti.

[kool kitty89]

Yes, it came out before AGA. There had been talk it would be part of AGA, but talks broke down between CBM and the makers of the Graffiti. If they HAD built Graffiti into the AGA, they could have had it run in 8 bitplane mode, giving two independent chunky playfields. That would have RULED games of the time.

Yeah, that would have been pretty awesome, especially if they'd tweaked the blitter to work more optimally with packed pixels. (not to mention working on the 32-bit bus . . . or at least double the clock speed of the old blitter and just rely on the existing block move/fill capabilities, but 32-bit chunky blitting abilities would have been great, so would be adding fast block/line fill with fast page mode writes for optimal fill rate -for clearing the framebuffer and filling polygons -even better is if the updated blitter could also access fastRAM when needed for faster blitting -efficient use of fast page mode copying, though like the 3DO's use of the same technique, you'd have contention with the CPU -except at least the 68020 and 030 have caches, unlike the ARM60)

 

Or if modifying the blitter caused too many compatibility issues (and adding a whole new blitter was too much cost overhead), they should at least have added basic VGA-type fill/raster op functions. (and require the CPU to do the rest . . . or the old blitter in cases where it was still OK)

 

 

On another note, they really could have used a Mode-X like facility by the time of the ECS, even if it meant as much contention as the graffiti historically. (though had they enabled fast page mode reads, even with 16 bits and 7.16 MHz chips -for 140 ns peak access speeds- it would have significantly increased overall performance . . . well, at least if it could be configured with wait states for when the scan line buffer was being filled -and that's ignoring possibilities to changing the clock speeds to things like 8.95 MHz -to be compatible with an NTSC/PAL divisible baster clock- and using 100 ns DRAM -pretty common/cheap by 1990)

 

After all, VGA had been around for 3 full years by that point. (abandoning the Ranger chipset in favor of a directly VGA competitive chipset -that was also aimed at generally being cost effective, avoiding VRAM, etc- would have made a lot of sense . . . not just the 8-bit packed pixels, but the 640x480x4bpp noninterlaced color support would have been quite significant too -something that the TT SHIFTER actually added along with the 320x480p 8bpp modes -though, again, I think it lacked packed pixel support, just 8 bitplanes like AGA but limited to 320x480p max, VIDEL from the Falcon added 16-bit chunky modes as well as 8/4/2/1-bit planar modes -no 8-bit chunky modes either AFIK, though those would have been really useful to have)

 

 

 

The former. Just like 16 color hires on OCS/ECS, things would grind to a halt when trying to access chip ram during the active display. You would have definitely wanted some fast ram with such a system.

Could you signal the start and end of vblank for the CPU to know when there free access to chipRAM? (you'd need better than just a simple vblank interrupt for that if you wanted to precisely time it for both the start and end of vblank -more like hblank/scanline interrupts with the proper interval set for the entirety of thhe usable part of vblank)

 

Could PAULA sill be used in those high bandwidth modes?

 

Page mode was added to AGA. Remember my explanations of the fetch mode? The OCS/ECS did regular FULL cycles. At least it interleaved custom and 68000 accesses for realtively free CPU accesses on most commonly used video modes.

Right, you mentioned it using 1 random followed by 1 page mode access, but still otherwise interleaved? (and that page mode -and the 32-bit bus width- was only used for sprites and playfield/framebuffer scanning)

But is that the only way it could be used? You'd get much, much better average bandwidth if sustained burst accesses were used (like scanning an entire scanline and then giving the bus back, more like what ANTIC+GTIA did, but with page mode -and exactly what the Jaguar does, but at 64-bits wide as well as in 75 ns page mode).

Not only would that give you a lot more video bandwidth in general, but it would give a hell of a lot more chipram bandwidth to the CPU than old fashion interleaving could. (more so if the CPU was fast enough to read/write in fast page mode -even if the CPU was given similar random+page pairs of accesses, that would still onyl be 14.32 MB/s peak bandwidth or half that for sustained random accesses -albeit without contention, while sustained page mode accesses would allow peak bandwidth of 57.27 MB/s, and video only using a small percentage of that time -and have higher theoretical max resolutions . . . but maybe changing the use of chipRAM like that would screw up PAULA, unless perhaps it had additional buffering/enhancements enabled for those access modes)

 

Edit:

Wait, it probably does support non-interleaved "bus stealing" access modes too (just like the OCS/ECS, but with 2x the clock speed, 32-bits wide, and with fast page support) . . . though the question would still be whether the CPU could be allowed to saturate the chipram bus like that, or only the video chips. (you'd really want to allow sustained fast page writes for the CPU to quickly copy data from fastRAM -albeit that would be even more useful with packed pixel graphics)

 

 

AKIKO was only on the CD32, which limited it's usefulness. That's why I said CBM would have been better off with something like Graffiti in the AGA. AKIKO was added later to get past the fact that they couldn't get a license on Graffiti.

Yes, so it was limited in use/introduction, even later (1994, just before CBM went under), and less convenient for programmers to port from PC games.

Edited May 24, 2011 by kool kitty89

[Chilly Willy]

Yes, it came out before AGA. There had been talk it would be part of AGA, but talks broke down between CBM and the makers of the Graffiti. If they HAD built Graffiti into the AGA, they could have had it run in 8 bitplane mode, giving two independent chunky playfields. That would have RULED games of the time.

Yeah, that would have been pretty awesome, especially if they'd tweaked the blitter to work more optimally with packed pixels. (not to mention working on the 32-bit bus . . . or at least double the clock speed of the old blitter and just rely on the existing block move/fill capabilities, but 32-bit chunky blitting abilities would have been great, so would be adding fast block/line fill with fast page mode writes for optimal fill rate -for clearing the framebuffer and filling polygons -even better is if the updated blitter could also access fastRAM when needed for faster blitting -efficient use of fast page mode copying, though like the 3DO's use of the same technique, you'd have contention with the CPU -except at least the 68020 and 030 have caches, unlike the ARM60)

 

Or if modifying the blitter caused too many compatibility issues (and adding a whole new blitter was too much cost overhead), they should at least have added basic VGA-type fill/raster op functions. (and require the CPU to do the rest . . . or the old blitter in cases where it was still OK)

 

The blitter worked on words, but if you think about what a number of different FP games of the time did (double the pixels horizontally to draw half the data), the blitter CAN be used in that respect for chunky graphics operations. But it would have been better to update the blitter. That was half the problem with AGA, it just wasn't enough. All they did was add two more bitplanes (going from 6 to 8 ), and the ability to fetch four times the data in the same time to support higher depths in higher resolutions. That's ALL they did... a fairly minor update to just the video. Applying that same update to other systems would have made the AGA much better - for example, four times the data for audio would have allowed four channels of stereo 16-bit 56 kHz sound. You could have done HD format on regular HD floppies instead of needing a special hacked floppy drive (1.4M and 2.8M even! ). The blitter could have been much faster.

 

 

The former. Just like 16 color hires on OCS/ECS, things would grind to a halt when trying to access chip ram during the active display. You would have definitely wanted some fast ram with such a system.

Could you signal the start and end of vblank for the CPU to know when there free access to chipRAM? (you'd need better than just a simple vblank interrupt for that if you wanted to precisely time it for both the start and end of vblank -more like hblank/scanline interrupts with the proper interval set for the entirety of thhe usable part of vblank)

 

The COPPER controls the video completely. You could EASILY set custom start and end points for the active display for a smaller screen allowing more time for the CPU and blitter. You could also change the depth on the fly for areas like a status bar at the bottom to allow CPU/blitter access earlier than using the same mode for the entire active display.

 

 

Could PAULA sill be used in those high bandwidth modes?

 

Paula did its DMA in the horizontal blank. The only thing overridden by the video DMA was sprites for wide screens (for scrolling) or the CPU/blitter.

 

 

Page mode was added to AGA. Remember my explanations of the fetch mode? The OCS/ECS did regular FULL cycles. At least it interleaved custom and 68000 accesses for realtively free CPU accesses on most commonly used video modes.

Right, you mentioned it using 1 random followed by 1 page mode access, but still otherwise interleaved? (and that page mode -and the 32-bit bus width- was only used for sprites and playfield/framebuffer scanning)

But is that the only way it could be used? You'd get much, much better average bandwidth if sustained burst accesses were used (like scanning an entire scanline and then giving the bus back, more like what ANTIC+GTIA did, but with page mode -and exactly what the Jaguar does, but at 64-bits wide as well as in 75 ns page mode).

Not only would that give you a lot more video bandwidth in general, but it would give a hell of a lot more chipram bandwidth to the CPU than old fashion interleaving could. (more so if the CPU was fast enough to read/write in fast page mode -even if the CPU was given similar random+page pairs of accesses, that would still onyl be 14.32 MB/s peak bandwidth or half that for sustained random accesses -albeit without contention, while sustained page mode accesses would allow peak bandwidth of 57.27 MB/s, and video only using a small percentage of that time -and have higher theoretical max resolutions . . . but maybe changing the use of chipRAM like that would screw up PAULA, unless perhaps it had additional buffering/enhancements enabled for those access modes)

 

Edit:

Wait, it probably does support non-interleaved "bus stealing" access modes too (just like the OCS/ECS, but with 2x the clock speed, 32-bits wide, and with fast page support) . . . though the question would still be whether the CPU could be allowed to saturate the chipram bus like that, or only the video chips. (you'd really want to allow sustained fast page writes for the CPU to quickly copy data from fastRAM -albeit that would be even more useful with packed pixel graphics)

 

That would have been nice, but only graphics (playfield and sprites) benefited from page mode (IIRC). The CPU could write 32 bits, but did so at the "normal" speed.

[kool kitty89]

The blitter worked on words, but if you think about what a number of different FP games of the time did (double the pixels horizontally to draw half the data), the blitter CAN be used in that respect for chunky graphics operations. But it would have been better to update the blitter.

Even if it works on words, it could still move data on byte (or bit -given the 1bpp planes its designed for) boundaries, so still useful for blitting full-res 8-bit chunky graphics with 2 pixels at a time. (block fill and line fill would have been really good for fast page mode or 32-bit support though -block copy would only be useful for page mode if you could use the blitter in fastRAM or if there was some added buffering or caching -line buffers, a texture cache, etc)

 

On the Atari Falcon, 16-bit chunky pixels ARE supported, so the blitter is useful for single pixels (not sure how the speed compares to the 68030, both are limited to a 16-bit bus, so different trade-offs than the Amiga -the blitter is also boosted to 16 MHz like in the MSTE, but I'm not sure if there's fast page mode support -which would only really be useful for fill operations and such where you'd have successive writes -if it did support that, it could have a peak fill rate of 16M 16-bit pix/s). VIDEL also supported pretty flexible resolutions, so you could do true double wide (1/2 res) pixels at 16-bit depth, so even more useful. (the Atari blitter is more rudimentary than the Amiga one, but when being used for such purposes, I think the Amiga blitter would lose many of its advantages that it has for manipulating planar graphics -especially masking- -though the Falcon still has to work with planes for 8-bit or lower depth and there's no dual playfield modes AFIK, that would have been a really nice feature for the STe to have for that matter, regardless of any VGA-like features -having 2 independent, scrollable 4-bit framebuffers with 2 16 color palettes would put it ahead of the amiga for many things)

 

 

That was half the problem with AGA, it just wasn't enough. All they did was add two more bitplanes (going from 6 to 8 ), and the ability to fetch four times the data in the same time to support higher depths in higher resolutions. That's ALL they did... a fairly minor update to just the video. Applying that same update to other systems would have made the AGA much better - for example, four times the data for audio would have allowed four channels of stereo 16-bit 56 kHz sound. You could have done HD format on regular HD floppies instead of needing a special hacked floppy drive (1.4M and 2.8M even! ). The blitter could have been much faster.

Yes it's definitely a "too little to late" sort of situation with that. ESC should have included some of those AGA features at the very least (8 bitplanes, perhaps not with full 256 color registers, but at least allowing 4-bit dual playfield modes -and perhaps allowing 3-bits for shadow or extending CRAM to 64 or 128 entries with 2 or 1-bits of shadow/luminance), that and fast page and/or 32-bit DMA support (especially given ECS was showcased with the 32-bit A3000 -though 32-bit access could have been limited to the CPU too -better than forcing 16-bit access to the CPU along with everything else). Perhaps fast page mode and 32-bits, but not 14.3 MHz. (which would make more sense for 1990, cheap 120/140 ns FPM DRAM rather than 70 ns -or they could have tweaked the clock speeds more moderately like 8.95 MHz with 100 ns DRAM I mused on earlier)

Increased bandwidth might have made 640x480 16 color modes realistic to use. (so at least 1/2 of what VGA added, but not the packed pixels)

 

That would have been nice, but only graphics (playfield and sprites) benefited from page mode (IIRC). The CPU could write 32 bits, but did so at the "normal" speed.

So the CPU would only ever be able to do fast page accesses in fastRAM?

 

Having fast page facilities for the main CPU would have been really useful, beyond just copying a complete frame over to chipRAM, it could have been used for fast 3D blitting or 3D texture mapping. (read from fastRAM, write directly to the back buffer in chipRAM, maintaining fast page mode reads/writes much of the time -especially if packed pixels were directly supported)

 

 

The CPU can't even read/write to chipRAM at the full (non-interleaved, non-fast page) bus speed, but only interleaved? (ie can it even read/write to chipRAM at 3.58 MHz -14.3 MB/s, but would be forced to access at the same slow 1985 speed for an effective 1.79 MHz bus speed -or 7.16 MB/s . . . though with full bus speed support -even with no page mode accesses- you could still do better than 3.58 MHz/280 ns for the RAM used in AGA, given the 70 ns RAM used, random accesses -RAS to RAS interval- should have been under 175 ns, probably around 165 ns, so definitely within 3 CPU cycles for the A1200, 4 for a 25 MHz, 6 for 32 MHz, 5 for 28.6 MHz, etc)

 

That would have made the CD32 (or unexpanded A1200) even more crippled. (if peak CPU bandwidth was only 7.16 MB/s)

[Chilly Willy]

So the CPU would only ever be able to do fast page accesses in fastRAM?

 

Right... which is part of what makes fast ram fast.

 

Some "accelerator" cards were better than others about how fast the fast memory was. The CBM cards were notorious for not being very fast.

 

 

Having fast page facilities for the main CPU would have been really useful, beyond just copying a complete frame over to chipRAM, it could have been used for fast 3D blitting or 3D texture mapping. (read from fastRAM, write directly to the back buffer in chipRAM, maintaining fast page mode reads/writes much of the time -especially if packed pixels were directly supported)

 

 

The CPU can't even read/write to chipRAM at the full (non-interleaved, non-fast page) bus speed, but only interleaved? (ie can it even read/write to chipRAM at 3.58 MHz -14.3 MB/s, but would be forced to access at the same slow 1985 speed for an effective 1.79 MHz bus speed -or 7.16 MB/s . . . though with full bus speed support -even with no page mode accesses- you could still do better than 3.58 MHz/280 ns for the RAM used in AGA, given the 70 ns RAM used, random accesses -RAS to RAS interval- should have been under 175 ns, probably around 165 ns, so definitely within 3 CPU cycles for the A1200, 4 for a 25 MHz, 6 for 32 MHz, 5 for 28.6 MHz, etc)

 

That would have made the CD32 (or unexpanded A1200) even more crippled. (if peak CPU bandwidth was only 7.16 MB/s)

 

Which is why the VERY FIRST upgrade recommended for A1200 owners was "true" fast ram. It could make your A1200 MUCH faster than the stock chip mem only model.

 

CBM really needed to push the Hombre chipset out, but that wasn't meant to be.