Hello Oliver, * On Fri, Aug 24, 2012 at 07:15:19PM +0200 Oliver Schmidt wrote: > > Those issues are why CBM-Command does it at a higher level (OPEN, CLOSE, > > READST). Look at "driveRoutines.s": > > http://cbmcommand.codeplex.com/SourceControl/changeset/view/76273#841469 > > Isn't that the approach that was classified as undesirable before in > this thread because it causes "drive noise" if there's no disk in the > drive? No. In fact, this code is actually very clever. I had to follow it in the KERNAL to find out why it works in the first place. I only have a look in the non-PET case. For the PET, I do not know its inner workings enough to tell what is going on. The code does (in BASIC Pseudo-code): OPEN 15,8,15 CLOSE 15 IF ST<>0 THEN GOTO "DEVICE NOT PRESENT" ELSE GOTO "DEVICE EXISTS" (The BASIC variable ST in Commodore BASIC is $90, the outcome of READST) The OPEN is essentially a NO-OP. I only sets up some internal tables. As there is no file name, no external activity occurs. The CLOSE is the clever part: $FFC3 -> $F291 -> $F2A5 -> $F2EE -> $F642 Here, we check the secondary address (bit 7 set -> we're done; fortunately, it is not) Then we do: LISTEN 8 SECONDARY ADDRESS (SA & 0x0F | 0xE0), here: $EF UNLISTEN So, the OPEN clears the status, and the close performs the LISTEN/UNLISTEN sequence. I'd say: Brilliant. > Here we are looking for a device check that doesn't provoke any > mechanical activity - I don't know how to describe better. It does not. The code here does not do any activity (the PET code does, however), it performs the same sequence of operations as your code. The only difference: The code linked above only uses the KERNAL jump table and should work on all CBM machines (but the PETs, that is). But for the PETs, there is already special handling available in the code. Regards, Spiro. -- Spiro R. Trikaliotis http://www.trikaliotis.net/ ---------------------------------------------------------------------- To unsubscribe from the list send mail to majordomo@musoftware.de with the string "unsubscribe cc65" in the body(!) of the mail.Received on Sat Aug 25 14:26:10 2012
This archive was generated by hypermail 2.1.8 : 2012-08-25 14:26:14 CEST