Gary, (01)
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? (02)
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. (03)
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. (04)
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. (05)
Best regards, (06)
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 (07)
Philip Gust
Nouveau Systems, Inc.
3120 De La Cruz Blvd., Suite 120
Santa Clara, CA 95054 (08)
phone: +1 650 961-7992
fax: +1 520 843-7217 (09)
mailto: gust@NouveauSystems.com (010)
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 (011)
_________________________________________________________________
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 (012)
|