Amiga 4000 vs 1200

[NightSprinter]

Rob, thing is it doesn't help much if composite only outputs monochrome on an American TV.

[FastRobPlus]

Ah, got it.

[kool kitty89]

4000 and 1200 share the same 32-bit bus, but the 4000 has Zorro II and III expansion capability. Your A1200 could too if you get a Mediator and stuff it into a case. Not wise economically to do so, but there it is. No reason to get a 4000 if you have an accelerated A1200. 4000 is ugly too IMO, but I love the keyboard. Sexiest Amiga's are the 1000 and 3000.

Huh, the 1200 has a 32-bit bus? I thought it was all 16-bit (for chipRAM and the fastRAM expansion bus -or at least for chipram).

[Tempest]

Just thought I'd bump this because just the other day I found myself pining for a 'big box' amiga. My 1200 is great and it's pretty decked out (CF card for the HD, 030 accelerator with lots of memory, PCMCIA to CF Card adapter, ClassicWB, etc), but it still looks 'cheap'. Since a 4000 is probably out of the question (hard to find and a bit buggy), and the 3000 doesn't really offer that much and they tend to be hard to find, I'm back to either a 1000 or 2000. Like I said earlier, the 1000 is my dream Amiga, but it's so limited so I guess that leaves me looking for a 2000. I'm not getting rid of my 1200 because WHDLoad is great, but I'm thinking that a 2000 would be a nice addition to my collection (it's a bit big for my tastes though).

 

Is a 2000 a good choice for a classic expandable Amiga?

What should I look for when buying one?

What's the average cost of a 2000?

Should I look for a 3000 instead?

 

Tempest

 

I like the 2000, and the battery damage is normally less invasive than you find on the 3000.

In the A3K, the Amber scan doubler can get zapped by the battery acid...

The 3000 is also pricier, has less expansion space, suffers heat build up when fully loaded, uses a harder to replace/find floppy drives, has an anemic PSU that is turned on by a rube-goldberg'esque stick (look in the case!), and uses oddball DIP chip RAM you can never find.

 

So my advice? Get the 3000.

 

Because all of the above is moot when you see how nice the 3000 looks and feels in person. It was the last good thing C= ever produced. The 1200 and 4000 were more capable, but were also-ran toys by the time they were released. The 3000 was the 2nd most powerful PC in the world at the time of its release (beneath the Mac II x) and was half the price. Byte magazine praised the computer as the best price to power machine they'd seen, even while warning that it needed a stronger parent company to have a hope of success.

How impossible/expensive are Amiga 3000 drives? Are they specific to the 3000 or can you use a drive from a 2000 or other amiga?

 

Tempest

[+save2600]

Huh, the 1200 has a 32-bit bus? I thought it was all 16-bit (for chipRAM and the fastRAM expansion bus -or at least for chipram).

Nope. You're confusing this machine with the Atari Falcon

 

http://www.absolutea...pics/Amiga_1200

 

...the PCMCIA architecture was 16-bits, which is why you wouldn't want to use it for Fast RAM as it would actually slow your system down. Come to think of it, I believe the 2MB Chip RAM and Kickstart is only 24-bits wide, but whenever you added Fast RAM through the expansion bus with an 030 or greater, all of that RAM was 32-bits of course. One of the reasons why its nice to remap Kickstart to expansion RAM. Little bit of a performance boost. Your 030 has to have an MMU of course or the expansion card has to have proprietary hardware in order to remap Kickstart.

Edited April 18, 2011 by save2600

[FastRobPlus]

 

How impossible/expensive are Amiga 3000 drives? Are they specific to the 3000 or can you use a drive from a 2000 or other amiga?

 

Tempest

 

The 500, 2000, 3000 use the same drive mechanisms. The issue is the outer housing of the mechanism and the eject button are different.

I suspect (but have never tried it) the mechanism from a 500 would be a direct replacement.

The biggest issue is actually the drive eject button. It’s unique for the A3000 and breaks easily. It’s also impossible to find.

[+wood_jl]

Huh, the 1200 has a 32-bit bus? I thought it was all 16-bit (for chipRAM and the fastRAM expansion bus -or at least for chipram).

Nope. You're confusing this machine with the Atari Falcon

Oooh, I know you enjoyed that.

 

 

...the PCMCIA architecture was 16-bits, which is why you wouldn't want to use it for Fast RAM as it would actually slow your system down. Come to think of it, I believe the 2MB Chip RAM and Kickstart is only 24-bits wide, but whenever you added Fast RAM through the expansion bus with an 030 or greater, all of that RAM was 32-bits of course. One of the reasons why its nice to remap Kickstart to expansion RAM. Little bit of a performance boost. Your 030 has to have an MMU of course or the expansion card has to have proprietary hardware in order to remap Kickstart.

 

 

ANOTHER Amiga enthusiast told me.....

 

Yeah the A1200 is pretty much a castrated A4000.. It has the AGA chipset, but only a 16bit expansion bus.. And really, AGA was a piss poor compromise on what AAA would have been. Most serious AMIGA guys consider the A3000 to be the APEX of commodore engineering.. The A1200 and A4000 were just cheap crap that got rushed to market to try and buy some time for commodore and keep the company afloat a while longer..

