There's one caveat, though. Onboard video can reduce the system memory bandwidth available for the CPU. 1280x1024 with 32-bit color takes over 300MB/s, just by displaying the image. 640x480 with 16 colors is your friend (9MB/s).
This is very likely to change relatively soon. Keep in mind many next generation consoles are multicore, like X-Box 2 with three cores. Game programmers are always eager to exploit any parallelism in the systems. Think consoles with their numerous co-processors, Amiga's blitter, Quake 1 which calculated floating point divide concurrently with other texture mapping code, or any current PC-system where graphics is processed on specialized GPUs. No, I'd say game developers will be one of the first ones to fully exploit dual processing capabilities. There are many highly "parallizable" tasks, like AI & pathfinding, physics, music & sfx playback, scripting, terrain generation, shadow hull calculations, CPU vertex skinning and hundreds of other small things games need to execute constantly.
I'm sure it not only makes gameplay smoother, but also increases the maximum FPS in CPU-bound situations in many future games released in 2006 and beyond.
400MHz SA (StrongArm)? Never heard of such a thing, but I assume it's an X-Scale (PCA-25x or PCA-26x) instead. 400MHz X-Scale is equivalent to magnitude of 20Mhz Pentium in floating point math, maybe 150-200Mhz Pentium in integer math. Afterall, Celeron has a huge cache compared to these (yeah, even the old joke-Celeron with a tiny cache has maybe 2-4 times more cache than this thing!)
In reality the simputer is equivelant to about 50-100Mhz Pentium, all things considered.
Good post. Makes me wish I had still some mod points left. The table hell should finally go, it's preventing mobile use of internet becoming widespread. You really DO hate when someone wants to make 800 px wide table fixed page when your web browser has 160-240 pixels horizontally... happy horizontal scrolling (unusable).
Re:Not a brick, suprisingly...
on
YOPY Arrives
·
· Score: 1
It doesn't matter PPC 2003 doesn't use the instruction set - it's not like the extra instructions could benefit the OS anyways. And I say this as a Pocket PC developer. It's really all about bus bus bus bus and bus. 100MHz at 16 bits per cycle (or every second cycle?) doesn't cut it! Memory fill speed is ~85MB/s on iPaq 3870 SA-1110 @ 206MHz and 80MB/s on iPaq 3970 X-Scale @ 400MHz.
When I tried to switch on fastpath on my T-DSL, they told me they don't know what fastpath means. I tried many reps. How to get them to actually do it?
No, the context switch wasn't 35ns. The system didn't even use that fast RAM. 35ns sounds more like the fastest pixel clock timing, the time it takes to display a single pixel. Pushing all the registers on the stack and switching the running task takes at least tens of microseconds on Amiga.
The screen switching magic was implemented using copper *1 lists - at some scanline copper would change the address from where the display hardware fetches the screen data. That's why screen switches were instantaneous - they only involve modifying the copper list. All the screens were drawn in the graphics memory (CHIP RAM) all the time anyways.
*1 Copper, a display coprocessor that can change values in the display hardware, color palette, playfields, horizontal pitch (modulo), scroll registers, sprites, graphics mode, etc. You could even flip the screen vertically just by making a copper list that does it (or having a negative pitch/modulo...) It basically has 3 different instructions - wait, move and skip and also a special code for terminating the list.
Well, use GSM compression @ 16kbps. 14MB will give you then almost 120 minutes. The microphone can't be much better anyways, you're not really even losing quality. It also said it has SecureDigital reader... The biggest SD-cards are now 512MB, they're going to have even 4GB cards later on.
Diablo 2 is mostly big because of the cutscenes and very stupidly compressed graphics. You can make graphics intensive games even in 8MB, check just about any older console that still used cartidges (or a bit older arcade machines). Or games like original Tomb Raider (8-9MB).
Well, the instruction timings oughta be the same for 16-bit and 32-bit instructions, which wasn't the case with 68000 (except, of course for multiplication, division and other instructions which actually have more work to do). But, then, 68000 only had 16-bit multiplication and division anyways... (32-bit/16-bit and 16bit*16bit). Even that should say something.
As a long time Amiga user (1989-1994), I can assure you Amiga *doesn't* have wavetable synthesis. Wavetable doesn't mean anything like "a whole bunch of samples", but it is a *synthesis* method. Just like FM-synthesis, waveguide, etc.
An Amiga could merely play 4 sound samples simultaneously. Two channels were assigned to left channel and two to right channel. Each channel also supported 6-bit volume (64 levels).
What, 68000 a 32-bit CPU? Since when? A 68000 can address 24-bit address space and it has 16-bit data bus. Sure, internally it is a 32-bit CPU, but using 32-bit ops took longer than their 16-bit counterparts! Smells badly as if the ALU was just a 16-bit one... (don't know this for certain).
I think Bluetooth would be easy to use for this purpose.
First you'd form a piconet. If any of the systems is physically connected to (internet | base station | something else), relay there, else form/connect next device on a (same | different) piconet (the next device might have different piconets available). When the working relay is found, send back a message, targetting the original device. Relay it randomly and add a node to the route table the message contains. The original sender can deduce a short path (it's not necessarily the shortest!) just by looking at the message that arrives first/has the shortest route.
At this point, it should be possible to send small text messages with some efficiency.
It's also possible for other devices that happen to recieve a route recovery message to use the some of the readymade routes (so that everyone doesn't need to do this slow procedure).
The total amount of transferrable payload *per device* should probably be limited to something like 2kB, if this is to be used as an emergency network, to insure everyone can transmit their messages.
Any ideas/corrections from those "in the know", especially bluetooth people here?
Disclaimer: I'm not a bluetooth specialist... In fact I don't know much at all about it!:)
Long distance phone calls cheap in USA? Not counting dialpad and other internet phones, I think 5 cents/minute for an interstate call isn't cheap at all. For example calling to USA from Germany (using ordinary phone line) costs only about *3* cents per minute. That's what I call cheap.
On the other hand, local calls are dirt cheap in USA.
And by the way, I think one of the biggest reasons for slow adoption of cellphones in USA is the policy of cellphone user having to pay for the calls he receives! That's not the case in Europe - in Europe the caller always pays (except when you have redirects and such).
I believe the social factor is fairly important in adoption rates. Examples...
Finland: In the countries like Finland the cellphone is almost fundamental for any kind of social life. Most things are arranged with SMS messages (kind of instant messaging system for GSM cellphones). That's why you almost *must* have a cellphone there! In fact, on average, almost 300 messages were sent per cell phone per year in Finland!
Japan: In Japan the teenagers want probably 3G also for social reasons. It's important when you arrange a party over there to be able to send pictures of the ppl who are going to attend the party, so that the other ones know if there's anyone interesting looking etc. So you need a small camera in your cellphone and a color display. This has been possible for years using the i-mode phones. I can imagine they start to use video clips in the near future for that purpose, as well.
Sorry for any grammar / spelling mistakes here, I'm far from native speaker...:)
7 am? I guess it really depends where you are. A significant portion of slashdot's readers are in other timezones as well (and for example, in europe it's afternoon now).
I don't personally analyze viruses, but the analyses I've seen indicate that Nimda is actually quite sophisticated in design. It's not like Melissa or other scripting viruses. In fact, it's not implemented in script but as a binary. It's definitely not made in any kind of virus creation toolkit. The person who did it is not only a good programmer, but also has very good knowledge about the Windows internals.
Consider, for example, on how many different versions of Windows it runs on. In this kind of application that's not an easy feat. Or that it has a novel, yet simple method for 'infecting' the executable files. It puts the original executable in it's resources, and when ran, writes the original exe to the disk and *then* runs it. It's important, because it will ensure any internal checksum calculation isn't going to detect it. Simple, but apparently effective. If you'd hook the filesystem, you'd need a lot of code and still it probably wouldn't run on that many machines as it does now. Or if it simply attaches itself to the binary, like classic viruses do, it would be detected by the self-infection check implemented in many programs (most notably any virus-checkers and such).
I'd imagine the person having made a substantial investment developing the virus. It's probably been tested & debugged in a network environment with many possible configurations of different Windowses, etc.
It's sad that whoever created is so irresponsible. I really despise this/these person(s) who did this.
if the game can load the data and display it, there's absolutely no encryption that isn't decryptable with relative ease, because the game must have the key and the decryption algorithm itself! If you just trace far enough, or put some breakpoints to the routines that load the graphics (or just to something like fread or so) you can have all the information you want.
Maybe some hardware based encryption or something like PDA content encryption technology might apply better... but definitely there's never going to be any game that can encrypt it's data and still be able to display it, without it connecting the network or requiring the user to enter some external codes.
Slashdot Mirror
There's one caveat, though. Onboard video can reduce the system memory bandwidth available for the CPU. 1280x1024 with 32-bit color takes over 300MB/s, just by displaying the image. 640x480 with 16 colors is your friend (9MB/s).
This is very likely to change relatively soon. Keep in mind many next generation consoles are multicore, like X-Box 2 with three cores. Game programmers are always eager to exploit any parallelism in the systems. Think consoles with their numerous co-processors, Amiga's blitter, Quake 1 which calculated floating point divide concurrently with other texture mapping code, or any current PC-system where graphics is processed on specialized GPUs. No, I'd say game developers will be one of the first ones to fully exploit dual processing capabilities. There are many highly "parallizable" tasks, like AI & pathfinding, physics, music & sfx playback, scripting, terrain generation, shadow hull calculations, CPU vertex skinning and hundreds of other small things games need to execute constantly.
I'm sure it not only makes gameplay smoother, but also increases the maximum FPS in CPU-bound situations in many future games released in 2006 and beyond.
I hope those topics aren't related...
400MHz SA (StrongArm)? Never heard of such a thing, but I assume it's an X-Scale (PCA-25x or PCA-26x) instead. 400MHz X-Scale is equivalent to magnitude of 20Mhz Pentium in floating point math, maybe 150-200Mhz Pentium in integer math. Afterall, Celeron has a huge cache compared to these (yeah, even the old joke-Celeron with a tiny cache has maybe 2-4 times more cache than this thing!)
In reality the simputer is equivelant to about 50-100Mhz Pentium, all things considered.
Mod up the parent. Unfortunately I have to say he got it right... It's all nonsense in grandparent.
Well, how about logging and examining the logs afterwards? That's how I did in a similar situation.
Blah, and I thought I said something original, for once... ;)
It's all just smoke and mirrors!
Good post. Makes me wish I had still some mod points left. The table hell should finally go, it's preventing mobile use of internet becoming widespread. You really DO hate when someone wants to make 800 px wide table fixed page when your web browser has 160-240 pixels horizontally... happy horizontal scrolling (unusable).
It doesn't matter PPC 2003 doesn't use the instruction set - it's not like the extra instructions could benefit the OS anyways. And I say this as a Pocket PC developer. It's really all about bus bus bus bus and bus. 100MHz at 16 bits per cycle (or every second cycle?) doesn't cut it! Memory fill speed is ~85MB/s on iPaq 3870 SA-1110 @ 206MHz and 80MB/s on iPaq 3970 X-Scale @ 400MHz.
Quite the contrary - that phrase is entirely correct.
When I tried to switch on fastpath on my T-DSL, they told me they don't know what fastpath means. I tried many reps. How to get them to actually do it?
No, the context switch wasn't 35ns. The system didn't even use that fast RAM. 35ns sounds more like the fastest pixel clock timing, the time it takes to display a single pixel. Pushing all the registers on the stack and switching the running task takes at least tens of microseconds on Amiga.
The screen switching magic was implemented using copper *1 lists - at some scanline copper would change the address from where the display hardware fetches the screen data. That's why screen switches were instantaneous - they only involve modifying the copper list. All the screens were drawn in the graphics memory (CHIP RAM) all the time anyways.
*1 Copper, a display coprocessor that can change values in the display hardware, color palette, playfields, horizontal pitch (modulo), scroll registers, sprites, graphics mode, etc. You could even flip the screen vertically just by making a copper list that does it (or having a negative pitch/modulo...) It basically has 3 different instructions - wait, move and skip and also a special code for terminating the list.
Well, use GSM compression @ 16kbps. 14MB will give you then almost 120 minutes. The microphone can't be much better anyways, you're not really even losing quality. It also said it has SecureDigital reader... The biggest SD-cards are now 512MB, they're going to have even 4GB cards later on.
Diablo 2 is mostly big because of the cutscenes and very stupidly compressed graphics. You can make graphics intensive games even in 8MB, check just about any older console that still used cartidges (or a bit older arcade machines). Or games like original Tomb Raider (8-9MB).
The description includes :
:)
"1x Biology U-Port"
What kind of beast is that?
Probably it's mistranslated bluetooth-port.
Otherwise, your post should be read by everyone on slashdot.
My earlier rant about this topic.
Well, the instruction timings oughta be the same for 16-bit and 32-bit instructions, which wasn't the case with 68000 (except, of course for multiplication, division and other instructions which actually have more work to do). But, then, 68000 only had 16-bit multiplication and division anyways... (32-bit/16-bit and 16bit*16bit). Even that should say something.
An Amiga could merely play 4 sound samples simultaneously. Two channels were assigned to left channel and two to right channel. Each channel also supported 6-bit volume (64 levels).
What, 68000 a 32-bit CPU? Since when? A 68000 can address 24-bit address space and it has 16-bit data bus. Sure, internally it is a 32-bit CPU, but using 32-bit ops took longer than their 16-bit counterparts! Smells badly as if the ALU was just a 16-bit one... (don't know this for certain).
We need more articles like this, they give insight for both application programmers *and* kernel developers.
First you'd form a piconet. If any of the systems is physically connected to (internet | base station | something else), relay there, else form/connect next device on a (same | different) piconet (the next device might have different piconets available). When the working relay is found, send back a message, targetting the original device. Relay it randomly and add a node to the route table the message contains. The original sender can deduce a short path (it's not necessarily the shortest!) just by looking at the message that arrives first/has the shortest route.
At this point, it should be possible to send small text messages with some efficiency.
It's also possible for other devices that happen to recieve a route recovery message to use the some of the readymade routes (so that everyone doesn't need to do this slow procedure).
The total amount of transferrable payload *per device* should probably be limited to something like 2kB, if this is to be used as an emergency network, to insure everyone can transmit their messages.
Any ideas/corrections from those "in the know", especially bluetooth people here?
Disclaimer: I'm not a bluetooth specialist... In fact I don't know much at all about it! :)
Long distance phone calls cheap in USA? Not counting dialpad and other internet phones, I think 5 cents/minute for an interstate call isn't cheap at all. For example calling to USA from Germany (using ordinary phone line) costs only about *3* cents per minute. That's what I call cheap.
On the other hand, local calls are dirt cheap in USA.
And by the way, I think one of the biggest reasons for slow adoption of cellphones in USA is the policy of cellphone user having to pay for the calls he receives! That's not the case in Europe - in Europe the caller always pays (except when you have redirects and such).
I believe the social factor is fairly important in adoption rates. Examples...
Finland:
In the countries like Finland the cellphone is almost fundamental for any kind of social life. Most things are arranged with SMS messages (kind of instant messaging system for GSM cellphones). That's why you almost *must* have a cellphone there! In fact, on average, almost 300 messages were sent per cell phone per year in Finland!
Japan:
In Japan the teenagers want probably 3G also for social reasons. It's important when you arrange a party over there to be able to send pictures of the ppl who are going to attend the party, so that the other ones know if there's anyone interesting looking etc. So you need a small camera in your cellphone and a color display. This has been possible for years using the i-mode phones. I can imagine they start to use video clips in the near future for that purpose, as well.
Sorry for any grammar / spelling mistakes here, I'm far from native speaker... :)
7 am? I guess it really depends where you are. A significant portion of slashdot's readers are in other timezones as well (and for example, in europe it's afternoon now).
I don't personally analyze viruses, but the analyses I've seen indicate that Nimda is actually quite sophisticated in design. It's not like Melissa or other scripting viruses. In fact, it's not implemented in script but as a binary. It's definitely not made in any kind of virus creation toolkit. The person who did it is not only a good programmer, but also has very good knowledge about the Windows internals.
Consider, for example, on how many different versions of Windows it runs on. In this kind of application that's not an easy feat. Or that it has a novel, yet simple method for 'infecting' the executable files. It puts the original executable in it's resources, and when ran, writes the original exe to the disk and *then* runs it. It's important, because it will ensure any internal checksum calculation isn't going to detect it. Simple, but apparently effective. If you'd hook the filesystem, you'd need a lot of code and still it probably wouldn't run on that many machines as it does now. Or if it simply attaches itself to the binary, like classic viruses do, it would be detected by the self-infection check implemented in many programs (most notably any virus-checkers and such).
I'd imagine the person having made a substantial investment developing the virus. It's probably been tested & debugged in a network environment with many possible configurations of different Windowses, etc.
It's sad that whoever created is so irresponsible. I really despise this/these person(s) who did this.
The example is a little bit bad.
if the game can load the data and display it, there's absolutely no encryption that isn't decryptable with relative ease, because the game must have the key and the decryption algorithm itself! If you just trace far enough, or put some breakpoints to the routines that load the graphics (or just to something like fread or so) you can have all the information you want.
Maybe some hardware based encryption or something like PDA content encryption technology might apply better... but definitely there's never going to be any game that can encrypt it's data and still be able to display it, without it connecting the network or requiring the user to enter some external codes.
Probably from one old Donald Duck story, where Uncle Scrooge was deceived into thinking fish is the new currency. Or maybe not. :)