davee@hpgrla.UUCP (davee) (12/12/84)
I am using an hp110 from a hotel room right now. The reason that they turn off the softkeys is because if they are on while you are in vi, the cursor ends up one line below where the pointer is in the file. I suspect that this is caused by fact that when the keys are on, you have less physical screen that you can use. (The softkeys take up 2 lines.) What irritates me is that if the softkeys are off when you enter vi, everything is okay, but if they are on you have to realize it, turn them off, and cntr-L to line things up. (Not fun at 300 baud.) Is there a termcap sequence that will get called when you enter vi? BTW, I think your change to a an escape code ending in C is correct but I haven't tried it out. Also, the hp110 doesn't have half-bright. Dave Ellis / GLD hpfcla!hpgrla!davee
barrett@hpcnoe.UUCP (barrett) (12/17/84)
# With the plethra of termcaps for the 110 posted here, I thought I would # compare them. Virtually all of them are identical except the most # recent posting which includes some additional capabilies like :bl and # :le, redundant ones like :ta Here is one which includes the best of # both: (I don't have an hp110, so forgive some ignorent questions) # # Notes: # # 0) Capabilities are in alphabetical order. # 1) I suspect that :cm should be :cm=\E&a%dy%dC instead. # 2) If the 110 has memory, and the home is absolute, then :ho should # NOT be specified. # 3) The :is function removes function key labels. (why?) # 4) What are the :bl (bell?), :le (left?) :me (end enhancement?) capabilities? # 5) For :so I used half-bright inverse video, rather than full bright. # 6) Why does :ti and :te turn off screen labels? # # Dave Barrett # Hewlett-Packard, Colorado Networks Operation # zz|hp110|110|hp110a|nomad|hp110a portable computer\ :al=\EL:am:bl=^G:bs:bt=\Ei:cd=\EJ:ce=\EK:ch=\E&a%dC:cl=\EH\EJ:\ :cm=\E&a%r%dc%dY:co#80:cv=\E&a%dY:da:db:dc=\EP:dl=\EM:do=\EB:\ :ei=\ER:ho=\EH:im=\EQ:ip=2:is=\E&j@:k1=\Ep\r:k2=\Eq\r:k3=\Er\r:\ :k4=\Es\r:k5=\Et\r:k6=\Eu\r:k7=\Ev\r:k8=\Ew\r:kd=\EB:ke=\E&s0A:\ :kh=\Eh:kl=\ED:kn#8:kr=\EC:ks=\E&s1A:ku=\EA:le=\ED:li#16:me=\E&d@:\ :mi:nd=\EC:pt:se=\E&d@:so=\E&dJ:ta=2^I:te=\E&j@:ti=\E&j@:ue=\E&d@:\ :up=\EA:us=\E&dD
barrett@hpcnoe.UUCP (barrett) (12/18/84)
The problem you had with the escape sequences that did not reverse the parameters is that they were wrong. The correct sequence is: :cm=\E&a%dy%dC ^ ^ see these letters, they are case sensitive and screen relative! Vi will use the :vs sequence on entering visual mode and :ve on ending visual mode. You should have them as follows for the 110: :vs=\E&j@ :ve=\E&jA assuming that you want the "modes" keys to be displayed when vi exits. Dave Barrett hp-dcd!barrett
hansen@pegasus.UUCP (Tony L. Hansen) (12/27/84)
< Vi will use the :vs sequence on entering visual mode and :ve on ending < visual mode. You should have them as follows for the 110: Excuse me, but vs and ve are the sequences to make the cursor very visible or normal, respectively. Vi does output those sequences at the beginning and end of visual mode, but not for the reasons implied by your statement. From my terminfo documentation: terminfo variable term- term- description info cap cursor_normal, "cnorm" "ve" Make cursor appear normal (undo vs/vi) cursor_visible, "cvvis" "vs" Make cursor very visible The sequences that you are thinking about are ti and te, which are output by vi and curses when entering/exiting visual mode. enter_ca_mode, "smcup" "ti" String to begin programs that use cup exit_ca_mode, "rmcup" "te" String to end programs that use cup Those are the sequences which you should be manipulating, rather than the vs/ve strings. Tony Hansen pegasus!hansen
rjn@hpfcmp.UUCP (rjn) (01/21/85)
[] re: termcap for HP110 {"The Portable"}
Here is some stuff I've collected - haven't tried it yet myself...
/**********************************************************/
Here is a version of the 110 termcap that <deleted> wrote when he
and I were still doing 110 code. The only problem I have seen with it
is that underline is mapped to blink so that man pages look a bit funny.
We have used this with vi, emacs, notes and it seems to work OK.
Unfortunately, emacs will not really work at 9600 baud.
nn|hp110|110|nomad|hp110a The Portable:\
:is=\E&j@:cm=\E&a%r%dc%dY:dc=\EP:ip=2:co#80:li#16\
:kn#8:k1=\Ep\r:k2=\Eq\r:k3=\Er\r:k4=\Es\r:k5=\Et\r:k6=\Eu\r:k7=\Ev\r:\
:se=\E&d@:so=\E&dB:us=\E&dD:ue=\E&d@:k8=\Ew\r:\
:al=\EL:am:bs:cd=\EJ:ce=\EK:ch=\E&a%dC:cl=\EH\EJ:\
:cv=\E&a%dY:da:db:dc=\EP:dl=\EM:ei=\ER:im=\EQ:\
:kb=^H:ku=\EA:kd=\EB:kl=\ED:kr=\EC:kh=\Eh:ks=\E&s1A:ke=\E&s0A:\
:nd=\EC:se=\E&d@:so=\E&dJ:us=\E&dD:ue=\E&d@:up=\EA:
/********************************************************/
Something like this should work ok; if you're running emacs you may want to
get rid of the al and dl fields; I've never been able to get enough padding
to make them work right.
zz|hp110|110|hp110a|nomad|hp110a portable computer:\
:is=\E&j@:cm=\E&a%r%dc%dY:dc=\EP:ip=2:co#80:li#16\
:kn#8:k1=\Ep\r:k2=\Eq\r:k3=\Er\r:k4=\Es\r:k5=\Et\r:k6=\Eu\r:k7=\Ev\r:\
:se=\E&d@:so=\E&dB:us=\E&dD:ue=\E&d@:k8=\Ew\r:\
:am:bs:cd=\EJ:ce=\EK:ch=\E&a%dC:cl=\EH\EJ:\
:cv=\E&a%dY:da:db:dc=\EP:ei=\ER:im=\EQ:al=\EL:dl=\EM:\
:kb=^H:ku=\EA:kd=\EB:kl=\ED:kr=\EC:kh=\Eh:ks=\E&s1A:ke=\E&s0A:\
:nd=\EC:se=\E&d@:so=\E&dJ:us=\E&dD:ue=\E&d@:up=\EA:
/* ---------- */
Regards, Hewlett-Packard
Bob Niland 3404 East Harmony Road
hplabs!hpfcla!rjn Fort Collins
CO 80525carl@hpcnoe.UUCP (carl) (03/22/85)
Any particular reason why you require BASIC? There's an extremely good HP terminal emulator which runs as a standalone operating system. Carl Dierschow / Hewlett Packard
dat@hpcnof.UUCP (dat) (07/15/85)
As far as having a remote ROM serial number or some other remote hardware device to ensure that the user doesn't have a ripped-off copy of software; I think it is a kind of dumb idea - it would be VERY easy to hook up some sort of line-protocol analyzer on the line and figure out what is being sent back and forth, and then build a little simulator that could fake it out...and the one you build would probably be significantly less expensive than the original unit! Another problem is that these assume that there is an unused port on the equipment...if I had to constantly mess with the wiring on my PC each time I wanted to change programs I would start thinking seriously about selling it until the manufactorers got their act in gear. I system I prefer is a hardwired serial number in the BIOS ROM of each PC - the program checks that and stores it, encoded, in it's own code... The biggest issue is that adding all this crap is just going to make software more and more expensive and motivate more people to try to rip off software (I wouldn't pay more than the cost of my PC for ANY program!!!). A more fruitful alternative is to work on generating software as CHEAPLY as possible to allow people to go and BUY it since it's worth the cost to be a supported, legit owner with the real users guides and updates. JRT and Turbo (Are they the company names?) have both made a name for themselves in the PC marketplace by using this sort of philosophy - while Microsoft offers the Microsoft Pascal Compiler for ? $300+ ? JRT and Turbo offer BETTER products at vastly lower prices (under $50.00 including extraneous software and well written user guides). I much prefer to deal with the latter two companies, personally... Enough topic wandering :-) -- Dave "High Notes Drifter" Taylor HP Colorado Networks PC Networking Group ..ucbvax!hplabs!hp-pcd!hpcnoa!d_taylor #! rnew
john@hp-pcd.UUCP (john) (07/17/85)
< I think it is a kind of dumb idea - it would be VERY < easy to hook up some sort of line-protocol analyzer on the < line and figure out what is being sent back and forth, and then < build a little simulator that could fake it out...and the one < you build would probably be significantly less expensive than < the original unit! Depends on how difficult you make the encoding scheme. If you used an encryption scheme like DES with a unique serial # in each device then it would be easier to disassemble the program rather than try and break the protection. The program would pass a random # to the hardware key and ask it to encrypt it using its internal number. The program could then encode the same number and verify it. Even a relatively weak encryption scheme could lock out 99 % of potential copiers. < I system I prefer is a hardwired serial number in the < BIOS ROM of each PC - the program checks that and stores it, < encoded, in it's own code... We do that on the Portable (AKA HP-110) and Portable Plus computers. A program can read the serial # of the computer it is running on and decide if it should abort or run. On of the best ways to copy protect software is to distribute it in ROM. The 128K byte roms currently have a high enough mask charge to make small numbers uneconomical to copy. Large volume cost more than floppies but gives the user a product that can be quickly loaded and will not wear out after X number of revolutions. John Eaton !hplabs!hp-pcd!john #! rnew
tim@hpfcla.UUCP (tim) (07/25/85)
I personally am not a real security fanatic, myself. The 'dongle' approach is nice for another reason - if you have two systems (identical) you can take the dongle with you (i.e. work-home). One of the responses mentioned a 'port limitation' problem. The one 'dongle' I have seen was an IEEE-488 (HP-IB, GPIB,...) style. The great thing about IEEE-488 is that you can keep stacking things on it (up to a 14 device limit - but you could use extenders up to 31). You can break them by using a hardware analyzer of some sort, but it would have to be a pretty fancy analyzer depending on the style of 'dongle'. Tim Mikkelsen hplabs!hpfcla!tim
dat@hpcnoa.UUCP (dat) (08/16/85)
The nickle solution is to rename config.sys to something else and then create a new one using your favorite editor (that's what I had to do on my 150...) -- Dave Taylor HP Colorado Networks ..ihnp4 \ ..decvax!hplabs \ !hpfcla!d_taylor ..ucbvax!hplabs / ..hpbbn /
ericr@hpvcla.UUCP (ericr) (09/16/86)
The 82905B can be converted to Centronics but it will only talk in HP escape sequences rather than Epson sequences. So, if you just have text applications that support HP or are configurable to support HP then the conversion is worth your effort. Procedure: (Warning: This will void your warranty) 1) Take the knob off. 2) remove the top cover. 3) There is an interface board for your (I assume HPIB) interface. Remove the board. 4) Reassemble the printer. The interface board uses the Centronics interface to communicate with the printer. With the interface board removed, the bus contention is removed. Eric Ross ihnp4!hpfcla!hpvcla!ericr