[OldSchoolRetroGamer]

ANOTHER Amiga enthusiast told me.....

 

Yeah the A1200 is pretty much a castrated A4000.. It has the AGA chipset, but only a 16bit expansion bus.. And really, AGA was a piss poor compromise on what AAA would have been. Most serious AMIGA guys consider the A3000 to be the APEX of commodore engineering.. The A1200 and A4000 were just cheap crap that got rushed to market to try and buy some time for commodore and keep the company afloat a while longer..

 

That is just an opinion and sounds like a biased one at that, I am guessing he bought / owned the 3000 and never bothered with the 1200 or 4000?

The only way a 1200 was a "castrated" A4000 was maybe because it did not have built in slots like the big box 4000 but I bet more people owned the A1200 and as a result a lot of expansions and accelerators came out for it.

[+save2600]

That is just an opinion and sounds like a biased one at that, I am guessing he bought / owned the 3000 and never bothered with the 1200 or 4000?

The only way a 1200 was a "castrated" A4000 was maybe because it did not have built in slots like the big box 4000 but I bet more people owned the A1200 and as a result a lot of expansions and accelerators came out for it.

Right, and the guy is full of shit talking about 16-bits. The expansion bus *is* 32-bits wide, just like the CD32, A4000 and A3000.

[+wood_jl]

That is just an opinion and sounds like a biased one at that, I am guessing he bought / owned the 3000 and never bothered with the 1200 or 4000?

The only way a 1200 was a "castrated" A4000 was maybe because it did not have built in slots like the big box 4000 but I bet more people owned the A1200 and as a result a lot of expansions and accelerators came out for it.

Right, and the guy is full of shit talking about 16-bits. The expansion bus *is* 32-bits wide, just like the CD32, A4000 and A3000.

 

Are you sure? This isn't a 68020 machine, it's an el-cheapo 68EC020 which has a 24-bit expansion bus, like a 68000, no? I'm not proclaiming to know, I'm just asking. So is it 32-bit or 24-bit?

Edited April 18, 2011 by wood_jl

[roland p]

The '24-bit' refers to the address space. That would be 16MB. Its a 32-bit processor with 24-bit addressing space.

 

A stock A1200 had 2MB of 'chip-ram', which is used by the custom-chips too.

By expanding the memory with 'fast-ram' through the expansion the machine became faster since this ram is not shared. I got that from this thread: http://eabmobile.abime.net/showthread.php?p=607286#post607286

[+save2600]

Are you sure? This isn't a 68020 machine, it's an el-cheapo 68EC020 which has a 24-bit expansion bus, like a 68000, no? I'm not proclaiming to know, I'm just asking. So is it 32-bit or 24-bit?

Ahh jeez. Have you been spending time in the Jaguar forum or what?

 

I guess by that definition, a stock A1200 might be 24-bits because access to RAM and its Kickstart is just that. But hardly ANYONE just uses the EC020 built into their machines though. Damn thing should have just come with an 030 in the first place.

 

But wait, there's more! How come the system speed is nearly doubled on a stock A1200 simply by adding Fast RAM in the trapdoor? Not talking about including an 030 here either. Somebody else care to extrapolate? Is it just as simple as Chip RAM/processor/co-processor contention or is it that the entire architecture of the A1200 is indeed 32-bits wide? AGA is supposed to be a 32-bit chip, but they always talk about 24-bit color...

[FastRobPlus]

Im not a huge 1200 lover, but I have to admit it was pretty slick back in the day when you could add a trapdoor expansion with an FPU, 2MB - 8MB FastRAM, and clock for something like $150.

The system with that simple upgrade was so fast I doubt most folks would have needed one of the pricier 030, 040, 060 trap door accelerators.

Although I think by the early 1990s the 030 upgrades were becoming quite cheap.

[kool kitty89]

Huh, the 1200 has a 32-bit bus? I thought it was all 16-bit (for chipRAM and the fastRAM expansion bus -or at least for chipram).

Nope. You're confusing this machine with the Atari Falcon

