Gary, (01)
I hope that things aren't as hectic for you now. I'm planning out the
next couple weeks of work on the project, and wanted to know when you
might have the detailed technical proposal and quote ready. I'd like
to include this information in the proposal to SRI. Also, please let
me know whether my latest responses made sense, or whether we should
try to have a live conversation to hash out these technical
points. I can be available nearly any time at your convenience. (02)
At 03:59 PM 4/7/2006, Philip Gust wrote:
>Gary,
>
>Thanks for the update. Customers can be such pesky creatures!
>
>At 02:58 PM 4/7/2006, Gary Oliver wrote:
> >Unfortantely I have exhausted my time this week. We had an unscheduled
> >visit from a customer that took an extra three days this week and I just
> >ran out of time. I have most of what I need to finish a quote, but
> >haven't yet been able to meet with the design engineer responsible for
> >the electronics. It will be the first thing I do next week.
> >
> >Regarding your questions about the USB cabling and switching: Our
> >current plans are for a single cable from the device to the computer.
> >This can be accomplished using an internal physical hub (ic) or through
> >a software "hub", depending on the choice of devices used to implement
> >the USB. My understanding is that you want to plug a mouse into the
> >device and the device into the computer. This will require the device to
> >accept an HID input mouse connection and then route the data as
> >appropriate to either the internal state machine or through to the
> >computer over the mouse "device" on the "hub." Your description of a
> >"num lock" would imply we also plug in a normal keyboard? Or are you
> >referring to a keyboard action on the chording device?
>
>On switching keyboard modes, we'd have to find an unused chord /mouse
>combination to switch between standard and Augment
>modes. Unfortunately, there are very few combinations that are not
>already used by Augment (e.g. Keyset: XXXXX, Mouse: 00X, or Keyset
>:?????, Mouse: 110 or 111 -- see
>http://chm.cim3.net/cgi-bin/wiki.pl?NlsTechnical/KeysetMap). I had
>envisioned some kind of separate non-transmitting toggle button
>(similar to the NUM LOCK on a standard keyboard) to control this only
>to make switching more obvious for users.
>
>My reference to allowing the mode to be toggled in software was based
>on my understanding of standard keyboards, where the computer can
>send commands to the keyboard, such as turning on the NUM
>LOCK. Sorry that I didn't make that clear. I hadn't intend to add
>reading input from a standard keyboard into the mix. This is
>completely optional. A typical use case for this capability might be
>to have The AugTerm application toggle this on/off when it
>gains/looses focus. No big deal, though, to have the user toggle
>this manually.
>
>For the standard keyboard, we'll also need to determine whether and
>how to map chords/buttons to standard keys and combinations that
>aren't possible otherwise, such as the control characters, edit keys,
>etc. One idea would be to adopt Microsoft's keyboard conventions for
>physically impaired users, such as sticky shift, etc. Jonathan and I
>will discuss this issue when we meet next week. What ideas can you suggest?
>
>On the
>
> >Our interpretation from John was that we wanted to be able to filter
> >mouse "keystrokes" as hints to the operating mode of the device. I
> >wasn't aware we would need to interpret keyboard strokes as well.
> >
> >I do think it would be "cleaner" to avoid adding extra switches, so long
> >as we can nail down what switch "gestures" we want to enable the
> >appropriate state changes.
> >
> >
> >Sorry for the delay. I realize this is crunching things for you.
> >Unfortuantely, I no control over the scheduling of things this week and
> >it all piled up after I promised an end-of-week to you. I'll get the
> >info to you as soon as I can.
> >
> >-Gary
> >
> >Philip Gust wrote:
> >
> > > Gary,
> > >
> > > Thanks for the update. Your description matches what we had in mind
> > > for the keyset. I'm assuming that there would be a single USB cable
> > > going from the unit to the computer. On the switch that controls which
> > > mode the unit is in, we could obviously add a physical switch to the
> > > unit. It might also be useful to be able to turn this on
> > > programmatically, either by reinterpreting an existing lock (e.g. num
> > > lock) command or by defining a new one. Do you have any thoughts about
> > > this?
> > >
> > > As I mentioned to John, we have been invited to make a formal proposal
> > > to SRI to fund the development work for the reproduction keyset. This
> > > would be done to coincide with SRI's 50th anniversary in October. I'd
> > > like to have a proposal in to them with detailed technical specs by
> > > April 15th or so your timing is great.
> > >
> > > Provided that SRI approves funding, we'll need to discuss production
> > > requirements to determine how large our initial run should be and
> > > project total requirements. It's really hard to say at this point. It
> > > may be a limited run of 25-50 for use by the communities involved in
> > > the historical and new Hyperscope work. On the other hand, it could
> > > catch the public fancy and several groups including SRI and CHM might
> > > decide to distribute them in their stores, in which case the run might
> > > be more like 250-500. It doesn't even make sense to take the outside
> > > temperature unless SRI agrees to fund the the development work and we
> > > decide the best way to float the cost of the first production run.
> > > Hopefully we'll have a much better idea by mid-May.
> > >
> > > Thanks again, and I'll look forward to seeing your proposal. If you
> > > want to talk in real-time, don't hesitate to give me a call.
> > >
> > > Best regards,
> > >
> > >
> > > At 02:12 AM 4/4/2006, Gary Oliver wrote:
> > >
> > >> Philip,
> > >>
> > >> John Sechrest and I have been talking about the technical needs
> > >> for your project and we are close to having a quotation ready for
> > >> you that will cover the mechanical and electronic requirements.
> > >>
> > >> Basically our understanding is:
> > >>
> > >> The keyboard unit needs to supply standard "human interface"
> > >> USB class connections and be able to multiplex a common USB
> > >> mouse into the data stream. An internal hub will provide the
> > >> mouse/keyboard multiplexing, with some local logic to redirect
> > >> the mouse inputs through the control processor handling the
> > >> keyboard functions.
> > >>
> > >> In one mode, the keyboard and mouse would be separate entities,
> > >> with mouse event going through untouched. In another mode,
> > >> the mouse buttons would be intercepted and used to augment
> > >> the code sequence generated by the keyboard.
> > >>
> > >> This will require a small microprocessor with can act as both an
> > >> HID input (for mouse redirection) and 2 HID outputs (to provide
> > >> the keyboard and optional mouse channels.) It is unclear
> > >> whether we would use an outboard steering logic to make the
> > >> mouse pass through or to always process it in the
> > >> microprocessor and pass it through "logically".
> > >>
> > >> After we finish parts definition and a preliminary circuit board
> > >> design, we'll send it along for your consideration. We should be
> > >> able to get this to you by the end of the week.
> > >>
> > >> Regards,
> > >> Gary Oliver
> > >> go@ao.com
> > >> 541-754-1911
> > >>
> > >> Philip Gust wrote:
> > >>
> > >> > John,
> > >> >
> > >> > I'm following up with you about a quote for the NRE and production
> > >> > costs to create a new batch of keysets. Will you be able to get us
> > >> > something this week?
> > >> >
> > >> > At 04:08 PM 2/12/2006, Philip Gust wrote:
> > >> >
> > >> >> At 03:11 PM 2/12/2006, John Sechrest wrote:
> > >> >>
> > >> >>
> > >> >>> Philip Gust <gust@NouveauSystems.com> writes:
> > >> >>>
> > >> >>> % > One of the places we got stuck was the need for a driver to
> > >> >>> % > coordinate the 5 bits from one keyboard with the 3 bits of the
> > >> >>> mouse.
> > >> >>> % > That was something that we did not process very well.
> > >> >>>
> > >> >>> % I'm a little confused by it myself. We wrote some specialized Java
> > >> >>> % code that processed input from the keyset, and allowed Java to
> > >> >>> % perform its normal mouse handling. I imagine that the same
> > >> would be
> > >> >>> % done for any other programming language. It's not clear what the
> > >> >>> % advantage would be of combining keyboard and mouse handling into a
> > >> >>> % single driver, especially in a windowed environment.
> > >> >>>
> > >> >>> Appearently NLS used the three mouse keys as modifiers,
> > >> >>> so you could get 8 states from the right hand to modify
> > >> >>> key stroke on the left hand...
> > >> >>>
> > >> >>> so if you have
> > >> >>>
> > >> >>> 10110 000
> > >> >>> 10110 100
> > >> >>> 10110 010
> > >> >>> 10110 001
> > >> >>>
> > >> >>> The the five keys on the left are generating different keys based
> > >> >>> on the keys on the right side.
> > >> >>
> > >> >>
> > >> >> I can see how there may be advantages to combining mouse and keyboard
> > >> >> input into a single driver. That way it can be used with any
> > >> >> application. The challenge I can foresee is trying to do that under
> > >> >> multiple OSes and their window system environments, and making it
> > >> >> user or application configurable. It would also be nice for such a
> > >> >> driver provide a way to emulate a keyset/mouse combo using a standard
> > >> >> keyboard/mouse with an appropriate modifier (similar to an embedded
> > >> >> numeric keypad using the numlock key)
> > >> >>
> > >> >> Up to now we've been treating the "vintage" keyset as an auxiliary
> > >> >> input device, and allowing the AugTerm application to read the device
> > >> >> through a set of APIs and interpret keypad/mouse input. For example,
> > >> >> on Linux, the vintage keypad appear as a USB joystick and we read it
> > >> >> through /dev/input/js0. The advantage is that we can leverage
> > >> >> existing drivers on various OSes.
> > >> >>
> > >> >> There's also a separate question of what type of USB device the
> > >> >> keyset should identify itself as, and if that should be one of the
> > >> >> standard types then which one.
> > >> >>
> > >> >>
> > >> >>
> > >> >>
> > >> >>> % > It is possible that Gary might be persuadable to do it off the
> > >> >>> clock.
> > >> >>> % > However, I do not see that happening on the time schedule you
> > >> >>> % > are laying out. I will ask gary tomorrow if the things that he
> > >> >>> % > is interested in stepping up to this project by end of May or
> > >> >>> % > not.
> > >> >>>
> > >> >>> % Thanks for taking this to them. There are certain promotional
> > >> >>> % opportunities that AO might be able to take advantage of were
> > >> it to
> > >> >>> % do this on a pro-bono basis. However, I understand about the
> > >> funding
> > >> >>> % issue as well.
> > >> >>>
> > >> >>> Yes, there are some wins.
> > >> >>>
> > >> >>>
> > >> >>> % In that case, could you find out what it would cost
> > >> >>> % to get something ready to bid out for manufacturing in May or
> > >> June by
> > >> >>> % completing the hardware and electrical design, and building a
> > >> >>> % prototype?
> > >> >>>
> > >> >>> Yes, I can get Gary to put together a quote for putting together
> > >> >>> 12 units. Is that the number that you want?
> > >> >>
> > >> >>
> > >> >> I'd suggest breaking the quote down into two parts. One is the NRE
> > >> >> required to get it ready for manufacturing. The other is the cost of
> > >> >> manufacturing certain numbers of units. It's hard to say how many we
> > >> >> may need over time. As more people use the restored NLS/Augment
> > >> >> system or the next generation system being planned, they may want to
> > >> >> have a keyset. Some people may also want one purely as a collectable.
> > >> >> In that case, we would like to be able to sell them one. I recommend
> > >> >> quoting an initial 12, and then incremental units of 48 keysets (or
> > >> >> whatever volume makes sense).
> > >> >>
> > >> >>
> > >> >>
> > >> >>> % We can probably get someone to do the drivers on a
> > >> >>> % volunteer basis if you can take care of the hardware end. I'd
> > >> expect
> > >> >>> % that if we found funding, this would be work for hire that
> > >> would be
> > >> >>> % whoever funded it.
> > >> >>>
> > >> >>>
> > >> >>> You will have to help me constrain the project some.
> > >> >>> Do you want us to replicate directly what is there?
> > >> >>> or do you want us to make some optimization for price?
> > >> >>> Or do you want us to make any evolutionary steps for it?
> > >> >>
> > >> >>
> > >> >> Optimizing for price would be fine. It would be great if we could
> > >> >> retain the look and feel of the original, for those who may want one
> > >> >> as an historical artifact. No need, though, to go through the effort
> > >> >> of a 15-pin analog output that must be converted to a game port and
> > >> >> again to a USB interface, for example. As to what type of USB device
> > >> >> it would appear as, we'll need to get a bit of a technical discussion
> > >> >> going on that.
> > >> >>
> > >> >>
> > >> >>
> > >> >>
> > >> >>
> > >> >>> % I'll hope to hear from you again in the next few days.
> > >> >>>
> > >> >>> I will talk to gary on monday and try to have you some
> > >> >>> details with in a day or so.
> > >> >>
> > >> >>
> > >> >> Thanks!
> > >> >>
> > >> >>
> > >> >>> -----
> > >> >>> John Sechrest . Helping people use
> > >> >>> . computers and the Internet
> > >> >>> . more effectively
> > >> >>> .
> > >> >>> . Internet: sechrest@peak.org
> > >> >>> .
> > >> >>> . http://www.peak.org/~sechrest
> > >> >>
> > >> >>
> > >> >>
> > >> >> Philip Gust
> > >> >> Nouveau Systems, Inc.
> > >> >>
> > >> >> phone: +1 650 961-7992
> > >> >> fax: +1 520 843-7217
> > >> >>
> > >> >>
> > >> >> mailto: gust@NouveauSystems.com
> > >> >
> > >> >
> > >> >
> > >> > Philip Gust
> > >> > Nouveau Systems, Inc.
> > >> >
> > >> > phone: +1 650 961-7992
> > >> > fax: +1 520 843-7217
> > >> >
> > >> >
> > >> > mailto: gust@NouveauSystems.com
> > >
> > >
> > >
> > > Philip Gust
> > > Nouveau Systems, Inc.
> > > 3120 De La Cruz Blvd., Suite 120
> > > Santa Clara, CA 95054
> > >
> > > phone: +1 650 961-7992
> > > fax: +1 520 843-7217
> > >
> > > mailto: gust@NouveauSystems.com
> > >
> > > Nouveau Systems products seamlessly integrate collaboration,
> > > information management, processes automation, and capture of
> > > mission-critical knowledge. To learn how Nouveau Systems products can
> > > help your organization drive innovation, visit:
> > > http://www.NouveauSystems.com
> > >
>
>
>Philip Gust
>Nouveau Systems, Inc.
>3120 De La Cruz Blvd., Suite 120
>Santa Clara, CA 95054
>
>phone: +1 650 961-7992
>fax: +1 520 843-7217
>
>mailto: gust@NouveauSystems.com
>
>Nouveau Systems products seamlessly integrate collaboration,
>information management, processes automation, and capture of
>mission-critical knowledge. To learn how Nouveau Systems products
>can help your organization drive innovation, visit:
>http://www.NouveauSystems.com
>
>
>
>_________________________________________________________________
>Message Archives: http://chm.cim3.net/forum/nls-technical/
>Shared Files: http://chm.cim3.net/file/work/project/nls-restore/
>Community Portal: http://www.computerhistory.org/
>To Post: mailto:nls-technical@chm.cim3.net
>Community Wiki: http://chm.cim3.net/cgi-bin/wiki.pl?NLS_Restoration (03)
Philip Gust
Nouveau Systems, Inc.
3120 De La Cruz Blvd., Suite 120
Santa Clara, CA 95054 (04)
phone: +1 650 961-7992
fax: +1 520 843-7217 (05)
mailto: gust@NouveauSystems.com (06)
Nouveau Systems products seamlessly integrate collaboration,
information management, processes automation, and capture of
mission-critical knowledge. To learn how Nouveau Systems products
can help your organization drive innovation, visit:
http://www.NouveauSystems.com (07)
_________________________________________________________________
Message Archives: http://chm.cim3.net/forum/nls-technical/
Shared Files: http://chm.cim3.net/file/work/project/nls-restore/
Community Portal: http://www.computerhistory.org/
To Post: mailto:nls-technical@chm.cim3.net
Community Wiki: http://chm.cim3.net/cgi-bin/wiki.pl?NLS_Restoration (08)
|