PC still playing Amiga catchup

[koaftder]

With caching and misalignment causing delays, you can have some larger piece of code execute faster than a smaller piece of code.  Also depends on what the instructions are.  One IN on PC is much slower than 100 MOVs if processor is like 1Ghz.

Don't forget Max Headroom was done on Amiga. If you can remember that.
:laughing:
Does being first count for anything nowadays?

It's a little known fact, but the stuttering was an unintended feature. The Amiga crashed so much they had to hire an assistant to "poll" the reset switch 5 times a second to keep it going. It wasn't a big deal because the Amiga booted so fast and besides, people liked the effect.

[amigaksi]

Well, Paula didn't change much.

It would be a joke to compared CBM's OCS/ECS/AGA's evolution rate to NVIDIA's NV20/NV30/G70/G80/G200/G300(soon).
...

Paula didn't change much is not the point.  The other custom chips that did do enhancement are also backward compatible with OCS.  Evolution rate should not impede people for making them backward compatible on hardware level.  The point is that the methodology of going about it is inferior-- they are already targeting only API level compatibility.

[amigaksi]

USB multifunction modules that provides 1 MHz sampling speed .
http://www.iotech.com/products/pdaq3s.htm

USB modules that provides 2 MHz sampling speed.
http://www.accessmylibrary.com/coms2/summary_0286-15005752_ITM

I know anyone can build hardware for any computer to do anything computer is able to do.  But we are looking at standards.  If all I did was talk about Video Toaster features on Amiga 4000, it wouldn't be talking about the general Amiga audience.

>There's Catweasel IV. It's too bad it's not in ExpressCard format.

Yeah, some Atari people also built joystick interface using parallel port but PC games out there aren't using it nor does having many different non-standard joystick interfaces give you ability to do low-level programming.

>I don’t know why you are addicted to this joystick thing?

It was one of the things mentioned that is superior on Amiga, but some people can't understand that so the argument keeps going on and on.

>What market are you targeting?

Most of the audience.  In amigas case, if you use the joystick interface $DFF00A, it works on all Amigas.

[amigaksi]

Correct, and that is all to the good.

...

That's bad that modern PCs aren't hardware compatible with each other.  

>No, what it would usher in would be a whole new round of I/O, IRQ and DMA conflicts as different programs fought for control of hardware, oblivious to one another. As well as very painfully kludged hardware.

No, if hardware was compatible like earlier VGA cards, they would use SAME I/O ports, same IRQs, same MEMORY MAP areas, etc.  And even if you had multiple boards in the same system (in rare cases), there's the plug-n-play hardware that allows you to remap the I/O ports.  Take another good example-- parallel ports are always mapped to 378h, 278h, 3BCh and using plug-n-play you can have 3 parallel ports and each one can be mapped to any of the standard I/O port locations.

[amigaksi]

I'm fairly certain that was more or less along the lines of what Karlos suggested... How many pages ago?

...

That test is not needed if you understand the logic.  I'll do it when I feel like it and have time.

>That is not a sentence.

>You cannot use the word ignorance as you did. It is gramatically incorrect and as such is invalid. It is not a sentence.

"You're in ignorance" is perfectly valid sentence and also reflects reality.

[the_leander]

That's bad that modern PCs aren't hardware compatible with each other.  

Again, I have to disagree with you. More on this in a sec.

>No, what it would usher in would be a whole new round of I/O, IRQ and DMA conflicts as different programs fought for control of hardware, oblivious to one another. As well as very painfully kludged hardware.

No, if hardware was compatible like earlier VGA cards, they would use SAME I/O ports, same IRQs, same MEMORY MAP areas, etc.  And even if you had multiple boards in the same system (in rare cases), there's the plug-n-play hardware that allows you to remap the I/O ports.  Take another good example-- parallel ports are always mapped to 378h, 278h, 3BCh and using plug-n-play you can have 3 parallel ports and each one can be mapped to any of the standard I/O port locations.

