Visiting this past summer I saw a similar system in South Korea. The receiver looks like a big black eyeball (think HAL-9000) with a bright blue LED on top. They have these things all over - fast food joints, small markets (think 7-11), and on buses. Just put your phone near it, hit a button, and the charge goes onto your cell phone bill.
Seems like it was getting well adopted. I googled for it, but I can't remember the name exactly.
"That means we have to find a way to emulate this data, in other words to turn into a form that can be used no matter what is the computer format of the future. That is the real goal of this project."
Hrm... how about printing it out and binding it together! Make bunches of copies, send them their separate ways. Oh... a book!
Get a 31xx monoPAQ. Get the compactflash sleeve and the pcmcia sleeve (the latter because it has its own battery). Get a large (5gb) PCMCIA drive (IBM microdrive), a smaller (1gb) CF flash card, a Targus foldable keyboard, a CF 10/100/802.11b card, a PCMCIA 10/100/802.11b card, a PCMCIA Sierra Aircard 510, and a CF vga-out adapter. Find a LCD panel that you like, build a battery pack for it.
Some creative duct taping or plexiglassing and yes sir, you have a Linux-capable computing brick that has a modular power system! Go full-tilt, and you have VGA on a full LCD with a keyboard and your big microdrive. Monitor dies, and you switch back the native screen. PCMCIA battery pack goes down, switch to CF. CF draining you too fast? Switch to internal memory.
If you want to get more creative, try it with the new 38xx series. Has longer battery life and built-in SD so you don't even need a sleeve. Don't forget, for the 31xx and 36xx series ipaqs, you can expand internal memory to 128mb with some creative soldering (read: surface mount).
So let's review your criteria:
1) clear screen: the 36xx has a nice screen, and whatever external LCD you choose could be good.. up to you.
2) decent 2d video: Hrm... well, it runs Quake. You decide.
3) Physical utility: Well, build a padded titanium case for your ipaq and lcd screen. Should be sturdy. Use it as a foot stool.
4) insanely long battery life: modular battery style means you can get long battery life. 12+ hours with the monopaq alone. Since everything else has it's own battery pack (except the CF sleeve), you can mix-n-match. A little creative hackery and you can probably paste an external big battery to the ipaq.
5) networking: 10bt, 100bt, 802.11b wireless, CDPD wireless and CDMA wireless. Sounds good to me.
Source view:
Apparently, it was a big gripe in pre-version 3.5. It popped up there around then and is basically a hack, IMHO. Just don't use it, because it really mucks things up. Unfortunately, that's the state of things. I just bury my head in the sand and work method-level. One other bug is that in exporting code to a conventional build+test system, sometimes things get put in the wrong order.. ie. static field declarations AFTER a static class initializer routine. Whups. Source view to the rescue. Otherwise, I don't care how the code looks in flat form.
Versioning:
There is a patch for 3.5.3 (or something like it) pertaining to the external versioning control subsystem. Maybe you should grab it. Yes, it's buggy:>. For CVS-die hards, you can get vaj2cvs, a plug-in that automates all the cvs stuff for you.
Debugger:
Yes, it's confusable sometimes. Remember to SAVE YOUR WORKSPACE before you try and debug a big change. It has saved my arse many a time.
CLASSPATH:
I don't know if this is VAJ or VA/Assist... but in my dev environment right-clicking on the class to run, going to run->check class path... fixes up the class path automagically. Never had a problem.
The WORST thing about VAJ:
Global search and replace for refactoring purposes. Oh boy, can this be trouble. Change a name, it breaks 50 things. Go through and rename those things, and each one recompiles and breaks 10 more. Oh, it's pretty friggin' painful, even with the automated tools from Instantiations. We just ended up exporting to Emacs, making the change, and importing. Worked like a charm!
Mark
Re:IBM VisualAge for Java?
on
Java IDEs?
·
· Score: 1
True, it could be better of an editor. VaAssist from instantiations gives you better control of the editing environment. But it does take a bunch of time getting used to it. Once you've got 30,000+ lines of code in there, written by a dozen or so people, you start to understand how good it can be at organizing your stuff.
Off-topic, IBM did not write VAJ, OTI (oti.com) did.
So, how the hell did that "'" get in my subject line? Oops.
As far as documentation system, VAJ doesn't have anything built in at all except generation of JavaDOC (gee, thanks IBM). But, the plug-in interface lets you write your own tool, or better yet, download/buy one that is already done:>.
The folks at Reliable Systems have a few tools that I've played with that might be useful to you.
iDarwin, iContract, and iDoc may all help you out.
VisualAge for Java`
on
Java IDEs?
·
· Score: 4, Informative
Personally, I'm a convert to VisualAge for Java from IBM. I've used JBuilder, Forte, Together/J, XEmacs, Notepad, VisualCafe, you name it.
VisualAge has a rather steep learning curve associated with it compared to a lot of the IDEs, but it really is the first product that I can recommend for Java coding.
Unique features that I find useful are:
* No files -- just a big 'ol database repository that is managed by VisualAge. There really is no need for files in Java, really, and this makes things great for reorganizing your code and proper versioning.
* Incremental compilation that works with the debugger -- breakpoint your app, change code, continue with new changes.
* Method-atomic units of editing. You edit at the method level instead of the file level. Easier to conceptualize large OO systems as you don't spend time navigating lines and lines of code and various files. Just pick a package, class, and method from a nice hierarchical window system and start coding.
* Semi-open plug-in interface. Write your own little applets to do things to your own code base (fancy search/replace, exporting your code, merging changes...) -- this also means you can download/buy cool add-ons (Instantiations' VA/Assist and JFactor come to mind).
* Good Enterprise team coding system. That repository is pretty good for keeping versions around and keeping things straight between teams of coders. You can also use and SCCI? compliant version control system.
It can be tricky to master at times, but worth it, IMHO. Best of all, you can get a copy for $60 with the book Effective Visualage for Java at your local Barnes and Noble.
Not affiliated--just finally satisfied with an IDE.
Actually, it ain't that bad Cliff. Just make sure you find a good job.
A rewarding job is paramount in staying happy with what you do. It isn't the CS part, it's what you're doing day in and day out. Honestly, working somewhere that challenges you and produces a fine product will be Much much more fulfilling than the off-by-one errors that you are finding now.
I agree that it is difficult to control where components get placed in an FPGA. But with the sizes of these things getting so big, it is hard to make a design that you will be hand placing and routing. Usually, we let the tools do this for us and just concentrate on the HDL.
Yes, portability is a big issue, but at least there is the hope of porting between similar architectures (such as between a Xilinx 4000-series and the Virtex series). In the case of ASICs, well, what does portability really mean? It's completely fabrication dependent.
Finally, regarding security of ROM images: I know that Xilinx keeps the format and interpretation of the bitstream proprietary and confidential. This doesn't mean that it is impossible to figure out, just more difficult than inserting a VM and "voila!".
I for one welcome the chance to re-design the processor in my computer:>.
Hollywood+. Works with remote as well. Have it set up in my living room with a regular-sized PC and it works well. I use it in addition to my regular standalone DVD player because it will play CDRs with VCD/SVCD/MP3/MPG stuff on 'em as well.
Something that I've been using instead of VNC lately when in the Windows world is Timbuktu Pro. It handles updates better than VNC and seems a bit more responsive. YMMV.
I'm feeling the wireless keyboard/touchpad combo calling to me with this setup. Throw in a Hollywood+ for _decent_ video playback, find a firewire video-input device and voila, quite the all-in-one.
I did some looking into his research a while ago for a seminar talk I did. Hopefully, you'll find it has more technical info than the article:
here it is
The Virtex can do slice reconfiguration which is a form of partial reconfiguration. But I don't know of any available boards that support that feature. Virtex-II will probably be better supported. The reconfiguration time of our XCV2000E is around a second through the PCI bus.
The other option is the now-defunct Xilinx XC6200. That was much finer-grained and allowed single cell reconfiguration. Unfortunately, it was too small to be useful, and was really just an experiment by Xilinx.
As far as 1000s of reconfigurations per second... not so, unless they have 1000s of FPGAs.
Re:Other groups working on similar stuff
on
FPGA Supercomputers
·
· Score: 1
Another salient link...
I work with this
group, which is researching adaptive computing from within NASA Goddard.
Re:Probably only faster for simple operations
on
FPGA Supercomputers
·
· Score: 1
You are correct on one count: highly-parallelizable code is great for FPGAs, since we can get much more done per clock cycle.
But, you will get killed in performance on a few counts, at least as far as current FPGA technology is concerned:
a) video processing is generally floating-point. not good for FPGAs since FPGAs are bad at variable-length shifts, which is at the core of floating-point math.
b) integration between the general purpose CPU and the FPGA co-processor is not as tight as, say, a video card.
Thus, you are limited a) by the PCI bus, and b) by any reconfiguration overhead that you may have if you have to time-multiplex configurations into your FPGA.
So, in essence, for something that is very specialized and very performance demanding, such as graphics rendering, you'll most always go straight to regular silicon (ASIC implementation), as your volume will make up for the costs.
Where FPGAs help out most is in their ability to morph into doing many different tasks, since it is reconfigurable. Video processing has a well-defined set of operations (shading, texture mapping, z-buffering, etc. etc..) that need to be supported, so flexibility is second to performance.
Mark
Slashdot Mirror
Cell phones now debit cards in S. Korea
Infrared lifestyle: South Koreans pay using cellphones
Visiting this past summer I saw a similar system in South Korea. The receiver looks like a big black eyeball (think HAL-9000) with a bright blue LED on top. They have these things all over - fast food joints, small markets (think 7-11), and on buses. Just put your phone near it, hit a button, and the charge goes onto your cell phone bill.
Seems like it was getting well adopted. I googled for it, but I can't remember the name exactly.
Yahoo contact info Or just google "yahoo, sunnyvale, ca"
Johns. Yes, with an "s" at the end!
mark
JHU class of 1997
Hrm... how about printing it out and binding it together! Make bunches of copies, send them their separate ways. Oh... a book!
Full blown laptop? Not quite. But try this:
Get a 31xx monoPAQ. Get the compactflash sleeve and the pcmcia sleeve (the latter because it has its own battery). Get a large (5gb) PCMCIA drive (IBM microdrive), a smaller (1gb) CF flash card, a Targus foldable keyboard, a CF 10/100/802.11b card, a PCMCIA 10/100/802.11b card, a PCMCIA Sierra Aircard 510, and a CF vga-out adapter. Find a LCD panel that you like, build a battery pack for it.
Some creative duct taping or plexiglassing and yes sir, you have a Linux-capable computing brick that has a modular power system! Go full-tilt, and you have VGA on a full LCD with a keyboard and your big microdrive. Monitor dies, and you switch back the native screen. PCMCIA battery pack goes down, switch to CF. CF draining you too fast? Switch to internal memory.
If you want to get more creative, try it with the new 38xx series. Has longer battery life and built-in SD so you don't even need a sleeve. Don't forget, for the 31xx and 36xx series ipaqs, you can expand internal memory to 128mb with some creative soldering (read: surface mount).
So let's review your criteria:
1) clear screen: the 36xx has a nice screen, and whatever external LCD you choose could be good.. up to you.
2) decent 2d video: Hrm... well, it runs Quake. You decide.
3) Physical utility: Well, build a padded titanium case for your ipaq and lcd screen. Should be sturdy. Use it as a foot stool.
4) insanely long battery life: modular battery style means you can get long battery life. 12+ hours with the monopaq alone. Since everything else has it's own battery pack (except the CF sleeve), you can mix-n-match. A little creative hackery and you can probably paste an external big battery to the ipaq.
5) networking: 10bt, 100bt, 802.11b wireless, CDPD wireless and CDMA wireless. Sounds good to me.
Sounds fun to me.
Source view:
:>. For CVS-die hards, you can get vaj2cvs, a plug-in that automates all the cvs stuff for you.
Apparently, it was a big gripe in pre-version 3.5. It popped up there around then and is basically a hack, IMHO. Just don't use it, because it really mucks things up. Unfortunately, that's the state of things. I just bury my head in the sand and work method-level. One other bug is that in exporting code to a conventional build+test system, sometimes things get put in the wrong order.. ie. static field declarations AFTER a static class initializer routine. Whups. Source view to the rescue. Otherwise, I don't care how the code looks in flat form.
Versioning:
There is a patch for 3.5.3 (or something like it) pertaining to the external versioning control subsystem. Maybe you should grab it. Yes, it's buggy
Debugger:
Yes, it's confusable sometimes. Remember to SAVE YOUR WORKSPACE before you try and debug a big change. It has saved my arse many a time.
CLASSPATH:
I don't know if this is VAJ or VA/Assist... but in my dev environment right-clicking on the class to run, going to run->check class path... fixes up the class path automagically. Never had a problem.
The WORST thing about VAJ:
Global search and replace for refactoring purposes. Oh boy, can this be trouble. Change a name, it breaks 50 things. Go through and rename those things, and each one recompiles and breaks 10 more. Oh, it's pretty friggin' painful, even with the automated tools from Instantiations. We just ended up exporting to Emacs, making the change, and importing. Worked like a charm!
Mark
True, it could be better of an editor. VaAssist from instantiations gives you better control of the editing environment. But it does take a bunch of time getting used to it. Once you've got 30,000+ lines of code in there, written by a dozen or so people, you start to understand how good it can be at organizing your stuff.
Off-topic, IBM did not write VAJ, OTI (oti.com) did.
So, how the hell did that "'" get in my subject line? Oops. As far as documentation system, VAJ doesn't have anything built in at all except generation of JavaDOC (gee, thanks IBM). But, the plug-in interface lets you write your own tool, or better yet, download/buy one that is already done :>.
The folks at Reliable Systems have a few tools that I've played with that might be useful to you.
iDarwin, iContract, and iDoc may all help you out.
Personally, I'm a convert to VisualAge for Java from IBM. I've used JBuilder, Forte, Together/J, XEmacs, Notepad, VisualCafe, you name it.
VisualAge has a rather steep learning curve associated with it compared to a lot of the IDEs, but it really is the first product that I can recommend for Java coding.
Unique features that I find useful are:
* No files -- just a big 'ol database repository that is managed by VisualAge. There really is no need for files in Java, really, and this makes things great for reorganizing your code and proper versioning.
* Incremental compilation that works with the debugger -- breakpoint your app, change code, continue with new changes.
* Method-atomic units of editing. You edit at the method level instead of the file level. Easier to conceptualize large OO systems as you don't spend time navigating lines and lines of code and various files. Just pick a package, class, and method from a nice hierarchical window system and start coding.
* Semi-open plug-in interface. Write your own little applets to do things to your own code base (fancy search/replace, exporting your code, merging changes...) -- this also means you can download/buy cool add-ons (Instantiations' VA/Assist and JFactor come to mind).
* Good Enterprise team coding system. That repository is pretty good for keeping versions around and keeping things straight between teams of coders. You can also use and SCCI? compliant version control system.
It can be tricky to master at times, but worth it, IMHO. Best of all, you can get a copy for $60 with the book Effective Visualage for Java at your local Barnes and Noble.
Not affiliated--just finally satisfied with an IDE.
Check out this review. Actual model in hand, retail purchased. Buttons fixed as well as screen dust bunnies addressed.
Actually, it ain't that bad Cliff. Just make sure you find a good job.
A rewarding job is paramount in staying happy with what you do. It isn't the CS part, it's what you're doing day in and day out. Honestly, working somewhere that challenges you and produces a fine product will be Much much more fulfilling than the off-by-one errors that you are finding now.
Good luck.
I agree that it is difficult to control where components get placed in an FPGA. But with the sizes of these things getting so big, it is hard to make a design that you will be hand placing and routing. Usually, we let the tools do this for us and just concentrate on the HDL.
:>.
Yes, portability is a big issue, but at least there is the hope of porting between similar architectures (such as between a Xilinx 4000-series and the Virtex series). In the case of ASICs, well, what does portability really mean? It's completely fabrication dependent.
Finally, regarding security of ROM images: I know that Xilinx keeps the format and interpretation of the bitstream proprietary and confidential. This doesn't mean that it is impossible to figure out, just more difficult than inserting a VM and "voila!".
I for one welcome the chance to re-design the processor in my computer
Did anyone else give a little Beavis 'n Butthead style chuckle when they read "... 160 edge nodes (Compaq DNARD Sharks)..."
Nards. Heh... Nard Sharks... Hehh hehhh.
Sure, they're going out of style, but it runs Linux, does MP3, can surf the net, and hell, I think it plays some games too.
Hollywood+. Works with remote as well. Have it set up in my living room with a regular-sized PC and it works well. I use it in addition to my regular standalone DVD player because it will play CDRs with VCD/SVCD/MP3/MPG stuff on 'em as well.
Something that I've been using instead of VNC lately when in the Windows world is Timbuktu Pro. It handles updates better than VNC and seems a bit more responsive. YMMV.
An alternative that I've been using that is small and fast is VirtuaWin [w1.457.telia.com/~u45706979/]
I'm feeling the wireless keyboard/touchpad combo calling to me with this setup. Throw in a Hollywood+ for _decent_ video playback, find a firewire video-input device and voila, quite the all-in-one.
I did some looking into his research a while ago for a seminar talk I did. Hopefully, you'll find it has more technical info than the article: here it is
The other option is the now-defunct Xilinx XC6200. That was much finer-grained and allowed single cell reconfiguration. Unfortunately, it was too small to be useful, and was really just an experiment by Xilinx.
As far as 1000s of reconfigurations per second... not so, unless they have 1000s of FPGAs.
Another salient link ...
I work with this
group, which is researching adaptive computing from within NASA Goddard.
You are correct on one count: highly-parallelizable code is great for FPGAs, since we can get much more done per clock cycle. But, you will get killed in performance on a few counts, at least as far as current FPGA technology is concerned: a) video processing is generally floating-point. not good for FPGAs since FPGAs are bad at variable-length shifts, which is at the core of floating-point math. b) integration between the general purpose CPU and the FPGA co-processor is not as tight as, say, a video card. Thus, you are limited a) by the PCI bus, and b) by any reconfiguration overhead that you may have if you have to time-multiplex configurations into your FPGA. So, in essence, for something that is very specialized and very performance demanding, such as graphics rendering, you'll most always go straight to regular silicon (ASIC implementation), as your volume will make up for the costs. Where FPGAs help out most is in their ability to morph into doing many different tasks, since it is reconfigurable. Video processing has a well-defined set of operations (shading, texture mapping, z-buffering, etc. etc..) that need to be supported, so flexibility is second to performance. Mark