 | | Re: Some comments (long)
|
|
(...) Absolutely. What I have in mind is that the basic level of access is to the raw sensor value of the A/D converter and whether it is active or passive. The interpretation of that value would be done by other classes. For example, I would like (...) (26 years ago, 6-May-99, to lugnet.robotics)
|
| |
| | Re: Some comments (long)
|
|
(...) You have reiterated exactly what I expected would be one of the most popular reasons to want to implement a JVM for the RCX. I hope you don't think I'm against what you're attempting to do... it's just that I, like Kekoa, believe that the (...) (26 years ago, 6-May-99, to lugnet.robotics)
|
| |
| | Re: Some comments (long)
|
|
(...) Remember that Java's origins came from Oak, which was intended to operate a Universal remote control. JVM runs on many very tiny computers, and I am certain that a large subset of Java can be made to fit on the RCX and be a usable product. (...) (26 years ago, 6-May-99, to lugnet.robotics)
|
| |
| | Re: Some comments (long)
|
|
(...) Not that I disagree with the elegance of being able to define a class that implements a new way of reading a sensor; however, I thought I'd point out two issues you might want to consider: First, the ROM already contains a significant amount (...) (26 years ago, 6-May-99, to lugnet.robotics)
|
| |
| | Re: Some comments (long)
|
|
(...) Unfortunately, the ROM code (as I understand it) does not implement any mechanism other than polling. I would like to do things like block a thread until a sensor value matched some criteria. The only efficient way to do that is to have the (...) (26 years ago, 6-May-99, to lugnet.robotics)
|
| |
| | Re: Some comments (long)
|
|
(...) What is your point? If you want to make sense of the raw values, and want to leverage the ROM code to process the existing sensor types/modes, you need to call a ROM sensor-processing function every time an a/d completes. That was the point I (...) (26 years ago, 6-May-99, to lugnet.robotics)
|
| |
| | Re: Some comments (long)
|
|
(...) Obviously you have spent much more time deciphering the ROM than I have. I wasn't aware that the ROM supported native threads, only multiplexing the bytecode streams it executed. How can replacement firmware hook into this sensor-processing (...) (26 years ago, 6-May-99, to lugnet.robotics)
|
| |
| | Re: Some comments (long)
|
|
(...) I've mislead you. The ROM does not support native threads. The firmware simulates cooperative threads. The firmware selects one of six functions to run based on priority and whether or not a run flag has been set for that function. The run (...) (26 years ago, 6-May-99, to lugnet.robotics)
|
| |
| | Re: Some comments (long)
|
|
(...) I didn't answer your question with the last message. The ROM does not execute byte codes, the firmware does. The firmware multiplexes between byte codes. I'm not sure what you mean by how can replacement firmware hook into the sensor (...) (26 years ago, 6-May-99, to lugnet.robotics)
|
| |
| | Re: Some comments (long)
|
|
(...) Thanks, I think I understand how it works. John A. Tamplin Traveller Information Services jat@LiveOnTheNet.COM 2104 West Ferry Way 256/705-7007 - FAX 256/705-7100 Huntsville, AL 35801 -- Did you check the web site first?: (URL) (26 years ago, 6-May-99, to lugnet.robotics)
|
| |
| | Re: Some comments (long)
|
|
(...) For the record, up until recently I agreed with you. However, after hearing further discussions I think it is possible. The biggest hurdle is probably garbage collection since this is what causes Java's propensity to "gobble" memory. The class (...) (26 years ago, 7-May-99, to lugnet.robotics)
|
| |
| | Re: Some comments (long)
|
|
(...) This is FUD. What causes Java to gobble memory is more likely (a) the amount of header overhead it places on objects (more to do with hashing support than gc, I suspect) and (b), to a lesser extent, the fact that objects are never "expanded" (...) (26 years ago, 8-May-99, to lugnet.robotics)
|
| |
| | Re: Some comments (long)
|
|
(...) Java is not particularly space efficient (in typical implementations) for several reasons: 1) value stacks are stored as a union of all the types you can store in a variable, so you eat up at least 32 bits (64 on an implementation supporting (...) (26 years ago, 8-May-99, to lugnet.robotics)
|
| |
| | Re: Some comments (long)
|
|
(...) Sure: one aspect of the "expanded" issue. (...) Well, dynamic loading, not late binding; this stuff would not be on the RCX - presumably almost all of the class loader remains on the host machine, with downloaded code pre-linked and (...) (26 years ago, 8-May-99, to lugnet.robotics)
|
| |
| | FWD: Re: Some comments (long)
|
|
(...) In environments which provide general purpose pointer types which can be assigned to addresses of explicitly allocated memory (like C and C++), garbage collection becomes an NP-hard problem. In environments which have no end-user accessible (...) (26 years ago, 8-May-99, to lugnet.robotics.rcx)
|
| |
| | Re: Some comments (long)
|
|
(...) Hmmm... I guess I have to explain every little word I write so as not to get flamed. People fear Java on a small memory platform because when they run a JVM for any length of time on their Wintel boxes they see it slowly "gobble" more and more (...) (26 years ago, 9-May-99, to lugnet.robotics)
|
| |
| | Re: Some comments (long)
|
|
Let's move this discussion to lego-robotics-rcx, since that group was created for discussions like these. (...) Late binding requires the symbol table or some representation of the same thing. For example, you have C inheriting from B inheriting (...) (26 years ago, 10-May-99, to lugnet.robotics)
|
| |
| | .rcx alternative firmware group/list
|
|
(...) John and several other people are set up with the new group and successfully posting to it, so this info is for anyone else: lugnet.robotics.rcx is a newsgroup running on the lugnet.com newsserver and it is available via e-mail as (...) (26 years ago, 10-May-99, to lugnet.robotics, lugnet.admin.general)
|