I know the falcon (and some macs) opted for 16-bit wide buses (in the Falcon's case, probably more due to cost than compatibility -for compatibility, they could always have dropped to 16-bit modes but also supported 32-bit bus as well -but with 16 bit alone, you cut back on traces used), but I'd gotten the impression that the 1200 used a 16-bit bus as well from several people. (actually odd that the Falcon didn't use a 16 Mhz 68EC020 rather than the 68030, that would have been a much better out of the box trade-off than the 16 bit bus -if they wanted really low-cost versions, they could have opted for a 16 MHz 68000 for that matter -you had the blitter and -more so- DSP to take up a lot of the grunt anyway -lack of a fastRAM bus on the falcon was also unfortunate, but at least it had packed pixel support -and 16bpp graphics for that matter- unlike the AGA chipset, though I think packed pixels my be limited to 16bpp modes and 8bpp and lower is all planar -which would be unfortunate)

 

Maybe the 16-bit comment was for chipRAM and not fastRAM.

 

 

...the PCMCIA architecture was 16-bits, which is why you wouldn't want to use it for Fast RAM as it would actually slow your system down. Come to think of it, I believe the 2MB Chip RAM and Kickstart is only 24-bits wide, but whenever you added Fast RAM through the expansion bus with an 030 or greater, all of that RAM was 32-bits of course. One of the reasons why its nice to remap Kickstart to expansion RAM. Little bit of a performance boost. Your 030 has to have an MMU of course or the expansion card has to have proprietary hardware in order to remap Kickstart.

I'm not sure how they could have managed 24-bits for 2 MB without some weird addressing or wasted RAM. (wouldn't 24 bits also be a pain for the CPU to work with -maybe it drops to 16-bits instead)

Again, I think it may have been chipRAM that was being referenced with the 16-bit comment, not fasRAM. (which also means the A1200 and CD32 would have been limited to 16 bit work RAM out of the box)

 

 

 

 

 

ANOTHER Amiga enthusiast told me.....

 

Yeah the A1200 is pretty much a castrated A4000.. It has the AGA chipset, but only a 16bit expansion bus..

Maybe 16-bit chipRAM, but it seems like fasRAM was definitely 32-bit.

 

The A1200 wasn't really a castrated 1200 though . . . it was a low-end model using some of the same advances as the 4000 had done. (albeit CBM really should have pushed 14.3 MHz A500 derivatives prior to that, perhaps even '020 based lower-end models prior to AGA as well)

 

 

And really, AGA was a piss poor compromise on what AAA would have been. Most serious AMIGA guys consider the A3000 to be the APEX of commodore engineering.. The A1200 and A4000 were just cheap crap that got rushed to market to try and buy some time for commodore and keep the company afloat a while longer..

 

I don't see how the A4000 was cheap crap at all. It was better in every respect than the 3000 (albeit, less so for the time) out of the box. I agree that AGA was really a poor upgrade to the overall system (no blitter upgrade at all, no packed pixel support, etc -albeit the CD32 supported hardware packed to planar conversion); it wouldn't have been so bad back in '89 or a bit earlier even (or similar but limited to 15 or 12-bit RGB), but they really should have been aiming more at something on par or better than VGA/SVGA. (packed pixel graphics, fast page mode DRAM support, and a blitter upgrade to cater to that, rather like the Amiga team went on to do with the Lynx blitter -and CBM should have had that by '89 or '90)

 

The ST and Amiga both lagged badly in terms of hardware upgrades (especially 1st party) and general successors/evolution; Atari was actually better off in many respect as far as upgraded hardware went (far from what they should have done though), and the Amiga only remained more attractive as it had been more capable from the start. (Atari -and PCs- thushad a lot more room to pull ahead of the aging Commodore hardware, but Atari ended up doing a mediocre job of pushing that -albeit the Falcon chipset WAS better than AGA at least, TT was arguably better than the A3000 on a technical level too- but PCs definitely pulled ahead rapidly -a mix of advantages and trade-offs in the late 80s, but pretty much unmitigated advantages by the early/mid 90s -with the exception of still not catering to analog SDTV resolution editing, though the arrival of digital video editing addressed that as well)

 

 

 

 

 

 

That is just an opinion and sounds like a biased one at that, I am guessing he bought / owned the 3000 and never bothered with the 1200 or 4000?

The only way a 1200 was a "castrated" A4000 was maybe because it did not have built in slots like the big box 4000 but I bet more people owned the A1200 and as a result a lot of expansions and accelerators came out for it.

Well, more like the 1200 was a much lower end model out of the box without any fasRAM and using a much less powerful 68020 (or EC020 to be specific -not really notable since all it did was cut the pin count by limiting the address bus to 24-bit/16 MB -unlike the 386SX also cutting data lines to 16-bit so you didn't have the option to use 32-bits at all and also couldn't use external caching).

 

It was a lower-end machine, so that's really sort of a given. (I agree with the AGA comments to a degree -not so much in the specific reference to AAA as that was way overkill in some areas, but AGA was definitely weak for the time: if AGA had all its current features plus packed pixel support, buffering for efficient fast-page mode use -and/or wider memory buses- and a blitter to match -maybe even with some added support for 3D acceleration assistance- then it would have been pretty good for the time, but as it was, AGA added very little of practical use outside of static -or limited animated- screens; the lack of highcolor also hurt it a lot for the time -the falcon was lacking too, but it was a lot closer to market standards at least -and the DSP meant if DID have a decent route for 3D acceleration too )

 

 

 

 

 

That is just an opinion and sounds like a biased one at that, I am guessing he bought / owned the 3000 and never bothered with the 1200 or 4000?

The only way a 1200 was a "castrated" A4000 was maybe because it did not have built in slots like the big box 4000 but I bet more people owned the A1200 and as a result a lot of expansions and accelerators came out for it.

Right, and the guy is full of shit talking about 16-bits. The expansion bus *is* 32-bits wide, just like the CD32, A4000 and A3000.

