68HC11 Simulator Toolbox 2.0 serial key or number
68HC11 Simulator Toolbox 2.0 serial key or number
cooljeanius/cromwellpsi.com
Serial Communications
updated
Contents:
see also local pages
- robot_cromwellpsi.com for info on serial EEPROMS, serial DACs, and other serial chips robot_cromwellpsi.com#serial_memory
- VLSI cromwellpsi.com for info on designing new, high-speed and/or low-power communication links.
- machine_cromwellpsi.com for information on infrared communication. [FIXME: move spread-spectrum and other 1D stuff here; leave low-level details of infrared light and high-level stuff 2D barcode there what about 1D barcodes ? They're undeniably ``machine vision'', yet very serial in nature.]
Communication standards
standard protocols
- cromwellpsi.com (pointers to the Hayes AT command set for modems, the RSc standard, the RS standard, the CCITT Group 4 fax standard, and several file transfer protocols). [FIXME: last time I checked, left out any mention of S11 -- perhaps give them the pointers below ?]
- cromwellpsi.com~chim/modemstuff/chapterhtml# has lots of details on the "S" registers, including the S11 DTMF Dialing Speed register. For example, S11= sets the DTMF pulse time to milliseconds and the time between pulses to milliseconds.
- cromwellpsi.com also documents S
- cromwellpsi.com~kae/faq/connecting/general/cromwellpsi.com claims that the minimum value for S11 is 50 ms, which seems incorrect -- my modem works fine with S11=[FIXME]
- Protocols/Standards/Guides cromwellpsi.com#LINKIN_
- Controller Area Network (CAN) #can
- Standard for Sensor Transducer Interface cromwellpsi.com
IEEE P (TM), "Standard for a Smart Transducer Interface for Sensors and Actuators; Common Functions, Communication Protocols, and Transducer Electronic Data Sheet (TEDS) Formats," will be a new standard containing a common set of functions, communications protocols and TEDS formats for various physical communications media. It will aid interoperability among IEEE (TM) standards and simplify the creation of standards for different physical layers.
protocol_considerations
If you design a new serial protocol, here are some ideas and suggestions you may want to consider:
- Say your receiver is busy for a few microseconds and drops a character or two. You might be able to check for a FIFO buffer overrun hardware flag.
- When you turn on a device, how does it know when to start talking ? Who talks first ?
- The bit-synchronization problem:
When a receiver is first turned on, how does it know where one transmitted bit ends and the next starts ? Also, what is the bit rate ? Pretty simple for clean RS (and most other hard-wired communications hardware) where you can just watch the edges; more difficult when there is noise (as in nearly all wireless hardware).
Often dedicated hardware synchronizes things to the nearest byte; then higher-level protocols in software deal with frame synchronization.
- The frame-synchronization problem:
Say the device that is *supposed* to talk first starts talking, but the other device doesn't get turned on until the middle of a "sentence". How does the receiver know to throw away the (incomprehensible) rest of the "sentence", and re-synchronize at the start of a new sentence ? (Same thing applies to buffer overrun).
Typically one re-synchronizes by transmitting a unique byte sequence (a "header" or "start-of-message") that will not (or "probably will not") be embedded in the middle of a sentence.
Including the newline and/or carriage return ( suggested by Dmitri Katchalov Date: 27 Jan ) in this byte sequence helps make it more human-readable.
- Robert Morris cromwellpsi.com~rtm/ claims that ``the Grid routing protocol lets collections of radio-equipped nodes automatically configure their own cooperative network, without relying on any pre-installed infrastructure.'' He also suspects ``a power-saving scheme for an ad-hoc net, that allows radio receivers to spend most of their time turned off. [perhaps] elect one node per region to buffer messages, so that other nodes can wake up from time to time and poll. Batch traffic, use geo routing to improve batching effectiveness by favoring batching over shortest path. Overall point: we will actually save you battery power, so don't worry about battery used by forwarding for others.'' [FIXME: link to low-power electronics]
- cromwellpsi.com~mdileo/ ``The Tiny Embedded Network is an Open Protocol I designed to interconnect embedded devices in a local area network. The protocol specifications are free and open and I plan to make available the basic routines as well.'' Is this a power + data bus ? Lots of other PIC stuff. [FIXME: PIC]
- CO's Fundamental Dicta(TM) cromwellpsi.com~chris/cromwellpsi.com lists lots of protocol design tips, including:
- 1. The packet has to know how to get back, too.
- 3. The network you are using is experimental technology and always will be.
- 5. The network is constructed of physical components.
- Subject: Embedded RS Protocol Needed! Newsgroups: cromwellpsi.comed
- [FIXME: summarize]
On Newsgroups: cromwellpsi.comed , sometime before , Edward K asked:
>I need a small (low C code size), simple protocol to drive a proprietary >network based on RS I dont want to get into TCP/IP for obvious reasons. >The clients on the RS bus would be based on a small 8 bit micro so speed >and efficiency are important.In response, Robert Reimiller suggested:
I have a small network (about a dozen nodes right now) using PIC processors. Although it doesn't use RS voltage levels, the operation is about the same. It uses a very simple message packet :
Length - 1 byte Source ID - 1 byte Destination ID - 1 byte Message Type - 1 byte <variable length message> Additive Checksum - 1 byte Exclusive-OR Checksum - 1 byteThis is a binary protocol so I used SLIP framing characters to determine the packet boundaries, very simple to implement.
A practical next step would be to use UDP/IP Packets, that way you could interface the system to router that supports SLIP.
Bob
In response, Ian Wilson commented:
Length as the first byte can cause all sort of mess in a noisy environment - consider what would happen to the when it receives noise. It would read the noise as a length and go off happily looking for the next x bytes before trying to crack the packet and seeing a back checksum. If the channel is very noisy so that you are getting continuous transitions at you receiver you can completely lock out you network. A better header for a noisy channel is a header sequence that is fixed. I does add overhead but will minimise the amount of false packets.
We use a time passed poll response system quite often. The master polls a slave and the waits for a response - if the reply has not started in a few milli-seconds the master assumes no reply is going to happen. Since replies are longer than a few ms this increases throughput on networks with lots of devices ( or ) where the most common reply is "nothing to report".
Also consider adding a sequence number to the packet. If a slave sees the same sequence number it saw on the last poll it knows the master did not receive its last reply - saves having a seperate ACK reply from the master to the slave. the master holds a differenet seq number for each slave and only increments it on a successfully decoded reply. Keep seq number = 0 as a special case that forces the slave to reset its seq number. Let the seq number increment wrap around from to 1.
Ian Wilson Considered Solutions considered@cromwellpsi.com (do the no spam thing to make a valid email address)
Mark Odell commented:
Subject: Re: Embedded RS Protocol Needed! Date: 31 Jan GMT From: Ian Wilson Newsgroups: cromwellpsi.comed <notjimbob at cromwellpsi.com> (James Meyer) wrote: >On Fri, 29 Jan GMT, leafs at cromwellpsi.com (Ian Wilson) >wrote: >>back checksum. If the channel is very noisy so that you are getting >>continuous transitions at you receiver you can completely lock out you >>network. > One would think that if the channel were getting continuous >transitions because of noise, that the channel would be completely >useless and *no* combination of packet parameters would be any better >than any other. No - this is not the case. Many RF receivers do not squelch (turn off) their outputs when the is no transmission - as the carrier detect circuit is often more complex and less reliable and more power hungry than the receiver (in micopower applications). So you have continuous streams of noise induced transitions. When a transmission arrives it is much higher than the noise level and so the receiver behaves correctly. What you don't want is the noise induced stuff to bugger up your network throughput. This sort of thing can happen even on wired networks - where you have heavy machines turning on and off or thyristor circuits nearby. Maybe not to the same degree but you can get false transitions. If a packet is not designed well then the network can fail. This is where: 1) fixed header sequences, 2) timeouts, 3) error detection/correction codes, 4) Ack/nack protocols make the difference between a system that works in good conditions only vs one that is truely robust. In designing for volume making a system robust at the expense of a few weeks of software and protocol design is definitely the way to go. Ian Wilson Considered Solutions considered@cromwellpsi.com (do the no spam thing to make a valid email address)Xmodem sends the length byte followed by the ~length byte. Then a checksum at the end. It was unlikely that the length and ~length would screw up randomly to still work. Besides, a practical max. packet size can help prevent you from going too far off in the weeds.
My RS protocol ran on 's with a single master that polled all 20 slave devices for status. I think the packet was destAddr, len, ~len, payload[len], 8-bit checksum. Worked okay for me over about a mile of total network distance.
- Mark
Subject: Re: Embedded RS Protocol Needed! Date: 01 Feb GMT From: Bill Gatliff <gatliff at cromwellpsi.com> Organization: Komatsu Mining Systems Newsgroups: cromwellpsi.comed
SAE has a standard called J Basically, all it says is that an idle period of ten or more bit times between bytes marks the end/begin of a packet, packets are at most N bytes in length, and that each packet starts with a destination byte and ends with a checksum. For the most part, you can put whatever you want inside.
In a noisy environment or one where collisions can occur (like RS), you *do not* want to depend on receiving a length byte. Idle timing is the best way to go.
Likewise, you don't want to deal with a negative acknowledgement (where the receiver tells the sender that the packet was corrupted). Instead, only acknowledge the correctly received ones, and let the transmitter resend a packet if it doesn't get a response.
To do it right all you need is about 50 lines of C code-- I think even the timer is optional if you're clever.
Heavy-duty trucks aren't the worst network environment in the world, but they're pretty bad. Despite this, J works very well-- nearly every truck on the road today uses it.
Just my $
b.g.
-- William A. Gatliff Senior Design Engineer Komatsu Mining Systems
- "An additional timeout on the receiver end to stop it from hanging within a packet"
- S.N.A.P. Scaleable Node Address Protocol cromwellpsi.com "a free and open network protocol." has free source code for AVR, PIC, Palm Pilot, and other popular processors.
Mac Serial Port
[FIXME: move to cromwellpsi.com ]
I have pushed the Mac serial ports to 1 Mbps; email me for more info. Comments?
the communications protocol for the Mac QuickCam takes advantage of many of the Mac serial ports to communicate at Kbps (synchronous). /* the protocol description *was* available at cromwellpsi.com */
[] How fast can the Macintosh serial ports really go?
Orignally the MacOS supported up to an asynchronous data rate of bps though the serial hardware could support much higher transfer rates externally clocked (as much as 16 times synchronously). The AV and Powermac introduced a different SCC clock and DMA based serial driver which allowed , and , bps.
While the ability to achive these speeds was useful in the days of communications software (see []) its importance dwindled with the introduction of Intenet communications and PPP (see []). The reason is that many non-text files on the Internet are already compressed which renders the built in MNP5 and Vbis compression methods virturally useless. In addition due to limiations in equipment and phone line quality even a 56K modem rarely gets a sustained throughput over 50K.
For these reasons the modem scripts that come with Open Transport have bps as the maximum serial speed for a modem.
-- cromwellpsi.com FAQ cromwellpsi.com
David Cary's experiences
David Cary's experiences with a pulse generator hooked to HSKi Mac data out (TxD+ and TxD-) changes only on rising edge of clock. (works fine when *input* data changes only on rising edge of clock).
clock specs: 4Vpp seems adequate, but it *must* go below ground. I used a green (all green LEDs are around V, it's a physical property of quantum electronics) LED in my level-shift circuit to give me +1 V and -4 V on my clock. It was very distorted (more triangular than square), but it worked OK transmitting stuff back and forth between 2 macs. (using custom software).
_Inside Macintosh IV_ has a nice circuit diagram on p.
The Macintosh Toolbox provides support for serial speeds up to a maximum of 57 bps. All my standard modem software is set to 57 bps; the 2 modems I use can handle talking to the Mac at that speed.
Technically speaking, however, the Mac serial port hardware can go much faster. You just need special hardware and special software.
I've witnessed a (prototype) gizmo that plugs into the Mac modem port and talks at 1 bps (roughly 1 Mega-bit / second) with a (1 MHz) pulse generator hooked to HSKi. (Of course, the 2 Macs involved were doing *nothing* but run my communication code).
(The hardware guys cranked it to 2 Mbps -- most characters still made it through, but many were lost.). It went that fast plugged into a PowerBook or when plugged into a Quadra
I got the information I needed to write software for a Mac to interface to this gizmo from the book _Inside Macintosh:Devices_ , a few paragraphs that talk about a "synchronous modem" connection.
_Inside Macintosh_ from Apple says that Mac serial port hardware can be made to go at Kbps ( Kbps or more on most recent models) by supplying a appropriate clock on HSKi. the book seems to indicate GPiA is used for devices with *different* transmit and receive rates. Wierd.
the GPi line it appears that the Mac SE has one connected, while the Mac Classic and the Mac Plus has no connection to that line (?).
I used the "officially sanctioned" call from the new Inside Macintosh books,
const Byte external_clock = 0x40; gOSErr = Control(gOutputRefNum, 16, &(external_clock)); /* set bit 6 to enable external clocking */This works fine on my PowerBookc, a Quadra, and a PowerPC (the only machines I tested my homebrew program, cable, and oscillator on). Mac data out (TxD+ and TxD-) changes only on rising edge of clock. Communication works fine when *input* data changes only on rising edge of clock. (This was the easiest to do -- I simply connect the same clock to both Macs). (I never got around to testing whether it would still work if input data changes on falling edge of clock -- I figure, if it works, don't fix it).
RS is quiescent *low* (normally low, at -5V on Mac serial port) I have succeded in writing a program that uses a toolbox call "set up Serial A to use HSKi as the receive and transmit clock". The normal serial toolbox calls only let me go up to 57Kbps. They say "it's easy -- just poke the appropriate values in the Z SCC. If you don't know it's address, just dissassemble the Mac ROMs and figure out how Apple did it". But of course they want the thing to work plugged into the serial port of *any* Macintosh, including the models. _Inside Macintosh_ from Apple says that Mac serial port hardware can be made to go at Kbps ( Kbps or more on most recent models) by supplying a appropriate clock (on HSKi, I think). I *think* it's easier to use the same clock as both transmit and receive, but the book seems to indicate GPiA is used for devices with *different* transmit and receive rates. Wierd. Surely someone, somewhere has done this before; I'd appreciate any programming tips, pointers to magazine articles, books, etc. I'll post a summary of emailed responses, as well as a report on how well they work on my Quadra and on my friend's Mac PowerPC. -dc
Date: Tue, 5 Dec 89 EST From: zben at cromwellpsi.com (Ben Cranston) Subject: Serial port document (long) MIT EE claims it is benign but confusing. Caveat Solderor This document contains notes on the Macintosh serial port and its use, with concentration on hardware interface issues. *** DANGER WARNING WILL ROBINSON!!! *** The DB on the back of a Macintosh is NOT a serial port! It is a SCSI parallel port. Any attempt to use this connector as a serial port will NOT function correctly and may cause damage to the Macintosh and/or the equipment being connected. The two serial ports of a Macintosh are mini-Din-8 connectors which are labeled with a telephone (the "modem port") and a printer ("printer port"). This is the pinout of the serial connectors. As we shall see below, there is an easy method for matching this to RS We buy the mini-Din-8 connectors at our local electronics surplus store. They cost just under four dollars each, but are not quite as nice as the Apple molded plugs (for example, they don't have the nice orienting-D shape). We are now carefully removing the pins from the connector, soldering the wires to the pin, then replacing the pin in the connector body. We fan out the end of the (stranded) wire into a little umbrella around the head of the pin, then we solder all around. A "third hand" reduces this task from impossible to merely tedious. On the original K and the K upgrade machines (which have a DB-9 connector instead of the mini-Din-8) the Output Handshake line was held in a "marking" condition by hardware (a small resistor to the appropriate power supply rail). On later Macintoshes there are logic and a line driver for this line. This change introduces the following incompatabilities: 1. SOME of the older terminal programs don't have the code to explicitly drive HSKo high. 2. SOME terminal programs drop HSKo when they close down. 3. SOME modems require DTR and will drop carrier if DTR goes away. If the cable design given below, mapping HSKo to DTR, is used, there are two recognized pathological conditions which can happen: A. Cannot use modem at all, because of 1 and 3 together. B. Modem drops out when switching between terminal programs, 2 and 3 together. Of course, some people consider B a feature, in that it will hang up the phone when you switch off the computer. Personally, I hang up the phone when I am done and I like to switch from terminal program to terminal program. If one of the above conditions happen, there are only three alternatives. I. If at ALL possible, set your modem up to IGNORE DTR and stay connected. Look for a DIP switch for this. I personally made this choice. II. Use only terminal programs which "properly" drive HSKo. You get to operationally define "properly" :-) III. Drive DTR from DSR at the modem end of the cable, as described below. Macintosh to modem (or other DCE device): DIN-8 MALE DB MALE GROUND 4 O--+O 7 GROUND RECV DATA + 8 O--+ RECV DATA - 5 OO 3 RD (Receive Data) XMIT DATA - 3 OO 2 TD (Transmit Data) HANDSHAKE OUT 1 O--+ HANDSHAKE IN 2 O--+O 20 DTR (Data Terminal Ready) Note that in RS the data signals are inverted (marking is minus) while the control signals are not (marking is plus). Thus the transmit data minus signal from the Mac is just right for driving the modem. Leave the transmit data plus signal disconnected. If you ground this you will short out a driver, and it will probably get hot. Similarly the receive data signal from the modem/DCE is inverted, so it can drive the Mac's receive data minus line, but in this case the receive data plus line is grounded to prevent any extraneous signals from being induced into the circuit. Note also that we are driving both HSKi and DTR from HSKo so the problems described above can happen. Note receive data plus is grounded while transmit data plus is left disconnected. For this particular cable we have wired the terminal/DTE's DTR back into the Macintoshes HSKi to implement a hardware handshake. Assume the terminal side is a printer that is being overrun. One of the things these printers can do is drop DTR. By wiring it through to the handshake input we make it possible for the Macintosh software to temporarily pause in sending, until the printer's buffers empty out and the printer reasserts the DTR signal. Some terminal devices may need to see DSR (Data Set Ready) or CD (Carrier Detect) or CTS (Clear to Send), in which case they may be driven >From an appropriate source. +--O 20 DTR (Data Terminal Ready) This is probably appropriate +--O 6 DSR (Data Set Ready) for a communications terminal +--O 8 CD (Carrier Detect) in which DTR is a totally static signal and does not move. +--O 4 RTS (Request To Send) +--O 5 CTS (Clear To Send) or +--O 4 RTS (Request To Send) This is probably appropriate +--O 6 DSR (Data Set Ready) for a printer that flaps DTR +--O 5 CTS (Clear To Send) as the buffer fills and empties. +--O 8 CD (Carrier Detect) The logic is to drive from whichever of DTR or RTS is NOT flapping around as buffers fill and empty or as the terminal transmits and receives To connect directly to an IBM PC we believe CD must be asserted. That is, an IBM PC will not accept data unless it also sees the CD signal. K/K MACINTOSH Somebody on cromwellpsi.comre asked for cables for a K/K Mac! I didn't know there were any more of those out there!!! :-) Here are the corresponding connections, please use these in conjunction with the analysis and suggestions provided above: K/K Macintosh to modem (or other DCE device): DB-9 MALE DB MALE GROUND 3 O--+O 7 GROUND RECV DATA + 8 O--+ RECV DATA - 9 OO 3 RD (Receive Data) XMIT DATA - 5 OO 2 TD (Transmit Data) + 12 Volts 6 O--+ HANDSHAKE 7 O--+O 20 DTR (Data Terminal Ready) K/K Macintosh to terminal (or other DTE device): DB-9 MALE DB FEMALE GROUND 3 O--+O 7 GROUND RECV DATA + 8 O--+ RECV DATA - 9 OO 2 TD (Transmit Data) XMIT DATA - 5 OO 3 RD (Receive Data) HANDSHAKE 7 OO 20 DTR (Data Terminal Ready) FINAL CLOSURE On the DB pin 1 is the FRAME ground and pin 7 is the SIGNAL ground. Equipment that requires connection to pin 1 is badly designed (IMHO). As a very last resort you might try a 1 to 7 jumper. As you can imagine from seeing all these alternatives, an RS breakout box is real handy, since you can try all these patches without having to warm up a soldering iron. The only other thing I can say is: IF IT DON'T WORK, DON'T LEAVE IT TURNED ON LONG ENOUGH TO GET HOT! Communications driver chips are built very ruggedly and will stand an amazing amount of mistreatment for a short period of time. But if you let two drivers fight for an hour one or both of them will burn out I've read this over a dozen times to make sure there aren't any totally glaring errors, but I cannot be responsible for anybody's smoked hardware. Let's be careful out there! Ben Cranston <zben at cromwellpsi.com> Network Infrastructures Group Computer Science Center University of Maryland at College Park of Ulm2 V) and gnd for power, put V to V, MHz clock on (both) HSKi. Connected a Quadra to a Mac Powerbook ; KHz clock worked OK but KHz failed. (1 HSK0)diode>|--R--+-->+Vcc->oscillator>-||--+>(2 HSKi) | | (4 gnd)-gnddiode>|-+ gndLED>|-+ oscillator>-||--+>(2 HSKi) | gndLED>|-+
(another pinout document: ftp://cromwellpsi.com )
Date: Wed, 28 Jun From: bill at cromwellpsi.com (Bill Stewart-Cole) Subject: Info-Mac Digest V13 #69
In Info-Mac Digest V13 #69, iedh1 at cromwellpsi.com (Dan Hofferth) writes
>Responding to: > >>Date: Thu, 22 Jun + >>From: thomas at cromwellpsi.com (Thomas H Eberhard) >> >>Fast modems with budget mac? >> >>LC II (this also apply to the LC and all the Classics including the II and >>colors) According to "Guru" the modemport only support hardware handshake >>on output. Does that mean that I can't get fast input speed even with >> modems?? > >The Mac Plus, LC, and Classic do _not_ support hardware handshaking. The >Classic II and LC II _do_ support it, both send and receive. So your "guru" >is incorrect.Not quite correct. *EVERY* Mac supports what is called "Hardware Handshaking" in the Mac world. Technically some RS purists will say this is strictly hardware flow control, and NO Mac can implement all the hardware handshaking of RS (which includes hardware ring indication, hardware speed control, and other things) EVERY Mac serial port has a pair of handshake lines, one in and one out. (abbreviated HSKi and HSKo in pinout shorthand) SOME Macs (all but the 'classic' sized models, the //si, and the LC & LC II) also have an additional input on pin 7 (which is disconnected in those other Macs) termed "general purpose' by Apple and designated GPi. This is used by some programs like FirstClass (given the rare correct cable) to do hardware carrier detection.
Hardware flow control is done with the pair of handshake lines in all Mac serial ports. HSKo is run to the modem's RTS (Request to send) pin, and HSKi is run to the CTS (Clear to send) pin. A good modem cable runs HSKo also to the DTR pin, since that is useful for using DTR in uni-directional flow control and for older (non-compressing and slower) modems. A few cables will also wire GPi to CD, useful in a few programs, but sadly that is still rare in OEM cables. The effect of using an old-style modem cable on a fast or compression-capable modem is in fact that you can only implement flow control on the data stream from the computer, whereas the computer has no way (due to the cable, not the computer) to ever tell the modem to stop. This is a serious problem with slower Macs, which can easily fall behind the data rate of a fast modem.
The reason that many people think the Plus, LC, and other Macs cannot do flow control is that Apple's move to the better serial port (with GPi) was somewhat around the same time as the move from vanilla bps modems to v/vbis modems and bps modems. Pure coincidence, but it meant that Apple was making port changes right as people were buying modems that did not work with their old cables. (Some modems even shipped with old-style cables, and in it was hard to find a 'hardware handshaking" cable except via mail-order) With Apple using a slightly enhanced serial port on high-end models of the day and high-end modems not working right without a special cable, it is easy to mistakenly connect the two.
Of course I could have just said that I ran a Plus and used "hardware handshaking" for 4 years with 3 different modems that demanded it, but that's not so convincing perhaps. The proof is in the pinouts.
-- Bill Stewart-Cole What is Stewart-Cole Consulting? Hell if I know. I'll find out when I finish the web page. Newsgroups: cromwellpsi.comles From: nirvana at cromwellpsi.com Subject: Re: vs Organization: Cruzio Community Networking System, Santa Cruz, CA Date: Fri, 25 Nov GMT Sender: nirvana at cromwellpsi.com (Leo Baschy) Lines: 36 rudolf mittelmann <rm at cromwellpsi.com> wrote: > I tried to use MacRecorder (a serial-device external microphone) on > a PB - but it did not work (with the newest MacRecorder driver > installed!). > I also could not get the CP Sound to work with it. > Why? > Did Apple cripple the ROMs to disallow sound input? Or what else > is missing? The problem is that "the" serial port device, the MacRecorder by Macromedia, has code that violates Inside Mac, therefore crashes. "The other" serial port device (a version of Voice Navigator from Articulate Systems) is no longer supported because the company now focuses on high-end automated dictation systems, I've been told. A possible solution would be to fix the code of MacRecorder, but I've tried to convince the manufacturers (it's been transferred from one company to another) for more than four years without result. The new Connectix serial port camera is neat, but the sound is limited to 5kHz, which is not so good. If anybody knows a serial port sound input solution that works for the PB I'd be more than glad to know about it and to write about it. We could even help out if anybody wants to fix the MacRecorder code, we have the know-how to rewrite that code from scratch. After all the manufacturer makes money on selling the hardware anyway, so they shouldn't mind if we write software that makes it work. It's just so much work, and little demand. - Leo Baschy nirvana at cromwellpsi.com Nirvana Research () --
From cary at cromwellpsi.com Wed Feb 1 Date: Wed, 16 Nov (MST) From: Mark Lankton <LANKTON%PISCES at cromwellpsi.com> Subject: synchronous serial port To: cromwellpsi.com at cromwellpsi.com X-Vms-To: VAXF::IN%"cromwellpsi.com at cromwellpsi.com" Mime-Version: Content-Transfer-Encoding: 7BIT Status: O X-Status: David, There is a fairly recent Control call you can make to the serial driver that lets you use HSKi as a clock, at least for receiving. I have never tried transmitting that way; all I have to do is listen to an instrument. The call goes like this: Control(driverNum,16,0x40); /* Set bit 6 to enable external clocking */ By the way, setting bit 7 with this call means DTR will be unchanged when you close the driver (if you ever happen to care). I am right in the middle of building some new hardware to use this method; for years I have used a home-grown get-in-and-fiddle-with-the-Z input driver. It always worked fine *except* for exploding on PowerBooks, and if I didn't have to work on PowerBooks and wasn't worried about maintaining it in the face of the changing device driver API, I would just keep on that way. One important note: the external clock signal apparently wants to be 1x the bit rate, not 16x as you might guess. And I am still trying to decide how important the clock polarity is. Information comes from NIM:Devices. Good luck, and please let me know how it goes for you. Mark Lankton Laboratory for Atmospheric and Space Physics University of Colorado From cary at cromwellpsi.com Wed Feb 1 Date: 22 Nov 94 EST From: intolabb at cromwellpsi.com (Steven Intolubbe) Subject: high speed serial stuff To: cromwellpsi.com at cromwellpsi.com .Hi David, Do you need to use a synchronous protocol, or do you just need to externally clock the serial port? The other problem is duty cycle of the data. Is it a constant stream, bursts, or do you request what you want when you want it? There is a toolbox call for setting the external clock mode (on HSKi) but it is in the new inside Mac books, which I don't have. I accessed the chip directly to set the external clock mode, and it appeared to work on the AV, but the toolbox would be the best way to do it. As far as synchronous modes go, I have also done that, all with direct chip register access, which is was very rude of me. If you want to run a machine in a synchronous mode, you should write a driver to replace apple's serial manager (I didn't do that because I don't know how). Apple has a driver for one of their Personal Laserwriters that was supposed to be close to 1 Mbaud, so if you were in the APDA fold, I'm sure they could help you out. Hope this helps, Steve APDA: () APDA developers support ()
Are the 2 serial ports on your machine inadequate ?
Date: Fri, Jun 3, ,
The only serial port boards for the Mac I know of are the "Hurdler" and the "Hustler" from
Creative Solutions Inc. Randolph Dr. Suite 12 Rockville, MarylandThere are *lots* of serial port boards for the PC.
A little bit of information about the PC serial port
From: helge at cromwellpsi.com (Helge-Wernhard Suess) Newsgroups: cromwellpsi.com Subject: Re: Question about serial ports Date: 12 Sep GMT Organization: Siemens AG Austria Lines: 26 In Subject: Re: ADB Physical Specs From: st93urnu at cromwellpsi.com (Aaron D. Marasco) Date: Fri, 23 Feb In article <C70@cromwellpsi.com>, Bryan Dunn <cromwellpsi.com at cromwellpsi.com> wrote: >Hello all! > >I'm designing some hardware that will use the ADB interface. Can anyone >suggest a good reference (on the net or in print) that describes ADB in >detail? > >Thanks in advance! > >Bryan "Guide to the Macintosh Family Hardware: Second Edition" Tells everything about the Macs up to the IIfx, including ADB, and a standard is a standard, so it shouldn't have changed (however, this *IS* Apple we're talking about!) Anyway, it is a book I have for a school class, so I have all the info: $ US, $ CAN Addison-Wesley ISBN I haven't checked any of the online bookstores, you might get it cheaper! Also, it's a paperback, to letcha know._Inside AppleTalk, Second Edition_
notes from _Inside AppleTalk, Second Edition_ by Sidhu, Andrews, Oppenheimer[1]. and from AMD's _Analog and Communications Products Data Book_[2]. and Apple _Macintosh Family Hardware Reference_ () [3]. LocalTalk uses Synchronous Data Link Control (SDLC) frame format and a frequency modulation technique called FM Each bit cell (nominally usec -> nominal Kbit/sec). differential, balanced voltage signaling over a maximum distance of meters. transformer provides ground isolation as well as protection from static discharge. "In the preferred hardware implementation of LocalTalk, a Zilog Serial Communications Controller (SCC) is used." [1] The classic Macs and the Mac SE [3] both use the SCC, a 26LS30 differential transmitter, a 26LS32 differential receiver, and a fistfull of RFI filters. The Mac II replaces the 26LS32 with a differential receiver. (I have no info on other macs) (the Maxim MAX Low-Power AppleTalk Interface Transceiver looks interesting). The SCC is clocked at MHz hooked to /RTxCa, /RTxCb, and PCLK. on classic, Mac SE, and Mac II. (Mac SE and Mac II has software switching of /RTxCa to the GPiA pin).[3] "don't access the SCC chip more often than once every us. on the Mac SE [and the Mac II] it is not neccessary to do so because [other circuits ensure the proper delay]"[3] "the transmitter and receiver hardware for LocalTalk is built into every Macintosh and AppleIIGS computer, and many peripheral devices " "If you are designing your own AppleTalk hardware from scratch, it is easiest to use a MHz oscillator and a Z This has been tested and works just fine." [HW - Serial I/O Port Q&As - Technical Notes - Developer Support ] "LocalTalk hardware can detect a flag byte, the distinctive bit sequence ($7E)." [1], but i can't find any reference to this capability in [2]. Well, the hardware guys have done it again. They're making this gizmo that they're hooking to the Mac serial port. They say it communicates "like a synchronous modem". They want it to go at least Kbits/sec. "see that Z85C30 on the Mac motherboard there ? the databooks say it can go at 10MHz cancha just poke the right values into it? dissassemble the Mac ROMs and figure out how Apple did it ? But of course we want the thing to work plugged into the serial port of *any* Macintosh, including the models." I know it can be done; the hardware guys had LapLink for Mac running on 2 Macs (homebuilt cable between them) "See that O'scope ? they're pumping KHz into the HSKi input LapLink just transferred a megabyte file at rougly 70KB/s."
Controller Area Network (CAN)
[What is the endianness of CAN ? ]
"CAN we talk? : Distributed systems require protocols for communication between devices. CAN and SPI are two of the most common." article by Niall Murphy cromwellpsi.com
a text-based protocol. This is how most of the Internet works; HTTP and SMTP are both built on text protocols. This approach allows the protocol to remain architecture agnostic. Text is less efficient than a protocol where each byte is given a meaning, but the upside is a protocol that's easy for a human to read and debug.
The biggest difference between CAN and SPI is that the CAN protocol defines packets. In SPI (and serial interfaces in general), only the transmission of a byte is fully defined. Given a mechanism for byte transfer, software can provide a packet layer, but no standard size or type exists for a serial packet. Since packet transfer is standardized for CAN, it's usually implemented in hardware. Implementing packets, including checksums and backoff-and-retry mechanisms, in hardware hides a whole family of low-level design issues from the software engineer.
There are a number of higher layer protocols that have been layered on top of the basic CAN specifications . These include SAE J, DeviceNet, and CANOpen.
points to the Linux CAN-bus driver project cromwellpsi.com
Open DeviceNet Vendor Association, Inc. cromwellpsi.com (DeviceNet is a more detailed specification for CAN)
information from "Hard real-time connectivity: It's in the CAN" article by Bruce Boyes in _Computer Design_ , p. 88
"CAN is a robust network designed for hard real-time distributed control systems in harsh environments. It's an open standard (and the subject of ISO )" "CAN is a peer-to-peer network packets with a maximum payload of 8 bytes adept at passing around simple commands or small amounts of data quickly not well-suited to moving around large files " "can go up to 1 Mbit/s, CAN systems most commonly operate at Kbit/s or Kbit/s, because lower baud rates are more resistant to brief bursts of noise." " fiber-optic cable also is common. " "The ISO document specifies a Ohm nominal impedance using terminated twisted-pair media. line length versus baud rate 40 m, 1 Kbits/s 1 m, 50 Kbits/s "
"low cost and relative simplicity" "Kevin Parkinson typically uses optically isolated chip-to-bus electronics using RS type drivers."
"Emphasis on content" "When data is transmitted by a CAN node, no other nodes are /addressed/; rather, the /content/ of the message (pressure, voltage, temperature, etc.) is designated by the identifier, which is unique throughout the network. The identifier also prioritizes the message. With care, this prioritizing guarantees the most important messages are transmitted with the least delay. Arbitration is nondestructive. In the case of an overloaded network, the highest-priority messages still get through. Latency is also very low. CAN hardware also provides message acknowledgment and automatic re-transmission in the event of an error."
"CAN data bits are either "dominant" or "recessive". A frame always begins with a dominant-level SOF (start-of-frame) bit. A dominant bit always "wins" over a recessive bit being transmitted at the same time. If 2 nodes start transmitting concurrently, each node performs bit-wise arbitration to resolve the conflict. A transmitter stops sending if it sends a recessive bit, but monitors a dominant bit. That guarantees a lower-priority CAN device immediately stops transmitting, while the higher-priority device continues unimpeded. The lower-priority device waits for the next bus idle time and tries again. 2 nodes [should] never send the same [arbitration field] followed by different data "
" ACK indicates sucessful message reception by at least one receiver the hardware ACK is an important component of CAN's real-time capability."
"For example, a vehicle wheel-speed sensor should transmit its data properly and let other nodes, if any, handle the data as they wish."
"The RTR bit permits any node to request data from another node."
"receiving nodes which detect a problem transmit in the end of frame space. The sender monitors the error flag, which triggers an automatic retransmission by the sending node."
"Honeywell's Smart Distributed System (SDS) DeviceNet (initiated by Allen-Bradley) DeviceNet and SDS also include specifications for rugged cable and connectors."
"The CAN in Automation (CiA) group (Erlangen, Germany) promotes the CAL"
"CAN specification B describes the extended message frame with a bit ID."
Siemens (SAE81C91), Motorola (MC), Intel (i), Philips (SJA), National Semiconductor (COP87L84BC). offer CAN controllers and/or microprocessors with CAN B capability.
CAN extended message format (bit field width is not to scale)
| Arbitration field | Control Field | Data field | CRC field | Response field
Arbitration field:
| SOF | 11 bit identifier | SSR | IDE | 18 bit identifier | RTR |
Control field:
| R1 | R0 | DLC |
Data field:
| Data: 0 to 8 bytes |
CRC field:
| 15 bit CRC |
Response field:
| ACK field | EOF 7 bits | INT 3 bits | bus idle (or another node starts transmitting)
For an extended frame, this is a total of 64 to bits (depending on data size). With 8 bytes of data, overhead (non-data bits) is therefore 1/2.
keyboard information
the various standard keyboard layouts, information on alternative keyboard-like data entry devices, and technical information on making your own devices that plug into the "keyboard socket".
[FIXME: consider moving this information to massmind: cromwellpsi.com ]
ergonomics
The human-keyboard interface. Various standard keyboard layouts, information on alternative keyboard-like data entry devices [woefully incomplete]
alternatives to the standard keyboard are useful for wearable electronic devices wearable_cromwellpsi.com .
some chairs have a built-in keyboard 3d_cromwellpsi.com#furniture ; all furniture is (or should be) designed with ergonomics in mind.
I'm paranoid about wrist pain. #RSI
[FIXME: put all this ergonomics, keyboard+other, on another page] Other ergonomics
- Bad Keyboards: cromwellpsi.com?BadKeyboards
- "Ergonomics" by Mark Kelly cromwellpsi.com talks about the ergonomics of everything related to the computer -- desk, chair, noise, lighting, etc.
- Ergonomics cromwellpsi.com
- cromwellpsi.com says
Locate the entire viewing area of the monitor between 15° and 50° below horizontal eye level.
old guidelines recommended that the monitor be placed at eye level New evidence (and some that has been around for a while) shows that, while the eyes might be most comfortable with a 15° gaze angle when looking at distant objects, for close objects they prefer a much more downward gaze angle (Kroemer ). Figure 1 shows the optimum position for the most important visual display, 20 - 50° below the horizontal line of sight, according to the International Standards Organization (ISO ).
Perhaps the most famous study regarding performance and lighting conditions was done at Western Electric's Hawthorne Plant in Chicago (Mayo ). The researchers found that when they increased light level, productivity increased. They also found that when they decreased the light level, productivity still increased. In fact, no matter how they changed the lighting, productivity continued to increase.
The term "The Hawthorne Effect" is now used to refer to the principle that making any change in a workplace can improve short-term performance. The improvement results from just "paying attention" to the workers.
On the other hand,
"The Hawthorne defect: Persistence of a flawed theory" report by Berkeley Rice cromwellpsi.com~stotts//cromwellpsi.com says
the Hawthorne effect has a life of its own that seems to defy attempts to correct the record. The story of this myth's growth and its recent debunking contains a moral of caution for behavioral researchers and those who uncritically accept their pronouncements.
the results have been pretty much misinterpreted or ignored for 50 years. Those results conflict with, or at least fail to support, the notion of the Hawthorne effect.
subsequent research has failed to duplicate the supposed Hawthorne effect
- Best colours for LCDs cromwellpsi.com+cromwellpsi.com#Q says what's importance is the brightness -- the actual color (amber, green, white, whatever) doesn't matter if the contrast is high enough.
- cromwellpsi.comcom/cromwellpsi.com talks a lot about the psychological effects of text in different colors
Keyboard ergonomics
- news: cromwellpsi.com?ErgonomicKeyboard
- the Typing Injury FAQ cromwellpsi.com from cromwellpsi.com?group=cromwellpsi.comtional
- RSI
- Repetitive Strain Injury cromwellpsi.com?RepetitiveStrainInjury
- -- Eric Soroos 9/3/ cromwellpsi.com
- cromwellpsi.com?CategoryKeyboard [FIXME: toread perhaps move this section there ?]
- ``There is a "sticky" shift key setting where you can press and release the shift key and it will be active for the next keystroke. I haven't used Windows 98 in a while (that's what your message header says you're running), but I believe you can probably find it in the Control Panel under Accessibility Options.'' -- unknown [FIXME: paraphrase and summarize with the exact keystrokes needed]
- ``my wrists'' © Jamie Zawinski cromwellpsi.com ``For several years I had pretty severe wrist pain, and it terrified me. These days my wrists are pretty much fine. People often ask me how I dealt with it, so I thought I might as well write it up. Pain is a signal that something is wrong, and is going to get worse if you don't fix it. It doesn't matter what that something is, you need to do something about it or you run the risk of permanently damaging your body.''
- Keyboard Alternatives cromwellpsi.com sells many different kinds of ergonomic keyboards and other unusual input devices: the "HeadMouse", the "MindMouse", foot pedals, etc. Keyboard Alternatives has a keyboard comaptibility chart cromwellpsi.com (I would have combined the "split keyboards" section and the "Wave Shaped Keyboards" section; a total of 16 different keyboards listed in both. )
They have a section "small keyboards" (most are normal QWERTY style keyboards with regular-sized keys, but without the numeric keypad I wonder why they don't list the happy hacking keyboard #happy ).
- "CRT and Computer Pain / Avoiding RSI" by ??? cromwellpsi.com
Weird and wonderful keyboard layouts. [FIXME: make seperate section for ``QWERTY-like'' layouts, that can be used with commodity keyboards with some remapping software, vs. stuff that needs completely different hardware ? ]
- the Alternative Keyboard FAQ cromwellpsi.com lists many, many kinds of alternative keyboards, from "Fixed-Split Keyboards" cromwellpsi.com such as
which are very close to standard flat QWERTY keyboards, to some radically different keyboard-like devices Chording Keyboards cromwellpsi.com such as
- "the twiddler" chording device; slightly modified keyboards to strap onto the wrist; cromwellpsi.com input devices for wearable computers:
- orbiTouch Keyless Keyboard cromwellpsi.com ``keyless keyboard with an integrated mouse.'' ``the orbiTouch have all of the functionality of a regular keyboard'' supposedly eliminates pain from RSI, because ``The orbiTouch requires no finger motion or wrist motion for use.'' it only uses hand and arm motion. very different from qwerty. ``In our initial studies, typists were at 50% of their regular flat board speeds in 5 hours.''
commentary: cromwellpsi.com . One commenter has this interesting idea:
and also Contoured Keyboards cromwellpsi.com including the
[FIXME: consider mirroring that FAQ -- does that make most of this section now obsolete ?]
- The JazzMutant's Lemur is a color "touchscreen that can track multiple fingers simultaneously." http://cyclingcom/products/cromwellpsi.com
- the Optimus keyboard cromwellpsi.com at first glance looks like an ordinary key keyboard. But every key has its own (color!) display; it can look like lowercase Latin, uppercase Cyrillic, special symbols for various programs, etc.
- closed-caption TV:
captioners actually use stenographic keyboards instead of real computer keyboards. These keyboards allow them to type a whole syllable by presing keys at once, but they are phonetic; there is a K key and an S key, but no C key. (There are actually three sets of keys: consonants on the left, vowels in the middle, and consonants on the right; This allows them to type a whole syllable.) The output from the keyboard is sent to a laptop computer running software that can match a steady stream of syllables with a word list and figure out that and/now/the/we/ther is "And now the weather". Errors like "Loss Alamos" occur when the captioner didn't have the word "Los" programmed in the dictionary. Usually they have a chance to add words before a job to prepare for any unusual words used, but sometimes they don't have time, they forget, or the computer picks the wrong word.
cromwellpsi.com?sid=&threshold=1&commentsort=0&tid=&mode=thread&pid=
Typing, Fastest. Mrs. Barbara Blackburn of Salem, Oregon can maintain wpm for 50 min (37, key strokes) and attains a speed of wpm using the Dvorak Simplified Keyboard (DSK) system. Her top speed was recorded at wpm.
Source: Norris McWhirter, ed. (), THE GUINNESS BOOK OF WORLD RECORDS, 23rd US edition, New York: Sterling Publishing Co., Inc.
Barbara Blackburn, the World's Fastest Typist cromwellpsi.com , cromwellpsi.com#WFT interview
- "Michael Shestor the world's fastest typist" cromwellpsi.com interview.
[FIXME: move to cromwellpsi.com ? Find out more about Michael Shestor's teaching methods ?]if a teaching strategy is wrong, no amount of practice will allow one to get better The Internet finally allows a widespread dissemination of exciting learning technologies. With the advent of Internet downloading, everybody now has the opportunity to teach and learn the best systems, in a very efficient way.
- cromwellpsi.com
- "UniTap - technology for the world's smallest alphanumeric keypad" cromwellpsi.com clever. It's nice that it lists other similar technologies: cromwellpsi.com
- gesture-input keyboards and pointing devices cromwellpsi.com full-size standard QWERTY also sells a "mini keyboard" that has the standard QWERTY layout in about half the space. cromwellpsi.com commentary: "(Nearly) Zero-Force Keyboard" cromwellpsi.com [keyboard alternatives] " get away from the impression that it is a keyboard, and look at it as a generic input surface." and also has some opinions on "a list of things I think the perfect keyboard would have." One opinion claims -- cheetah_spottycat [theory]
Another poster suggests: -- D4rkm1lk
- cromwellpsi.com asks people to *please* make the backspace key double-wide, the way it is on many keyboard, rather than shrinking it to the size of other letter keys to make room for the backslash and an extra-large enter key.
- Re: musings about keyboards and writers cromwellpsi.com mentions strapping a keyboard onto the arm, and other "wearable" issues with keyboards. [should I divide this into a "theory / speculation" section ?]
- FrogPad One-handed Keyboard cromwellpsi.com?id= , cromwellpsi.com
- If you are designing a keyboard, perhaps you would be interested in knowing statistically which keys are the most-often pressed. ``How Many Keys Have You Pressed ?'' cromwellpsi.com ``How meny inkorrect keys r actualley pressed ? That would be interesting to see. Possible to if you could record and check to see the most popular key pressed right before the backspace.'' -- TexTex
- cromwellpsi.com sells lots of different alternative keyboard-like devices. ; ;
- keyboard humor: ``I'm so fully of his pizza crumbs, I'm a bio-hazard !'' cromwellpsi.com
- cromwellpsi.com
-- Eric Raymond cromwellpsi.comthe most important aspect of any laptop is not the CPU, or the disk, or the memory, or the screen, or the battery capacity. It's the keyboard feel, since unlike in a PC, you cannot throw the keyboard away and replace it with another one unless you replace the whole computer. Never buy any laptop that you have not typed on for a couple hours. Trying a keyboard for a few minutes is not enough. Keyboards have very subtle properties that can still affect whether they mess up your wrists.
A standard desktop keyboard has keycaps 19mm across with mm between them. If you plot frequency of typing errors against keycap size, it turns out there's a sharp knee in the curve at millimeters.
- Thumbnails that link to all the common keyboard layouts: cromwellpsi.com
- Trevor Blackwell cromwellpsi.com gives detailed instructions (with photos) explaining how to make one particular modification to one particular brand of a standard keyboard.
the numeric keypad I write programs and prose, but I never enter in columns of numbers. Anyway, this vestige of adding machines had to go! It forces the mouse to be about 5 inches farther away from where I'm typing than it needs to be, which is a lot of unnecessary arm movement over the years. So I set about to chop the numeric keypad off the otherwise excellent Microsoft Natural Keyboard. It worked well (on my second try) and took about two hours.
- Thumbcode: A Device-Independent Digital Sign Language Vaughan R. Pratt cromwellpsi.com
- cromwellpsi.com
- ``the Filewalker, a new Linux-based handheld, with a very unique (one-handed) means of inputting characters.'' cromwellpsi.com (basically a dial and 3 buttons all (more or less) letters are displayed in a Nx3 grid; the wheel selects a column, and the top button enters the top letter of that column)
Some other interesting discussion on input devices: ``What IS a good way to get data into tiny things ?''.
- Virtual Keyboards cromwellpsi.com (not exactly what *I* think of when I see the phrase "virtual keyboard", which is one of Donald's keyboards synthesized with VR gloves). [FIXME: email ?]
I think of something more like Key-Glove cromwellpsi.com The cheapest wearable keyboard on earth.
or perhaps "Essential Reality's P5 glove controller" cromwellpsi.com,aid,,asp cromwellpsi.com
- ``"Body Coupled FingeRing": Wireless Wearable Keyboard'' paper by FUKUMOTO, Masaaki and TONOMURA, Yoshinobu cromwellpsi.com finger-typing on any convenient surface the hardware in the form of a ring on each finger and thumb, so it can be left on in most activities
- "Teen inventor creates 'mouse mitt'" cromwellpsi.com "Tobias Patterson Jones, 16, from Brecon, mid Wales devising a glove to attach to a mouse-like device, which allows the hand to move through the air, as sensors send messages to the computer. Bending your fingers has the effect of clicking a normal mouse button the Coleg Powys student "
- "T9(R) Text Input" cromwellpsi.com enter letters on 10 key pad; tries to recognize the word you spelled (even though each button could be one of 3 or so letters). cromwellpsi.com
- cromwellpsi.com [FIXME: is this any different from other one-handed keyboards ?]
- cromwellpsi.com another one-handed keyboard
- [FIXME: should I separate ``quality hardware'' issues like this from other ergonomic issues ? perhaps move to 3D_cromwellpsi.com] cromwellpsi.com and further details cromwellpsi.com ``evidence that the HP49G's keyboard is an abomination.'' talks about button wearout: letters printed on the keys wearing off, making them illegible.
- cromwellpsi.com lists some pretty funky alternatives to the PC keyboard. (Many of them plug into a standard PC keyboard port).
- closed-captioning info cromwellpsi.com info on how people can type that fast (using a Steno machine (chording and abbreviations) and a computer translator, a person can type over words per minute.) technical information; Line 21 Captioning Character Set cromwellpsi.com
- footmouse ? cromwellpsi.com?sid=99/11/30/&threshold=0&commentsort=0&mode=thread&pid=37#99
- mouth mouse ? cromwellpsi.com?sid=99/11/30/&threshold=0&commentsort=0&mode=thread&pid=#
- cromwellpsi.com ???
- cromwellpsi.com
- "Interface Zen: modern keyboards, and the problem with them" cromwellpsi.com by Tom Christiansen. (DAV: I, too, agree that Caps Lock is utterly useless -- -- please return Ctrl to its rightful place ! I also despise the "Insert" key. ) (I'm not sure about the inverse-T arrow keys, though. I sure like them much better than the <- -> v ^ arrows on my portable computer -- but maybe if they had been v <- -> ^ I would have been even happier. ). One reply mentions lar3ry:
Using the right input device for the right job is crucial. Otherwise we will never be able to get the non-initiated to use them.
People not "in the know" still wonder how a Palm Pilot can survive without a keyboard. The answer is really simple: the software is written such that using the stylus becomes second nature. Same as with the Millipede example the software was written for a specific input device.
Maybe neurocomputing will allow people to get information into a computer faster than is currently possible (I doubt so, but I'm willing to be proven wrong!), but that is not available right now. Keyboards have worked for a nice long time and will probably be ubiquitous for a time being.
Another reply:
Failure to notice awkwardness (Score:1, Insightful) by Anonymous Coward on Tuesday November 30, @PM EST (#) There's another UI-related lesson I learned from Quake. Back when Quake 1 deathmatches were beginning to become popular, there was always a crucial turning point in everyone's gameplay: the point when they set up the Correct Bindings. The details varied from person to person, but there are some things that all Correct Bindings had in common. One hand was on the mouse, which was permanently in mlook mode. The other was on the keyboard. The keyboard hand could strafe left or right without repositioning; often, the "strafe" keys simply replaced the "turn" keys, since the mouse was perfectly adequate for turning. For Quake 1, this was the right tool for the job. Nothing else provided the speed, precision, and flexibility needed for deathmatch play. Now, there's someone I know who didn't like using the mouse, even for Quake. I argued the point with him, and he claimed that the keyboard was perfectly good and easier to control. He didn't do deathmatch, but he had played through the entire game in single-player mode. I watched him play. When he wanted to aim up or down, he stopped stock-still and tapped the turn-upward and turn-townward keys lightly several times, often overshooting and tapping the opposite key. It looked incredibly awkward, and would have gotten him killed in deathmatch play, but - and this is the point - he was completely unaware of it. As far as he was concerned, he had a desire to do something, and this translated directly into action. It just so happened that the action was awkward and slow and only worked because the monsters were stupid, but it worked, and that was enough. His brainstem was satisfied. There's a lesson in this for all of us who think our familiar user interfaces are "good enough". (Too bad there's no deathmatch mode for text editors. We'd settle the emacs vs. vi issue in a hurry then.)
And another:
The Right Interface for the Job (Score:4, Insightful) by jalefkowit (jalefkowit@cromwellpsi.com) on Tuesday November 30, @AM EST (#28) (User Info) The problem isn't limited to input devices. This article got me thinking about something I've been wondering about for awhile -- the recent tendency to use a 'standard' interface for various tasks, rather than a purpose-built, optimal interface. It seems like there are dozens of companies these days that want their interface design to be the One True Interface to All Things. The best example of this is Microsoft, which every couple of years makes noise about how toasters and refrigerators should be controlled with some variant of Windows. But MS isn't the only offender -- lots of Internet companies do this too, by forcing you to use an HTML front-end to their resources rather than designing software for the purpose. Don't get me wrong, I can see the reason for this approach -- once you've learned the One True Interface, you're set, you don't have to learn anything else. The problem is that trying to force all devices to share the same interface means that some of those devices are going to feel clunky -- or, worse, be downright unusable. Take, for example, the whole WinCE vs. PalmOS war. On its face, you'd think people would prefer WinCE devices, since they're already familiar with the Windows interface. But (based on my observations, not any hard research) it seems to me that people vastly prefer the Palm interface, which is optimized for handheld devices, rather than Windows, which really wants you to have a big, roomy display to work well. In other words, people are willing to learn a new, unfamiliar interface if doing so offers them substantive productivity benefits -- which would seem to give savvy product developers an incentive to follow Mr. Christiansen's advice to optimize the interface for the task. This trend is only going to get worse as computing intelligence is embedded in more and more consumer devices. The temptation will be very strong for those developing software for such embedded systems to leverage interface designs they already have, rather than create from scratch. With more and more of a car, for example, being run by software, it's not hard to imagine MS someday proposing that you run your AutoPC through a modified Windows interface, even though such an interface would be totally inappropriate for the task at hand. Let's hope that more product & software designers take note of the evidence that people prefer optimized interfaces and don't automatically rule them out. -- Jason A. Lefkowitz "A statesman is a dead politician. Lord knows, we need more statesmen." -- Bloom County
all caps (Score:2) by kuro5hin (rusty@cromwellpsi.com) on Tuesday November 30, @PM EST (#) (User Info) cromwellpsi.com No, I don't use caps for much. Only for global constants, really, and even then, sometimes I don't. I'm a perl programmer, by the way. I started, however, as an HTML jockey, and during my servitude with that miserable beast, I got so I can type in all caps, just by holding down the shift key, almost as fast as I can type without holding it down. I was always in the "HTML tags are capitalized and that's that" school. So, the caps lock key is thoroughly useless and should, indeed be banned outright. The only thing it appears to be good for is getting in the way of the tab key and making me capitalize a whole line instead of moving it four (that's pronounced "The One True Tab") spaces to the right.
Is this following on from the poll? (Score:1) by anthonyclark (anthony dot clark at adv dot sonybpe dot com) on Tuesday November 30, @AM EST (#51) (User Info) from My comment from the last poll. What I want in a keyboard: Ergo/split design. All the programming symbols on their own keys ($#|{}[]()<>?@) Silent, soft but clicky keys. I hate noisy typists! A whole bunch of keys with durable 32x32 LED panels on them, programmable to display different symbols. (so I can reprogram the windows key to be a penguin without buying a new keyboard) (or so I could program a key to do C-c C-f for open or C-c < for docbook) Lasts a lifetime Function keys below the space bar Large keys so I don't miss On-board memory for keymappings and symbols (see above) Statistically designed using only programmers as the sample. This should give a keyboard with all those funny symbols in nice convenient places. AFAIK the dvorak keyboards were designed statistically with the most frequently used keys closer to the fingers. why not do this now, using programmers as the sample? It could run a bit like the SETI programme, with users installing a little daemon that just records how many of each key was pressed and then sends that back to a central server There should be no security risk as all that would be sent would be statistics, not something like the output from "script" Or maybe I need to think this through more I'm an INFP, what are you?
- A keyboard with only the most-often used keys for Windows cromwellpsi.com
cromwellpsi.com
- [FIXME: someday, put a sketch here of a keyboard I might use, if only ]
- Ergonomic Keyboards cromwellpsi.com
- "It took an average of only 52 hours of training for the typists' speeds on the Dvorak keyboard to reach their average speeds on the qwerty keyboard." -- cromwellpsi.com
- "It took well over twenty-five days of four-hour-a-day training for these typists to catch up to their old Qwerty speed. " cromwellpsi.com~liebowit/cromwellpsi.com . This is misleading; see cromwellpsi.com for details.
- The Dvorak keyboard cromwellpsi.com
- Dvorak International cromwellpsi.com
- "The Dvorak keyboard: A Brief Primer" by Randy Cassingham cromwellpsi.com explains the simple, reversible steps of how to switch Windows and MacIntosh to Dvorak keyboard layout.
- XKeyCaps cromwellpsi.com which can apparently be used to remap your keyboard on just about any X Window terminal. The most common use is to make the key to the left of A on a Qwerty keyboard act as the control key, and demote the Caps Lock key to a more appropriate location.
- "why the IBM PC does not have my favorite keyboard" article in DTACK GROUNDED, The Journal of Simple Systems Issue # 24 October Copyright Digital Acoustics, Inc cromwellpsi.com whines about control key placement and other keyboard details.
- How to Remap Your Keyboard
for Windows 98,
- Click on Start
- Click on Settings
- Click on Control Panel
- Double click on Keyboard
- Click on Language tab
- Click on Properties
- Select "United States Dvorak" from drop-down list (default is "United States ") (also available is "United States LH Dvorak" and "United States RH Dvorak")
- OK
- OK
For Windows , Macintosh, DOS, X Window, etc. see "How to Remap Your Keyboard" are available from cromwellpsi.com .
- the happy hacking keyboard cromwellpsi.com cromwellpsi.com /* was cromwellpsi.com */
- WristPC Model FA4 Keyboard cromwellpsi.com "Completely sealed, it can operate in the rain" "The WristPC keyboard comes with an optional wrist strap to provide the capability of attaching it to your wrist." DAV: I like the inverse-T arrow keys. The keyboard is very minimal, even fewer keys than the happy hacking keyboard . Surprisingly, the keys are in a perfectly rectangular grid, yet it still has all the letters of a full PC keyboard in exactly the same locations (very slightly shifted to fit onto the rectangular grid). the space key occupying 2 squares of the grid, all others occupy 1 square, This makes it just perfect for an embedded 10 key pad, with the space key acting as the zero key. And making the shifted up and down keys do pageup and pagedown makes sense. q w e r t y u i o p a s d f g h j k l BSP CAPS z x c v b n m ^ ENT [] [] [] [] space [] < V > | | | | | | | | | FUNC DEL arrow keys | | NUMLOCK | ALT CTRL
I imagine it would be pretty easy to convert to Dvorak.
Having to hit 2 keys to get `;' is difficult for a C programmer; and having to hit 2 keys to get "esc" is difficult for a "vi user". Perhaps getting making the key to left of z do "ESC" would be better for a "vi user". software_david_cromwellpsi.com#vi
- roll-up keyboards: DAV: There are quite a few keyboards that can roll up into a tight bundle. See "roll-up electronics" wearable_cromwellpsi.com#roll-up
- [FIXME: split ``ergonomics'' into 2 parts: ``normal'' (more or less) keyboards, a solid mass with buttons, vs. ``virtual'', where there's nothing really there which is further divided into datagloves, cameras that watch the fingers, and general-purpose touch sensitive surfaces -- DAV ] [virtual keyboard] cromwellpsi.com ``Virtual Keyboards Approach Reality: All-optical keyboards put typists in touch with their handheld devices.'' article by Michael Fitzgerald
Three competing companies -- VKB of Jerusalem, Israel, Canesta of San Jose, CA, and Virtual Devices of Pittsburgh, PA -- are selling products that use lasers to project an image of a full-sized QWERTY keyboard on a flat surface. Optical sensors then track the user's finger movements and translate them into keystrokes on a screen. The machine-vision software that goes into such systems is so complex that it could easily handle other tasks such as facial recognition.
You'd need both hands to count the methods inventors have proposed for typing without keyboards. Pressure-sensitive gloves, finger rings and “air” gloves that use fiber optics to detect finger curvature are among the many that will never leave the lab. But once other manufacturers started making tiny, low-cost optical sensors, Canesta's engineers were convinced they had the answer, says Bamji.
- "virtual keyboard" a sensor band tht you wear on your hand, across your palm and it senses and measures muscle tension when you move your fingers. [Who makes this ?]
- cromwellpsi.com [FIXME: keep lumping all human-to-computer input devices here, or make seperate sections for keyboards, pointing devices, etc ?]
If this is not done, the antivirus may not activate or activate for only 30 days. pblockquoteh3Trial (trial) keys for Kaspersky 2019-2020h3pbUpdated 02. 19bppDownload file licenses for Kaspersky 2019-2020ppiPassword for archive: websiteippThe program for kis 2019 trial reset and detailed instructions can be found inside the archive. The program is also suitable for other versions of the antivirus.
brpp[collapse]ppDownload keys for Kaspersky Internet SecurityppbThe last three fresh keysbppQUM3H-VFDCM-TW58W-8C16W (without proxy) br 1R6YA-XEWN9-MWFFH-F7KFC (without proxy) br B3DFM-Q3KGA-UP7WG-X5SQ6 (trial reset) br F9QF9-HN23H-RRTYZ-79CGK (proxy France 300 days) br TVUNE-3ZJXU-YD46R-TTU2E (Germany proxy 300 days)ppbKaspersky Internet Security (Russian proxy)b:pp6TB12-W6FPC-RYAYW-XCR22ppbKaspersky Internet Security for 90 days (European proxy)b:brbr Q6PZK-A8CAG-VBG9A-F7N46 br Q7DGF-S9EPE-JQ74E-BE96SppbKaspersky Internet Security for 91 days (England proxy)b:br (Instructions for changing proxies are at the bottom of the article) br TC88N-DYTFH-3S9GN-9E6X7 br GE8U8-QT8B6-BQNJ2-N84D7 br Q5WD2-XKMBD-YSM49-834HB br Q6D92-7NCZH-2A79K-ARP4CppbKaspersky Internet Security - Multi-Device for 60 days (proxy India)b:br (Instructions for changing proxies are at the bottom of the article) br CBFDK-HB478-TY7VU-9K6GW br R13EF-PJY95-YK3FV-3F445 br WNFET-CHA2U-H2EYX-C9G2N br WNFR3-Q129W-F6CU6-8MCTYppbKaspersky Internet Security (2012 - 2017) for 90 daysb:br (Instructions for changing proxies are at the bottom of the article) br 95XKY-9HS4E-R315U-HVJZB br 4CH4C-PPFDT-NFK4B-45R69 brATTENTION.
.What’s New in the 68HC11 Simulator Toolbox 2.0 serial key or number?
Screen Shot
System Requirements for 68HC11 Simulator Toolbox 2.0 serial key or number
- First, download the 68HC11 Simulator Toolbox 2.0 serial key or number
-
You can download its setup from given links:
68HC11 Simulator Toolbox 2.0 serial key or number & Kali Software Crack
68HC11 Simulator Toolbox 2.0 serial key or number& PC Free Download
68HC11 Simulator Toolbox 2.0 serial key or number
About Author