As I said in a previous post, that's all great for the very basics, but once you get into multiple layers of this and things become more complex, the hassle of maintaining this hardware compatability becomes emense, not to mention pointless - no desktop built in the last few years has a serial or parallel port, ISA hasn't been seen for over a decade and PCI has (largely) been discontinued, this is true especially of fast evolving things like graphics.

The modern x86_64 is perhaps one of the most kludgey processors ever created, it is essentially a highly advanced risc core that has to have a pile of extra logic to convert between what we know as x86 and what it uses internally. I read somewhere (ok, I could be wrong and I would appreciate being corrected on this) that nearly a third of all the logic built into an x86 core is there purely to translate between x86 and the risc part. A third!

x86 is considered by most to be a massive and hugely inefficient hack. It should have died with the P4 and moved over to the Itainium tbh, but no, AMD bolted on another hack and here we are, nearly a decade later with it limping on still.

Now consider how much extra logic would have to be built into a modern gpu so as to include hardware compatability with just the major jumps in gpu design over the years...

Can you even begin to imagine the horror such a chip would be? I don't even want to think about the thermal and power implications.

[Hammer]

Paula didn't change much is not the point.  The other custom chips that did do enhancement are also backward compatible with OCS.

The changes is comparatively minor. We are talking about following the latest micro-architecture paradigm and implementing them. From Nov 2006 to Q1 2010, you have G200 (SIMT) and G300 (MIMT*) designs being released.
 
In the GPU market, maximum math unit count at a given transistor budget is paramount. Adding legacy compatibility reduces the available transistors for math units.
Haven’t you noticed that ATI and NVIDIA are in GFLOPS and TFLOPS race?

Evolution rate should not impede people for making them backward compatible on hardware level.

It's a matter of priorities. The market with get a GPU with legacy ISA support i.e. Intel Larrabee.

The point is that the methodology of going about it is inferior-- they are already targeting only API level compatibility.

It's actually superior when factoring the maximising math unit count.

[the_leander]

I know anyone can build hardware for any computer to do anything computer is able to do.  But we are looking at standards.  If all I did was talk about Video Toaster features on Amiga 4000, it wouldn't be talking about the general Amiga audience.

So you want it to be mainstream eh? I can do that...

USB2 Soundblaster Audigy2.

Ok perhaps that one too is a little OTT, but there are a great many other USB cards at much lower prices, and I'd bet good money that they too can sample at far, far higher rates then 1khz. I pointed to this one simply because it was the first one I found that had the sampling rate capabilities printed out up front. The other cards I looked at briefly are available to view here. Note that as laptops are becoming more and more popular, these sorts of external usb based expansions are becoming ever more mainstream.

In a way the above box is almost as though the hardware has gone full circle - many old soundcards included a gameport, now they're including usb ports...

[Hammer]

Again, I have to disagree with you. More on this in a sec.

>No, what it would usher in would be a whole new round of I/O, IRQ and DMA conflicts as different programs fought for control of hardware, oblivious to one another. As well as very painfully kludged hardware.



As I said in a previous post, that's all great for the very basics, but once you get into multiple layers of this and things become more complex, the hassle of maintaining this hardware compatability becomes emense, not to mention pointless - no desktop built in the last few years has a serial or parallel port, ISA hasn't been seen for over a decade and PCI has (largely) been discontinued, this is true especially of fast evolving things like graphics.

The modern x86_64 is perhaps one of the most kludgey processors ever created, it is essentially a highly advanced risc core that has to have a pile of extra logic to convert between what we know as x86 and what it uses internally. I read somewhere (ok, I could be wrong and I would appreciate being corrected on this) that nearly a third of all the logic built into an x86 core is there purely to translate between x86 and the risc part. A third!

Refer to http://www.chip-architect.com/news/2003_09_21_Detailed_Architecture_of_AMDs_64bit_Core.html

It's about 10 percent for K8 Sledgehammer. The legacy tax is more apparent when you implement this as a GPU i.e. maximising math unit counts.

