On Fri, Apr 30, 2010 at 1:08 AM, Ullrich von Bassewitz <uz@musoftware.de>wrote: > > On Thu, Apr 29, 2010 at 10:52:46PM -0500, Payton Byrd wrote: > > After a lot of digging, it appears to be a problem in the libraries. > > Actually not. cbm_open is identical for all CBM platforms. It returns what > the > kernal returns. If you don't get the expected error, this means that the > kernal doesn't return it. This is the code for cbm_open: > > _cbm_open: > pha > txa > pha ; Save name > > jsr popa ; Get sec_addr > jsr _cbm_k_setlfs ; Call SETLFS, pop all args > > pla > tax > pla ; Get name > jsr _cbm_k_setnam > > jsr _cbm_k_open > sta __oserror > > rts > > And here is cbm_k_open: > > _cbm_k_open: > jsr OPEN ; <- KERNAL call > ldx #0 ; Clear high byte > bcs @NotOk > txa > @NotOk: rts > > If the carry is set after a call to the kernal, the error code is > definitely > stored in _oserror. If _oserror doesn't contain an error code, it is > because > the kernal doesn't return it. > > What is the correct way to determine if a drive exists on the IEC bus? I've tried simply doing an open using the cbm_open routine but the kernel does not return an error as expected when attempting to open the drive. From BASIC the following happens: OPEN 15,15,15,"" READY PRINT #15, "UJ" ?DEVICE NOT PRESENT READY So it appears that with BASIC you have to attempt to write to the channel to get the error, but how does it know about the error if the kernel didn't set the error in the accumulator when open was called? When I attempt to read or write to the channel of a non-existent drive the 64 locks up as is evidenced by the sample I posted. Obviously lots of people have overcome this problem or the C64 would have been useless from the get-go. -- Payton Byrd <http://www.paytonbyrd.com> <http://it.toolbox.com/blogs/paytonbyrd> ---------------------------------------------------------------------- To unsubscribe from the list send mail to majordomo@musoftware.de with the string "unsubscribe cc65" in the body(!) of the mail.Received on Fri Apr 30 15:07:39 2010
This archive was generated by hypermail 2.1.8 : 2010-04-30 15:07:42 CEST