Crazyace
-
Content Count
1,027 -
Joined
-
Last visited
Posts posted by Crazyace
-
-
Yeah, and they should have called it the Commodore 65.

No, it would have been the Commodore 68K

-
2
-
-
This website is quite interesting http://www.amigahistory.plus.com/sales.html
It shows the breakdown as almost 10 to 1 in favour of the cheap A500 model, which just shows how the market had moved on

The ST had the foresight to implement the b/w mode - that was a failing of the amiga tying it completely to NTSC - given the price of the A1000 support of a workstation monitor ( No VGA in 1985 ) output with non interlaced 640x480 @ 60Hz would have been amazing - even if it was limited to 4 colours it would still be better than the ST.
Maybe the Amiga would have been better as a bare bones machine - a super C64 rather than a new multitasking windowed machine. As well as the games, lot's of the definiing titles such as DPAINT weren't really windowed apps anyway
-
1
-
-
If the Amiga had shipped with mixed chip and fast ram it might have helped things a bit - the original A1000 could have been 256K fast plus 256K chip - and that would allow the 640x240 16 colour modes to be used without slowing down the cpu at all.
It would have been a lot easier to make new models with faster cpu's - or even move the video circuitry onto a card in the A2000's to more directly compete with the IBM PC
-
1
-
-
-
Expansion on cart would be nice - It might actually be better to only have 'chip rom' instead , The Amiga 1000 used up to four banks of 128K chip ram ( 2 on board, 2 in expansion ) so something similar could be used to allow 3 possible 128k areas on the cart.
-
Hi Carlsson,
I'm not worried about the price too much. It was being designed as a console, so I'm just assuming it must have been possible to price as one.
-
Having FAST and CHIP on the cart port would complicate things. I was thinking that 68k only rom could be slow, and still work at the same time as chipset ram accesses
-
For a 1985 launch, you'd have to also make the assumption that Commodore would have to pull a Nintendo (who marketed the NES as a robot toy initially) and use some clever ploy to actually get into stores. Retailers wanted little to nothing to do with videogame stuff until the NES started gaining momentum in the latter part of 1986, so even with all of the obvious technical and cost hurdles aside, it's not realistic to think that Commodore would simply release an Amiga-centric console as-is at that time, particularly when the Commodore 64 at that point was console priced and still selling like relative gangbusters. In other words, with a lack of a market, there would be no logical reason to release a videogame console until it was clear that consoles were a thing again. So again, if we're going to play "what if?" here, it's realistic to think that Commodore wouldn't even consider releasing an Amiga-centric console until at least late 1986, if not 1987.
Hi Bill,
I'm not making any assumptions really, just following up the comments by one of the original designers ( Joe Decuir in the video ) about the Amiga being designed for 32k as a console ( I'm guessing that 128K was the computer version shown in 1984 ). Whether an Amiga computer from Commodore would actually happen if the console had been picked up is a completely different question.
It's not as if the NES sold amazingly well in it's first year anyway - and that was in a market where it was technically superior.
I still have to ask where the games are coming from (that's as important a point as any). Sega had a lot of first party content to leverage, Atari leveraged old license agreements and struggled to get any notable new software or third party support, etc., and both struggled against the NES, which had awesome first party stuff and had locked up a lot of third parties exclusive to their system. It's not like Commodore would be programming very many state-of-the-art games on its own dime. So what exactly would be left after Nintendo, Sega, and Atari snatched up what they snatched up? It wouldn't be until Sega released the Genesis that Nintendo's lock on the best third parties was finally broken, and that wasn't exactly immediate either.
In 1985 Nintendo didn't have all of the US developers locked in. Also an Amiga console may not have been a commodore product
( If Commodore had announced a console they would have produced software - after all, there would be no intuition or Amigados required, so companies like EA would have been offered gamedev opportunities with the lorraine devkits in baremetal mode )If you're going to argue that Commodore would "win" based on brute force of the tech alone, that's simply never been the case. It's always been about the games first and the technology second (or third). It's also easy enough to argue that even 86/87 would be too early to realize the potential of that type of technology in a console package anyway.
There's no argument that it would win , but it would be in the market in 1985, with way superior technology - at the same time as the initial NES launch with ROB and duckhunt

FWIW, there were supposedly some arcade machines that were based on Amiga hardware. I saw a few of the games.
I think a game console could have done well if it were implemented properly.
Cartridges would have had to allow at least some of the ROM to be mapped to CHIP memory.
If cart memory could be mapped as CHIP or FAST it would have allowed as much of either as you need since you could page either one.
The one major drawback to this is that a dual buss architecture would require a dual buss interface.
There might be a way around that by multiplexing some buss lines but I wouldn't even want to guess how nasty that would be.
The CDTV was late but it could have been a CD based version of the console if they had released a console.
The CDTV should have had a 2x CD and the cpu should have run at double speed either way.
Cart memory as chip would be nice - but I think better as 'fast', If code is running from ROM there wouldn't be as many stalls,
I was thinking that graphics would be copied from ROM to the 32k ram via movem.l sequences - and only the actual writes would actually stall, ( after all on the ST the CPU handles all graphics, and still there were games running at 60Hz )
-
1
-
-
I would counter that 1985 would be a viable launch - this isn't an Amiga computer, i expect it would be a lot cheaper as a bare bones console. Given the timeline where the h/w was near complete in 1984 for the computer , there would still be a year for software dev.
In that situation an Amiga console would launch against the early NES - and in my opinion a 32KB '7800 style' amiga would outperform the NES dramatically....
I dont know how this would have affected the Amiga computer. I'm actually thinking more about this technically. - In terms of games though I think an Amiga console would actually get better games, as there would be no Atari ST ports that dont use the hardware.
Given better hardware in the US market would the NES have managed to dominate as much as they did?
I assume a 32K Amiga would be more expensive to build than the 4K NES , but the 5200 already had 16K of ram , so it would be possible to price as a console for $299
As Awhite2600 says, it would need programming tricks to work with only 32KB of chip ram.... that's what is interesting to me. I expect that a lot more software would rely on the hardware sprites - and the lack of memory for double buffering or blitter object data would be challenging. But the 2600 only had 128 bytes after all, and 32KB is more than the 4K on the NES, ( and the 8K+16K of the Master system )
-
1
-
-
Its predecessor was the CDTV, although that was obviously priced much higher and targeted more as a set top box, which was thought to be a market at the time. Obviously that wouldn't start to be a thing until the post-DVD era.
I don't think there are many scenarios where a cartridge-based 1980s Amiga game console would have been a success, particularly one fronted by Commodore. As we know, one reason for the NES's level of success was its access to the best third party content and killer first party titles. Commodore would have had none of that, and it likely would have been more along the lines of the reception the XEGS got, with its more computer-centric games line-up.
You should disregard both the CDTV and CD32 from this discussion - they both arrived much later ( 1991 and 1993 ) and were based on Amiga computers. I'm thinking of a 1985 launch where it would compare to the NES and 7800 at launch ( and non launch for the 7800 )
I doubt it would have the same reception as the XEGS - that was old technology way behind the competition - Amiga was state of the art technology in 1985.
-
I'm guessing the 32K comment from Joe Decuir would be for a console in the 1985 timeframe - so competing against the NES.
I think that even with 32K an Amiga cartridge machine would provide much better games - Marble Madness would be pretty much the same as it was on the real Amiga for example.
With 128K and carts there would be room for almost all of the effects that people used on the 512k Amiga computers.
-
I was watching the excellent video about the Amiga design, and one comment here was interesting
An Amiga games console with only 32K of chip ram. It would be interesting how this would have looked to the market, and the kinds of programming tricks that would have been needed.I think, even with 32K it would have competed with the NES and SMS.For scrolling - 336x192x8 colours would fit in 24k , leaving 8k for h/w sprites and Copper listsA pseudo colour mode could be implemented by replicating some plane data over multiple lines...336x192x2 for 2 full screen bitplanes + 336x(192/4)x2 would give 16 colours using 1x by 4y 'attributes' in 20kThe CPU would be busy copying data from cartridge rom ( like fast ram) to chip ram for graphics updates during vblank, and any blitting would need to chase the beam as double buffering would need too much ram to be practical.-
2
-
-
Hardware wise, ignoring a ton of other variables and missed opportunities on the R&D end from 1989 to 1993 when the chipset was frozen for production and indistrial design of the PCB, case, etc were laid down for mass production, the only big engineering mistake seems to have been heavily banking on DRAM prices dropping rapidly. The Jaguar was screwed over by the same situation as the ST in 1988: DRAM shortage/crisis stagnating (and even INCREASING) prices of existing DRAM grades. (that more than anything else killed the ST's momentum or its supremacy in the 16-bit computer market in Europe ... or potential edge over the Amiga in any market -lack of major hardware updates didn't help, and Sam taking over as CEO in 1989 ... )
I don't think the ram cost was that important - Atari just didn't sell enough systems at the launch price, and publishers weren't willing to commit.
It's compounded by the fact that that single-bank 2MB arrangement also squanders some very nice features of the chipset and for a cart based system, RAM capacity isn't all that critical (yes, nice fast memory to work in AND decompress into, but there's moderation). Cutting down to 1 MB and lumping another MB onto the CD drive later on would have been a far, far safer bet and very practical for the time. Using 4 128kB 16-bit wide DRAMs for one 512 kB bank and a single 512kB 16-bit wide DRAM for the 2nd bank would be great. (allow a lot of interleaving with 68k and DSP accesses in the 16-bit bank, speed up blitter texture rendering a ton, and retain peak bandwidth for OPL-intensive games and minimal framebuffer scanning overhead) You'd even still have room to Z-buffer with some freedom. (tougher if you interleaved with the framebuffer on a 64-bit phrase basis -ie 4x 16-bit screens rather than 3x- but still doable if most/all textures are in the other bank and you're not using many sprites)
With interleaving they might have been better to stick with 25 MHz rather than pushing to that extra 26.6 MHz given it'd allow 4 clock random access cycles rather than 5 for better interleaving and synchronization with 68k cycles. (lose a little on peak FPM bandwidth, but gain a lot on average performance and latency) Plus you can use 12.5 MHz rated 68ks and save a little bit.
They probably could have cut more than $25 of the raw component costs, and a good deal more when scaling that up to final retail distribution pricing (Kskunk said a save rule of thumb is double, but it's obviously more complex than that in real world terms). Managing a $199 price point for the promotional test market in '93 and $149.99 for a bare bones core-system arrangement for the 1994 launch might have been doable then.
ROM is in a separate bank as well and wouldn't screw with DRAM cycle timing, so having the DSP mainly limited to ROM fetches might have been one more way to minimize bus strangling. (for games using the DSP purely for sound -hard to do much else given its slow bus logic, ROM would be fine for streaming samples from for sample based stuff -rather than wavetable synth using ROM and scratchpad RAM alone)
Would it have made that much difference to the games? Also I dont think the price was the issue at launch.
Hell, dropping the RAM content AND going with a CD-ROM based machine from day one probably would have made sense for the time too, Atari apparently had problems negotiating for cheap enough drives and controller chipsets but they probably could have compromised more on that to make it to market sooner. (licensing that Phillips CD controller chipset was a bad investment anyway, better to buy off the shelf until they have enough volume to merit long-term investment like that) Flair had already embedded a CD-ROM decoder in their more modest Slipstream 3 ASIC, so taking that as a priority sooner should have allowed it to be crammed into JERRY as well ... though its existing UART bugs don't make that promising. (not sure why they didn't go cheaper/simpler with JERRY and use an up-clocked flair DSP, save a ton on silicon and leave less space for bugs -maybe allow use of simpler/faster to engineer gate array logic to get the bugs smoothed out quicker than standard cell)
Using a 1x rather than 2x speed drive is a given for a 1993/94 timeframe too. (keeping the total system cost close to the Sega CD's price would have been a nice marketing angle ... new 64-bit machine CHEAPER than the combined cost of a Genesis + CD bundle ... let alone 3DO)
Having 2MB ram would be important for a CD only console - You can easily take 450K just for a double buffered 320x240 16 bit screen + Z buffer.
That said, they also could have just kept the Jaguar in development longer and used the simpler, cheaper single-chip ASIC Slipstream 4 design Flair also had ready by 1993 (1992 as well, but there were multiple revisions and the Slipstream archive site only has the 1993 V 3.3 manual available -the 1988 and 1989 versions of the prototype and production 16-bit slipstream are there too, but nothing on the 1990 or 1992 revisions) Less powerful but critically cheaper and simpler 32-bit system targeting a 386SX though I believe (like the Jaguar) able to swap big and little endian modes and support a variety of CPU types. (swapping that 386SX for a cheaper, more elegant 68000 would probably have been the natural solution) It supported dual DRAM banks and FPM access as well, but no CRY color or 64-bit stuff, just a blitter, DSP, I/O hardware (including CD-ROM decoder), video controller, and memory controller. (it used 18-bit RGB paletted and 5-6-5 RGB direct color with gouraud shading/lighting and color blending done using that rather than CRY methodology -I'd have thought going 4-4-4-4 RGBY would have been a simpler extension to the older Slipstream configuration and simple 4-bit additive based color blending and lighting ... and an easy option for a 4-4 C/Y palletted 256 color arrangement with fast shading, but they went more typical highcolor or SVGA-like it seems)
The slipstream would have trouble matching the SNES graphics capabilities in 2D , although it may have made a better StarFox

-
A VCS computer hack wouldn't compete with the Vic20 even if it contained a built in supercharger, and it would be more expensive than the zx80 ( let alone the zx81 )
There should have been low cost versions of the 400 at that time, ( something like the 5200 board with a cheap keyboard )
-
In my opinion, there is everything inherently wrong with this statement. (Like anything there is always blissful ignorance)
Also, Mr Motorola 'Sixty-Eight' Kay just 'stopped' by to say... "Hi".
Hi Mr 68K

Games like Zero 5, Doom, Wolfenstein ( though not after doom
) , and AVP showed off the system pretty well.Trevor McFur showed what could be - whilst not being any fun to play at all

-
In my opinion, there was nothing inherently wrong with the jaguar hardware. ( Like anything there are always trade offs ) - but I think the only thing that may have made any difference would have been to make it a CD machine from day one.
( The Jag CD is barely more than an audio CD anyway - so the cost wouldn't compare to PC CD-roms at the time ). Even if that resulted in a higher price at launch it would still be cheaper than 3DO and much more capable than PC engine CD or Mega CD.
The real advantage would then be that CD's are far cheaper and far less risky in inventory terms - so more publishers may have joined.
-
Is it loaded at $4000 - I just get a green screen with skunkboard
-
I'd just like to point out that Atari had a 3D renderer api in their sdk samples. I would recommend you start off by using that instead of wasting your time porting some ST 3D code.
-
Notmy worst spelling mistake, but it doesnt change the fact that you are incorrect in your argument.
-
An amiga has a blitter, copro, etc, much the same. But you don't hear anyone claim that has 3d acceleration.
The jaguar is inherently NOT three dee, sorry.
The Amiga blitter is a different device - please look at the specification, not just the name. The Jaguar blitter has a special mode to draw Z buffered gourard shaded line segments - it is the lowest level of a 3D graphics rendering system.
-
Any processor can do 3D. The Jaguar, by default, does not have any 3d accelerated hardware features.The 2nd statement isn't correct. The Jaguar has accelerated hardware features to support gourard shading and z buffering of horizontal line segments. These are an important part of the pixel pipeline required to display 3D lit gourard shaded models.
If you want it, you have to write the render path yourself - just like every other 2D based system with a frame buffer before it. What the Jaguar does have is a set of processors that, when programmed efficiently enough, are capable of rendering 3D at an acceptable frame rate (for the time)You only have to write part of the render path - and that's not really a problem, the designers placed the gpu there to run the render path. They also made it general purpose enough to support other uses ( such as the 8x8 matrix multiplication designed for video decoding )
Again, you can't blame the designers for people trying to make it work beyond it's capabilities.Even when texture mapping ( which isn't the strong point of the system ) you are using the blitter to accelerate the process

-
I found this - using the Atari 3D renderer , which has poly counts..
Here are a couple of screenshots

This renderer seems use gpu ram as a buffer - so it's faster than the original Atari code.
-
2
-
-
The ST version sounds good in the title sequence - but in the actual game it sounds really muffled compared to the Amiga version. ( Makes sense, as you can allocate more cpu time to run the sample player at a higher frequency )
( Also is this ST or STe? as that would make a big difference to the quality of the audio )
-
In the optimal case - arcade quality - Atari supplied some FM synth code in the SDK, and in the case of MK2 it actually used a DSP anyway.
Most games used samples though - it was easier, and more flexible.

If Atari released panther instead Jaguar
in Classic Console Discussion
Posted
I think that the panther also would have a problem due to the lack of colour - the line buffer only supports 32 colours per line - less than the 64 colours ( more with shadow/highlight ) on MegaDrive.
Also a 16 pixel sprite would be 4 longs in ramfor the control (8 cycles ) + 4 words of ROM data ( 16 cycles ) - given 1024 cycles per line this allows 42 sprites per line - more than the MegaDrive, but without any background screens...