Amiga.org
Amiga computer related discussion => General chat about Amiga topics => Topic started by: SamuraiCrow on August 05, 2008, 04:04:55 AM
-
This post by me from the other Natami thread is what started this thread:
The Natami is pushing the hardware limits but it will only be able to run OS 4+ if they add a PowerPC accelerator card to it. Before the Mac went to Intel the PowerPC was a vibrant design with lots of attention and now it is relegated only to game machines which are restricted by hypervisors so that they don't allow ordinary people to experience their full potential.
I think PowerPC is a dead-end as much now as ever and the Intel and AMD processors are reaching a dead end also due to the heat restrictions of higher clock frequencies and are turning their attention toward multiple cores. Since their software doesn't run well on multiple cores they are going to be at a standstill.
I think the Intels will make it further than the PowerPCs because they have a more compact instruction set but that will wear thin when easier-to-use instruction sets prevail. I think the way of the future is asymmetric multicore design where the cores are dedicated to the functionality they are intended for.
What makes an Amiga, in my opinion, is the dual-bus architecture. While most computers are stuck with a left-brain dominant design that didn't allow for parallelism, the Amiga introduced a computer with a right hemisphere for creative thinking. On most computers it may be considered a required peripheral for graphics and sound, but on the Amiga it was standard, integrated, and elegant. On the stock A1200 it was even right-brain dominant due to the underpowered main processor.
I could say more but if you want to hear more of why I think the way I do, I'll start a new thread.
So here I go:
Most software is serial with branches. Most hardware is parallel but controlled by a processor. Now the industry expects software engineers to develop parallel applications and hardware engineers to take the lazy way out and make duplicate cores. This can only lead to tears because they are asking hardware and software engineers to use the other one's work techniques.
Software engineering is supposed to be easier than hardware engineering because unique software is more common than unique hardware. The symmetric multiprocessing path will be used in high-end applications but will be impractical for low-end applications until new programming languages come out that take advantage of parallelism.
Hardware engineering is always more parallel than software engineering because that's the way gate layout works on a chip. It's always quickest to have many things done at once and only resort to serialization when you run out of space on the die.
What I'm proposing is a compromise: FPGAs are programmable hardware and the software that controls them is designed to convert serial programs into parallel programs whenever possible but, at the same, maintain synchronization with the other parts of the chip by counting clock cycles.
The type of parallelism that takes place on an FPGA is much more flexible than parallel processors because, as long as you've got space on the chip, you can expand the bus width to 128 bits or narrow it to 1 serial connection depending on the data type.
The Amiga championed the way into the multimedia age by allowing a serial threaded processor to multitask and by making the most processor-intensive tasks run on a separate bus for all of the right-brain graphics calculations and sound mixing.
The next generation of hardware will start there with asymmetric cores like Intel's Atom and the Natami70. These multicore chips have a processor, a graphics core, sound capabilties and have them all on one chip. To keep down the costs they will have to cache the accesses differently from the dual-bus architecture of the Amiga but there is a unique characteristic that the Amiga chipsets had that isn't on the others: The and/or/invert logic in the blitter's bit-masking mode is the same bit-twiddling technique used in the FPGA!
Now, by practicing the custom bit-masking modes of the blitter, software engineers can learn to become hardware engineers and hardware engineers have a more important role. Hardware engineers can take the bit-masking modes of the blitter programmers and make them into custom chips thus completing the cycle. Software makes new hardware and new hardware makes more efficent ways to make software.
For an example of software being translated into hardware, download this PDF Slideshow (http://llvm.org/devmtg/2008-08/Sander_HW-SW-CoDesignflowWithLLVM.pdf) from the LLVM Developers' Conference that took place last Friday. There's a Quicktime Movie (http://llvm.org/devmtg/2008-08/Sander_HW-SW-CoDesignflowWithLLVM_Lo.3gp) to go with it if you can view it.
-
SamuraiCrow,
I guess this is the bottom line for the reason I have to have a Natami. It is the closest modern example of a new Amiga I've seen yet. None of the other projects "even the vaporware ones" come close. The final version of this thing may just catch on to other types of users. The only problem I see is making new software. I'm not too optimistic on the idea that some software may go back in to production, I myself have a good collection but new users may have a problem.
Chris
-
Lazy or not, single-threaded software still benefits from multiple cores, as users tend to run more than one single-threaded program at a time. At the same time, however, we're expecting more out those single cores than we have in the past by way of hardware virtualization.
My own preference is for hardware solutions that keep my current Amiga platform running. I'm not really interested in reinventing the Amiga as something that does all the things a cost-effective *nix or Windows workstation does.
That said, I should probably just keep my mouth shut. ;-)
-
This sound like Amiga to me. Amiga was all about forward thinking. Jay Miner would have been all over this. This sounds really promising.
Can you see a system like this with AROS on it apart from all the platforms it running on all ready?
A super NATAMI ONE Amiga for WB AROS with seamless backward compatibility thanks to UAE. Is this what lays ahead? Closer cooperation between the soft and hardware side?
-
SamuraiCrow wrote:
Hardware engineering is always more parallel [snip] and only resort to serialization when you run out of space on the die.
Bollox.
SamuraiCrow wrote:
The software that controls [FPGAs] is designed to convert serial programs into parallel programs whenever possible but
Again not true. This software you talk of does not control. It creates the contents of the FPGA. And it does not convert serial programs into parallel programs. (Not quite sure where you got that idea from.) The high level languages used to define the contents have sequential (serial) and concurrent (parallel) statements where the designer can choose serial or parallel. The Synthesis tools do not (or at least, very rarely) try to change this.
SamuraiCrow wrote:
at the same, maintain synchronization with the other parts of the chip by counting clock cycles.
Yup, static timing analysis... all done over several minutes while creating the image to load onto the FPGA.
SamuraiCrow wrote:
The type of parallelism that takes place on an FPGA is much more flexible than parallel processors because, as long as you've got space on the chip, you can expand the bus width to 128 bits or narrow it to 1 serial connection depending on the data type.
Not real-time you can't.
You seem to be talking about reconfigurable hardware using FPGA's. While this has been discussed and experimented with over the years. The devices to support partial reprogramming do not commonly exist. (Although there are some on the market).
You could not reprogram the entire FPGA in real time as it currently takes many many hours to re-calculate complex designs. You have to cut the design into manageable hierarchical structures which can individually be reconfigured. However if the reconfiguration exceeds the resources previously owned by that block... you're screwed. You need to have worked out the sizes of all possible reconfigurations before you implement the overall FPGA.
And as I said... most devices do not support partial reconfiguration. Not to mention holding the current data in the pipelines.
BUT: It's very interesting stuff... undoubtedly the future of some areas of electronics.
SamuraiCrow wrote:
The and/or/invert logic in the blitter's bit-masking mode is the same bit-twiddling technique used in the FPGA!
At the lowest possible level.
SamuraiCrow wrote:
Now, by practicing the custom bit-masking modes of the blitter, software engineers can learn to become hardware engineers and hardware engineers have a more important role. Hardware engineers can take the bit-masking modes of the blitter programmers and make them into custom chips thus completing the cycle.
Erm, I don't think so. :-)
The overheads of reprogramming will be (for a long time) worse than just doing it in software.
What would be better is if the software engineers knew how to use the profiling tools that come with their system, they profile where the code is spending most of it's time, and work out what "acceleration" hardware they would like... and then reconfigure some "spare" logic to do this task. Reconfiguring at the data-path level is not practical yet.
Edit: Just read the slides. Interesting how it brushes over the reconfigurability aspect.
P.S. I think I had a board like the one in those slides years ago. We're all Virtex4 in our office now.
-
Well, lets hope there is a crouched way forward, and you know who travel them roads.
-
@SamuraiCrow,
I'm not sure if I follow your thinking here. The FPGA issues aside, since they have been covered by AlexH... I don't uderstand your left brain/right brain metaphore...
Lets look at my aged Althon64 PC (and contrast it with my one of my A1200s with 4meg FastRam)...
The Athlon: It has a CPU on a bus with some memory, local and for the CPU only.
The A1200: It has a CPU on a bus with some memory, local and for the CPU only.
The Athlon: It has a separate main System bus for all support systems (GFX, Audio, I/O).
The A1200: It has a separate main System bus for all support systems (GFX, Audio, I/O).
The Athlon: It has a GFX CoProcessor (a Nvidia 8600) with it'a own RAM (512Megs) that performs all gfx functions, and capible of massively parallel GP processing.
The 1200: It has a GFX CoProcessor (The Blitter, Copper and barrel shifter) with its own RAM (well shared with the Audio and I/O).
The Athlon: It has a dedicated Audio DSP and its own RAM.
The A1200: It has a DMA fed DAC, and RAM shared with the GFX and I/O
I could go on... but my point is made, the Athlon is structurally rather similar to the A1200, but massively improved on the idea. Each of the various subsystems are powerful independant devices in their own right. I don't really see how this relates at all to your mataphore?
-
@alexh
I never said configuring the FPGA in realtime was a reality. I didn't know how long it took to do the timing analysis though. What I was thinking of was more cores to add to the chipset could be implemented by converting some of the most frequently called subroutines in the OS to custom operations in the hardware.
@bloodline
The right-brain analogy was for the custom chips having their own memory bus. On the NatAmi there are 16-megs of Chip RAM built in to the FPGA. It is used as local-store memory for the custom chips and functions like a software cache for multimedia chip accesses.
Oddly, for whatever reason, the custom chips on the Natami can access the Fast bus and gain a huge amount of memory. So whether it's fully a dual-bus Amiga remains to be seen.
Your analogy of the PC being like an Amiga holds very true. Many graphics cards do have their own memory and are like Amigas in that aspect. If the GPU were used for doing all of the sound mixing like is proposed on the NatAmi, your AROS system could be an Amiga.
-
This is slightly off-topic, but people might want to take a look at Stanford's ELM architecture (http://cva.stanford.edu/projects/elm/architecture.htm). They've identified that 70% of all power in a CPU is taken up by loading data and instructions. The ELM architecture is designed to lower that significantly, and they claim that it's power consumption is as little as 3x what an ASIC implementation for a task would be (i.e., the same algorithms implemented as software on the ELM vs an ASIC based design). This is down from 50x for typical CPUs.
Hans
-
SamuraiCrow wrote:
@bloodline
The right-brain analogy was for the custom chips having their own memory bus.
Well, all systems use separate busses for different parts of the system... that's nothing unique to the Amiga.
On the NatAmi there are 16-megs of Chip RAM built in to the FPGA.
Is that an FPGA with 16megs?
It is used as local-store memory for the custom chips and functions like a software cache for multimedia chip accesses.
I don't understand... software cache?
Oddly, for whatever reason, the custom chips on the Natami can access the Fast bus and gain a huge amount of memory. So whether it's fully a dual-bus Amiga remains to be seen.
Again, I don't understand... if the Custom chips can access the CPU local bus, then why bother with it?
Your analogy of the PC being like an Amiga holds very true. Many graphics cards do have their own memory and are like Amigas in that aspect. If the GPU were used for doing all of the sound mixing like is proposed on the NatAmi, your AROS system could be an Amiga.
Why not just use a DSP for the Audio mixing? Leave the GPU to do GFX stuff... perhaps?
-
bloodline wrote:
SamuraiCrow wrote:
@bloodline
The right-brain analogy was for the custom chips having their own memory bus.
Well, all systems use separate busses for different parts of the system... that's nothing unique to the Amiga.
On the NatAmi there are 16-megs of Chip RAM built in to the FPGA.
Is that an FPGA with 16megs?
It is used as local-store memory for the custom chips and functions like a software cache for multimedia chip accesses.
I don't understand... software cache?
Oddly, for whatever reason, the custom chips on the Natami can access the Fast bus and gain a huge amount of memory. So whether it's fully a dual-bus Amiga remains to be seen.
Again, I don't understand... if the Custom chips can access the CPU local bus, then why bother with it?
Your analogy of the PC being like an Amiga holds very true. Many graphics cards do have their own memory and are like Amigas in that aspect. If the GPU were used for doing all of the sound mixing like is proposed on the NatAmi, your AROS system could be an Amiga.
Why not just use a DSP for the Audio mixing? Leave the GPU to do GFX stuff... perhaps?
The Natami is a hybrid between PC architecture and Amiga architecture. It will still have 16 megs of static memory on the chip for use as chip memory but it will be many times faster than the fast-page memory used in the AGA machines. It will function much faster than even the main memory on the motherboard. That's how it will function as a local-store memory. When I referred to it as a software cache, I mean that it will function much like a disk caching system works. The recently accessed stuff will be in the 10 nanosecond chip memory for ready access by future operations.
If you used a DSP for sound then it wouldn't be a single-chip solution. As it is, there will likely be some external memory chips on the system board but only because it is more configurable that way. The idea is to have a mostly self-contained computer on just one chip.
As for the multi-bus architecture, it is only common for desktop models, single-chip solutions like the Intel Atom will use a bunch of backside caches and other tricks to make their systems work. Since the Amiga is designed to run from 2 megs of chip RAM, there will be no conflict with using software to detect and use the chip memory manually on the Natami without wasting chip space on yet another cache controller.
-
SamuraiCrow wrote:
On the NatAmi there are 16-megs of Chip RAM built in to the FPGA.
Yeah right... NOT!
An FPGA with 16-Mbytes of on chip SRAM would cost more than the gross debt of Northern Rock!
-
At least that was the impression that I got. Maybe it will use external SRAM but either way it's going to be fast for a 200 MHz chip assuming it gets that far.
-
It's gotta be external. The biggest FPGA's today only have about 3Mbytes SRAM and they cost about $10,000 each.
You have to take everything written by the Natami wannabe "Gunnar von Boehn" as bollox.
Only Thomas Hirsch knows what is really going on.
-
bloodline wrote:
@SamuraiCrow,
I'm not sure if I follow your thinking here. The FPGA issues aside, since they have been covered by AlexH... I don't uderstand your left brain/right brain metaphore...
Lets look at my aged Althon64 PC (and contrast it with my one of my A1200s with 4meg FastRam)...
correcting a lot of mistakes here
The Athlon: It has a CPU on a bus with some memory, local and for the CPU only.
The A1200: It has a CPU on a bus with some memory, local and for the CPU only.
The Athlon has the memory controller built-into the CPU, requiring all system access to utilize the Athlon whenever they need memory. Is limited to an 8-bit DMA system.
By comparison, the Amiga has memory used exclusively for the CPU, and used for the rest of the system.
The Athlon: It has a separate main System bus for all support systems (GFX, Audio, I/O).
The A1200: It has a separate main System bus for all support systems (GFX, Audio, I/O).
No, the Athlon has all support systems running through the CPU bus, opposite of the Amiga which keeps them seperately
The Athlon: It has a GFX CoProcessor (a Nvidia 8600) with it'a own RAM (512Megs) that performs all gfx functions, and capible of massively parallel GP processing.
The 1200: It has a GFX CoProcessor (The Blitter, Copper and barrel shifter) with its own RAM (well shared with the Audio and I/O).
Here is the real difference. The Athlon has this the opposite of the Amiga, sharing the CPU memory while the Amiga shares the video memory. The advantage to this is in the fact that the CPU gets undivided memory access in the Amiga, unlike the Athlon[/quote]
The Athlon: It has a dedicated Audio DSP and its own RAM.
The A1200: It has a DMA fed DAC, and RAM shared with the GFX and I/O
[/quote]I don't see many Athlons with audio DSP's. In addition, you remain stuck with the 8-bit DMA system of the Athlon vs the 16-bit DMA of the Amigas.
I could go on... but my point is made, the Athlon is structurally rather similar to the A1200, but massively improved on the idea. Each of the various subsystems are powerful independant devices in their own right. I don't really see how this relates at all to your mataphore?
No, your example fails due to not understanding the underlying design.
-
Downx, perhaps if you sort out your quotes I'd be able to follow it...
I honestly have no idea what you are talking about... I think you've misread my post... since I know you're not stupid... so reread it, cheers :-)
Oh, and yeah, I actually have a DSP in my Athlon desktop (with a Gigabyte Nvidia4 chipset)... and since I was comparing MY Athlon with MY A1200..
PS have you read the old AMD Athon64 technical docs right?
-
downix wrote:
The Athlon ... Is limited to an 8-bit DMA system.
:-o
-
-D- wrote:
downix wrote:
The Athlon ... Is limited to an 8-bit DMA system.
:-o
I can only think he is referring to the old southbridge DMA... I guess he doesn't know that it's not used any more, since DMA is an old concept... with USB, FIrewire and PCI-E
-
bloodline wrote:
I can only think he is referring to the old southbridge DMA... I guess he doesn't know that it's not used any more, since DMA is an old concept... with USB, FIrewire and PCI-E
Wow. just Wow.
I hope you didn't mean that the way you typed it.
I should probably let Nate answer this himself, as I'll probably get it as wrong as you did. Yes, DMA is old. It's as old as the IBM System 360, and it's as old as the Nvidia GTX 280.
DMA stands for Direct Memory Access. It's not (just) a theoretical concept, or an antique type of data bus, it's a data transfer method, regardless of bus. It's the method a peripheral device uses to put/get its data into/from memory without getting permission from the CPU. It's written into the PCI/AGP/PCI-e specs.
An nVidia SLI setup uses DMA. It doesn't wait for the CPU to fill its (3-way) 3 Gigabytes of texture/data RAM, the CPU tells the GPU where in main memory the data is, and the GPU goes and gets it, itself. If you have a network connector, it will also DMA its data, as will any SCSI, and most SATA and PATA controllers (hint: UDMA mode).
BTW, Firewire, aka IEEE-1394, aka Sony iLink, also uses DMA.
DMA is also the reason there's a patch for A1-XEs. If the OS isn't critically careful, the peripheral DMA data can get overwritten by the CPU - while the DMA transfer is still in progress.
-
Ahh yes, The naysayers are in force. Come on guys, don't sweat the little stuff. A good solution for old hardware is on track and nobody is twisting your arm. Just go out and get one when available. It will probably blow your mind in speed and versatility.
I for one need to see the Multimedia features that come out of this, should be very interesting.
Chris
-
SyrTran wrote:
bloodline wrote:
I can only think he is referring to the old southbridge DMA... I guess he doesn't know that it's not used any more, since DMA is an old concept... with USB, FIrewire and PCI-E
Wow. just Wow.
I hope you didn't mean that the way you typed it.
Ok, I will have to go into detail then... (Can't anyone on this board use Google?)
I should probably let Nate answer this himself, as I'll probably get it as wrong as you did. Yes, DMA is old. It's as old as the IBM System 360, and it's as old as the Nvidia GTX 280.
DMA stands for Direct Memory Access. It's not (just) a theoretical concept, or an antique type of data bus, it's a data transfer method, regardless of bus. It's the method a peripheral device uses to put/get its data into/from memory without getting permission from the CPU. It's written into the PCI/AGP/PCI-e specs.
An nVidia SLI setup uses DMA. It doesn't wait for the CPU to fill its (3-way) 3 Gigabytes of texture/data RAM, the CPU tells the GPU where in main memory the data is, and the GPU goes and gets it, itself. If you have a network connector, it will also DMA its data, as will any SCSI, and most SATA and PATA controllers (hint: UDMA mode).
BTW, Firewire, aka IEEE-1394, aka Sony iLink, also uses DMA.
DMA is also the reason there's a patch for A1-XEs. If the OS isn't critically careful, the peripheral DMA data can get overwritten by the CPU - while the DMA transfer is still in progress.
When you refer to DMA on the IBM-PC compatible architecture you are refering to the old 16bit ISA system, the DMA in this part of the system can only access the lower 16megs of the adderss space. Almost nothing uses this any more... but it is all still included in the southbridge... this is where things like Serial ports, Parallel port, the Floppy drive, Real time clock, Legacy IDE, PS/2 ports and god knows what else antiquated hardware sits.
All modern parts of the system, GFX cards, Sound cards, I/O (USB, Firewire, ATA/S-ATA, Ethernet, etc...) sit on the PCI/PCI-E bus. Which is then connected via the northbridge to the CPU. The CPU has a second local bus where the main system RAM is located... I hope Downx wasn;t suggesting that the System RAM was located on the PCI/PCI-E bus because that would be a pretty horrific architecture. The Athlon64 is slightly different at the top as it use HyperTransport, and my particular Athlon64 actually has three Hyper transport links and its own RAM controler... but that just confuses this issue.
-
i hope this is helpfull, just for the sake of clarity...
Intel x86 architecture:-
CPU connects to the northbridge via the frontsidebus only. no seperate memory bus.
the northbridge has the memory subsystem controllers, and PCIe bus controllers and/or AGP hookup. plus a link to the southbridge which has your basics. USB, Floppy, normal IDE, original PCI, parallel, serial, ps2 yadda yadda yadda.
AMD x86 architecture:-
the CPU has connection to the north bridge via hypertransport (a much more flexable hook up than using frontsidebus). plus the CPU has its own onboard memory controllers and bus connection, so doesn't need the extra hop to the northbridge to get data to and from ram.
the northbridge does the same, except, no need for memory subsystem, as it is all on the CPU, but has PCIe controllers and the southbridge link just like the above.
southbridge does the same job as the intel system.
each has its own advantages and disadvantages.
Intel currently seems to favour a bottom heavy system, as graphics cards can DMA data to and from main memory without bothering the CPU, or its relatively antiquated frontsidebus connection - via the north bridge.
this will change when intel adopts the 'quickpath' system for interfacing CPUs to the system. about that time intel will probably adopt the CPU onboard memory controllers that AMD has championed so far.
AMD favours a top heavy system where the CPU has dominance on main memory access, but everything else needs to use the (primary) CPU as the gate keeper to main memory over the hypertransport link. this is advantagious in a multiple CPU socket system with multiple hypertransport links, as more CPU's equals more memory controllers, and more memory.
i'm not entirely conversant with the hypertransport bus technology, but i'm sure with it being a fairly open interfacing standard, the graphics card bothering the cpu to let it move data around in main memory isn't too detrimental to overall CPU performance....
sorry for the off topic. :-)
-
bloodline wrote:
SyrTran wrote:
bloodline wrote:
I can only think he is referring to the old southbridge DMA... I guess he doesn't know that it's not used any more, since DMA is an old concept... with USB, FIrewire and PCI-E
Wow. just Wow.
I hope you didn't mean that the way you typed it.
Ok, I will have to go into detail then... (Can't anyone on this board use Google?)
I should probably let Nate answer this himself, as I'll probably get it as wrong as you did. Yes, DMA is old. It's as old as the IBM System 360, and it's as old as the Nvidia GTX 280.
DMA stands for Direct Memory Access. It's not (just) a theoretical concept, or an antique type of data bus, it's a data transfer method, regardless of bus. It's the method a peripheral device uses to put/get its data into/from memory without getting permission from the CPU. It's written into the PCI/AGP/PCI-e specs.
An nVidia SLI setup uses DMA. It doesn't wait for the CPU to fill its (3-way) 3 Gigabytes of texture/data RAM, the CPU tells the GPU where in main memory the data is, and the GPU goes and gets it, itself. If you have a network connector, it will also DMA its data, as will any SCSI, and most SATA and PATA controllers (hint: UDMA mode).
BTW, Firewire, aka IEEE-1394, aka Sony iLink, also uses DMA.
DMA is also the reason there's a patch for A1-XEs. If the OS isn't critically careful, the peripheral DMA data can get overwritten by the CPU - while the DMA transfer is still in progress.
When you refer to DMA on the IBM-PC compatible architecture you are refering to the old 16bit ISA system, the DMA in this part of the system can only access the lower 16megs of the adderss space. Almost nothing uses this any more... but it is all still included in the southbridge... this is where things like Serial ports, Parallel port, the Floppy drive, Real time clock, Legacy IDE, PS/2 ports and god knows what else antiquated hardware sits.
All modern parts of the system, GFX cards, Sound cards, I/O (USB, Firewire, ATA/S-ATA, Ethernet, etc...) sit on the PCI/PCI-E bus. Which is then connected via the northbridge to the CPU. The CPU has a second local bus where the main system RAM is located... I hope Downx wasn;t suggesting that the System RAM was located on the PCI/PCI-E bus because that would be a pretty horrific architecture. The Athlon64 is slightly different at the top as it use HyperTransport, and my particular Athlon64 actually has three Hyper transport links and its own RAM controler... but that just confuses this issue.
Yes a horrific design if it was done. Thankfully it is not. But you are still tied to the CPU / Northbridge (there is no HT to Northbridge connection in Athlons, the Northbridge is embedded INTO the Athlon, the HT is the connection to the southbridge) for system memory access. That means whenever this memory is polled for such minor things as, say, keyboard or mouse access, you will find that the memory is, ta da, blocked from CPU access during this time. The whole use of CPU cache, pre-fetching, all those fun things is to prevent CPU idle during this period. But as the CPU keeps going faster and faster but a keyboard is still, really, the same thing that was powered by the 4092 way back when, that lag time will get worse and worse. By putting the CPU's memory front-and-center makes sense for a low cost minicomputer. But the Amiga instead did a "hey, we have a dedicated RAM for our peripherals" which means that the peripherals ran without bothering the main CPU. The PC's video and DSP cards are a step in the right direction, but not a complete one. Intel's new maneuvers for a TurboFlash on board is, really, the best step to this I've seen in ages. But nothing is handling the peripherals but... the CPU. Your big huge math engine is resorting to doing the same meanial tasks as an 8088 controller chip. Some high-end systems such as my Xeon here have an i940 processor for controlling these peripherals, but they are the exception, rather than the rule, and using a general purpose CPU for such a specialized task is crude. The best route would be to do the "GPU/DSP" route, with dedicated controlling systems for the various peripherals.
-
@Downx
Are you smoking crack? My mouse and Keyboard are on USB, which itself is on the PCI-E bus, which is connected to the CPU via HyperTransport... the RAM is connected directly to the CPU, not via an HT link.
Your idea of a computer system seems 15 years old!!!! The only thing on the south bridge is pretty much just the BIOS now (since I don't use any of the legacy ports or floppy disk)...
Start here to refresh your memory:
http://en.wikipedia.org/wiki/Hyper_transport
http://en.wikipedia.org/wiki/Socket_939
And here is a nice picture of the standard PC architecture (Note the different Busses):
(http://upload.wikimedia.org/wikipedia/commons/thumb/1/1a/Northsouthbridge.svg/300px-Northsouthbridge.svg.png)
-
bloodline wrote:
@Downx
Are you smoking crack? My mouse and Keyboard are on USB, which itself is on the PCI-E bus, which is connected to the CPU via HyperTransport... the RAM is connected directly to the CPU, not via an HT link.
Your idea of a computer system seems 15 years old!!!! The only thing on the south bridge is pretty much just the BIOS now (since I don't use any of the legacy ports or floppy disk)...
Start here to refresh your memory:
http://en.wikipedia.org/wiki/Hyper_transport
http://en.wikipedia.org/wiki/Socket_939
And here is a nice picture of the standard PC architecture (Note the different Busses):
(http://upload.wikimedia.org/wikipedia/commons/thumb/1/1a/Northsouthbridge.svg/300px-Northsouthbridge.svg.png)
Um, dude, that is what I just said. The "Northbridge" which includes the RAM controller is integrated onto the die with the CPU in the Athlon, with a HT bus connecting the CPU to the southbridge.
So you agree, for anything to utilize system RAM, it must go through the northbridge, now handily contained within the silicon of the Athlon CPU? Or what are you saying?
That picture you have is several years old, only Intel still uses that architecture, and Intel is abandoning that next year with their next-generation interconnect technology. Death to the Front Side Bus!
-
downix wrote:
bloodline wrote:
@Downx
Are you smoking crack? My mouse and Keyboard are on USB, which itself is on the PCI-E bus, which is connected to the CPU via HyperTransport... the RAM is connected directly to the CPU, not via an HT link.
Your idea of a computer system seems 15 years old!!!! The only thing on the south bridge is pretty much just the BIOS now (since I don't use any of the legacy ports or floppy disk)...
Start here to refresh your memory:
http://en.wikipedia.org/wiki/Hyper_transport
http://en.wikipedia.org/wiki/Socket_939
And here is a nice picture of the standard PC architecture (Note the different Busses):
(http://upload.wikimedia.org/wikipedia/commons/thumb/1/1a/Northsouthbridge.svg/300px-Northsouthbridge.svg.png)
Um, dude, that is what I just said. The "Northbridge" which includes the RAM controller is integrated onto the die with the CPU in the Athlon, with a HT bus connecting the CPU to the southbridge.
So you agree, for anything to utilize system RAM, it must go through the northbridge, now handily contained within the silicon of the Athlon CPU? Or what are you saying?
Of course... and in that way, System RAM on a PC is like FastRAM on the Amiga. Which was my original point. Just as the Amiga Chipset does not access FastRAM, the Gfx chips and Audio chips do not access System RAM... like the Amiga there is RAM dedicated to the task.
That picture you have is several years old, only Intel still uses that architecture, and Intel is abandoning that next year with their next-generation interconnect technology. Death to the Front Side Bus!
Given the two biggest PC architectures are AMD and Intel... and the biggest of those is Intel, then that picture is more than adequate!
Now if we refer back to your original post... You will agree that it bears no relation to the modern system.
-
Um, dude, you just destroyed your own arguement.
No, the CPU ram is closer to the CHIP ram, that is, "a shared pool of RAM, used by all peripherals. There is no PC equal to the Fast RAM, that is RAM used soly by the CPU, without interruption by those pesky peripherals. Video cards use their own RAM, which is closer to the Amiga's Fast RAM, but is now only for the GPU.
as I said, inverse design.
And, as pointed out, Intel itself is abandoning that design. FSB are for antiques.
-
QuikSanz wrote:
I for one need to see the Multimedia features that come out of this, should be very interesting.
Chris
Hi QuikSanz,
Well, what will intrigue me the most is, an Amiga 4000 w 2 Megs chip, 16 Megs Fast with video toaster + 68060 @ 66MHz (is that the fastest unoverclocked 68060?) w 128 Megs of ram VS. a NatAmi60!
That would be a very compelling stats set.
Also, could we get the performance of a P4 at say 400 MHz?
AOS is so streamlined, that even games that need 1 GHz P4s may actually be able to run on NatAmi60s!
Look at, just how big is DirectX?!? Can't tell me that doesn't use tons of Hz.
-
Atheist,
I'm not sure if my Cyberstorm can get a memory combo that small, 4 old 4 meg?
If I were to clock that high I would probably want to get a fan and heat sink. It is tight inside my A4000T (Amiga Tech), Not sure I can Make that happen as I recall there is a brace in the way.
However those comparisons would sure be telling...
Chris
-
Update from the Natami website regarding how the memory busses are connected:
Just like the original AMIGA, the NATAMI has two fully separate memory busses.
1) The CHIP-memory bus
2) The Fast memory bus.
The SuperAGA chipset has in addition to this a very small 3rd memory block inside the chipset. This 3rd memory block is a Sprite/3D cache and can be used to accelerate blitting and 3D operations.
The two buses are independent and the NATAMI can do two memory operation at the same time, one to each of the buses.
In addition to these two memory access on the two external buses, the NATAMI Blitter can do several memory operations per clock inside his local store.
The CHIP-memory is 64bit wide and is build from very fast pipelined, syncrones external SRAM.
The fast memory on the Natami60 is regular SDRAM.
A major strength of the original AMIGA design is its DMA capabilities. The Natami is fully compatible to this.
But of course the SuperAGA chipset is faster and can do 100 times more DMA than the original AMIGA chipset.
The original AMIGA could do Audio and Sprite DMA into Chip memory only. The original AMIGA could do SCSI DMA into fast memory.
This means the original AMIGA could do DMA to both memory busses but not fully freely.
The Natami improves this design. The Natami can do all types DMA to both memory banks.
From a programming point of view you can program the Natami liek any other AMIGA.
It good to use the chip memory as always to keep your audio and video data in it.
For best performance you should always store your heavy accessed video data in chip memory. But as the Blitter can read from fats-memory as well you are more flexible in creating huge games as you can as well store information inside the bigger fast memory.
SuperAGA is many times faster than normal AGA out of several reasons.
a) Blitter and Chipmemory are 64bit wide.
AGA was 16bit wide.
b) Blitter and Chipmemory is much higher clocks. Natami Chipmemory can be clocked to 200 MHz. While the original AMIGA was only working at 3.7 MHz.
c) The Natami Blitter has a local store inside the chip which means if you blit the same sprite many times or draw the same texture several time you only need to read it once. Depending on your game engine this can up to quadruple the overall performance.
So the chip bus is off of the FPGA but there is a 32Kbyte local store for the 3D and vector acceleration portion of the new SuperAGA Chipset.
-
Atheist wrote:
AOS is so streamlined, that even games that need 1 GHz P4s may actually be able to run on NatAmi60s!
Even though AOS doesn't impose much overhead compared to Windows, there's a physical limit to everything. You won't get P4 performance from a 060.
When porting stuff to another 680x0-based platform, I've concluded that stuff intended for ~300Mhz Pentium machines often runs well on a 100Mhz 060. This comparison assumes low OS overhead (well, virtually none in fact) and slow chipram for graphics, which means it's most problably applicable on the Amiga as well.
Atheist wrote:
Look at, just how big is DirectX?!? Can't tell me that doesn't use tons of Hz.
On the other hand, DirectX provides tons of accelleration features. I think size is a bad comparison here.
-
yet again i stumble upon a thread where uncorrect statemnents by supporters of the natami project are made. gunnar v.b. has never stated that the 16mb chip ram is going to be included into the fpga. i dont know if this project is going to work out but it is unfair to criticize something or someone on account of hearsay.
also the dev team has never stated that the natami's computing speed is going to be comparable to p4 clocked @ some ghz.
-
I posted that quote from the Natami website as a correction for my previous bad information.
What they said on the Natami website about the speed of it is that it should be comparable to the Wii or the Playstation 2.
-
@SamuraiCrow:
apologies, sir. once more ive been too careless reading.