NetInfo, but doesn't actually mention how to map hosts to IP addresses! I'm really tired of typing in IP addresses that start with 192.168.0!
I'll take this one;)
Now, warning, this works in 10.0 and 10.1, and I haven't yet verified it works in 10.2:)
And I didn't read this anywhere, or anything, it was one of those experiments which worked back when 10.0 came out;)
Gah, 10.2 has eaten my netinfo db:(
I'll have to restore or something:-\
Anywho, in/machines (in netinfo space) you'll find entries for localhost and broadcast host, copy localhost, change it to "blahblah" and set its IP up, that should give you a local domain name blahblah
You will probably need to restart the netinfo service
The projector in the cinema flashes every frame twice, for an illusion of 48fps
Some newer projects flash 3 times for 72 frames per second.
When film content is digitized and transferred to DVD it is typically slowed to 23.976 fps which can be trivial frame doubled up to 30/1.001 fps (which is the true NTSC rate). For PAL they just speed it up a few percent to 25% in most cases.
Anywho, assuming the hardware is capable of it, then the ability has just been disabled.
I can think of 3 areas where it could be disabled
1) the openfirmware could disable it in the chip... somehow 2) the driver could disable it, or just not advertise the ability 3) the config software could pretend it doesn't exist, and perhaps actively set it to mirroring
if its 2 or 3, then most likely, there will be a gestalt check (gestalt will tell the software which model/series the machine is etc), and after the check the software will make the necessary adjustments.
If that is the case, then all you need to do is 'krack' the driver/config software. Simply set the jump so that the driver does not recognise teh ibook, or recognises it as a powerbook, or recognises it and DOESN'T disable spanning.
Or whatever.
Your first step should be to prove that the hardware is capable of spanning, and if this works in OS9, then go and install OS9 right now;)
Just because you don't want to use OS9 is no reason not to use it to prove that it works... if you are serious about tackling this issue;)
Anywho, once you've proved it works... then you have to work out when/where it gets disabled...
Bit tricky... I don't even know how OSX software detects models (ie gestalt).
There should be no reason to right your own drivers, just hacking the drivers to *not* screw up the spanning should be enough.
With luck, it'd just be 1 byte.
You'll be wanting to find a good disassembler, and learn PPC asm;)
Running fully optimized AltiVec code all G4s are currently memory bound for most operations
It is really really hard to keep a dual 1Ghz machine fed when a single instruction (taking a single cycle) can process 16bytes of information.
If you had a simple filter for example, a blur.. that could be executed in perhaps 10 cycles...
which would require 3.2GB/s of bandwidth to run at full speed (1.6GB in, 1.6GB out), and on a dual... 6.4GB/s (which happens to be the bandwidth on that new IBM PowerPC;))
The current bus can only provide 1.3GB/s
Which means this filter would run at 40% of the full speed...
If its running on two cpus, then its going to run at 20% of full speed.
This means DDRing the bus would double the performance... but you'd still only be running at 40% of full speed.
AltiVec generally converts almost any relatively complex operation into a memory benchmark.
Since altivec is used for the most time critical parts of a program, faster memory would allow these time critical parts to run x times faster... Anywho, when it takes only two cycles to multiply 16 values by another 16 values, then add another 16 values, and saturate the result (something which would maybe take 80 cycles without altivec, memory bandwidth becomes the limiting factor. (for those counting that's a 40x improvement, the equivalent of a 40GHz chip if it was running scalar code)
Its even worse on 7450s because the AV unit can execute multiple instructions concurrently.
G4s *ARE* memory constrained, I'd say even seriously.
Small benchmarks will not expose this as they'll almost always run out of L3, or even L2 (L1!) cache.
BUT real world operations normally work on massive data sets...
(be it video, audio, 2D, 3D, genetic sequences, or just your window being composited with a menu)
Incidentally, the speed improvements from altivec can generally be worked out as 4x, 8x, or 16x for most uses depending if you can use 8, 16 or 32bit math. Some operations can make use of tricks altivec can do and scalar can't. which allows speeds of 32x (or even more)
Running a highly optimized calculation which is NOT memory bound we've managed to come up with some interesting numbers;)
The algorithm was highly optimized for MMX and AltiVec,
running on a single G4/500, with many other applications running etc, the calculation was over twice as fast, as the same calculation on an athlon 1.3Ghz. The G4 has a 100Mhz bus, the athlon has DDR266, but it doesn't matter because the process is not memory bound.
this means it took 15 mins on the G4/500 and 30mins on the athlon/1300.
This means the memory subsystem can keep BOTH processors completely saturated. (the processor core could use more data... but there is NO way to get more data into the processor faster than SDR (except for L3 cache)
So essentially this is a HUGE improvement for heavy tasks which get a big improvement from bus speeds and processor count...
This is a very good thing. It'd be better to have the processors on a DDR bus... but and extra 33Mhz is definately welcome.
AltiVec is soooo powerful that an altivec algorithm generally runs at the same speed as your memory subsystem... the cpu is actually idling waiting for memory.
Increase the memory speed and you release the latent potential of the altivec unit..
In many ways its more important these days than processor speedbumps.
I didn't say the load/store instructions took that form. The data processing instructions take that form.
BTW, almost all the altivec data processing instructions DO take that form. An interesting example of an instruction in non-normal form is the permute instruction which is:
d = vec_perm(a,b,c); where a,b are source registers, c is the permute register and d is the destination. Very powerful instruction
The difference is that each of the 142 instructions had multiple modes, multiple formats, multiple argument lists and where compeltely different from each other
RISC means reduced complexity, not reduced instructions, all the instructions can roughly be divided into
load/store processing branching
that's more or less it, and they're all the same in each category, they just do different things
so you have loads, they all load from memory to a specified register, there are different instructions for loading a 8 bits, 16bits, 32 bits etc, and some different ones to handle signextension etc.
meanwhile the processing instructions are basically all of the form
C = A + B
where A, B and C are any registers, B could be a number instead of a register. The + of course can be one of many operations, and thats the difference between teh instruction
All the instructions might update the condition registers, or might be word, byte, or halfword variants... but there aren't very many base instructions but, if you combine the base instructions with the 5 combinations of instruction for every instruction, then you get a fairly large number.
But because the ISA is so elegant its very easy to learn. And its very easy for the CPU to process it.
In relation, to a CISC architecture (which is a retroactive name), any RISC design is a model of simplicity.
Slashdot Mirror
They're also around in Europe...
The one I remember was at Losanne (sp?) train station in Switzerland...
Massive, in fact, larger than the one in this article.
They're also fairly common in belgium.
Overall, nothing special...
And in other news, HP holds a monopoly on Hewlett-Packard hardware...
whoop-di-doo, its not a monopoly by the legal definition
NetInfo, but doesn't actually mention how to map hosts to IP addresses! I'm really tired of typing in IP addresses that start with 192.168.0!
;)
:)
;)
:(
:-\
/machines (in netinfo space) you'll find entries for localhost and broadcast host, copy localhost, change it to "blahblah" and set its IP up, that should give you a local domain name blahblah
I'll take this one
Now, warning, this works in 10.0 and 10.1, and I haven't yet verified it works in 10.2
And I didn't read this anywhere, or anything, it was one of those experiments which worked back when 10.0 came out
Gah, 10.2 has eaten my netinfo db
I'll have to restore or something
Anywho, in
You will probably need to restart the netinfo service
I'm not telling ;)
Most motion pictures are filmed at 24 fps
The projector in the cinema flashes every frame twice, for an illusion of 48fps
Some newer projects flash 3 times for 72 frames per second.
When film content is digitized and transferred to DVD it is typically slowed to 23.976 fps which can be trivial frame doubled up to 30/1.001 fps (which is the true NTSC rate). For PAL they just speed it up a few percent to 25% in most cases.
You know, I happen to agree with about 50% of your assertions...
Mmmmm
;)
camembert, cranberry and chicken is great too
You should try OSX 10.2 on it ;)
:)
Perhaps you'd use it more then
The problem is iThings don't have multi-monitor support, they just have display mirroring...
yes, multi-monitor support is even better than the normal spanning, but in the context of this discussion, they are the same thing.
I believe you'll find the chip does support spanning, but the ability has been disabled so that Apple can clearly delineate the iBook/PowerBook lines
;)
;)
;)
spanning = G4
G4 = G4
Bigger screen = G4
Slot Load Driver = G4
DVI = G4
etc...
Anywho, assuming the hardware is capable of it, then the ability has just been disabled.
I can think of 3 areas where it could be disabled
1) the openfirmware could disable it in the chip... somehow
2) the driver could disable it, or just not advertise the ability
3) the config software could pretend it doesn't exist, and perhaps actively set it to mirroring
if its 2 or 3, then most likely, there will be a gestalt check (gestalt will tell the software which model/series the machine is etc), and after the check the software will make the necessary adjustments.
If that is the case, then all you need to do is 'krack' the driver/config software. Simply set the jump so that the driver does not recognise teh ibook, or recognises it as a powerbook, or recognises it and DOESN'T disable spanning.
Or whatever.
Your first step should be to prove that the hardware is capable of spanning, and if this works in OS9, then go and install OS9 right now
Just because you don't want to use OS9 is no reason not to use it to prove that it works... if you are serious about tackling this issue
Anywho, once you've proved it works... then you have to work out when/where it gets disabled...
Bit tricky... I don't even know how OSX software detects models (ie gestalt).
There should be no reason to right your own drivers, just hacking the drivers to *not* screw up the spanning should be enough.
With luck, it'd just be 1 byte.
You'll be wanting to find a good disassembler, and learn PPC asm
Another nifty thing about the family 5 pack, is they'll be able to count each 5 pack as 5 separate OSX installations...
;)
;)
Even if someone just buys it for 2 computers (it is cheaper than 2 separate 10.2s)
Lets see on average 50% of the licenses won't be used
That's some nice user base inflation
Nope, that URL doesn't work....
possibly, just maybe... its because...
"(the Apple Store doesn't like deep linking)"
Yes, it probably does :)
;)
Unless the high-quality acquisition cards you are talking about are for 10 bit uncompressed video
As far as I remember HyperStudio is nothing to do with hypercard and superficially looks a lot like hypercard.
But deep down, it doesn't have the flexibility. but it does have lots of candy coating.
SuperCard is a much better heir to hypercard's throne
Its actually a lot more powerful than that.
;)
I wrote an email system and a LOGO emulator (remember turtle graphics?) in hypercard, back before the internet was called the web
Heh, had to learn trig to do that
I did find something interesting today... Apparently the new controller allows the G4s to support "intervention" in their L3 caches...
basically, they only need to synchronise data if in fact that data is required by the other CPU.
That could provide a large benefit in a dual config.
Also I think the docs said that it didn't use the system bus, not sure though.
Anyway, it was the Technology Overview PDF for the new PowerMacs
Unfortunately, bomniweb has gone and lost the URL
Running fully optimized AltiVec code all G4s are currently memory bound for most operations
;))
;)
It is really really hard to keep a dual 1Ghz machine fed when a single instruction (taking a single cycle) can process 16bytes of information.
If you had a simple filter for example, a blur.. that could be executed in perhaps 10 cycles...
which would require 3.2GB/s of bandwidth to run at full speed (1.6GB in, 1.6GB out), and on a dual... 6.4GB/s (which happens to be the bandwidth on that new IBM PowerPC
The current bus can only provide 1.3GB/s
Which means this filter would run at 40% of the full speed...
If its running on two cpus, then its going to run at 20% of full speed.
This means DDRing the bus would double the performance... but you'd still only be running at 40% of full speed.
AltiVec generally converts almost any relatively complex operation into a memory benchmark.
Since altivec is used for the most time critical parts of a program, faster memory would allow these time critical parts to run x times faster...
Anywho, when it takes only two cycles to multiply 16 values by another 16 values, then add another 16 values, and saturate the result (something which would maybe take 80 cycles without altivec, memory bandwidth becomes the limiting factor. (for those counting that's a 40x improvement, the equivalent of a 40GHz chip if it was running scalar code)
Its even worse on 7450s because the AV unit can execute multiple instructions concurrently.
G4s *ARE* memory constrained, I'd say even seriously.
Small benchmarks will not expose this as they'll almost always run out of L3, or even L2 (L1!) cache.
BUT real world operations normally work on massive data sets...
(be it video, audio, 2D, 3D, genetic sequences, or just your window being composited with a menu)
Incidentally, the speed improvements from altivec can generally be worked out as 4x, 8x, or 16x for most uses depending if you can use 8, 16 or 32bit math. Some operations can make use of tricks altivec can do and scalar can't. which allows speeds of 32x (or even more)
Running a highly optimized calculation which is NOT memory bound we've managed to come up with some interesting numbers
The algorithm was highly optimized for MMX and AltiVec,
running on a single G4/500, with many other applications running etc, the calculation was over twice as fast, as the same calculation on an athlon 1.3Ghz. The G4 has a 100Mhz bus, the athlon has DDR266, but it doesn't matter because the process is not memory bound.
this means it took 15 mins on the G4/500 and 30mins on the athlon/1300.
(the athlon was running NOTHING else)
The G4 bus (to the best of my knowledge--please provide link proving me wrong) isn't point to poit,
:(
That means all the processors share the SAME 133MHz bus. So, no, two G4 processors can't each use 133MHz of bandwidth to the memory at the same time.
Thanks, I checked up, I think you're right
Which just goes to hammer home how bad the memory speed situation is for a G4
They're not though, you see :)
De Beers just wants your to believe that
The memory bus is DDR, the processor bus is SDR.
There are two processors.
This means the memory subsystem can keep BOTH processors completely saturated. (the processor core could use more data... but there is NO way to get more data into the processor faster than SDR (except for L3 cache)
So essentially this is a HUGE improvement for heavy tasks which get a big improvement from bus speeds and processor count...
This is a very good thing. It'd be better to have the processors on a DDR bus... but and extra 33Mhz is definately welcome.
AltiVec is soooo powerful that an altivec algorithm generally runs at the same speed as your memory subsystem... the cpu is actually idling waiting for memory.
Increase the memory speed and you release the latent potential of the altivec unit..
In many ways its more important these days than processor speedbumps.
I have benchmarked it.
The ARM DSP extensions aren't very applicable to video. For audio they are pretty nifty though.
I didn't say the load/store instructions took that form. The data processing instructions take that form.
:
BTW, almost all the altivec data processing instructions DO take that form. An interesting example of an instruction in non-normal form is the permute instruction which is
d = vec_perm(a,b,c); where a,b are source registers, c is the permute register and d is the destination. Very powerful instruction
WTH are you talking about?
Apple uses 64bit FPU operations on the 64bit FPU...
BUT the altivec unit is only capable of 32bit FP operation (of course it does 4 of them at a time)
Ahem...
;)
:)
The big ones (IBM's) use PowerPC chips...
They just call them POWER3 and POWER4
IBM doesn't make big ones which don't use PowerPC's as far as I know.... all the ones which use Intel's chips aren't.... big
The difference is that each of the 142 instructions had multiple modes, multiple formats, multiple argument lists and where compeltely different from each other
RISC means reduced complexity, not reduced instructions, all the instructions can roughly be divided into
load/store
processing
branching
that's more or less it, and they're all the same in each category, they just do different things
so you have loads, they all load from memory to a specified register, there are different instructions for loading a 8 bits, 16bits, 32 bits etc, and some different ones to handle signextension etc.
meanwhile the processing instructions are basically all of the form
C = A + B
where A, B and C are any registers, B could be a number instead of a register. The + of course can be one of many operations, and thats the difference between teh instruction
All the instructions might update the condition registers, or might be word, byte, or halfword variants... but there aren't very many base instructions but, if you combine the base instructions with the 5 combinations of instruction for every instruction, then you get a fairly large number.
But because the ISA is so elegant its very easy to learn. And its very easy for the CPU to process it.
In relation, to a CISC architecture (which is a retroactive name), any RISC design is a model of simplicity.