SLSW2@cc.usu.edu (Roger Ivie) (04/29/90)
In article <A8AE650AB7BF804CA0@uwplatt.edu>, UCSLCT@UWPLATT.EDU (LANCE TAGLIAPIETRA) writes: > The osborne version > loads in and runs, but gives a very strange cursor > (inverse video m)@(block cursor) and prints this sequence between > every character entered. Back in the old days, I took DBASE from an Osborne and worked over with ZSID to run on an H19. As I recall, all you have to do is find that escape sequence and patch its count byte to zero. It will then not print out that escape sequence after every character. After quite a while, I discovered that the dBASE from the Osborne was missing an overlay (I forget which) but I wasn't able to determine if it was shipped without the overlay or if I merely missed it in the upload (the Osborne was long gone by then). I think the missing overlay had something to do with the MODIFY command. =============================================================================== Roger Ivie 35 S 300 W Logan, Ut. 84321 (801) 752-8633 ===============================================================================
luke@i88.isc.com (Luke Weerts) (05/03/90)
In article <A8AE650AB7BF804CA0@uwplatt.edu> UCSLCT@UWPLATT.EDU (LANCE TAGLIAPIETRA) writes: >Has anyone gotten Dbase II to work properly on a TRS-80 Model IV >using Montezuma Micro CP/M. I have a working copy for my Osborne >1, and the DBINST.COM installation program. The osborne version >loads in and runs, but gives a very strange cursor >(inverse video m)@(block cursor) and prints this sequence between >every character entered. I also have the demonstration program >for Dbase II which runs fine (no strange characters). It signs >on as version 2.3B DEMONSTRATOR. Also, what is the difference >between this version, and the non-demonstrator version, besides >that the installation program does not seem to work with it. > >If you need more info to help me, just ask, any hints would be >appreciated. > >Lance These characters are probably part of an unrecognized escape sequence which the osborne uses to do special stuff like cursor positioning or bold print or some such thing. When running on the osborne, is the field being typed in highlighted or underlined or some special video effect? That's a clue that this is an escape sequence. The demonstration probably does all its screen updating as if the video display is a dumb terminal ie. without cursor positioning, repainting the whole video screen on update, etc. Generally, demonstration programs disable the save/write functions which would allow someone to keep their changes, making it useless for real work. To change the program, try to figure out the hex equivalents of the unwanted characters and place an escape character in front of it. Then go to your osborne users manual and see if this matches some escape sequence to do fancy stuff. Find out if the TRS-80 has a similar function. Generally a program which runs on many different terminal types has this string of characters defined in a single spot in the install program either as a length prefixed string or a string with a zero byte at the end. Use a debugger (DDT, Z8E) and find this set of characters in the DBINST.COM file and place a length of zero in the byte before the string if it appears to be the length of the string or zero out the bytes if that first byte doesnt seem to be the length of the string. Save this modified version of DBINST.COM (to another name of course) and try to install Dbase again. This should clear up the problem. How do I know this you ask. Once I had a comm program that used Kaypro 4 video highliting for some messages but on my old Kaypro II it came out as weird characters like you described because the II (pre-84) did not support video highliting. Good luck. Let me know if this helps. Luke -- Luke Weerts, Software Technologies Group | luke@i88.isc.com INTERACTIVE Systems Corporation, Naperville, IL | ...!{sun,ico}!laidbak!luke