kodiak@amiga.UUCP (Robert R. Burns) (01/11/89)
A few comments: In article ... (Matt Dillon) writes: )But as I said, I do not know if the "need to set the ln_Type field )to NT_MESSAGE" bug was fixed or not. Can anybody at C-A say for sure that )all IO devices now set the ln_Type field properly for asynchronous requests? 1. It is not necessary to set the ln_Type of an IO Request before performing XxxIO (DoIO/SendIO/BeginIO). Any device that requires this is broken. a. If a device defers a request (i.e. it returns from BeginIO before the command is completed), the ln_Type is set to NT_MESSAGE (or at least to *not* NT_REPLYMSG), and the IOF_QUICK flag is cleared in io_Flags. 2. DoIO will write IOF_QUICK to io_Flags, SendIO will clear io_Flags. We investigated changing these to only affect the IOB_QUICK bit itself. Unfortunately, some disk-based Commodore supplied devices counted on the fact that the other flags were clear, so changing the behavior of DoIO and SendIO would break old programs. You must therefore use BeginIO to access the flags for robust audio & trackdisk use. 3. We don't know of any devices broken in the mechanics of their IO execution (note: I don't claim all devices to be bug-free, just that XxxIO threads as expected). a. Matt Dillon has reported a bug here in the way the audio.device replies commands. I've both reviewed the source, which appears correct, and tried via email and phone to get more details (it appears that Matt is not being paid by the University of California -- I hope *someone's* paying him :-). I have a hard time believing that it's cockpit error here -- Matt's an ace. I mention this because there's a general lesson here, albeit not a new one: We appreciate the *work* y'all do to ferret out bugs in the Amiga. Developers have always been instrumental to our efforts -- but we often need more. Please be as complete as you can when describing a problem. Tell us whether you know the solution, and what it is if you do. Be sure there's a way for us to get more information when we need it. Amiga folk enjoy unique access to the development team, but sometimes it needs to be a two-way street. -- Bob Burns, amiga!kodiak _ | /_ _|. _ | Commodore __ |_) _ |_ _ )' |<(_)(_)|(_\|< /\ | ||| _` /\ |_)(_\| )(_\ | | \ Software ___/..\|\/|||__|/..\___ Faith
louie@trantor.umd.edu (Louis A. Mamakos) (01/11/89)
In article <3243@amiga.UUCP> kodiak@tooter.UUCP (Robert Burns) writes: >2. DoIO will write IOF_QUICK to io_Flags, SendIO will clear io_Flags. We > investigated changing these to only affect the IOB_QUICK bit itself. > Unfortunately, some disk-based Commodore supplied devices counted on > the fact that the other flags were clear, so changing the behavior of > DoIO and SendIO would break old programs. You must therefore use > BeginIO to access the flags for robust audio & trackdisk use. In a future release, why not have DoIO and SendIO use a different library base offset, and rename the existing ones as OldDoIO and OldSendIO. This way, you have binary compatibility with existing programs, and new programs will use the correct definitions. I believe that you guys did something like this between 1.0 and 1.1 with OpenLibrary(). Or it might have been earlier; haven't run 1.0 for quite a while now! Louis A. Mamakos WA3YMH Internet: louie@TRANTOR.UMD.EDU University of Maryland, Computer Science Center - Systems Programming
bader+@andrew.cmu.edu (Miles Bader) (01/11/89)
kodiak@amiga.UUCP (Robert R. Burns) writes: > 2. DoIO will write IOF_QUICK to io_Flags, SendIO will clear io_Flags. We > investigated changing these to only affect the IOB_QUICK bit itself. > Unfortunately, some disk-based Commodore supplied devices counted on > the fact that the other flags were clear, so changing the behavior of > DoIO and SendIO would break old programs. You must therefore use > BeginIO to access the flags for robust audio & trackdisk use. Surely it must be easy to fix commodore supplied programs in conjunction with new os releases. Maybe you could change the behavior in the next "lots of things break anyway" release... -Miles
w-colinp@microsoft.UUCP (Colin Plumb) (01/12/89)
bader+@andrew.cmu.edu (Miles Bader) wrote: > kodiak@amiga.UUCP (Robert R. Burns) writes: >> 2. DoIO will write IOF_QUICK to io_Flags, SendIO will clear io_Flags. We >> investigated changing these to only affect the IOB_QUICK bit itself. >> Unfortunately, some disk-based Commodore supplied devices counted on >> the fact that the other flags were clear, so changing the behavior of >> DoIO and SendIO would break old programs. You must therefore use >> BeginIO to access the flags for robust audio & trackdisk use. > > Surely it must be easy to fix commodore supplied programs in > conjunction with new os releases. Maybe you could change the behavior > in the next "lots of things break anyway" release... I must agree. As it is now, it's a wart, and fixing it is very little problem. Just fix the buggy code! If you absolutely can't fix the devices, but they are intended to be called through Dos, you can just fix Dos to always pass 0, and nobody will notice the shift of responsibility... except audio.device programmers. Or add two new entry points to Exec.library and make them DoIO and SendIO for 1.4 and beyond. A bit ugly to have the old entry points hanging around so long, but at a cost of about 20 bytes of memory, it's not very objectionable. -- -Colin (uunet!microsof!w-colinp)
andy@cbmvax.UUCP (Andy Finkel) (01/12/89)
In article <sXmdRNy00Uka89Pj5F@andrew.cmu.edu> bader+@andrew.cmu.edu (Miles Bader) writes: >kodiak@amiga.UUCP (Robert R. Burns) writes: >Surely it must be easy to fix commodore supplied programs in >conjunction with new os releases. Maybe you could change the behavior >in the next "lots of things break anyway" release... Except that some of those devices that are broken may be on the Workbench disk, rather than in the ROM. This means if we change the behavior of the rom routines to only twiddle the bit it needs to twiddle, old Workbench disks may stop working. (Or work strangely). One of our usual release goals is that old Workbench disks work with newer Kickstarts. -- andy finkel {uunet|rutgers|amiga}!cbmvax!andy Commodore-Amiga, Inc. "Possibly this is a new usage of the word 'compatible' with which I was previously unfamiliar" Any expressed opinions are mine; but feel free to share. I disclaim all responsibilities, all shapes, all sizes, all colors.