glmwc@marlin.jcu.edu.au (Matt Crowd) (12/20/90)
In article <650@cbmger.UUCP> peterk@cbmger.UUCP (Peter Kittel GERMANY) writes: >Well, probably not before the software is really put into ROMs/EPROMs >on the A3000. When this state is reached (it is HOPED to appear soon, >it always depends on how many bugs are still found), THEN it will be >POSSIBLE to make up things also for other users. But the actual release >is again a marketing decision, not our field. Well it seems damn stable to me. Every bug in 1.3 that our rather largish program has discovered is fixed in the version of 2.0 that I have. Not only that but it runs considerably faster at some things (ScrollRaster, PrintIText (seems to be but might be my eyes), Loading a large file from the RamDisk, and lots of other stuff). IMHO, at present 2.0 is much more stable that 1.3 ever was. The only thing that is annoying is the longer wait when switching back from an editor window back to the shell. It takes much longer to update the shell window than it used to under 1.3. This is probably due to the nicer auto-updating window but it would be nice if this was quicker in the ROM version (listening guys? :-) ). BTW, have you fixed the printer driver feature that makes the requester for the printer being off line take so long to come up? I haven't tested this yet. >Best regards, Dr. Peter Kittel // E-Mail to \\ Only my personal opinions... >Commodore Frankfurt, Germany \X/ {uunet|pyramid|rutgers}!cbmvax!cbmger!peterk Matt. -- Matt Crowd Amiga Man Email Address glmwc@marlin.jcu.edu.au
peterk@cbmger.UUCP (Peter Kittel GERMANY) (12/21/90)
In article <1990Dec20.131346.23479@marlin.jcu.edu.au> glmwc@marlin.jcu.edu.au (Matt Crowd) writes: > >BTW, have you fixed the printer driver feature that makes the >requester for the printer being off line take so long to come up? I >haven't tested this yet. This is really a "feature". The timeout is a constant defined by the writer of the driver program and is a fixed value. In most cases they chose the recommended value of 1 minute. But I as well already was in a situation where I found this annoying. Perhaps one could put this into the printer preferences? I think another solution that comes to my mind is not real possible: to let the printer driver open a little window on Workbench with a cancel gadget and a wording "printing in progress", where you may cancel the output at any moment. But what if Workbench was closed? The timeout value is placed among the very first bytes in a printer driver. If you take out the RKMs, it shouldn't be too difficult to patch your driver for more convenient values. -- Best regards, Dr. Peter Kittel // E-Mail to \\ Only my personal opinions... Commodore Frankfurt, Germany \X/ {uunet|pyramid|rutgers}!cbmvax!cbmger!peterk
jap@convex.cl.msu.edu (Joe Porkka) (12/22/90)
peterk@cbmger.UUCP (Peter Kittel GERMANY) writes: >In article <1990Dec20.131346.23479@marlin.jcu.edu.au> glmwc@marlin.jcu.edu.au (Matt Crowd) writes: >> >>BTW, have you fixed the printer driver feature that makes the >>requester for the printer being off line take so long to come up? I >>haven't tested this yet. >may cancel the output at any moment. But what if Workbench was >closed? Then you open it first :-) Actually in the printer driver that I wrote, it opens a window on the wbscreen (for another reason). If the screen was closed, then it opens - the only problem being that the WorkBench interface gets lost. I suspect that doing an OpenWorkbenchScreen() first would fix it. >The timeout value is placed among the very first bytes in a >printer driver. If you take out the RKMs, it shouldn't be too >difficult to patch your driver for more convenient values. Perhaps you couldclarify this point. I have written my own custom printer driver and the exact way the timeout is used is not clear. My only guess is that it is the time between sending a packet to the (parallel|serial).device and recieving the reply. I think that maybe the #?.device needs to be enhanced to give info about how much time has passed since it was able to send data, or have the timeout depend on the packet size, or simply do not send packets greater than some x number of bytes - all to allow for a small timeout (say 5 or 10 seconds).
peterk@cbmger.UUCP (Peter Kittel GERMANY) (12/29/90)
In article <1990Dec21.182047.12630@msuinfo.cl.msu.edu> jap@convex.cl.msu.edu (Joe Porkka) writes: >peterk@cbmger.UUCP (Peter Kittel GERMANY) writes: > >>The timeout value is placed among the very first bytes in a >>printer driver. If you take out the RKMs, it shouldn't be too >>difficult to patch your driver for more convenient values. > >Perhaps you couldclarify this point. Oh, I hoped nobody would ask :-). You see, I did this ONE time in my life (with not SO much success) and still under 1.2, that I tried to write a printer driver. There was that little part that had to be in Assembler, named printertag.asm that had to be linked as the very first part of the final driver code. It has the entry "DC.L 30 ;Timeout" at offset about 60 from the beginning (add some bytes for hunk header in the file). Details are found in the RKM Libraries & Devices (1.3, blue), p. 764. -- Best regards, Dr. Peter Kittel // E-Mail to \\ Only my personal opinions... Commodore Frankfurt, Germany \X/ {uunet|pyramid|rutgers}!cbmvax!cbmger!peterk