Scout support in NQC -------------------- LEGO has introduced a number of new (and useful) extensions in the Scout. Taking full advantage of these within NQC is going to take some work. However, adhering to the "release early, release often", I've decided to release a version of NQC with very preliminary Scout support. Currently, many of the Scout features must be manually invoked from within NQC, and there are a few things that aren't supported at all. Future releases will improve this. * The -TScout option can be used to inform NQC that it should target (and/or download to) a Scout. Downloading will only work if the Scout is in "power mode". ************************************************************************** * The Scout API is very preliminary. It will change. A lot. Anything * you write today probably won't compile two months from now. You've been * warned. ************************************************************************** Why so preliminary? Simple...nobody has much experience using the Scout from within NQC. The RCX API evolved over many months (including a good amount of use by myself before NQC was ever posted). I'm looking for feedback on the names for the different API calls and/or constants. I want to keep the names consistent with the RCX API as much as possible, but also make sure that the resulting functions seem intuitive from a Scout perspective. Here are the Scout API calls (listed with their Scout SDK mnemonic) cntd DecCounter(counter) cnti IncCounter(counter) cnts SetCounterLimit(counter, limit) cntz ClearCounter(counter) event Event(eventMask) gdir GSetDirection(outputs, direction) gout GSetOutput(outputs, mode) gpwr GSetPower(outputs, power) light SetLight(mode) lsbt LSBlink(time) lscal LSCal() lsh LSHyst(hysteresis) lslt LSLower(cutoff) lsut LSUpper(cutoff) playv PlayTone(note, duration) rules Rules(m,t,l,time,fx) scout Scout(mode) setfb SetFeedback(fb) setp SetPriority(p) sound Sound(mode) tmrs SetTimerLimit(timer, limit) vll VLL(value) There are also global versions of the standard NQC output calls: GOn, GOff, GFloat, GToggle, GFwd, GRev, GOnFwd, GOnRev, GOnFor If you want to read one of the counters, use Counter(n) (just like reading a timer for the RCX)... x = Counter(0); // read counter 0 into variable x Variables present some new problems. Scout has global variables (just like the RCX) and "local" variables. The locals are pretty useful, and it will take a good deal of work to get NQC to support them fully. In the meantime, NQC simply makes use of the 10 globals and leaves all of the locals alone. You can use them manually with the "local(n)" expression where "n" is a value between 0 and 7 inclusive. For example, to set the first local variable to the value 123, you'd do this: local(0) = 123; This is particularly useful for calling the built in subroutines which expect parameters in certain local locations. NQC doesn't really know about the subroutine library, so you can't call them like you call user subroutines. Instead, use "Call(n)" where "n" is the subroutine number: Call(3); // call subroutine 3 Both the local() and Call() macros are hacks. Real support will follow later on. I've added some really crude support for events in the form of the WaitEvents() function. You pass it an event mask and control waits at that point until one of the specified events happens. ----------------------- Pending Issues for Future Releases A) Consistent mnemonics for listings. Scout-style mnemonics are being used, however there are still some RCX-only functions using my old mnemonics. B) Full support for resource acquisition, events, and loops (decvjn, decvjnl, monal, monax, mone, monel, and monex bytecodes). This will probably involve new syntax, and I'd love to hear some suggestions. C) Use short forms of branches where possible (this will save program space) D) Full utilization of locals E) Calling of library subroutines with normal call syntax (including parameter lists for the arguments). F) Better names for the various API functions. What should the output functions be called? Is is ok to just prepend "G" to the standard ones, or does this look hideous? What about the light sensor calls? LSxxx is pretty ugly. Any ideas? In general, feel free to suggest names for some or all of the API functions. G) Support for all of the different data sources (listed in the SDK). All that's really needed here is good names for each of them.