A shame the CD32 didn't use fasRAM out of the box . . . 1 MB fasRAM and 1 MB chipRAM would have made it a lot more usable. (still really underpowered for the time, but a fair bit better off at least)

An amiga based game system would have been great for '89 (or even as late as 1991), but they pushed the extremely dated (and poorly executed) C64GS instead, followed by the (again, poorly executed -also rather niche) CDTV.

 

 

 

 

 

 

 

Are you sure? This isn't a 68020 machine, it's an el-cheapo 68EC020 which has a 24-bit expansion bus, like a 68000, no? I'm not proclaiming to know, I'm just asking. So is it 32-bit or 24-bit?

Ahh jeez. Have you been spending time in the Jaguar forum or what?

Except it's the opposite: Jag's 64-bitness comes from the external bus (internally, the GPU/OPL/blitter are a mix of 32, 64, and heavily buffered 16-bit logic -not buffered for texture mapping, unfortunately)/

 

I guess by that definition, a stock A1200 might be 24-bits because access to RAM and its Kickstart is just that. But hardly ANYONE just uses the EC020 built into their machines though. Damn thing should have just come with an 030 in the first place.

24-bit data bus? (not address bus)

 

But wait, there's more! How come the system speed is nearly doubled on a stock A1200 simply by adding Fast RAM in the trapdoor?

More than that too since the CPU and coprocessors can both run at full bore. (so the blitter can spend far more time on the bus on top of the CPU running at full width without wait states for coprocessor access)

 

Is it just as simple as Chip RAM/processor/co-processor contention or is it that the entire architecture of the A1200 is indeed 32-bits wide? AGA is supposed to be a 32-bit chip, but they always talk about 24-bit color...

Is there ANYTHING in the AGA chipset that's 32-bits (or even anything other than 16-bits)? I was under the impression it was the same old 16-bit blitter at the same speed (higher clock speed would do little since you're limited to random access DRAM bandwidth anyway -it would help a little, going from 280 ns closer to 180-200 ns; a 14.3 MHz blitter could do 3 cycle delayed accesses at ~209 ns vs the 280 ns of the OCS/ECS; you'd need fast page mode support or a wider bus to get more bandwidth than that).

 

24-bits is just the depth of the master palette, the display depth is limited to 8-bit planar graphics or less. It's generally worse than VGA (let alone SVGA), though you could use the blitter to handle packed to planar bitmap conversion and be fairly close to unaccelerated VGA with a similarly powerful CPU.

 

For games, the best thing about AGA is probably the extended dual playfield support for 2 4-bit layers rather than 3-bit of the OCS (at least I think it supports that). That limits color of course (2 15 color planes rather than 1 255/62/31/etc), but it allows faster rendering due to the dual framebuffers just like the OCS dual playfield. (which was limited to 2 7 color layers -plus the boarder color)

 

 

