hsgj@batcomputer.tn.cornell.edu (Dan Green) (12/05/86)
first I would like to thank everyone to replied about my concern that the new (V1.2G1) Amiga-Emacs has some bugs. Apparently it does indeed "lock up" occasionally when the Global-Replace and Insert-File commands are used. No one seemed to know why, but hopefully it will be fixed by next release. Three Quick (and hopefully non-boring) Questions: 1) I just bought the Commodore 1200 bps Modem. I really like it and it works fine with AmigaTerm (included). I leave the modem plugged in all the time. Question: Is this ok? I don't want it to overheat, but there is no "on/off" switch, and it is a pain to keep unplugging the power-transformer from the wall socket. So does anyone know if bad things will happen to the modem if I leave it plugged in all the time? 2) I have Lattice C. When possible I try to compile WITHOUT lc.lib and use Astartup.obj. This works fine (assuming I use no stdio functions) but I always get undefined variables "__base" and "__xcovf" when I BLINK. However, the application still runs. I have been putting "char *base" and "char *xcovf" declarations to silence the errors, but this is a real kludge. What the heck are "base" and "xcovf" for anyways? Note: "base" is not IntuitionBase or ExecBase or GfxBase, but just plain, old "base". I.E. it does not seem to be a library entry point. I have no idea what "xcovf" is. 3) I am thinking about commercially distributing an Amiga program I wrote. However I used Sam Dicker's "vtbeep" to get a bell sound for a certain part of the program, because I don't like DisplayBeep(). Obviously I have to give credit to him for the beep. However, I do NOT want to have to put up a requester on program startup saying "vtbeep courtesy Commodore Amiga". For all the moral and ethical lawyers out there, would it be "OK" to merely give credit for the beep in the documentation, and not in the program itself? Please realize that the beep is an extremely trivial part of the program, but something I want to keep. I have no urge to fool around with the Audio Device, which is why I am using Dicker's code. Note: vtbeep is "copyrighted" public domain but it has one of those "you must include this message if you use this code" stipulations. End of questions, and now a final comment: The Notepad has been getting better and better, but the print function, while working fine, is not that fast. I noticed when I attempted to print a two page note (in "Emerald font" to look cool) that even though 3/4 of page one was blank, the Notepad apparently just trudged along sending the bitmap pattern of 80 "Emerald" spaces to the printer. In other words, it took just as long to print a blank line as it did to print a text line. On my Epson compatible where you have to program each dot, this means that it takes about 2 seconds/line. Perhaps in future NotePad (take note Wordprocessor authors) the print routine could scan the line to be output, and if it is all blanks, just output a carriage return instead of hundreds of blank graphic pixels. This would speed prints trememdously for sparse pages. Also, Notepad has, not a bug, but a Bad Feature. Notably, never ever re-size the Notepad window while you are printing! Hasn't Commodore-Amiga heard of the SIZEVERIFY flag? If you size the window while printing, the window is not refreshed (because the program is busy sending pixels to the printer). The printer then starts printing the window borders, or the "null space" where notepad text and paper background should be. A feature I would like added to Notepad, beyond fixing the window, is that a requester saying "Printing in Progress, please wait" should pop up when printing. This is because the print takes so long that you might forget it is printing, and try executing a Notepad command. The command obviously won't execute until the print is done, making it appear that Notepad is "hung". The requester (or maybe just a window title message) would remind you that printing is still going on. I'd appreciate any comments on either the questions or the Notepad suggestion. -- Dan Green -- ARPA: hsgj%vax2.ccs.cornell.edu@cu-arpa.cs.cornell.edu UUCP: ihnp4!cornell!batcomputer!hsgj BITNET: hsgj@cornella
carolyn@cbmvax.cbm.UUCP (Carolyn Scheppner) (12/06/86)
re: unresolved references to __base and __xcovf
These are variables referenced by the stack checking code that
Lattice adds to each of your functions UNLESS you use the -v flag
on LC2. The -v flag should be used when you are compiling anything
that will be linked with AStartup.obj or no startup.
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Carolyn Scheppner -- CBM >>Amiga Technical Support<<
UUCP ...{allegra,caip,ihnp4,seismo}!cbmvax!carolyn
PHONE 215-431-9180
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=wagner@utcs.UUCP (12/08/86)
Dan Green brings up some good points about printing on the Amiga. He gave them in the context of NOTEPAD, but, in fact, they are problems with Amiga printing in general. Raster map printing seems to take forever, and there seems to be little one can do about speeding it up. The print drivers all seem to output long strings of blank rasters. I'm writing a program to rasterize the output from Aegis Draw (I know, they did it themselves already), and I've spec-ed out the section which compresses blank sections of output. It's not that hard. Maybe a good suggestion for v1.3? Another thing that would speed up the printer would be support for spooling within the driver. That is, have the printer.device accept data and buffer it (in ram or disk or some combination according to a flag in preferences). And now a suggestion for a function enhancement (as opposed to a performance enhancement). It would be nice if there were another level of talking to the printer.device besides the text and bitmap levels. I would like to be able to specify graphics (and 'fonted' text) and let the printer rasterize it at the resolution of the printer. The calls should be identical to the calls for the screen. Then, an application could write on the screen by issuing a set of calls; switch it's attention to the printer, issue the same calls and get the better resolution of, say, a laser printer. Another suggestion for 1.3, perhaps? Michael