a golden age of Amiga

[Mrs Beanbag]

I've got a plan.

Plan A phase I is to produce a new Amiga 1200 accelerator card featuring an ARM cpu and software 68k emulator in flash ROM (so instant boot and your Amiga won't know the difference).

Phase II is replacement Amiga 1200 motherboard using an ARM cpu again, but for software emulation of the chipset only and accelerator card is needed for CPU (but original A1200 accelerators will still work.  So you can replace your Accelerator for a faster one, and/or replace your mainboard if that fails.  Mainboard chipset will be faster than AGA but otherwise compatible.

Phase III is both of the above on one board, eliminating the A1200 edge connector, but perhaps with socketed CPU.  Maybe plan for both Amiga and ATX case compatibility (provide both sets of mounting holes).

Phase IV is original Amiga case to put it all in!

[Mrs Beanbag]

things like that have been proposed, discussed and forgotten..

I know... but... it's still a plan.

I'm not the best person for carrying through with plans to be honest, I tend to get all excited about some new idea and then run out of steam after about a month.  But I know people who could probably help me with this, if they are willing.  Plenty of amateurs manage to knock up ARM boards these days.  (Armatures?)  The hardware side of things is getting easier all the time as technology progresses, and the software side of things is already pretty much covered by UAE.

Actually phase III might be easiest to start with now I come to think of it, trying to interface with the A1200 edge connector is probably the most awkward bit.

[Mrs Beanbag]

other asked similar questions again and again, myself i proposed something like that on a german hardware dedicated forum, with no outcome, only it was x86 at the time. arm mighht be simplker because of endianness, but there arent many people here around who could carry out such a project especially till commercial availabiliuty. the closest to what you propose is currently gba1000 with its i believe 100mhz 060 accel:
http://www.gb97816.homepage.t-online.de/

ARM is simpler for a great many reasons.  They're made for embedded use so they're relatively simpler to put on a board.  Software emulation isn't a problem.  Or at least it's not the first problem.  A simple ARM board with two CPUs that can run anything at all would be a good start.

I need to talk to some hardware people.  I'm on the Edinburgh tech scene and I know people do this kind of stuff.  Not Amiga stuff yet, but, well, I'll let you know how I get on.

That 060 board looks pretty cool, real 060s are quite expensive though, that would be a barrier there.

[Mrs Beanbag]

I don't think we will ever have another 'golden era' -that was, I guess, 86-94 in Europe.
We can have some nice hobbyists hardware and software.

We are going to have to move off 68x soon. Freescale appear to be phasing out a lot of the lower end chips, and the 040 and 060 parts are still at crazy prices. FPGA (or other) solution can't come fast enough me (in terms of accelerators for classic).

The successor to Freescale's Dragonball is i.MX series, which is an ARM based CPU, so I'd still consider this "linear development".  In other words, if I could do with with the freescale component it would still be "real amiga" spiritually, if that makes any sense to anyone.

ARM is the future of computing though, I'm sure of that.  x86 has to end sooner or later, it's too stupid to continue indefinitely.  Surprised it's lasted this long to be honest.

Still.  Now we can buy a Megadrive in a hand held device, not sure what the hardware is in one of these exactly but there must be a market for a similar Amiga product.

[Mrs Beanbag]

There are many aspects of ARM that make it easier to follow the crowd but then where is the creativity and originality? If you want simple and want to follow the crowd then buy an x86 and run UAE.  I think an enhanced 68k (with ColdFire and other improvements) still has possibilities because I think it can offer better code density than ARM with Thumb 2 while being easier to program and more powerful (although not as energy efficient). It was dropped and is still delegated to the cellar for pure marketing reasons while it is proven technology (68060) that can be improved and scaled up with today's technology. The Natami fpga 68k+ CPU should be as fast as the last 68k processors and it would be possible to burn ~500MHz processors that would provide enough power to do most of today's computing needs.

x86 over my dead body!  I'm as big a fan of 68k as anyone but let's face it, there is never going to be a 68k CPU in the mainstream market ever again; blame marketing all you want, but this is a fact.  The Natami project is awesome but their 68k CPU, in an FPGA or otherwise is always going to be an enthusiast product, with a price tag to match, and there's nothing wrong with that but it's not what I'm aiming for.  If you care about code density though, x86 wins, because it's still an 8-bit instruction set at heart so it can encode some instructions in a single byte, whereas 68k instructions are 16 bit and therefore always multiples of two bytes.

UAE again solves an entirely different problem.  We can do that already of course on existing hardware but having to load it up on another operating system just isn't the same.  It relegates it to the lower social class of historical curiosity.  Emulation isn't living, only reliving.  It has no future, only a past.

ARM will do well in the low end device market where energy efficiency matters. They are getting faster too, but I think x86 will be able to hold them off on the high end.

x86 will still be around for a few more years at the top end but it won't hold on forever.  Heat dissipation is already becoming an unmanageable problem in high performance systems.  Whereas ARM is already being investigated for servers, and Nvidia are going to be pushing it for mainstream desktop/laptop use.  AMD and Intel don't just supply top-end CPUs, once their mid-range and server markets fall away they're going to find their premium products much more difficult to keep competitive.

We need Amiga users to support what we have and consolidate development efforts.

This much I agree with, and I will say, I fully support Natami in their endeavours, and I'd buy one if they were available already, but to be honest I think their project might just be a little too ambitious, which is perhaps why it's taking them so long.  They have made work for themselves with their philosophy, they really are doing things the hard way and hats off to them.  I have no intention of trying to compete with them, it just solves a different problem as far as I'm concerned.

But let's not forget what else we already have in the community, AROS's new Kickstart and 68k JIT for ARM CPU's could come in very handy for the scheme I have in mind.

[Mrs Beanbag]

well my first concern isn't performance so any 68k emulator I can get to compile for ARM will do to begin with.  Should be possible to pull UAE to bits to get something running.  Can get ARM chips of up to 1GHz for less than £50!  Chipset emulation could be done with a lot less.  I need to speak to some hardware folks first.

[Mrs Beanbag]

We know how little of memory and storage an Amiga needs to be useful.

Hell yeah but that's not just the CPU...

Servers generally need to access lots of memory and 64 bit x86 makes sense there. Yea, it generates a little more heat but crank up ARM to that processing power with 64 bits and I wouldn't expect a huge difference.

http://www.tomshardware.com/news/redstone-moonshot-arm-server-data-center,13884.html">tell it to HP

PowerPC was supposed to be able to dethrone x86 due to it's more efficient and superior design but it didn't happen. IBM has take the PowerPC to the max but it's advantages don't seem to be enough to pay the cost differential in most cases.

All market forces, I'm afraid.  It takes a lot to dethrone x86 because of its position, not because of any technical advantages intrinsic to the design.

It's very difficult and expensive to revolutionize the gaming/computing world anymore. Another golden age for me would be a very affordable for everyone Amiga in 1 chip (68k CPU, custom chips, 3D) with backward compatibility.

Indeed and I don't know what that revolution would be.  Amiga revolutionised the home computer world with its high quality graphics and sound, while PCs were still green screen beeping number crunches.  These days PC and console graphics and sound are so good I don't even see the point of them getting any better.  We need radically new concept of computer...

Think Natami produced in enough quantity to approach the Raspberry pi price. Say $100 U.S. with the expansion the Natami has. It is possible with enough quantity.

Yeah but we'll never get that quantity if it is only of interest to die-hard fans.  But there is a demand in the world at large for a cheap computer that's competent at games like a console, works out of the box without mucking about with drivers, but also with an operating system that you can use to browse the web, write docs, draw graphics, compose music etc.. just from a software side of things, I am sick that these days I have to pay £400 for cubase or photoshop!  (Well I don't because I use Gimp on Linux but you know...)

XBox 360 runs on a PowerPC chip by the way.

[Mrs Beanbag]

Yes, a computer with some FPGAs on board that could be reconfigured on the fly through the OS could lead to some very interesting projects...

Tonight I've been looking into hardware/realtime raytracing.  Of course we all remember The Juggler.  Raytracing was what made Amiga's name!

So I'm now wondering just how many ARM coprocessors we could pack on one board... forget GPUs, maybe a stack of CPU/FPGA pairs could do all sorts of crazy things.

[Mrs Beanbag]

ARM is very much the present of computing, let alone the future. I wouldn't write off the x86 though. The current generation of these processors is a far cry from the clunky old components. The modern 64-bit implementations are actually quite nice and extremely high performance.

Oh yeah there's a really neat RISC core hiding behind all that microcode gubbins, shame we can't get at it directly and turn off all those redundant transistors...

Still.  Check this out: http://www.youtube.com/watch?v=oLte5f34ya8

this is the sort of trick a new Amiga ought to aim for.  Forget GPUs, massive parallelism is the way to go.  Maybe a single standard supervisor CPU with a whole load of barrel co-processors similar to the UltraSparc T1.  The throughput of those things is incredible, given the right workloads.  They threw away such complexities as out-of-order execution in exchange for simultaneous multithreading, thus all but eliminating cache latencies.  This strategy would be perfect for highly paralellisable workloads such as ray-tracing.

We could call them Juggler Chips!

[Mrs Beanbag]

Full ray tracing is a tough one due to the tendency of threads to become divergent in their flow of execution but far from impossible with modest GPUs today. Then there is ray marching, which is the poor man's next best thing. And they can do that entirely realtime. In your browser, even, if you happen to have a WebGL capable one and supported hardware.

On ray marching, or "volume ray casting" as they call it, Wikipedia states

"However, adaptive ray-casting upon the projection plane and adaptive  sampling along each individual ray do not map well to the SIMD  architecture of modern GPU; therefore, it is a common perception that  this technique is very slow and not suitable for interactive rendering.  Multi-core CPUs, however, are a perfect fit for this technique and may  benefit marvelously from an adaptive ray-casting strategy, making it  suitable for interactive ultra-high quality volumetric rendering."

http://en.wikipedia.org/wiki/Volume_ray_casting

Here Intel are doing real time ray tracing show off their Nehalem core:
http://www.youtube.com/watch?v=ianMNs12ITc

Obviously that is an expensive top-of-the-range CPU there (or rather, four of them).  It makes me wonder what could be done with a big bunch of ARM chips.  GPUs can be made to do this but you'd not be using them optimally.  Likewise even a general purpose chip like the Nehalem is a lot more complex than necessary.

I think to sum it up, GPUs are designed for a task too specific, while mainstream CPUs are designed for tasks too general.  I wonder if this goes some way to explain AMD's strategy with their Bulldozer chips, which seems to have confused a lot of people.

[Mrs Beanbag]

@Mrs Beanbag

I do agree that FPGAs represent a big opportunity to change how flexible computing architecture can be, but the line I quoted above doesn't make sense. The very reason GPGPU is a growing field is due to the massively parallel nature of modern GPUs. GPU computing and FPGA computing are not identical, but they are clearly related.

Why are you talking about FPGAs?  I never mentioned FPGAs in that post.  I'm talking about generic CPUs in massive parallelism.  GPUs are SIMD.  Well some degree of SIMD is still useful for raytracing, because they do a lot of basic vector arithmetic, but not with the same amount of repetition as a GPU is designed for.

GPUs are of course massively parallel, but they are optimised for a specific sort of workload, although they are becoming more general purpose lately.

I've got good news for you, your Juggler chips already exist:
http://www.eetimes.com/electronics-products/processors/4115523/Xilinx-puts-ARM-core-into-its-FPGAs

These are not barrel processors.  They are FPGAs with an ARM core attached.  Which is also cool and useful, but not "Juggler chip" as described above.  "Juggler chip" is similar design strategy to UltraSPARC T1 but with ARM instruction set.

[Mrs Beanbag]

Wikipedia must be out of date there. I can assure you raymarching works fine on my gtx 275 and better still on fermi based GPUs which have superior divergent conditional branch handling and cache. There are several realtime examples written entirely in glsl for Mr doob's web glsl playground which run at full speed on my kit. I've tested even better CUDA specific examples. Lastly, even SIMD does not accurately describe the operation of these GPUs. SIMD better describes SSE or altivec. Its a poor description for modern stream processors.

Shader engines aren't really ray tracing, impressive though they may be.  CUDA can get closer to what I'm talking about, but "General Purpose GPU" is a self-contradictory phrase!  Either these chips are general purpose or they are special purpose.  Maybe we only call them GPU because they happen to be used for graphics.

I'm not saying it can't be done, or even done well, I'm only saying it's not optimal, because the chips are designed for something else and to make them do it you have to work around their limitations.  In other words, if they are so good at doing ray tracing already, imagine if they were actually designed for ray tracing instead of rasterisation... it seems to me that the complexity of graphics is these days getting to the point where ray tracing could actually be faster!  But a mainstream CPU is also far more complex than it needs to be, having been optimised for single-threaded performance, which is the opposite of what we want.

I mean look at this:
http://www.youtube.com/watch?v=x5aXxJGefxU

100% CPU work, and "Running in an E2140 1.6GHZ", that's not a lot of CPU, doesn't even have hyperthreading.  Now if you had 16 of such cores instead of only two, each with 8-way hyperthreading instead of superscalar... this is where CPU and GPU would meet in the middle.  The compromises made for streaming processors no longer seem appropriate.

[Mrs Beanbag]

Well if that is the case then a modern GPU *is* a CPU, the only difference being the way it is connected to the memory.  But I still don't think that is quite the case.  How I understand it, a GPU is given a "kernel" which is a small program that is run for every piece of data that comes in on the stream.  They don't run a "full program" like a CPU does, but continually apply the same function over and over on the incoming data.  Which is very useful.  But its "Turing completeness" is limited to the bounds of the kernel, that is you can branch and loop as much as you like within a kernel, but you can't arbitrarily call one kernel from another.  Also the data goes in one end and out the other, very useful if you can split your dataset up into loads of small independent chunks.  If you're doing rasterisation this is very easy because every triangle can be done independently.  Maybe there's some cunning trick to it but I don't know how ray tracing would work in that scheme, because you want to do blocks of pixels in parallel rather than triangles or objects so every pipeline needs access to the complete scene structure.

But theory aside, I've been putting "real time ray tracing" into Youtube and I get a lot of stuff on CPUs and GPUs, and a lot of it is very impressive, but I don't see that GPUs actually have any obvious advantage over CPUs so far.

[Mrs Beanbag]

I guess I misread what you meant. Perhaps it would be best to outline in more detail what design you had in mind for the 'juggler chip', I'm interested to hear your thoughts.

Ok just look up UltraSPARC T1 to get what I mean.  I'll summarise.  Traditionally CPUs have been designed for single-threaded performace, by inventing such things as instruction-level parallelism (you can do several consecutive instructions at once if they don't clash), branch predication, speculative execution, out-of-order execution etc.. All of these things require extra circuitry of course but it's worth it for the performance boost.  Problem is you don't get 2x performance for 2x transistors so then multiple cores came into play.  But lots of programs don't run in multiple threads so they still try to maximise the performance of single cores.  And they are still held back when one instruction has a dependency on a previous one that hasn't finished yet, or it's waiting for memory reads etc..

UltraSPARC T1 took a more holistic approach.  Knowing servers always run umpteen threads at once, there's really no point in all that extra complexity to get the most single threaded performance.  So they ditched it all and instead made a CPU core that could switch threads on every cycle.  They only have to have a register file for each thread and rotate them round (hence the term "barrel processor"), and you can get rid of a whole load of complexity and go back to a very simple core that only does one instruction at once, which gives you room for loads more cores on a die, and cache misses can be made to vanish into the background.  Single-thread performance is terrible, but if you can throw enough threads at it it can keep up with CPUs that run at far faster clock speeds.  The T1 typically ran at 1.2GHz and, given the right sort of workloads, could keep pace with 3GHz Xeons.

[Mrs Beanbag]

Well that makes sense but

Think of these as very simple CPU cores where stuff like conditional branching is expensive but data processing is not. Then imagine them in clusters, each cluster running the same code but on different data. Not like a SIMD unit, but as an array of cores, able to branch independently but optimal when in step.

see this is where I'm getting stuck, surely independent conditional branching is exactly what ray tracing needs a lot of.

Also the kernel doesn't have random access into a large area of memory (where your scene might be stored, for instance) but only to the small portion that comes in on the stream, yes?