@Leo

>In 1995 SVGA was starting to take off.

Yes.
I always forget that VGA is only 320x400x8.
UPDATE: VGA is only 320x200x8, typo.

>- no standard way to display the 95% of PAL/NTSC games on a standard cheap vga monitor

There was no need for vga monitor for games at that time.

>- no chunky mode ...- too slow, especially in 640x480x8bit

Yes. AGA was released at the time of VGA.
Dropping clearly behind vs SVGA cards that had more than 1Mb RAM.

>- slow CPU, no fast ram

68020 was ok, but it needed RAM. Then it would have been compareable to low end x86 of that time.

>- limited sound (8bit only, when all soundcards had

x86 started to have proper sound very late because they had no standard audio.
Windows 95 started to enable proper audio.
In 1995, standard PCs came without audio card. (like my P75)

(I personally have not yet used audio HW that beats my A4000. Too much noise on those basic motherboard audio solutions etc.)

>- most machines sold came with no harddrive (come on!)

Yes. CBM management stupidity.
(? hdd was not mandatory for games, especially since 90% of Amiga games did not install to HDD.)

>Something between the Atari Falcon with its DSP/68030/Chnuky modes and Amiga would have been great.

"A3000+" had DSP and AGA and flixer fixer but management did not want it out.
That DSP would have been multipurpose.
Falcon had 16bit RAM, and very simple DSP etc. IMO, not better than A1200+RAM+HDD.

>These games required raw CPU power in addition to fast chunky graphics and 640x480 resolution.
>AGA provide neither.

AGA was released at the time of VGA. VGA did not have 640x480x8 mode either.
IIRC, 386 ran DOOM ok, 68020/14+RAM would not have been much behind.

>And 640x480 is unusable apart from displaying still images with AGA.
I used 1440x580 HAM8 for still images on my A4k.
Far better than 640x480x4. (VGA)
640x480 was usable but little too slow in games like SimCity2000 on A4k (they say Mac version ran faster on Amiga than the Amiga version, for some weird reason).

640x480xHAM8 was usable for painting.

Last edited by KimmoK on 22-Jun-2015 at 09:26 AM.
Last edited by KimmoK on 18-Jun-2015 at 03:29 PM.
Last edited by KimmoK on 18-Jun-2015 at 03:25 PM.
Last edited by KimmoK on 18-Jun-2015 at 03:24 PM.

_________________
- KimmoK
// For freedom, for honor, for AMIGA
//
// Thing that I should find more time for: CC64 - 64bit Community Computer?

@KimmoK

VGA can have up to 360x480 pixels in 256 color mode using standard hardware. In practice all SVGA machines support 320x600 pixels and some support 640x400 using the standard mechanisms.
Above that is in pure SVGA territory due to the design of the VGA (256kiB is the maximum addressable except in a very small subset that supports 512kiB using the standard design - it requires a 128kiB "window" into the frame buffer to be supported which no card I've tested does).

But in most cases using the SVGA mechanism instead of the chunky-planar design required for higher resolution 256 color modes is simply the wise choice.

@Jupp3

Quote:

Of course second generally depends on the previous one (of course you CAN use things like "long", keeping in mind that long long long is too long for gcc), but if you want, you can well install a 32bit OS on a 64bit system.

What system uses 'long long long'? That would be LLLP64, I guess, but I've never heard of such a thing.

_________________
"Unix is supposed to fix that." -- Jay Miner

@KimmoK

SVGA was first released in 1987 but Vesa came only in 1989. In 1995 most graphic cards also came with SVGA. You didn't have "VGA-Only" boards.

I had a (s)VGA card with only 1mb Ram which allowed resolutions of up to 800x600x16 bit or 1024x768x8bit.

Of course, 1024x768x8 was a lot faster than AGA with 648x480x8bit (esp. in dblpal mode).

Most game ran in 320x256 indeed. But what about workbench: you needed a VGA monitor in order to have a usable high resolution flicker free desktop.

68020/14+RAM would be much behind 386+VGA since you'd have to spend lots of time doing chunky to planar conversion in addition to the game's 3D graphics. Chunky to planar conversion only begins to be negligible with a 040/060...

Last edited by Leo on 18-Jun-2015 at 09:13 PM.
Last edited by Leo on 18-Jun-2015 at 09:13 PM.

_________________
http://www.warpdesign.fr/

@matthey

Quote:

matthey wrote: Quote: Thorham wrote: Why use less if you can have 64 bit? Would it be cheaper at a similar speed? Less than 64 bits "saves transistors and energy" as KingKong correctly stated. This means it's possible to be cheaper and/or faster at the same clock speed.

AMD declared that adding 64-bit to x86 required only 5% more space (transistors), which is meaningless in terms of saving transistors and energy.
Quote:

Advantages and disadvantages of 64 bit: + Practically unlimited address space is available (more directly addressable memory). + Work can sometimes be done twice as fast by working on data that is twice as wide. + Less registers are needed for data that would overflow 32 bit registers. - More transistors are needed for wider paths, registers and DCache.

negligible: see above.
Quote:

- More transistors are needed for more and larger instructions and ICache.

That's not true: in general you don't need to increase the instructions size.

Here you're referring to x64, which increases the instructions size of 0.8 bytes on average.
Quote:

- Multiply, divide and shift in full 64 bits generally slows down the pipeline.

You don't need to do them every time. And you can put them on specific execution units, letting the normal, more common, instructions run on the fastest EUs.
Quote:

- More transistors are commonly used for better branch prediction and OoO execution to reduce the pipeline slow downs caused by 64 bit.

I don't see any pipeline slowdown only because of 64-bit.
Quote:

- Die shrinks are especially beneficial to offset the disadvantages of 64 bits but increase costs.

See above: 5% is a ridiculous impact. And we are talking about 35-40 millions processor (2003, year of introduction of Opteron & Athlon64). Now we have BILLIONS of transistors used, and the impact of 64-bit introduction is just above zero...
Quote:

The 64 bit x86_64 benefited from ISA changes including 8 more registers which helped to push 64 bit CPU popularity. The speed advantages of the ISA change more than offset the speed disadvantages of a 64 bit processor. There are still a few tasks which are faster in 32 bit on the x86_64 due to better code density and cache utilization. Other processors commonly see a slow down with 64 bits.

Sure. But you also need to address more memory, and there's no other way to use 64-bit pointers and do 64-bit pointer arithmetic also. Something which is not possible with 32-bit processor, unless for some prehistoric bank-switching-like techniques.
Quote:

There are (semi-)modern processors with 48 (and 40 bit) hardware data types. They are processors for specific (usually embedded) uses like DSPs, micro-controllers and media processors. The purpose is usually to have extra precision for multiplication products (24x24=48 for example in 56k DSP). The extra precision is helpful with cumulative rounding errors and saturation math while having the speed possible with narrower data multiplications.

Yes, but usually they have dedicated registers & logic to internally use such odd sizes. To be more clear: the input and output data are "normal-sized", as well most of the internal registers.
Quote:

Much of the high end market for DSPs has been replaced by more general purpose CPUs with SIMD processors.

Exactly: they are more general, and cheaper too (don't require specific designs and related development costs).
Quote:

FPGA DSPs with limited data width multiply support have helped the popularity of low end DSPs with odd data type sizes though.

"low end": that's the point.
Quote:

Specialty processors are usually difficult to program and odd data type sizes make them more so. Compilers will have fewer problems and better support for 32 bit and 64 bit sizes which are better choices for general purpose computers.

Absolutely. And that's why doesn't make sense to think about odd architectures.
Quote:

It's too bad good code density 32 bit CPUs like the 68k don't get more development love as they are easy to program, address enough memory for most general purpose computing needs

Sorry, but nowadays memory is important too.
Quote:

and would use a lot less transistors than a modern x86_64. RIP 68k.

I don't see why a 68K can require less transistors. Especially for a 68020, the decoder is complicated due to 16-bit opcodes with several exceptions, and specially for the complicated extension words (for memory addressing).

P.S. Sorry, no time to re-read and to answer to some other interesting comments.

A couple of minutes, so I add some quick things.

KimmoK, you reported many wrong information. Please, talk about things that you know. See comments from other people that have corrected you.

Regarding AGA, it was plain wrong and late. The primary problem is that the Blitter was exactly the same. So same bandwidth of an ECS machine. That's why most of games used only 320x240 or 320x256 resolution, at 256 or even 128 colors because that limitation.

Other bad thing: the miss of chunky pixels, which help a lot not only for 3D, but when you have so many colors. You don't know how much bandwidth is wasted by bitplanes due to the cookie-cut technique (which is NEEDED to "insert" the BOBs on the screen graphic).

The "funny" thing is that there's people that continue to think about using bitplanes. A Paleolithic stuff which should be forgotten, but some engineers still think about providing 10 or even 16 bitplanes with some "new" Amiga hardware. No comment...

@cdimauro

48 bitplanes!! ;)

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@cdimauro

>KimmoK, you reported many wrong information.

I think I did not.

_________________
- KimmoK
// For freedom, for honor, for AMIGA
//
// Thing that I should find more time for: CC64 - 64bit Community Computer?

@Leo

Do not start to mix up things.
It's different reality between when stuff is invented and when they become normal for users.

>SVGA was first released in 1987 .... In 1995 most graphic cards also came with SVGA. You didn't have "VGA-Only" boards.

The discussion was regarding games. It was VGA for games untill 1995(+).
Standard VGA 256 color resolution is about 320x200.
256c out of 262144 was inferior in quality, but it was a lot faster for 3D games etc.

I was drooling after HDD capable (multitasking, etc) advanced games ever since I got Amiga with HDD & 3MB RAM (1989), but they were pretty non-existant for Amiga.

>I had a (s)VGA card with only 1mb Ram which allowed resolutions of up to 800x600x16 bit or 1024x768x8bit.

AGA had some advantages vs that kind of SVGA, like being able to show higher resolution photos with more colors and video playback. Otherwise AGA generally was slower.

>of course, 1024x768x8 was a lot faster than AGA with 648x480x8bit (esp. in dblpal mode).

Yep. On amiga it was no needed To have 8b wb when i could jump To another screen instantly.

>Most game ran in 320x256 indeed. But what about workbench: you needed a VGA monitor in order to have a usable high resolution flicker free desktop.

Sure. But it was about games. You REALLY do not need VGA monitor for VGA caliber games. TV is BETTER for lores GFX.

Last edited by KimmoK on 19-Jun-2015 at 11:45 AM.
Last edited by KimmoK on 19-Jun-2015 at 11:39 AM.

_________________
- KimmoK
// For freedom, for honor, for AMIGA
//
// Thing that I should find more time for: CC64 - 64bit Community Computer?

@bison

Quote:

What system uses 'long long long'? That would be LLLP64, I guess, but I've never heard of such a thing.

No idea really. Just added that because I always found the error message "long long long is too long for gcc" rather funny

And of course, no matter if you have 8, 16, 32, 64 or even 48bit!1! CPU, you can usually "chain" basic math operations to as many bits as you like.

f.ex. addition on 6502:
.macro Add a, b, result, numbytes
clc
.repeat numbytes, i
lda a+i
adc b+i
sta result+i
.endrepeat
.endmacro

Of course it's obviously slower than being able to do that with a single add command.

@KimmoK: In 1993 some popular games already required Svga: 7th guest, myst, sim city 2000 (which was unusable unless you had a 040). There is no way Aga could handle these without a very fast processor that would compensate for Aga's slowliness.

_________________
http://www.warpdesign.fr/

@Leo

Quote:

Example of games released in 1994-5: Doom, The Dark Forces,...

It is even worser, Doom was released in 1993!


Interesting to note, ADoom 1.3 is exactly as fast on my A1200 (68030 50 MHz) as Doom on my laptop (486SX 25 MHz, slow ISA GFX).
However, most A1200 users in 1994 had bare configuration, in some cases speeded-up by fast RAM. In 1995, common PCs around 1000 USD were sold with 486DX/2 CPU and SVGA VLB GFX, compare this with then similarly priced Amiga configuration (A1200+030 50 MHz). PC world progressed dynamicaly in early 1990s - you could buy 386+VGA for far less than 1500 USD in 1991. A1200 was decent machine for its price, in 1992, but out-dated only year later.

@KimmoK

Quote:

KimmoK wrote: @cdimauro >KimmoK, you reported many wrong information. I think I did not.

So, just an example that every amigan should know: The Secret of Monkey Island - DOS

Take a look at the screenshots, and then from the Specs:

"CD-ROM release requires: 80286 CPU
Video Modes Supported: CGA, EGA, Hercules, MCGA, Tandy / PCjr, VGA
Sound Devices Supported: Adlib, Game Blaster (CMS), PC Speaker, Roland MT-32 (and LAPC-I), Sound Blaster, Tandy / PCjr"

Pay attention: CD-ROM release. Means CD-quality sound-track. And you don't need an 80386 processor.

Last but not least, "Released: 1990"

But starting from 1988 the VGA was used. For example, BattleChess:



@KimmoK

Quote:

KimmoK wrote: @Leo Do not start to mix up things.

That's what you did.
Quote:

It's different reality between when stuff is invented and when they become normal for users.

So, see above.
Quote:

>SVGA was first released in 1987 .... In 1995 most graphic cards also came with SVGA. You didn't have "VGA-Only" boards. The discussion was regarding games. It was VGA for games untill 1995(+).

No, it was before. Look at the other comments.
Quote:

Standard VGA 256 color resolution is about 320x200.

No. You missed megol's comment. With the standard VGA you are able to reach 360x480 at 256 colors, with the so called Mode-X.
Quote:

256c out of 262144 was inferior in quality,

Only after AGA was introduced, but at that time SVGA were already available, with true colors also.
Quote:

but it was a lot faster for 3D games etc.

Not only for 3D games. With 256 colors graphics, chunky pixels were much easier and efficient compared to biplanes (and using the cookie-cut method). Masking was (is) very simple, by just checking for zero, and techniques were developed to completely avoid checking for zero.
Quote:

I was drooling after HDD capable (multitasking, etc) advanced games ever since I got Amiga with HDD & 3MB RAM (1989), but they were pretty non-existant for Amiga.

Exactly.
Quote:

>I had a (s)VGA card with only 1mb Ram which allowed resolutions of up to 800x600x16 bit or 1024x768x8bit. AGA had some advantages vs that kind of SVGA, like being able to show higher resolution photos with more colors and video playback. Otherwise AGA generally was slower.

I quote you:

"Do not start to mix up things"

and:

[/i]"The discussion was regarding games"[/i]



One question: why video playback was faster on AGA?
Quote:

>of course, 1024x768x8 was a lot faster than AGA with 648x480x8bit (esp. in dblpal mode). Yep. On amiga it was no needed To have 8b wb when i could jump To another screen instantly.

That's only an excuse. High resolution graphics was deadly slow on AGA, whereas PCs handled it much faster.
Quote:

>Most game ran in 320x256 indeed. But what about workbench: you needed a VGA monitor in order to have a usable high resolution flicker free desktop. Sure. But it was about games. You REALLY do not need VGA monitor for VGA caliber games. TV is BETTER for lores GFX.

The TV was "better" only because the signal was of lower quality, so pixels were "merged/blended".

It might look fancy at the eyes, but you lost part of the details.

@cdimauro

Quote:

Last but not least, "Released: 1990"

May I ask price of such machine (286+VGA+CD-ROM in 1990)?

Quote:

But starting from 1988 the VGA was used.

Only in few titles. Major use is later since 1990/1991.

Quote:

No. You missed megol's comment. With the standard VGA you are able to reach 360x480 at 256 colors, with the so called Mode-X.

What games use this feature?

Quote:

Only after AGA was introduced, but at that time SVGA were already available, with true colors also.

True colour cards were costly in 1992 - SVGA (up to 256 colours from 262144) with 256 (or 512) kB was choice for computers in price class of A1200 back then.

Quote:

That's only an excuse. High resolution graphics was deadly slow on AGA, whereas PCs handled it much faster.

Tried SVGA card in ISA slot?

@matthey

Quote:

matthey wrote: Oligopolies tend to produce a few quantity competitors and many specialty (niche) competitors. The "quantity" processor chip designers for general purpose computing have produced 32 bit and 64 bit designs. The x86_64 choice to go 64 bit was made easier by the advantages of ISA changes as I mentioned.

Not only for that. The primary requirement was to (easily) address more than 4GB of RAM per process/thread. In fact, the first incarnation of x86-64 was on AMD's Opterons.
Quote:

The other "quantity" chip developer is ARM and they are mostly still 32 bit (they have a new and different 64 bit offering but it is not obvious that it will be successful).

ARM64 is widespread and continuously increases its market share.
Quote:

One could argue that 64 bit PPC and MIPS designs made it to "quantity" production but they have largely failed to maintain market share. Economies of scale with chip production are huge and have more to do with success than any ISA design. I see only one successful 64 bit ISA for "quantity" production which is x86_64. I would rather not judge based on one success in an oligopoly with many variables.

I don't agree. First, all major RISC processors, except ARM, had 64-bit architectures.

Second, x86_64 wasn't developed by AMD, which was a small player in the processors market.

Third, it succeeded only because Linux and Microsoft supported it, otherwise today we were talking of Itanium, instead.
Quote:

However, your reasoning for skipping 48 bits is a good reason for general purpose computers. Memory and compilers being more efficient with powers of two are other good reasons. I'm not advocating making a modern 48 bit CPU. My point was that there is a significant cost to 64 bit processors for the extra bits.

The cost is negligible. See my previous comment. And compared to an hypothetical 48 bit architecture, we are talking of 33% more bits & corresponding transistors amount.
Quote:

A 64 bit CPU is not always able to take advantage of a 64 bit bus or use a 64 bit operation. Actually, the majority of the time it doesn't. In many cases it ends up extending and aligning with padded zeros or ones which just plug up the DCache.

Absolutely not. You aren't forced to use 64-bit registers every time. You can execute 32 and 64-bit operations without problems at all. Of course, you might need some sign or zero-extension if you mix 32 and 64-bit on some operation, but that's a relatively uncommon case. In fact, sign-extension is around 2% of instructions and 1% for zero-extensions (take a look here).
Quote:

The instructions are also bigger which plug up the ICache.

Now you are talking of x64.
Quote:

Wide multiplication, division and shifting can slow down the pipeline. There is no free lunch. A 32 bit processor can be faster than a 64 bit processor,

On average x64 is faster. There are some cases where 32-bit if faster than 64-bit one, but they are uncommon and without huge differences.
Quote:

especially with limited number of transistors.

5% for introducing 64-bit, included doubling of general purpose and SSE registers, is a very little prise, even with a limited number of transistors.
Quote:

Unused transistors are more expense and potentially more heat. You must be the guy who has bought a dozen AmigaOS 4 computers and thinks the high price is "a hedge against obsolescence". Chip die shrinkage is becoming more difficult. There is no guarantee that Moore's Law will continue forever. I doubt those DNA processors will be available in time to take up the gap. Also, God may have trademarks on the design :P.

See above: 5% is non-significant.
Quote:

IMO, the best chance of Amiga survival is for the Amiga owners to become vertically integrated as processor and chip designers. It is now possible (cheap enough) to own and develop specialized CPU and custom chip designs which allows a company to control it's own destiny.

The design takes too much time. Take a look at the most supported and widespread Amiga clone, the Minimig: how long it took to get the AGA implementation? After several years they are still working on it...
Quote:

Many SoC designs have gone back to gfx near the CPU for performance and the Amiga only needs 3D.

What kind of 3D? With shaders? DirectX 12 or OpenGL 4 GPU classes?

Because I saw here that many people were enthusiast only because it was introduced OpenGL 1.3 (if I remember correctly) to Hollywood. I repeat: OpenGL ONE DOT THREE. Are we kidding? On 2015?
Quote:

AmigaOS and CPU efficiencies could allow the Amiga to do more with less kind of like how a console is more efficient than a desktop. It would still be niche but could be cheap enough and high enough production to be successful. This was also the idea Dave Haynie commented as the best chance for the Amiga when he heard about the FPGA Amiga development.

First, you need a lot of time for getting some hardware available.

Second, and most important, you need support, and it requires even more time & resources.

@bison

Quote:

bison wrote: @matthey Quote: Advantages and disadvantages of 64 bit: + Practically unlimited address space is available (more directly addressable memory). + Work can sometimes be done twice as fast by working on data that is twice as wide. + Less registers are needed for data that would overflow 32 bit registers. - More transistors are needed for wider paths, registers and DCache. - More transistors are needed for more and larger instructions and ICache. - Multiply, divide and shift in full 64 bits generally slows down the pipeline. - More transistors are commonly used for better branch prediction and OoO execution to reduce the pipeline slow downs caused by 64 bit. - Die shrinks are especially beneficial to offset the disadvantages of 64 bits but increase costs. One more disadvantage: linked data structures (lists, trees, chained hash tables, etc.) use more memory due to the increase in pointer size.

Sure, and even objects (which usually are pointers to memory areas + VMT for accessing virtual methods).

But you have also other advantages. For example, moving, filling, and searching memory is faster, and they are common operations.

You can also do more fixed-point arithmetic operations because you have much more precision.

And there are ways to use 64 bits with some creativity.

@KingKong

Quote:

KingKong wrote: PS: "... AMD has re-introduced the "Clustered Integer Core" micro-architecture, an architecture developed by DEC in 1996 with the RISC microprocessor Alpha 21264. This technology is informally called CMT (Clustered Multi-Thread) and formally called "module" by AMD. In terms of hardware complexity and functionality, this "module" is equal to a dual-core processor in its integer power, and to a single-core processor in its floating-point power: for each two integer cores, there is one floating-point core. ..." (Bulldozer (microarchitecture))

Bulldozer was/is a flop, and AMD announced that this CMT implementation will be completely discarded, and replaced by an SMT one (like Intel's HyperThreading) with the new Zen architecture (which'll be available on 2016).

So, what are you taking about? You proposed a failed and dying implementation to make AmigaOS... a leading o.s..

@matthey

Quote:

matthey wrote: PPC 64 bit was used in Apple, Sony, Nintendo and Microsoft products and was produced by at least 4 manufacturers for several years. Now it has only a fraction of the support it had and is on the verge of extinction. Was/is it a success or failure?

It was a success. Now, it's not anymore. But PowerPC was/is 64-bit, exactly like other architectures.
Quote:

ARM 64 bit will probably be a success but it is too early for me to judge. It is very similar to PPC. What major advantages does it have over PPC which will make it a success where PPC failed?

It's ARM...
Quote:

I was surprised from the article that 48 bit integer was higher quality than double precision fp. Too bad they didn't try extended precision fp as I would have liked to see the results with the much greater exponent range.

That's strange. I think that they made some mistake using double precision floating point, because in the worst case you can treat is like a 52-bit integer, and get exactly the same results as using 48-bit integers.
Quote:

The best savings while staying easy to program and port software would be to only support integer and single precision in an Altivec like SIMD unit. This is what most game consoles have done. A neat concept may be to borrow idle single precision gfx units from the SIMD for gfx processing. The gfx processors usually use single precision fp.

I don't that it's a good idea. The next step is introducing double-precision floating point support in SIMD units, because operations based on this kind of data type are become more and more common (for example Windows Presentation Foundation uses doubles for representing coordinates, components, etc.).

The following one will be supporting 128-bit floating points. There are already such kind of needs on specialized sectors.
Quote:

Thanks, somehow I missed the X32 ABI even though Donald Knuth helped create it. They only see 5%-8% performance gains on average (with up to 40%) for integer performance but these gains would mostly come from less DCache use and some ICache gains (better code density)

ICache has more or less the same usage.
Quote:

as x86/x86_64 instructions tend to be smaller in size for smaller data sizes (not so for the 68k). The gains of X32 do not include the full cache advantage of code density (I expect an enhanced 32 bit 68k could be 15%-30% better at code density than X32) or the pipeline slow downs of 64 bit. I would expect the cost of similar 64 bit CISC CPU vs 32 bit CISC CPU in performance to be higher (maybe 10%-20%). The 64 bit CPU would be much larger, more expensive, hotter and likely more difficult to design.

It's not. See the previous comments.
Quote:

The 68k starts with 16 mostly general purpose registers, better code density, position independent code, a better FPU design (8 more FPU registers could be easily added) and it's easier to program than the x86. It could benefit from an SIMD unit, ABI with register passing and a more modern MMU with memory extension.

Who will do all that? How long it'll take? How much it'll cost?

@matthey

Quote:

matthey wrote: Smart phones and tablets are a big market but more importantly ARMv8 is not competing against x86_64.

Well, ARMv8 was designed to compete against x64.
Quote:

ARMv8 processors are not going to be as power efficient as Thumb2 on the same sized die though.

Thumb-2 isn't currently possible, due to the increased registers size & number.

However ARMv8 was born to supplant ARM(v7), not Thumb2.
Quote:

The "Natami LX Evaluation Baseboard Bringup" thread at Natami.net has 320969 views. Thomas Hirsch is an artist at hardware design and designed the Natami masterpiece with his own investment. There are several synthesizable (for FPGA) 68k CPU and custom chip designs that could be obtained and further developed for a relatively low price. A cost reduced Natami with several times the performance of the last 68k Amiga could be created with hundreds of thousands of dollars of investment giving a less than $300 price for a board. For a few million invested, the Natami could be sold for less than $200 where it starts to get interesting for non-Amiga users.

Isn't it better to invest such money to create a multi-core Amiga emulator, squeezing the most performance but... running on economic hardware?

@pavlor

Quote:

pavlor wrote: @cdimauro Quote: Last but not least, "Released: 1990" May I ask price of such machine (286+VGA+CD-ROM in 1990)?

I don't remember, sorry. But this wasn't the point. The point was: what a PC did at the Amiga time.

BTW, I bought an Amiga 2000 + second floppy drive + monitor 1084s for 3 millions of "lire". I don't remember the prices in dollars, but it was comparable to low/mid-end PCs of the time.
Quote:

Quote: But starting from 1988 the VGA was used. Only in few titles. Major use is later since 1990/1991.

Sure. 1989 was the transition year, but on 1990 there were plenty of VGA games.
Quote:

Quote: No. You missed megol's comment. With the standard VGA you are able to reach 360x480 at 256 colors, with the so called Mode-X. What games use this feature?

It's difficult to know, if not publicly exposed on the game's specs. Doom for sure, because it's quite well known.

However Mode-X was published only on mid-1990.
Quote:

Quote: Only after AGA was introduced, but at that time SVGA were already available, with true colors also. True colour cards were costly in 1992 - SVGA (up to 256 colours from 262144) with 256 (or 512) kB was choice for computers in price class of A1200 back then.

We should take a look at magazines of the time, if we want to clarify it. But now I'm going to sleep, because it's too late and I'm tired.
Quote:

Quote: That's only an excuse. High resolution graphics was deadly slow on AGA, whereas PCs handled it much faster. Tried SVGA card in ISA slot?

Tried torture? No thanks.