It's no problem accomplishing all of that in a single frame, most things you listed are neglible:
Updating sprites - 544 byte DMA transfer (assuming ALL sprites which is unlikely) Updating scroll offsets - 12 bytes of register writes (3 layers, 16-bit x, y offsets) Sending a command to the SPC - A couple bytes (doesn't happen most frames) Controller input - 2 byte reads per controller
You can easily accomplish these things during Vblank and then you have the rest of the frame to do your game logic and "physics".
I stand by saying that slowdown doesn't affect most games. Although by "most" I mean most non-crappy games. I'm sure there are plenty of half-assed ports, etc. that have slowdown issues. But fixing a few rare instances of slow-down isn't worth totally mangling your sprites by overclocking.
Anyway you can't update the sprite data on the SNES during h-blank reliably because the PPU pre-fetches sprite data. Also the sprite memory address selector is invalidated outside V-Blank so you can't write to the sprite memory anyway. You can only update sprites during V-blank.
Chances are it's not a syncronization issue but he just broke the processor by running it at that speed and is lucky the game runs at all.
Flicker comes from the hard limit of 32 sprites per scanline (and 34 sprite tiles). Games have to flicker the sprites otherwise the ones outside the limit would disappear entirely. On the NES this was a lot more noticeable since the limit was a measely 8 per line.
SNES games run at a fixed 60 frames per second (they're syncronized with the TV signal) and most games have no trouble moving all the graphics around each frame. I can't see overclocking doing anything but screwing the games up.
The point of this program is not to nag people who knowingly pirated Windows. They're just going to uninstall/hack it or whatever. It's to notify people who DON'T know that they're using a pirated XP install. Then they know not to buy computers from "John's Shady Computer Store" in the future.
No, the trim option trims the process working set on minimize. It has nothing to do with the page memory cache. Trimming the working set results in the OS eventually paging the memory to disk, leaked memory or not. This is not a solution to the problem it's just defeating the purpose of the system's memory manager.
This doesn't reclaim anything. All it does is trim the working set which results in less RAM usage being reported and, will be more likely to page the memory to disk. If you use your system for awhile with the application minimized, it will likely be very unresponsive once restored.
I'm pretty sure the Apple IIs also ran a 6502 like the NES except it was clocked slightly higher. Also the NES 6502 was completely lacking a decimal mode. Regardless, its a 1970s-era chip being used in 1984 into the 90s, likely for its cheapness.
Well, you can transfer 1 byte over DMA at about the same speed as 1 CPU cycle. With some dirty math, there's about 6810 CPU cycles in a v-blank period so you can transfer about 6.65 KB in a vblank. Of course you're not going to be updating character data EVERY frame. And you don't necessarily need to update any character data at all unless you can't fit all of it in the 32 KB of video RAM. Switching a sprite's character data to point somewhere else in memory is just a 1 byte write.
Genesis specs I'm not too familar with, but I've written an SNES emulator.
If a game performs shitty on one system, poor coding could always be blamed especially if it's a port.
Nah, SNES memory bandwidth was excellent. It had 8 DMA channels and could hit ~2.68 megs/sec (that's a lot for back then). If there were any issues with moving sprites compared to the Genesis it was likely a CPU-bound problem. Of course, if this was really hurting the game you could always get one of those external co-processors in the cartridge. =)
Gamecube actually didn't really have ATI graphics. ATI was just on the business end of things. The GPU was designed by Art-X which is an SGI spin-off. This gave Gamecube a lot of unique graphics capabilities. Anything related to SGI is a step up from ATI in my book.
Nintendo systems have always had underpowered main processors, going back to the NES. Then they throw loads of custom chips on top of everything.
The SNES had its unique "color math" capabilities and the famous Mode7 affine matrix transformation mode.
I believe the N64 let you re-write the microcode in the GPU for custom needs.
The Gamecube, had lots of unique graphical capabilities like an indirect texture unit. SGI workstations are about the only machines that had indirect texturing. You can do lots of cool effects like fake light refraction and psuedo-3D geometry.
Slashdot Mirror
Maybe they're more concerned about the long-term and shipping a quality product?
I heard he gets paid $8400 to speak at Universities although I'm unsure what UIC paid him. Also doesn't the ACM server have a 2 gig bandwidth limit?
It's no problem accomplishing all of that in a single frame, most things you listed are neglible:
Updating sprites - 544 byte DMA transfer (assuming ALL sprites which is unlikely)
Updating scroll offsets - 12 bytes of register writes (3 layers, 16-bit x, y offsets)
Sending a command to the SPC - A couple bytes (doesn't happen most frames)
Controller input - 2 byte reads per controller
You can easily accomplish these things during Vblank and then you have the rest of the frame to do your game logic and "physics".
I stand by saying that slowdown doesn't affect most games. Although by "most" I mean most non-crappy games. I'm sure there are plenty of half-assed ports, etc. that have slowdown issues. But fixing a few rare instances of slow-down isn't worth totally mangling your sprites by overclocking.
The similar clock-rates are by pure coincidence though. The clock rate of a CPU has nothing to do with the frequency of an NTSC signal.
3.58 Mhz isn't the "NTSC frequency."
Anyway you can't update the sprite data on the SNES during h-blank reliably because the PPU pre-fetches sprite data. Also the sprite memory address selector is invalidated outside V-Blank so you can't write to the sprite memory anyway. You can only update sprites during V-blank.
Chances are it's not a syncronization issue but he just broke the processor by running it at that speed and is lucky the game runs at all.
Games like Star Fox are bound by the speed of the SuperFX chip in the cartridge. Someone did manage to overclock it though, right here: http://benheck.com/phpBB/viewtopic.php?t=7680&star t=0&postdays=0&postorder=asc&highlight=
And yes it does increase the frame rate.
Flicker comes from the hard limit of 32 sprites per scanline (and 34 sprite tiles). Games have to flicker the sprites otherwise the ones outside the limit would disappear entirely. On the NES this was a lot more noticeable since the limit was a measely 8 per line.
SNES games run at a fixed 60 frames per second (they're syncronized with the TV signal) and most games have no trouble moving all the graphics around each frame. I can't see overclocking doing anything but screwing the games up.
You start with 1000 awesome features, and end up implementing 2.
The point of this program is not to nag people who knowingly pirated Windows. They're just going to uninstall/hack it or whatever. It's to notify people who DON'T know that they're using a pirated XP install. Then they know not to buy computers from "John's Shady Computer Store" in the future.
Safari basically replaced it.
They can't fix EVERY bug in the product, man.
No, that's reserved for OSTG affiliates. =)
No, the trim option trims the process working set on minimize. It has nothing to do with the page memory cache. Trimming the working set results in the OS eventually paging the memory to disk, leaked memory or not. This is not a solution to the problem it's just defeating the purpose of the system's memory manager.
This doesn't reclaim anything. All it does is trim the working set which results in less RAM usage being reported and, will be more likely to page the memory to disk. If you use your system for awhile with the application minimized, it will likely be very unresponsive once restored.
I guess you've never been to an arcade before.
And most "American" cars are assembled in Mexico and Canada.
I don't see how liability is an issue if the driver is responsible for braking.
I am sincerely hoping we'll see an end to above jokes when Office 2007 kills off Clippy... yeah right.
I'm pretty sure the Apple IIs also ran a 6502 like the NES except it was clocked slightly higher. Also the NES 6502 was completely lacking a decimal mode. Regardless, its a 1970s-era chip being used in 1984 into the 90s, likely for its cheapness.
Well, you can transfer 1 byte over DMA at about the same speed as 1 CPU cycle. With some dirty math, there's about 6810 CPU cycles in a v-blank period so you can transfer about 6.65 KB in a vblank. Of course you're not going to be updating character data EVERY frame. And you don't necessarily need to update any character data at all unless you can't fit all of it in the 32 KB of video RAM. Switching a sprite's character data to point somewhere else in memory is just a 1 byte write.
Genesis specs I'm not too familar with, but I've written an SNES emulator.
If a game performs shitty on one system, poor coding could always be blamed especially if it's a port.
Nah, SNES memory bandwidth was excellent. It had 8 DMA channels and could hit ~2.68 megs/sec (that's a lot for back then). If there were any issues with moving sprites compared to the Genesis it was likely a CPU-bound problem. Of course, if this was really hurting the game you could always get one of those external co-processors in the cartridge. =)
Gamecube actually didn't really have ATI graphics. ATI was just on the business end of things. The GPU was designed by Art-X which is an SGI spin-off. This gave Gamecube a lot of unique graphics capabilities. Anything related to SGI is a step up from ATI in my book.
Nintendo systems have always had underpowered main processors, going back to the NES. Then they throw loads of custom chips on top of everything.
The SNES had its unique "color math" capabilities and the famous Mode7 affine matrix transformation mode.
I believe the N64 let you re-write the microcode in the GPU for custom needs.
The Gamecube, had lots of unique graphical capabilities like an indirect texture unit. SGI workstations are about the only machines that had indirect texturing. You can do lots of cool effects like fake light refraction and psuedo-3D geometry.
Err, make that 88 megs!