Unlike CPU vs CPU battles, the argument for clean designs is actually strong for the GPU market.

[the_leander]

"You're in ignorance" is a perfectly valid sentence

fix'd.

and also reflects reality.

Pithy. Amusing given that you're the one whose backside has been handed back to them on a plate on pretty much every single point you've made thus far too.

[the_leander]

Refer to http://www.chip-architect.com/news/2003_09_21_Detailed_Architecture_of_AMDs_64bit_Core.html

It's about 10 percent for K8 Sledgehammer. The legacy tax is more apparent when you implement this as a GPU i.e. maximising math unit counts.

Ahh, cheers for that! I am curious though how it compares to other processors in the x86 family now though.

But again, thanks for pointing me to that.

[Hammer]

I know anyone can build hardware for any computer to do anything computer is able to do.  But we are looking at standards.  If all I did was talk about Video Toaster features on Amiga 4000, it wouldn't be talking about the general Amiga audience.

>There's Catweasel IV. It's too bad it's not in ExpressCard format.

Yeah, some Atari people also built joystick interface using parallel port but PC games out there aren't using it nor does having many different non-standard joystick interfaces give you ability to do low-level programming.

>I don’t know why you are addicted to this joystick thing?

It was one of the things mentioned that is superior on Amiga, but some people can't understand that so the argument keeps going on and on.

>What market are you targeting?

Most of the audience.  In amigas case, if you use the joystick interface $DFF00A, it works on all Amigas.

What about A1 and SAM?

[the_leander]

Not to mention the Peg. Wasn't there some talk also of OS4 being able to run on a MacMini as well?

[koaftder]

Not to mention the Peg. Wasn't there some talk also of OS4 being able to run on a MacMini as well?

found this poking around.

Amiga OS 4.0 Install CD for Mac Mini G4 (Moana Loader)
------------------------------------------------------

This CD will allow you to boot the Amiga OS 4.0 kernel and run the Amiga OS 4.0 installer.  I've yet to try installing this on my hard drive.

The knows issues with the Moana loader are:

 * Displays message that USB stack has not been loaded (USB keyboards and mice work)
 * Doesn't detect the Mac Mini built-in Ethernet
 * Doesn't detect the Mac Mini AirPort Extreme card
 * Doesn't detect the Mac Mini Bluetooth device
 * Probably a lot more I've not come across yet!

Testing has been performed with a Mac Mini G4 with the following specs:

Model Name: Mac mini
Model Identifier: PowerMac10,2
Processor Name: PowerPC G4 (1.2)
Processor Speed: 1.5 GHz
Number Of CPUs: 1
L2 Cache (per CPU): 512 KB
Memory: 1 GB
Bus Speed: 167 MHz
Boot ROM Version: 4.9.4f0

This CD may/may not work on other Mac Mini G4 models.


Instructions for booting:
-------------------------

 1) Boot into Open Firmware (Hold down "Option" "Command" "o" "f" when powering on)
 2) First time users will only need to enter the following command once:
    setenv boota-device cd:
 3) Begin loading the OS 4.0 kernel/kickstart by typing in the following command:
    boot cd:slb_v2
 4) Select option "1. Amiga OS 4.x/MM_Full_silent_USB"
 5) Press "Enter" at the "Installed mem: 1024 mega bega" prompt
 6) Press "Enter" at the "About to build thecopy of the OF tree; Code start at 0x01800000; press any key" prompt
 7) Press "Enter" at the "All init done; about to kill OF and start ExecSG; press any key" prompt

At this point, the screen should turn black and after a few seconds, the CD drive will spin up.

Eventually you'll see an AmigaDOS window displaying the message "USB stack not loaded".  Oddly enough, USB keyboards and mice seem to work.

 7) You'll be greeted with a "Welcome to the Amiga OS 4.0 Install CD" window, click on "Proceed"
  On the next window, select your language, country and time zone and click "Use"
 9) A window will pop up and will ask how the system time should be updated.  Click on "System"