Of course, if CBM really was having trouble extending the old architecture, they could have primarily focused on consolidating/cost reducing the existing hardware (with some basic enhancements that didn't require really intimate knowledge of the original designs -doubling Paula's audio would have been nice and pretty simple, maybe support the 14-bit channel pairing in hardware too, rather than having to work around with dual 8-bit streams with the proper offsets). And then just "tack on" hardware upgrades with the old hardware embedded for compatibility, or something like AGA (more so with basic packed planar conversion logic as the Akika chip added) with more powerful additions outsourced or bought off the shelf. (various DSPs could have helped a great deal for multipurpose coprocessing -sound, graphics, math, etc- or TI's TMS340 series GPUs for that matter; very flexible and the older 34010 series might have been cheap enough to add by the early 90s -also a pretty flexible/general purpose chip, optimized for video, but capable of various DSP type tasks and even CPU-like tasks; good for 2D and 3D acceleration and could be useful for audio processing or general fixed/floating point math coprocessing as well)

The other route would be going mainly with CPU grunt, but that's far less cost effective in general.

 

 

Hmm, it would have been interesting if Atari had gone more in that direction with the Falcon: have bottom end models with a 16 MHz 68k, no FPU (maybe a socket), VIDEL video, fasRAM expansion, but a TMS34010 for general purpose coprocessing (best for graphics, but also good for sound, math, etc -and seems to have been much easier to program than most traditional DSPs including the MC56k, very general purpose more like a CPU but with different performance and feature optimizations), probably with 32-bit access to video RAM (if not already using 64-bit wide shared RAM like the TT SHIFTER -not sure what VIDEL uses) and a general purpose expansion port in addition to some internal sockets. (and higher end models with '020s, '030s, '040s, etc -I think the TMS34010 may be faster at floating point math than a 68801/2, I know its faster than a 287, though it's probably significantly slower than the '040 FPU)

Of course, if Atari had been further ahead with their computers in other ways, they could have waited a bit and added the jaguar chipset instead of anything off the shelf. (with the bugs worked out, the Jag GPU should have been generally better than the 340, and obviously more cost effective for atari due to owning the IP -though you've got R&D costs and production volumes to consider too)

[FastRobPlus]

Interesting observations regarding bus speeds, chipset roadmaps, etc., but honestly I’m betting the topic starter is (was) more interested in a comparison of the two systems as collectibles.

[Chilly Willy]

The AGA chipset is a curious beast, and the A1200 just makes it even curiouser. AGA uses a 32 bit bus to chip ram that runs at twice the frequency used in the old OCS/ECS chipset. The "normal" mode used to fetch video data was backwards compatible - it fetched 16 bits every other time. You could change the fetch mode to "wide", which fetches 32 bits instead of 16, "fast", which fetches 16 bits every time instead of every other time, or "fast-wide", which fetches 32 bits every time. Some video modes need fast-wide fetch to get all the data they need. The fetch mode also affects the sprites - in wide or fast mode they are 32 pixels wide instead of 16, and in fast-wide mode are 64 pixels wide.

 

The CPU in the A1200 is an MC68EC020; it has a 32-bit data bus, and a 24-bit address bus. The "16-bit expansion" is the PC Card slot on the side, and it uses the old 16-bit PC Card specs... which is slow. Don't use it for ram expansion. The belly slot uses all 32 data bits and all 24 address bits; it is also full-speed, so ram in the belly slot will be fast. To get more than 8 MBytes of fast ram, you HAVE to have an accelerator in the belly slot; as mentioned, the 68EC020 only has 24 address bits, so it can only address 16 MBytes of space, of which only 8 MBytes can be fast ram. An 030 or better accelerator will have all 32 address bits and allow for more fast ram.

[NightSprinter]

So, any thoughts on the new 64MB equipped EC030 accelerator from AmigaKit? Given how expensive ones with a working MMU are, I've been pondering it.

[+save2600]

So, any thoughts on the new 64MB equipped EC030 accelerator from AmigaKit? Given how expensive ones with a working MMU are, I've been pondering it.

Seems to be a good product. Only negative I've heard maybe is how hot it gets. Might be able to super glue a low profile heat sink to her though...

[kool kitty89]

The AGA chipset is a curious beast, and the A1200 just makes it even curiouser. AGA uses a 32 bit bus to chip ram that runs at twice the frequency used in the old OCS/ECS chipset. The "normal" mode used to fetch video data was backwards compatible - it fetched 16 bits every other time. You could change the fetch mode to "wide", which fetches 32 bits instead of 16, "fast", which fetches 16 bits every time instead of every other time, or "fast-wide", which fetches 32 bits every time. Some video modes need fast-wide fetch to get all the data they need. The fetch mode also affects the sprites - in wide or fast mode they are 32 pixels wide instead of 16, and in fast-wide mode are 64 pixels wide.

Is that just for the framebuffer management, or also for blitter, copper, etc, operations? (32-bit phrase capabilities could be pretty useful for the blitter, at least for traditional 2D stuff)

 

Also, when you say double the speed, do you mean double the speed of the OSC/ESC chipset going full-bore and saturating the bus (halting the CPU or using fastRAM)?

 

If that's the case, it would mean 140 ns accesses in "fast" mode, but that would imply fast page (burst mode) accesses limited to working within a common row of DRAM cells. (so good for reading the framebuffer, doing line/block fills/erasing, etc, but not good for copying graphics data -if you had the framebuffer in a separate bank of DRAM chips than the texture data, you could make good use of fast page writes to the framebuffer/destination side of things, but I don't think any Amigas were configured that way -except perhaps using software rendering with the CPU using fastRAM as source and chipRAM as destination, assuming the CPU could saturate the bus when needed and wasn't limited to 460 ns interleaved accesses -you could get burst mode performance in a single bank for copy/moves, but that would require additional buffering/caching to achieve)

 

 

Hmm, for things where you really needed packed pixels (software rendered 3D/pseudo 3D stuff -be it limited amounts mixed with 2D, or most/all of the game), a good blitter routine probably wouldn't have made AGA much worse than a decent EISA VGA card using VRAM. Even if limited to slow interleaved accesses, it probably wouldn't be much (if at all) worse than a slower EISA card using plain DRAM, let alone a slower 16-bit ISA card. (though an 8 MHz 16-bit card with VRAM could have an advantage)

Having Akika from the start would have made things a bit easier too (faster/simpler operation compared to using the blitter) and would have made adding a CD-ROM drive easier. (assuming it was like the CD32 and not a simpler chip just for packed to planar conversion)

 

It still was a far cry from the performance gap of the Amiga in the mid 80s compared to PCs. (aside from the out of the box 2D rendering advantages -granted, PC accelerators weren't used for 2D or 3D games until around 1995 anyway, you were mainly relying on CPU resource to drive the system further -not even a fast DSP like the Falcon got; pairing Paula channels for ~14-bit stereo could roughly approximate what the SB-16 was offering -sans the FM, so it was more of a matter of CPU grunt to catch up -given the lack of substantial hardware acceleration that defined the original Amiga)

 

 

Without fasRAM, you're a lot worse off though, that definitely hurt the CD32. (1 MB chipRAM and 1 MB fastRAM could have meant a substantial performance boost, though still would have left it pretty underpowered for the generation -maybe if they added a decent, relatively low-cost DSP or GPU-like coprocessor it could have become a real competitior . . . of course CBM collapsed in 1994 anyway, so that's moot)

Better would have been to invest in a custom design that met similar requirements, but was more cost optimized for their target and catered to in-house manufacturing (assuming CSG still had an advantage in vertical integration over outsourcing to overseas chip vendors), or at least cut out overhead by owning the IP. (at the expensive of R&D overhead . . . which wouldn't have paid off if a similar off the shelf product had reached sufficient volumes/competition/cost reduction to outstrip those in-house advantages -various off the shelf DSPs or TI's 340 series GPUs)

Edited April 24, 2011 by kool kitty89

[Chilly Willy]

The AGA chipset is a curious beast, and the A1200 just makes it even curiouser. AGA uses a 32 bit bus to chip ram that runs at twice the frequency used in the old OCS/ECS chipset. The "normal" mode used to fetch video data was backwards compatible - it fetched 16 bits every other time. You could change the fetch mode to "wide", which fetches 32 bits instead of 16, "fast", which fetches 16 bits every time instead of every other time, or "fast-wide", which fetches 32 bits every time. Some video modes need fast-wide fetch to get all the data they need. The fetch mode also affects the sprites - in wide or fast mode they are 32 pixels wide instead of 16, and in fast-wide mode are 64 pixels wide.

Is that just for the framebuffer management, or also for blitter, copper, etc, operations? (32-bit phrase capabilities could be pretty useful for the blitter, at least for traditional 2D stuff)

 

The change in width was just for sprites, and playfields just got more data more quickly. Everything else still worked with words like normal for compatibility reasons. Fast/wide also affected the alignment of data - there was a "bug" where moving the screen made part of it disappear - that was when the screen started on the wrong alignment for the fetch mode. Much like in fast-wide where sprites were 64 bits wide, video data had to be 64 bit aligned to fetch properly. There was no attempt to make the BLITTER better since the CPU was faster for AGA class machines. Of course, if they had made the BLITTER better, that might not have been true, so it's a bit of a circular argument.

 

 

Also, when you say double the speed, do you mean double the speed of the OSC/ESC chipset going full-bore and saturating the bus (halting the CPU or using fastRAM)?

 

Double the clock rate when accessing memory. You had twice as many access cycles per line compared to OCS/ECS. While the OCS/ECS did everything at 7MHz, AGA did everything at 14MHz.

 

 

Without fasRAM, you're a lot worse off though, that definitely hurt the CD32. (1 MB chipRAM and 1 MB fastRAM could have meant a substantial performance boost, though still would have left it pretty underpowered for the generation -maybe if they added a decent, relatively low-cost DSP or GPU-like coprocessor it could have become a real competitior . . . of course CBM collapsed in 1994 anyway, so that's moot)

Better would have been to invest in a custom design that met similar requirements, but was more cost optimized for their target and catered to in-house manufacturing (assuming CSG still had an advantage in vertical integration over outsourcing to overseas chip vendors), or at least cut out overhead by owning the IP. (at the expensive of R&D overhead . . . which wouldn't have paid off if a similar off the shelf product had reached sufficient volumes/competition/cost reduction to outstrip those in-house advantages -various off the shelf DSPs or TI's 340 series GPUs)

 

The CD32 would have been MUCH better with 2MB chip + 2MB fast and a 28MHz 030. 2MB chip and a 14MHz 020 was just too weak for the time. 2+2+030 would have been closer to consoles of the mid to late 90s. AKIKO + BLITTER could have helped with chunky affine texture mapping, but it still would have lagged behind the PSX, Saturn, and N64. It would have needed a separate rasterizer (maybe in a beefed up BLITTER) to compete at the same level as those consoles.

[kool kitty89]

The change in width was just for sprites, and playfields just got more data more quickly. Everything else still worked with words like normal for compatibility reasons. Fast/wide also affected the alignment of data - there was a "bug" where moving the screen made part of it disappear - that was when the screen started on the wrong alignment for the fetch mode. Much like in fast-wide where sprites were 64 bits wide, video data had to be 64 bit aligned to fetch properly. There was no attempt to make the BLITTER better since the CPU was faster for AGA class machines. Of course, if they had made the BLITTER better, that might not have been true, so it's a bit of a circular argument.

You'd think they'd want to improve things across the board, not just make the CPU do more work . . . I mean it's not like the Amiga in '85 had a weak CPU with coprocessors to make up for it, it had a powerful CPU AND coprocessors to assist it. (obviously, you'd want to make the coprocessors optimized for things the CPU is less efficient at)

If nothing else, the addition of fast packed pixel to planar conversion in the blitter would have made sense.

 

At that time, PCs had already been moving more and more towards hardware acceleration on the consumer market (albeit mainly for windowing early on -not much game support until windows based games got really popular).

 

Same thing for a DSP, different things a CPU and DSP would be good at.

Although, if you significantly enhanced the blitter (32-bit accesses, fast page mode for some operations, support for packed pixel manipulation, maybe even scaling/rotation/affine line rendering logic) and you added a DSP on top of that, then you'd have a lot more room to cut back on CPU resource. (probably a lot more cost effective in general too, of course, high-end models would have powerful CPUs either way)

 

Hmm, in that respect, if CBM wasn't really in a position to push heavily with custom hardware, the TMS340 again seems like an interesting possibility. (both for blitting capabilities and for general math/audio coprocessing) Or just a DSP (TI, Motorola, etc) used for graphics, math, sound, etc as needed. (probably not nearly as easy to work with and less optimized for graphics stuff)

 

Also, when you say double the speed, do you mean double the speed of the OSC/ESC chipset going full-bore and saturating the bus (halting the CPU or using fastRAM)?

 

Double the clock rate when accessing memory. You had twice as many access cycles per line compared to OCS/ECS. While the OCS/ECS did everything at 7MHz, AGA did everything at 14MHz.

Yes, but what about the actual memory accesses?

 

It was my understanding that the OCS/ECS chipRAM was all accesses at 280 ns (that's 2 7.16 MHz clock cycles or an effective 3.58 MHz), or 560 ns interleaved performance. (4 clock cycles per access to share 50/50 with the 68k -with no wait states on the 68k end)

So the peak bandwidth of the OSC/ECS would be 7.16 MB/s (16-bits at 3.58 M transfers/s).

 

14.3 MHz wouldn't mean anything unless the RAM was configured to be fast enough to allow single cycle accesses. Even 140 ns accesses would be much too fast for random accesses (and thus any interleaved accesses), and if burst-mode was supported, it would mainly have been useful for scanning out the playfields/framebuffers and similar examples of sequential accesses within a consistent shared row of DRAM cells.

 

The CD32 would have been MUCH better with 2MB chip + 2MB fast and a 28MHz 030. 2MB chip and a 14MHz 020 was just too weak for the time. 2+2+030 would have been closer to consoles of the mid to late 90s. AKIKO + BLITTER could have helped with chunky affine texture mapping, but it still would have lagged behind the PSX, Saturn, and N64. It would have needed a separate rasterizer (maybe in a beefed up BLITTER) to compete at the same level as those consoles.

I was thinking more in practical pricing for 1993/94. Keeping things to 2 MB would have made more sense (and with DRAM densities available at the time, you could managed that with 4 256kx16-bit DRAM chips -like what the Jaguar used- configured as 2 1MB 32-bit blocks in fasRAM and chipRAM)

 

A 33 MHz rated 68030 would have been a pretty expensive option too, even a 68EC030 or 33 MHz 68020 would be pretty expensive. The 68EC020 was also offered in a 25 MHz variety, but that would need a different clock to work off to get close to that speed. (and would still be more expensive than the bottom barrel 16.7 MHz model) Hmm, maybe adding a separate clock to facilitate the existing EC020 to run at the rated 16.7 MHz. (hell, the Amiga 3000 and 4000 had used unrelated clocks as such . . . and that would have boosted the value of the A1200 as well)

 

That, and an added DSP or other coprocessor could have been a more cost-effective option than a faster CPU in general. (be it a low cost/embedded DSP solution -especially some becoming available from Japan, or a more powerful DSP like the popular 56k or TMS320 series -some of which were becoming relatively cheap in the early 90s, or, again, the TMS340 -the ASDSP route, like Samsung offered with the SSP-1601 could have been an interesting route as well: an embedded DSP put on-chip with a sizable amount of custom logic specified by the contractor/buyer either in gate array or standard cell logic -presumably the latter would be more expensive with the advantage of being denser and potentially faster for significantly more potential on the same amount of die space, that and I believe gate array logic is easier to engineer in general -ie easier for the contracting company to design for a mask)

 

A lot of that was really up to whether CBM had capable engineers on staff (or connections to ones they could outsource to) to make an in-house solution attractive compared to off the shelf or semi-custom outsourced designs. (ie in the case of the ADSP, you'd need engineering resource to design the custom logic for the manufacturer to mask, etc -of course, you could have a full gate-array chip used for a custom ASIC rather than more expensive standard cell or full custom logic, it's all a matter of the circumstances -performance, volumes, R&D vs manufacturing costs, short run vs long run, etc)

 

 

 

 

 

On another note, looking at Atari's Falcon, it wouldn't have been too good for a game console either, but would have been better off than the CD32 in several respects.

It had a 16-bit packed pixel mode, 8 16-bit hardware DMA sound channels, a 32 MHz 56000, and a 16 MHz 68030. Except the '030 was limited to a 16-bit bus and a 16 MHz 68EC020 probably would have been much more cost effective for a console (or the low-end Falcon models for that matter). It probably would have made more sense to save costs with the cheaper EC020 and allow 32-bit bus access (limit to 16-bit in ST compatibility modes if necessary) and offer fastRAM expansion. (on a console, probably make trade-offs to allow fasRAM out of the box)

 

The other problem is that the 16 MHz blitter is really about as limited as the old MEGA blitter from '87, so pretty limited in utility. On top of that, all the other color modes (8bpp, 4bpp, 2bpp, etc) are planar iirc, so you'd have to deal with packed to planar conversion as well. (that's one thing the blitter might be useful for, though faster/dedicated packed to planar conversion logic -or VGA style chained planes- would have been preferable)

Highcolor is great, but there's a lot of things you'd want to use with 256 color stuff due to the lesser bandwidth/memory required. (especially if you couldn't afford to do texture color look-up -albeit the bandwidth issue only matter for cases where you could practically manage a routine that would read/write multiple pixels at a time)

 

I think VIDEL allows for very flexible resolutions, so it should be possible to drop to lower resolutions as needed in any case. (plenty of cases where using 160x200 or similar could be preferred -or even 1/2 vertical resolution, especially if you changed modes to higher res above/below the game window for full-res status display stuff, possibly at a lower color depth )

Edited April 25, 2011 by kool kitty89

[Chilly Willy]

Yes, but what about the actual memory accesses?

 

It was my understanding that the OCS/ECS chipRAM was all accesses at 280 ns (that's 2 7.16 MHz clock cycles or an effective 3.58 MHz), or 560 ns interleaved performance. (4 clock cycles per access to share 50/50 with the 68k -with no wait states on the 68k end)

So the peak bandwidth of the OSC/ECS would be 7.16 MB/s (16-bits at 3.58 M transfers/s).

 

14.3 MHz wouldn't mean anything unless the RAM was configured to be fast enough to allow single cycle accesses. Even 140 ns accesses would be much too fast for random accesses (and thus any interleaved accesses), and if burst-mode was supported, it would mainly have been useful for scanning out the playfields/framebuffers and similar examples of sequential accesses within a consistent shared row of DRAM cells.

 

I already told you - twice accesses as many in the same time. As to the actually hardware used, as I understand it, the first cycle in fast fetch is regular, and the second is via fast page mode, or something similar. It's partly why there was an alignment issue. It's also why it was only for sprites and playfields.

[kool kitty89]

I already told you - twice accesses as many in the same time. As to the actually hardware used, as I understand it, the first cycle in fast fetch is regular, and the second is via fast page mode, or something similar. It's partly why there was an alignment issue. It's also why it was only for sprites and playfields.

With the way page mode works, you'd have a random access each time you needed to change rows of RAM being accessed or whenever you accessed the bus with a different processor/bus master. Every access by that same processor/bus master after the initial random access can be in page mode until you need to change the rows being addressed.

 

If you were doing operations that didn't make fast page accesses useful, then you'd only be moderately faster than the OCS/ECS with 3 14.3 MHz (70 ns) cycles per random access rather than 2 7.16 MHz ones. (or 4 7.16 MHz/280 ns cycles if you were interleaving with the 68k -ie no fasRAM)

 

AFIK, the OCS didn't have fast page support, so 140 ns accesses wouldn't be possible. (if they did have fast page accesses, the utility of such would be rather limited -like scanning the framebuffer and maybe some fast fill operations)

[Dauber]

Sorry to possibly divert the thread, but my contribution is simply answering the original question: 1200 or 4000?

 

I had a 4000 for a while, loved it, got rid of it after I got the microAmigaOne, blah blah blah, but, having said that?

 

I say go with a 1200 if you're looking for expandability. Believe it or not, it's much more expandable than the 4000. With the 4000, you're pretty much limited to Zorro slots if you want to add devices. With a 1200, though, you can put the thing in a tower that can add Zorro slots. The A1200 has its famous clock port because the motherboard doesn't have a built-in clock, but since most accelerators have their own clocks, the clock port was almost never used for a system clock, so enterprising third-parties came up with creative ways to use the clock port, like USB cards, serial port accelerators, etc. (Amiga serial ports are extremely limited -- you can't even run a high-speed dialup modem at full speed on 'em. Basically the fastest you can go on 'em is 14.4kbps, so they're really only useful for MIDI.)

 

So yeah....a towered Amiga 1200 gives you all these options:

- Accelerator port

- Zorro II/III slots

- clock port (not available on the 4000, although I think there is now a Zorro module that adds clock ports)

- PCMCIA port (not available on the 4000)

 

Actually, even if you do get a 4000, I'd say tower it anyway (or get one already in a tower) because you'll have much better airflow, and your CD/DVD drive will have a much better chance of fitting in the slot. (Most optical drives actually stick out of the slot by an inch or so.)

[Tempest]

Just thought I'd bump this because I finally did get that 3000. Man this thing is so much nicer than my 2000. It's quieter, faster, has a built in scanline doubler with a super nice picture, and can support an internal HD and up to 16MB on the motherboard (no wonky cards needed). I still have the 2000, but I was getting tired of random memory errors on soft reboots (I think the RAM card might have had issues) and I never could get the CD-ROM drive working.

 

My 3000 came with 2MB Chip RAM and 8MB Fast RAM. I already found enough ZIP RAM to upgrade to 16MB (it was super cheap so why not?). Now I just need to find another hard drive for the second bay (although it has the cover so that's not a huge deal at the moment) and possibly a RTG card, although those tend to be super expensive and not really all that useful since I have a large number of DOS PCs also setup. Thankfully I already have an external CD drive that I can borrow from my Mac when I need one.