I also seem to recall that Mulg II running on the internal accellerometer (if it was stuck in that mode), has an awful habit of crashing on a TRGpro.
Seems that the TRGpro uses the same pins as the accellerometer, and can trick Mulg into thinking there is an accellerometer when there isn't - instead it goes to the compactflash hardware.
You can NOT make back up copies of the ROMs! [Unless you are a video game developer] While the backup law allows you to make a backup, that backup has to be an *EXACT* copy. Thus, the copy of the ROM you have on disk is legal only when used to create another ROM from it as backup. But the use of the disk file is not covered by the backup clause - it is not operationally necessary to the operation of the game.
If you are a legitimate videogame developer, however, things are different - you may have a copy of the disk file of a game (not necessarily the one you're working on). This has been recognized in the courts. See this web page for more details. Root of this document is here.
IANAFC (I am not a financial consultant), but I guess it's because of April being the tax month? I know taxes are charged on a year starting/ending basis (Jan 1 to Dec 31), but it's probably easier for businesses to say that April is a good time to start counting their fiscal year again (do taxes, then 1 year of not having to do it). Makes it easier to calculate after-tax profits after you pay taxes, no?
One way was to evaluate various "trees" - we'd feed in a file from gutenburg, and it'll add "words" (delimited with whitespace - we're talking C++ extraction operators here) to the tree.
Then, using that tree, search for several words, timing the length of time it takes to perform the search. It's certainly more fun playing around with real text and searching through it (500k - searches/tree insertions aren't "instant").
I suspect using Gutenburg for data processing isn't exactly unique... but it provides a nice example to do lots of stuff with "interestingly-sized" data, rather than the 10 pieces of data that people have to make up.
Missed a platform that can run VNC client: PalmOS(!). Yes, you have to do a bit of scrolling on a 160x160 (I think it's 150x150 actual usuable area - rest is scrollbars etc) screen, but you can run the client on it (Don't know how long it would be before you give up on a B&W/16grey screen [unsure if color version out yet]).
Someone should ask Logitech to license their Marble technology... my Marble FX has only needed very little cleaning, and dirt doesn't affect it too much.
Must admit, though, that thanks to tax breaks, the movie industry here (BC) is booming, much to the extent of people calling "Hollywood North" thieves for taking the real Hollywood jobs >G<.
It's the same everywhere. BC's economy in the 90s has been the pits, while Alberta's boomed. Now, several large companies promptly moved their headquarters from BC to Alberta. I wonder why... (Don't say oil. Oil prices were awful a few years ago, yet Alberta managed to boom. Of course, it's really booming now that oil prices are so high).
Do remember, Chretien is from Quebec, another whacky province IMNSHO.
Actually, it isn't the EEPROM that wears out. There's a little counter beside the region encoding on most implementations that limit the number of region changes. The firmware then checks against this number all the time.
If you have an older Dxr2 card/drive, there are utils that will reset the region code practically infinite number of times (because the "counter" isn't updated), as well as reset the count. However, it does involve re-flashing the ROM of the drive to turn it region free, so the card itself is the only thing that needs to be reset all the time.
I am taking a course that utilizes both the NachOS "OS" and the Stallings book. I find NachOS perfect for introductory courses to operating systems - explain topics like multithreading, mutual exclusion (very tricky!), memory protection, cpu scheduling, etc. It's abstracted far enough from a "real" OS that you get the concepts down (and some basic implementation).
As for telling the difference between simulated hardware and the kernel, I've found the simulated hardware is hidden away in the/machine directory (with explicit warnings to not touch code there), while the kernel is everywhere else.
But, NachOS' scope as a teaching OS dies beyond the basics (definitions and a basic implementation with testcases). But, it is good at teaching the basics I've found, and explaining the basic functions of OS' (multi*, mutex, protected memory, etc) with some real implementation.
Sure, if I want to expand that knowledge to Linux, FreeBSD, etc, I'd have to relearn it all, but it's easier to relearn implementation in a certain OS once one knows what is the basic premise.
Heheh. I seem to recall that on M$' homepage, there was the logo - it weighed in at 666 bytes!
So, perhaps now we see the return of web pages with actual content, and smallish GIFs.
I'd love to see the results of this contest (I have a 56k modem, and have access to a LAN connection [LAN is more troublesome, having to lug laptop around]).
I use identd all the time - it's required to utilize most IRC servers. Now, normally I run a Windoze box with an identd server - easy to change ID's that way. What would be nice is a way to get identd to instead of replying a real user ID, reply a fake one (user-settable).
I know <tt>ezbounce</tt> does have a modified identd that'll fake it as necessary, but one that gets installed by default would be great.
By default, the identd server tells me who and the data of the identd request (incoming/outgoing), and I've only seen one webserver that actually did try to access it - it connected (once each per Netscape connection - ARG!), then timed out.
<i>Um, no, I don't think so. You are wearing rose-tinted glasses my friend. </i>
<i> Unless you're knee-deep in assembly macros, in which case that's strictly speaking at a higher-level than assembly anyway.</i>
Um, <b>YES</b>, certain processors have *extremely readable* assembly. I know for certain that the 68k has a very nice asm opcodes (it's very much like C - reads like it, too). And this is with a dumb 2pass assembler (no macros, nothing).
The only reason "assembly is hard" is due to Intel and their awful pocket-calculator decendent chip, the x86. Now, this chip has extremely wierd instruction rules with wierd register accesses (some faster than others for certain operations)...
Probably more than you think... General key to seeing if something uses floating point is to look for a decimal point. Not a sure-fire way, but works well enough in practice.
While M$ Word won't care if your CPU does only 1 FLOP/s or 10 billion FLOP/s (well, at 1 FLOP/s...) or even use that much, oftentimes programs use floating point.
As for other than games, if you use a spreadsheet, that's a nice use of floating point there. Or perhaps sound editing (usually integer, but sines and cosines have an awful habit of being in [0,1], and FLOP/s are important when you want to do accurate fourier transforms). Or perhaps GIMP/Photoshop. Or perhaps apps like CAD/FEM(finite element modeling)/etc.
Another caveat of voice-recog PDAs - are you sure you'd want to be talking to one of these in public?
Nothing about spilling your personal life to anyone who'd listen, but what's a typical citizen to do when seeing someone looking at a black box, talking out loud? (I.e., that person's talking to himself! Nuts!)
Heheh. ALthough, I do see a use of vocal "rm -rf/*" from time to time.
Ever consider that (last I checked, which was a while ago), that since they get paid for domains, they create them very quickly. Since altering the record is a 'freebie', it costs them money to change it. Thus, they lose money from every record change, and what better way to save money than not doing it?
Well, 6pm PST is also the time most people have dinner, no? And since it *IS* Sunday, I doubt many people do spend time at the computer typing and eating (well, I don't know about/.ers... so this probably isn't true).
I guess central and mountain time people have it made >G
Don't forget the numerous simpson cameo appearances in Futurama, as well as other works by Matt Groening (that little comic he draws weekly pops up now and again) that do show up.
How about, first the program generates a lot of valid assembly code of the server's processor, then assembles it, and chooses various assembled bytes as the key? (New meaning to "large instruction set"...)
Certainly hard to find a key through what looks like valid executable binary code...
Comparing clock speeds without consideration of clock efficiency is like comparing the version numbers of the various Linux distributions.
Plus, a lower clock speed has much less design issues than a higher clock speed. Lower clock speed chips can use cheaper fab processes, the motherboard can be laid out without as much concern to cross-coupling/transmission line problems, clock skew (very important), and a host of other problems inherent with high speed/microwave design.
Here's a way to imitate more sensors/motors, assuming we can do it with a mindstorm (I don't have one, so this is just hypothetical).
For less verbosity, I'll call the motor controls A, B, and C, and sensors 1, 2, and 3.
Additionally, I'm assuming the motor outputs are tri-state (forward, off, reverse), but sensors are binary (shorted, open).
[Method 1]
Leave A for motor control, and multiplex it via a serial output from say, B. Leave sensors 1, 2 for direct use, and make 3 a multiplexed one. Contol the sensor multiplexor from C.
[Method 2]
Use A, B for motor control. Use C to control multiplexors for both motors and sensors. Again, sensor input 3 is multiplexed.
[Method 2.1]
Control motors by using a positive-going multiplexing scheme, and sensors by a negative going (reverse) scheme.
[Method 3]
Again, A is for multiplexed motor control. Again, 3 is for multiplexed sensor control, 1, 2 are regular sensor inputs. Use B as a clock, and C as data to control a shift-register, whose outputs connect A or 3 (as appropriate) to inputs.
I'm not saying that the constraints aren't limiting, just be imaginative and try to think of something. I don't know if these ideas work or not, but they're ideas for people to try, perhaps mess around with, which can lead to more ideas. Perhaps try various constrained microcontrollers (very little RAM (from bytes to countable kbytes), low clock, constrained instruction set, low program memory count [there are processors that separate program instructions from RAM]), like Basic STAMPs, PICs, to more "expansive" processors like a HC11.
The challenge is to make things work given a constraint (usually cost) >G. Perhaps you'll make an "MindStorm Expansion Brick" that hooks up to the RCX unit and offers a lot of sensors/motor control, at the expense of software complexity.
IIRC, commodity DVD recorders (DVD-RAM, DVD-R) also have on the media an unrecordable area, which on a normal DVD movie, contains the decryption keys. So even if you have a complete bit copy on the hard disk, and a program that'll burn raw data, the decryption key doesn't get recorded. Of course, if you have the raw data already...
Of course, until an enterprising DVD recordable media manufacturer decides to make it recordable >G [not sure if that area *has* to be unrecordable to record the media correctly (like the ATIP part of a CD-R), it's just in the standard].
Re:Serial and Parallel in a SchizoPhrenic article?
on
Future I/O Standards
·
· Score: 1
The fact that Serial is much, much less tricky to physically handshake is the reason we've seen so many R&D development dollars poured into it.
Actually I think all the money's being poured into the design of fast serial because parallel interfaces need to be short and very rigidly controlled to be fast. And to get faster you need to add more lines (beyond the double-edge clocking and stuff). Serial offers more in this arena, and if you need to be faster than that yet, you can parallelize individual serial lines.
Yes. It's very difficult to build high-speed parallel interfaces, even if you have proper handshaking similar to serial. When you have a data cable with 8, 16, etc data lines (parallel), you start to worry that when you change the data on those lines and handshake, that the data appearing on the lines hasn't fully propogated to the end. So what appears on the end is a few changed bits, some indeterminate bits (in the process of changing), and some bits from the old bit of data. It's much easier to worry about 1 line than 8/16/2^n.
Related note: 'Clock Skew' is an important part of IC design, especially as processors get faster. The clock pulse changes at one end, but the change until some time later at the other end, which messes up timing.
Slashdot Mirror
I also seem to recall that Mulg II running on the internal accellerometer (if it was stuck in that mode), has an awful habit of crashing on a TRGpro.
Seems that the TRGpro uses the same pins as the accellerometer, and can trick Mulg into thinking there is an accellerometer when there isn't - instead it goes to the compactflash hardware.
This dongle will be useful...
If you are a legitimate videogame developer, however, things are different - you may have a copy of the disk file of a game (not necessarily the one you're working on). This has been recognized in the courts. See this web page for more details. Root of this document is here.
IANAFC (I am not a financial consultant), but I guess it's because of April being the tax month? I know taxes are charged on a year starting/ending basis (Jan 1 to Dec 31), but it's probably easier for businesses to say that April is a good time to start counting their fiscal year again (do taxes, then 1 year of not having to do it). Makes it easier to calculate after-tax profits after you pay taxes, no?
This is only a guess.
One way was to evaluate various "trees" - we'd feed in a file from gutenburg, and it'll add "words" (delimited with whitespace - we're talking C++ extraction operators here) to the tree.
Then, using that tree, search for several words, timing the length of time it takes to perform the search. It's certainly more fun playing around with real text and searching through it (500k - searches/tree insertions aren't "instant").
I suspect using Gutenburg for data processing isn't exactly unique... but it provides a nice example to do lots of stuff with "interestingly-sized" data, rather than the 10 pieces of data that people have to make up.
Missed a platform that can run VNC client: PalmOS(!). Yes, you have to do a bit of scrolling on a 160x160 (I think it's 150x150 actual usuable area - rest is scrollbars etc) screen, but you can run the client on it (Don't know how long it would be before you give up on a B&W/16grey screen [unsure if color version out yet]).
Someone should ask Logitech to license their Marble technology... my Marble FX has only needed very little cleaning, and dirt doesn't affect it too much.
I see an opportunity here...
Must admit, though, that thanks to tax breaks, the movie industry here (BC) is booming, much to the extent of people calling "Hollywood North" thieves for taking the real Hollywood jobs >G<.
It's the same everywhere. BC's economy in the 90s has been the pits, while Alberta's boomed. Now, several large companies promptly moved their headquarters from BC to Alberta. I wonder why... (Don't say oil. Oil prices were awful a few years ago, yet Alberta managed to boom. Of course, it's really booming now that oil prices are so high).
Do remember, Chretien is from Quebec, another whacky province IMNSHO.
Actually, it isn't the EEPROM that wears out. There's a little counter beside the region encoding on most implementations that limit the number of region changes. The firmware then checks against this number all the time.
If you have an older Dxr2 card/drive, there are utils that will reset the region code practically infinite number of times (because the "counter" isn't updated), as well as reset the count. However, it does involve re-flashing the ROM of the drive to turn it region free, so the card itself is the only thing that needs to be reset all the time.
Most EEPROMs have at least 1000 write cycles...
I am taking a course that utilizes both the NachOS "OS" and the Stallings book. I find NachOS perfect for introductory courses to operating systems - explain topics like multithreading, mutual exclusion (very tricky!), memory protection, cpu scheduling, etc. It's abstracted far enough from a "real" OS that you get the concepts down (and some basic implementation).
/machine directory (with explicit warnings to not touch code there), while the kernel is everywhere else.
As for telling the difference between simulated hardware and the kernel, I've found the simulated hardware is hidden away in the
But, NachOS' scope as a teaching OS dies beyond the basics (definitions and a basic implementation with testcases). But, it is good at teaching the basics I've found, and explaining the basic functions of OS' (multi*, mutex, protected memory, etc) with some real implementation.
Sure, if I want to expand that knowledge to Linux, FreeBSD, etc, I'd have to relearn it all, but it's easier to relearn implementation in a certain OS once one knows what is the basic premise.
Heheh. I seem to recall that on M$' homepage, there was the logo - it weighed in at 666 bytes!
So, perhaps now we see the return of web pages with actual content, and smallish GIFs.
I'd love to see the results of this contest (I have a 56k modem, and have access to a LAN connection [LAN is more troublesome, having to lug laptop around]).
I use identd all the time - it's required to utilize most IRC servers. Now, normally I run a Windoze box with an identd server - easy to change ID's that way. What would be nice is a way to get identd to instead of replying a real user ID, reply a fake one (user-settable).
I know <tt>ezbounce</tt> does have a modified identd that'll fake it as necessary, but one that
gets installed by default would be great.
By default, the identd server tells me who and the data of the identd request (incoming/outgoing), and I've only seen one webserver that actually did try to access it - it connected (once each per Netscape connection - ARG!), then timed out.
ASM is just as readable as C these days.
<i>Um, no, I don't think so. You are wearing rose-tinted glasses my friend. </i>
<i> Unless you're knee-deep in assembly macros, in which case that's strictly speaking at a higher-level than assembly anyway.</i>
Um, <b>YES</b>, certain processors have *extremely readable* assembly. I know for certain that the 68k has a very nice asm opcodes (it's very much like C - reads like it, too). And this is with a dumb 2pass assembler (no macros, nothing).
The only reason "assembly is hard" is due to Intel and their awful pocket-calculator decendent chip, the x86. Now, this chip has extremely wierd instruction rules with wierd register accesses (some faster than others for certain operations)...
Probably more than you think... General key to seeing if something uses floating point is to look for a decimal point. Not a sure-fire way, but works well enough in practice.
While M$ Word won't care if your CPU does only 1 FLOP/s or 10 billion FLOP/s (well, at 1 FLOP/s...) or even use that much, oftentimes programs use floating point.
As for other than games, if you use a spreadsheet, that's a nice use of floating point there. Or perhaps sound editing (usually integer, but sines and cosines have an awful habit of being in [0,1], and FLOP/s are important when you want to do accurate fourier transforms). Or perhaps GIMP/Photoshop. Or perhaps apps like CAD/FEM(finite element modeling)/etc.
Just my pointless bool bit[2]; .
In 3.1, it was easy. I think in win.ini, you added/modified a few settings, and the border size, icon spacing, etc all changed...
Then again, having windows "in-proportion" is a nice idea, but pointless if the icons you're concerned about are, oh, 1 mm on a side.
How about a screen that folds out automatically, similar to those "butterfly" keyboards a while back on those IBM subnotebooks...
Then again, I don't think you'd want a 50 inch screen expanding out of your notebook on a flight in coach...
Another caveat of voice-recog PDAs - are you sure you'd want to be talking to one of these in public?
/*" from time to time.
Nothing about spilling your personal life to anyone who'd listen, but what's a typical citizen to do when seeing someone looking at a black box, talking out loud? (I.e., that person's talking to himself! Nuts!)
Heheh. ALthough, I do see a use of vocal "rm -rf
Ever consider that (last I checked, which was a while ago), that since they get paid for domains, they create them very quickly. Since altering the record is a 'freebie', it costs them money to change it. Thus, they lose money from every record change, and what better way to save money than not doing it?
Well, 6pm PST is also the time most people have dinner, no? And since it *IS* Sunday, I doubt many people do spend time at the computer typing and eating (well, I don't know about /.ers... so this probably isn't true).
I guess central and mountain time people have it made >G
IIRC, you can't. The area that has decryption keys is either "burned out" or contains data there, such that it is impossible to record there.
So you have to hack the movie and hack the player to store the data...
Don't forget the numerous simpson cameo appearances in Futurama, as well as other works by Matt Groening (that little comic he draws weekly pops up now and again) that do show up.
How about, first the program generates a lot of valid assembly code of the server's processor, then assembles it, and chooses various assembled bytes as the key? (New meaning to "large instruction set"...)
Certainly hard to find a key through what looks like valid executable binary code...
Comparing clock speeds without consideration of clock efficiency is like comparing the version
numbers of the various Linux distributions.
Plus, a lower clock speed has much less design issues than a higher clock speed. Lower clock speed chips can use cheaper fab processes, the motherboard can be laid out without as much concern to cross-coupling/transmission line problems, clock skew (very important), and a host of other problems inherent with high speed/microwave design.
Here's a way to imitate more sensors/motors, assuming we can do it with a mindstorm (I don't have one, so this is just hypothetical).
For less verbosity, I'll call the motor controls A, B, and C, and sensors 1, 2, and 3.
Additionally, I'm assuming the motor outputs are tri-state (forward, off, reverse), but sensors are binary (shorted, open).
[Method 1]
Leave A for motor control, and multiplex it via a serial output from say, B. Leave sensors 1, 2 for direct use, and make 3 a multiplexed one. Contol the sensor multiplexor from C.
[Method 2]
Use A, B for motor control. Use C to control multiplexors for both motors and sensors. Again, sensor input 3 is multiplexed.
[Method 2.1]
Control motors by using a positive-going multiplexing scheme, and sensors by a negative going (reverse) scheme.
[Method 3]
Again, A is for multiplexed motor control.
Again, 3 is for multiplexed sensor control, 1, 2 are regular sensor inputs.
Use B as a clock, and C as data to control a shift-register, whose outputs connect A or 3 (as appropriate) to inputs.
I'm not saying that the constraints aren't limiting, just be imaginative and try to think of something. I don't know if these ideas work or not, but they're ideas for people to try, perhaps mess around with, which can lead to more ideas. Perhaps try various constrained microcontrollers (very little RAM (from bytes to countable kbytes), low clock, constrained instruction set, low program memory count [there are processors that separate program instructions from RAM]), like Basic STAMPs, PICs, to more "expansive" processors like a HC11.
The challenge is to make things work given a constraint (usually cost) >G. Perhaps you'll make an "MindStorm Expansion Brick" that hooks up to the RCX unit and offers a lot of sensors/motor control, at the expense of software complexity.
IIRC, commodity DVD recorders (DVD-RAM, DVD-R) also have on the media an unrecordable area, which on a normal DVD movie, contains the decryption keys. So even if you have a complete bit copy on the hard disk, and a program that'll burn raw data, the decryption key doesn't get recorded. Of course, if you have the raw data already...
Of course, until an enterprising DVD recordable media manufacturer decides to make it recordable >G [not sure if that area *has* to be unrecordable to record the media correctly (like the ATIP part of a CD-R), it's just in the standard].
The fact that Serial is much, much less tricky to physically handshake is the reason we've seen so
many R&D development dollars poured into it.
Actually I think all the money's being poured into the design of fast serial because parallel interfaces need to be short and very rigidly controlled to be fast. And to get faster you need to add more lines (beyond the double-edge clocking and stuff). Serial offers more in this arena, and if you need to be faster than that yet, you can parallelize individual serial lines.
Yes. It's very difficult to build high-speed parallel interfaces, even if you have proper handshaking similar to serial. When you have a data cable with 8, 16, etc data lines (parallel), you start to worry that when you change the data on those lines and handshake, that the data appearing on the lines hasn't fully propogated to the end. So what appears on the end is a few changed bits, some indeterminate bits (in the process of changing), and some bits from the old bit of data. It's much easier to worry about 1 line than 8/16/2^n.
Related note: 'Clock Skew' is an important part of IC design, especially as processors get faster. The clock pulse changes at one end, but the change until some time later at the other end, which messes up timing.