10) A window will pop up with the message "Your system time has been updated".  Click on "OK"
11) Shortly after, a window will appear to advise you that you must select a keyboard.  Click "OK"
12) Select your keyboard and click "Use"

If the start up appears to stall between steps 10 and 11, press "Ctrl C" and you should see a "WAIT: ***Break" message appear.  The installer will now continue.

Good luck!

[Karlos]

All I am stating regarding hardware standards is that they base it on I/O ports and memory maps like VGA/EGA/CGA was rather than API calls.  That way, you don't have to rely on any drivers and API calls although those can also be present in a system.

>From the above statement, clearly not. I could program a "pallete change" for my GPU that simultaneously sets every colour register in parallel in a couple of shader clock cycles.

Now you call an API to do that which works on majority of PCs and see how well it performs as compared to Amiga swapping two palette registers or to a standard VGA swapping color registers.  You can't just target your machine since we are talking about making it work in general; that's why I am talking hardware compatibility to begin with.

1) Not just my machine, any CUDA 1.0+ capable machine. That's every G80 upwards. There are more of those installed in machines today than there are amigas. Hence my code will run on more machines than yours.

2) It won't run on the rest. Well, there's a pity. Perhaps this is why API calls exist in the first place, eh?

>However, palette changes are a thing of the past for modern hardware. I haven't used a indexed colour mode for more than a few hours (usually when retgrogaming) in almost 10 years, even on the Amiga.

That's subjective.

No it isn't its FACT. The only time I have used indexed colour modes are on a physical AGA machine when playing old games. The rest of the time I run  32-bit truecolour displays, or at worst, high colour 16-bit ones.

But regardless, I was giving example where I/O accesses are better than API calls and Amiga I/O accesses aren't that slow.

Compared to speed of modern graphics memory it is ACHINGLY SLOW. Why don't you time how many palette registers you can update in 1 second? Doing it from either the copper or the CPU, you'll hit the limit of the bus speed. However you decide to divide the workload between the copper and CPU, you are going to be restricted by the write bandwidth, which is at best 7-8MB/s for AGA class hardware and even less for OCS/ECS.

That particular limitation is mitigated in current hardware, where memory bandwidth is in the GiB/s range. So, in the time it takes you to set just one palette register with an IO instruction, a modern G200 class GPU could have done all of them dozens of times over, that's even before you parallelise the code.

Assuming you want to set 256 32-bit registers, you can do so by moving a vector of 4 32-bit integers to the target location. CUDA executes parallel threads in "warps" of 32 threads. In the absence of any conditional branching, every thread in a warp runs the same instruction concurrently as it's neigbours.

So, you'd need a GPU kernel that you invoke as a pair of concurrent warps (giving 64 threads in total), where each thread sets a block of 4 registers using a vector of 4 ints, ensuring coalesced memory access.


64 threads each setting 4 registers in parallel, each thread running in parallel. On my GPU, which will happily run 24576 parallel threads at any one instant, that's only 64/24576 = 0.26% utilisation.

In theory, that's pretty damn fast, especially at 1.3GHz (shader clock of said PU)

In practise, it would take much longer to set up than it does to execute. That dominates the timing, so much so that I'd almost guarantee that a basic API call on the CPU that just does 256 successive 32-bit writes to the same address space would be faster in "real" time and would work on any graphics card.

So, for all I can actually set the registers faster by "hitting the metal", the end result is less portable and most likely slower than using the API since the job at hand is so easy to do anyway that it ceases to benefit from HW acceleration.

[bloodline]

Ahh, cheers for that! I am curious though how it compares to other processors in the x86 family now though.

But again, thanks for pointing me to that.

While some members of the x86 family (I note the 286 and 386) were horrific fankenPuters... The x86_64 is actually pretty hot, AMD pretty much cleaned out all the old cruft and once the CPU is in "long mode", I can't think of a better* general purpose CPU right now



*it's pretty cheap too, always a bonus