bryce@COGSCI.BERKELEY.EDU.UUCP (04/18/87)
Amiga BUGLIST. Each bug/condition has been verified as repeatable in V1.2 (Release or Gamma1), and is not related to any hardware problems. Pass this list around, add to it, and see that C-A gets a copy every now and again. Bugs with a "<" are already know. Contributors: bryce@cogsci.berkeley.EDU/415-524-2110 Hans Gregory dillon@cory.berkeley.EDU <A phantom hacker> -- Trackdisk -- Sticking a disk in a drive, then changing your mind and pulling the disk back out can severely confuse trackdisk. It will continue to step and notice disk insertion, however DOS will never find out about a disk placed in that drive until a re-boot. Timing is critical, but repeatable; insert a new disk in, wait for the light to come on and the first 'grind' as the head steps to block 880. Pull the disk out before it gets there; If you get a 'disk corrupt' requester you waited too long. Repeat, varying timing until the CLI 'info' command locks up when getting the status of the 'dead' drive. This can also happen if your finger slips on the button while removing a disk, and that, in fact, is how I noticed this bug. -- ED -- Type "fish". Press and hold the "-" key until the message "Line Too Long" comes up. Now type <CTRL><]> (control-bracket). 'Poof',the line disapears. Now cursor up to the "h" in "fish" and hold the "-" key until the "Line Too Long" message comes up. Save to disk with <ESC>,<X> (escape then "x") Ed has now crashed. -- DOS -- Calling Delay(0), or WaitForChar(blah, 0) (any DOS call which takes a timeout and setting that timeout to 0) intermittently crashes the Amiga. ( Test program: for(;;) Delay(0); ). DOS devices such as RAM: or PIPE: that are meant to have a single invocation/filehandle for multiple users have a problem. If two programs attempt to reference the same DOS device simultaneously, and DOS must load it from disk, the window is sufficiently large to cause separate invocations of the driver (instead of just one) for each program causing all sorts of problems. [Mini editorial:] The DOS driver must set a field when it starts up to cause DOS not to make separate invocations. Rightly, this should be a bit or field in the Mountlist. [suggestion] BCPL programs link weird, and a exec() function should be provided that will allow alternate CLI programs to function without major structure fondling, compromises or kludges. The current DOS execute() does not qualify. !!Requested by several programmers!! [suggestion] Error #200,'internal error' - #201,'newer operating system required' [suggestion] Rather than have empty drives 'click' every 3 seconds simply reset the DISKCHANGE* latch by stepping outward repeatedly. The optical stop is there, it reduces noise, wear on the mechanism and the sample rate can be upped without driving people batty. [suggestion] Preference item to enable/disable a requester warning when a file is about to be overwritten. Must be software setable so programs with such protection already installed will not cause the user to be asked twice. -- Exec/Intuition -- Disk insertion should NOT <RETRY> a 'software error - task held' requester. Alerts display the text message in the system font, NOT a hard coded ROM font. If the default system font has been changed to a RAM based font and if becomes trashed, the alert will be unreadable. Not a bug, but a survivability concern. The Alt-Amiga combinations are not accepted when alerts want a mouse button press. -- Intuition -- ! ! I have a tool that opens a window on the Workbench screen. It works ! perfectly. I wished to speed up text writes to this window so I set the ! rp_Mask field to $1, this too worked fine; that is until I depth arranged ! the window and it started dropping bitplanes all over the place. $FE,$FD ! provided the same results. I was shocked, one would think that Intuition ! would have it's own idea about rp_Mask. My tool now does things the old ! way, monochrome text written into two bitplanes when the second plane is ! already at a known state. AHHHHH!!!!!! ! For monochrome text the proper approach should be to clear/set all planes ! of the text area, and write the text into only one of them. Common sense. ! < Place a window in the center of the screen and start a window resize. Hit < Left Amiga-N or M. Continue the resize PAST the top left corner of the < window. < When the system is nearly out of memory menus can still be pulled down, but the actual graphics will not be drawn. [mini-editorial:] Why not calculate and reserve the proper maximum amount of memory needed at the time a new strip is submitted to Intuition. One memory pool will serve all menus, since only one menu and one sub can be pulled at a time. Intuition should skip ahead to the latest mouse position report after pulling down a menu, rather than responding to each in turn. -- Workbench Bugs -- Type 'LoadWB' after hanging around in the CLI for a while. Workbench will ask for each know volume in turn. <CANCEL> will not convince the Workbench to give up asking for a disk that may be long gone, lost, formatted, copied over or even relabeled. Either the <CANCEL> option should not be selectable, or it should cause WB to ignore that disk/lock until it shows up on it's own accord. Dropping a dragged icon at EXACTLY the right time, into the space where a new disk icon is ABOUT to appear will cause that icon to 'stick' to the pointer even after the button is released. Moving the pointer to the title bar and clicking crashes the machine. V1.0,V1.1 & V1.2 repeatable. < < Vigorous resizing of WB windows will trash the 'Gas gauge' < Corrupt .info files can crash the Workbench tool. Sample 'killericon.info' available on request. If Workbench is not already doing it, these steps should be taken: 1> RENAME instead of COPY if the source and destination locks refer to the - same volume. 2> When updating the '.info' file, if no substantive changes are needed - update the datestamp with a seek, rather than with a new file. 3> When 'snapshoting' a '.info' file seek to the position variables and - modify them in place, rather than creating a new file. -- V1.2 RAM: bugs -- < < Create an empty file. Delete it. The block count will be incorrect. < [COPY * TO FISH , <CTRL><\> , DELETE FISH , repeat , INFO] < Block counts such as -3 are easy to create. < related: If the first copy that sets up the RAM: fails due to lack < of memory the block count will be similarly screwed. < Rename allows duplicate file names. [create files 'fish' & 'frog' rename one to match the name of the other] -- Font editor -- Select 'OPEN' from the menu. While the editor is reading in the font names, move the 'ZOOM' gadget. Crash. DOS related requesters belonging to the font editor appear in the Workbench screen, not the font editor screen. Set the pr_WindowPtr in the DOS process structure. -- EMACS Bugs -- In EMACS, select SAVE AS with mouse. Save a long file to floppy. While it is grinding away, select SAVE AS again and type another filename. EMACS does not like this, and will become upset. The justify function (^X^J) is broken. Crashes always. The 'ENTER' key does not function properly when inputing on the bottom line -- StripA (From Toolkit, strips extra symbol hunks from executables -- Files often do not work after the treatment. Example; the notepad. -- User interface -- The input device/Intuition does not track pointer movement during such operations such as window resize. This 'feels' sloppy. Some hyper-high priority task should keep the pointer visuals intact, even if Intuition is stomping on the input.device task. In cases where <RETRY> or <CANCEL> on a requester is NOT a valid operation, the gadget should not be present, or selectable. Example: <RETRY> on most 'task held' requesters. <CANCEL> should <CANCEL> .period. none of this asking twice stuff. 'Desk' accessory menu to help combat clutter on the Workbench screen. Direct support for moving windows from one compatible screen to another. -- Documentation -- The examples in Intuition manual encourage limiting window growth to 640*200. PAL, interlace & morerows freaks hate this. The manuals should encourage no limits if none are required. Many, many people miss setting the NOCAREREFRESH flag in their SMART_REFRESH windows, thus causing extra refreshes forever after a window resize.
kent@xanth.UUCP (Kent Paul Dolan) (04/19/87)
Environment: WorkBench 1.2, 2.5 Megabytes, 1 disk drive (df0:).
Problem: Info function reported two disks plus ram: all mounted,
copy from ram: copied to wrong disk.
Reproduce by: I don't know.
Details: I scratched the surface of disk Communications_1.2: right
in the middle of the vt1002.4 executable. I saw that the
disk was scratched, so brought up workbench 1.2. I wanted
to clean the disk drive, so I ran v1.1 format, twice, since it
writes all the tracks before verifying any, and thus gives
a longer cleaning cycle than does the 1.2 format. The first
time, after the write cycle, I got impatient for the track
zero verify to fail (didn't know if it would) and so popped
the disk out of the drive, getting the expected error. The
second time I let format time itself out.
I put workbench 1.2 back in and copied :c to ram:c, to have
working code available for the rest of the process. I never
reassigned C:, just typed ram:c/function all the time.
I made a directory called ram:communications_1.2. I deleted
c/vt1002.4 from the damaged disk, and then did a
copy communications_1.2: ram:communications_1.2 all
to recover most of the files from the damaged disk.
Next, I copied vt1002.4 from a back-up disk into
ram:communications/c. Next I formated a new communications_1.2
disk. Since format is in system under 1.2, that started with
my workbench_1.2 disk in the drive, and I put it back when the
format was done, to shut the drive up while I put a label on
the new disk.
I did an info, just for heck, to see how busy my ram: was
getting, and noticed, but didn't think much about, ram:,
workbench_1.2:, and communications_1.2: all being shown as
mounted. Now I issued
copy ram:communications_1.2 communications_1.2:
and the machine promptly began to write all over my working
copy of workbench_1.2:.
Grrrrr. Another disk to rebuild. (BTW, diskcopy takes 3
passes on one drive systems even with add on memory. Yuk.)
Sorry to make this so drawn out, but a lot went on here, and I have no idea
which of my bits of idiocy managed to elicit one from the system, but there
should be some reasonableness check built in to convince the workbench that I
probably didn't have two floppies in the same drive at once.
Isn't home computing fun! Kent.
--
The Contradictor Member HUP (Happily Unemployed Programmers) // Yet
// Another
Back at ODU to learn how to program better (after 25 years!) \\ // Happy
\// Amigan!
UUCP : kent@xanth.UUCP or ...{sun,cbosgd,harvard}!xanth!kent
CSNET : kent@odu.csnet ARPA : kent@xanth.cs.odu.edu
Voice : (804) 587-7760 USnail: P.O. Box 1559, Norfolk, Va 23501-1559
Copyright 1987 Kent Paul Dolan. How about if we keep the human
All Rights Reserved. Author grants free race around long enough to see
retransmission rights, recursively only. a bit more of the universe?hobie@sq.UUCP (04/21/87)
One of the bugs mentioned in this list is that the rp_Mask field
in the RastPort doesn't seem to do much. I had this problem when using
ClipBit() to copy a 4-plane RastPort to a 5-plane screen, replacing a previous
5-plane image, and setting the rp_Mask appropriately (0x1f for 5 planes, 0x0f
for four). What happened is that the four planes of the second image appeared,
along with the fifth plane of the first. Any comments, CATS?
Hobie Orris |
SoftQuad Inc., Toronto, Ont. |"There'll be no more giant leeches
{ihnp4 | decvax | ? }!utzoo!sq!hobie | When you find the good Lord Jesus"
(NSA terrorist CIA cryptography DES drugs NRO cipher IRS secret RSA decode
coke libyan crack penguin lust russian nuclear missile atom assassinate) gary@eddie.MIT.EDU (Gary Samad) (04/28/87)
In article <1987Apr21.152123.4753@sq.uucp> hobie@sq.UUCP (Hobie Orris) writes: > One of the bugs mentioned in this list is that the rp_Mask field >in the RastPort doesn't seem to do much. I had this problem when using >ClipBit() to copy a 4-plane RastPort to a 5-plane screen, replacing a previous >5-plane image, and setting the rp_Mask appropriately (0x1f for 5 planes, 0x0f >for four). What happened is that the four planes of the second image appeared, >along with the fifth plane of the first. Any comments, CATS? Yes, I've had some bizare problems with rp_Mask also, but have finally figured it all out. As for your problem, the rp_Mask in the RastPort simply defines how many planes will be written whenever you write into that RastPort. So, your 4-plane image is correctly rendered into your 5-plane window. That fifth plane is NOT erased, but is left alone. The other problem which was mentioned in the buglist is that if you shu}iffle your windows around while rendering into a window with rp_Mask set to anything other than the depth of the screen causes funny colors to be left behind. This happens because you have modified Intuition's RastPort and this RastPort is used when moving windows around. Two solutions are possible. You may Forbid and Permit around any drawing operations so that no window shuffling is possible while you have the rp_Mask set to an unusual value, but you MUST reset it to it's original value before Permitting. The second solution is to set up a copy of Intuition's RastPort and ONLY use that one when rendering into funny rp_Mask windows. Learned the hard way... Gary
michael@ihnp4.UUCP (04/29/87)
Another 1.2 bug: Dragging icons around will occasionally lock up the system. This has happened dozens of times, might be related to extra memory, might not. Michael Gerten The opinions represented here are a result of being educated at a school that discriminates againts roosters. Only the birds are responsible.