 | | Some comments (long) (was: Something else is needed, I think...)
|
|
I think that what may actually be the best thing for the RCX in terms of a new bytecode interpreter is one which is virtually a plug-in replacement for the old one. I've been doing some extensive mulling over the RCX internals documentation so (...) (25 years ago, 6-May-99, to lugnet.robotics)
|
| |
| | Re: Some comments (long)
|
|
(...) <snip> Mark and John's messages this morning look like the beginnings of two separate developments for the RCX, both of which have the potential to satisfy the needs of many who are dissatisfied with the current firmware. Hopefully both ideas (...) (25 years ago, 6-May-99, to lugnet.robotics)
|
| |
| | Re: Some comments (long)
|
|
(...) I was wondering if any of these projects is thinking in providing enough flexibility that would make possible for anyone smoothly integrate new sensors with the currently supported ones? (Like Dennis Clark's RCX IRPD?) Sorry to return to this, (...) (25 years ago, 6-May-99, to lugnet.robotics)
|
| |
| | Re: Some comments (long)
|
|
(...) My request to both groups is: don't go 'off-list' until you have a feature spec that was formed with feedback from the whole list. It would be a shame for you to finish development of a tool that no one else uses. -Wes (25 years ago, 6-May-99, to lugnet.robotics)
|
| |
| | 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 (...) (25 years ago, 6-May-99, to lugnet.robotics)
|
| |
| | Some more comments and suggestions.
|
|
(...) I concur with this opinion. I realize that the subject may be a bit prevalent right now but the alternative would be to develop a separate list for alternative firmware discussion, and I don't know how viable that would be. What follows is a (...) (25 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 (...) (25 years ago, 6-May-99, to lugnet.robotics)
|
| |
| | Re: Some comments (long)
|
|
So to preface my comments to Mark's message, I should say that even though I point out technical problems with what he proposes, I do not mean to imply that these technical problems cannot be overcome. (...) There are some technical issues that (...) (25 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. (...) (25 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 (...) (25 years ago, 6-May-99, to lugnet.robotics)
|
| |
| | Re: Some comments (long)
|
|
(...) Could you explain what you mean by this, exactly? I would have figured that if a new interpreter is designed from scratch, the lengths of the opcodes could be hard-coded into the interpreter in some way. I was not suggesting that any existing (...) (25 years ago, 6-May-99, to lugnet.robotics)
|
| |
| | Re: Some comments (long) (was: Something else is needed, I think...)
|
|
Mark Tarrabain wrote in message <3730DE97.EFB3BF9A@l....bc.ca>... (...) It is probably true that a floating-point library cannot (should not?) be built into the firmware. It would probably be better for this to be supported by the compiler(s). But (...) (25 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 (...) (25 years ago, 6-May-99, to lugnet.robotics)
|
| |
| | Re: Some comments (long)
|
|
(...) Assuming you use the ROM to receive things, which would be prudent in terms of space but not strictly necessary, the lengths of the opcodes in the message receiving code are determined by the lowest three bits of the opcode: 0 means length 0, (...) (25 years ago, 6-May-99, to lugnet.robotics)
|
| |
| | Re: Some comments (long) (was: Something else is needed, I think...)
|
|
Some comments on what Chris Phillips wrote: - as far as I know, you will not be able to implement floating point in byte code, it will be too inefficient (mostly in terms of space) - agreed, current firmware does not support fixed point well, and it (...) (25 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 (...) (25 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 (...) (25 years ago, 6-May-99, to lugnet.robotics)
|
| |
| | Re: Some more comments and suggestions.
|
|
(...) That's a good pseudo-question. It would actually be quite easy to set up a focused group/list for this, as has been done for legOS, NQC, and pbFORTH; the viability is only dependent on the interest in having more room to breathe. Anything (...) (25 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 (...) (25 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 (...) (25 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) (25 years ago, 6-May-99, to lugnet.robotics)
|
| |
| | Re: Some comments (long) (was: Something else is needed, I think...)
|
|
Kekoa Proudfoot wrote in message ... (...) Do you think it would be possible with improved firmware to support inline H8 code embedded in a user program? For example, a special byte code could indicate that the following code should be executed (...) (25 years ago, 6-May-99, to lugnet.robotics)
|
| |
| | Re: Some more comments and suggestions.
|
|
Well, now that you mention it... lugnet.robotics.rcx.misc might be the best way to go. That seems to have the most consistency with existing groups. If that group's discussion splinters considerably, then new groups could be created in the l.r.r.* (...) (25 years ago, 6-May-99, to lugnet.robotics)
|
| |
| | Re: Some comments (long) (was: Something else is needed, I think...)
|
|
(...) Good idea! I like it! The only problem I can see with this is I'm not sure if the H8 supports position independant code or not. If it does, then there's no problem. (...) (25 years ago, 6-May-99, to lugnet.robotics)
|
| |
| | Re: Some comments (long) (was: Something else is needed, I think...)
|
|
(...) You might be able to do this if you were clever about it; you might be able to define an opcode that defines a native subroutine that you can call with another opcode, say, that passes in 16- or 32-bit values in registers and expects you store (...) (25 years ago, 7-May-99, to lugnet.robotics)
|
| |
| | Re: Some comments (long) (was: Something else is needed, I think...)
|
|
(...) I should clarify this. The 16-bit software multiply takes two 16-bit numbers and stores their product in a 16-bit number. The 32-bit software multiply takes two 32-bit numbers and stores their product in a 32-bit number. The operations are (...) (25 years ago, 7-May-99, to lugnet.robotics)
|
| |
| | Re: Some comments (long)
|
|
(...) At the risk of splintering the development efforts here from 2 to three, I've been wondering the same thing. I guess I'm not as concerned with ensuring that my existing OCX code works - I'd rather see any new OS make the RCX "be all that it (...) (25 years ago, 7-May-99, to lugnet.robotics)
|
| |
| | Re: Some comments (long)
|
|
(...) There are no limitations in LegOS at all that I am aware of. The biggest problems with LegOS are the size of and number of tools required work with it and the learning curve for people who don't have any prior programming experience (let alone (...) (25 years ago, 7-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 (...) (25 years ago, 7-May-99, to lugnet.robotics)
|
| |
| | Request for new list
|
|
I request that the discussions of alternate firmware implementation details go into their own newsgroup now. Discussions about features can be crossposted to both lists. There were several requests recently to create a new group for newbies to (...) (25 years ago, 7-May-99, to lugnet.robotics)
|
| |
| | group lugnet.robotics.rcx created
|
|
[Crossposted to lugnet.robotics & lugnet.announce; followups set to lugnet.robotics & lugnet.robotics.rcx] All right -- better late than never... A new group lugnet.robotics.rcx has been created, and is there now for anyone wants to jump in and use (...) (25 years ago, 7-May-99, to lugnet.robotics, lugnet.announce)
|
| |
| | Would-be hacker queries. / Re: Request for new list
|
|
Hi. Hope I can jump in here and ask where a newby who knows he's in the deep end in computer science discussions, - knows he's taking in water, coughing and spluttering but loving every minute of it - go to ask elementary questions like: What's a (...) (25 years ago, 8-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" (...) (25 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 (...) (25 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 (...) (25 years ago, 8-May-99, to lugnet.robotics)
|
| |
| | Re: Would-be hacker queries. / Re: Request for new list
|
|
(...) I'm going out of town and have to run for the bus ayt any moment, so I'm afraid I don't get to answer your questions. But a quick comment to those who are contemplating what the New Environment should be: You see? Not everyone out there wants (...) (25 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 (...) (25 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 (...) (25 years ago, 9-May-99, to lugnet.robotics)
|
| |
| | Re: Would-be hacker queries. / Re: Request for new list
|
|
Valid questions, all of them. We do tend to remain in the upper ranks of CS on this list. I'll see if I can take a stab at defining some terms quickly and clearly. BTW, I wouldn't mind adding my knowledge of CS to a FAQ for newbies. Mindstorms will (...) (25 years ago, 9-May-99, to lugnet.robotics)
|
| |
| | Re: Would-be hacker queries. / Re: Request for new list
|
|
(...) I have never said that everyone wants or needs Java. I am quite certain that no single platform of any type will please all of the people all the time. As I have said repeatedly here, I think choosing Java minimizes the total work required to (...) (25 years ago, 10-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 (...) (25 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 (...) (25 years ago, 10-May-99, to lugnet.robotics, lugnet.admin.general)
|
