I am trying to find out the easiest way to discover whether a given IEEE device (let's say: a disk drive) exists, from an assembler code.

I have been thinking that simply sending a TALK or LISTEN command to a non-existent device would result in some value of "Status" variable that would tell me that the device is not present. But it's not the case. I need to actually read something from a device, and only then the ACPTR command sets the "Timeout" bit in the status variable if the device is not there to send anything.

So the correct way would be to make a device actually send something to the computer. But I am not that proficient in the low-level details of the IEEE interface, so I don't know how to prepare the device so that it sends me something. I guess I need to call LISTEN and SECOND, tell the device that I need something from it, then TALK and TKSA... but with what parameters? I have no clue. I would appreciate any help.

Quote from: Michau on October 10, 2010, 05:12 AM
I am trying to find out the easiest way to discover whether a given IEEE device (let's say: a disk drive) exists, from an assembler code.

I have been thinking that simply sending a TALK or LISTEN command to a non-existent device would result in some value of "Status" variable that would tell me that the device is not present. But it's not the case. I need to actually read something from a device, and only then the ACPTR command sets the "Timeout" bit in the status variable if the device is not there to send anything.

So the correct way would be to make a device actually send something to the computer. But I am not that proficient in the low-level details of the IEEE interface, so I don't know how to prepare the device so that it sends me something. I guess I need to call LISTEN and SECOND, tell the device that I need something from it, then TALK and TKSA... but with what parameters? I have no clue. I would appreciate any help.

You're making it way too complicated fooling around with the kernel primitives.  Simply open a file to the command channel and tell the device to initialize.  When the non-existent device fails to respond, the kernel will return an error status.  It's no different than doing it from BASIC, except there's a little more code to be written.

Well, the problem is I need to do it in a kernel overaly. So:

* I cannot disrupt the state of the computer in any way. Therefore I cannot open/close any files on the computer.
* I cannot disrupt the state of the drive in any way. So I cannot send commands to initialize it.

Quote from: Michau on October 11, 2010, 09:18 PM
Well, the problem is I need to do it in a kernel overaly. So:

* I cannot disrupt the state of the computer in any way. Therefore I cannot open/close any files on the computer.
* I cannot disrupt the state of the drive in any way. So I cannot send commands to initialize it.

Well, then, you have a problem, in that the IEEE-488 protocol is stateless and therefore doesn't indicate if a device is present unless the device is command to do something.

Can you read the disk status from the command channel to see if the device is present? The equivalent of the Basic program


10 dv = 8 : rem device to test
20 open 1,dv,15
30 get#1,A$
40 if st = 0 then print "present"
50 close1


So in machine language


lda #$00
sta $96 ;status
lda #$08 ;device #
sta $d4 ;device
jsr TALK ; $f0d2 in basic 4
lda #$6f ;secondary address
sta $d3
jsr SECND ; $f143 in basic 4
jsr INPUT ; $f1C0 in basic 4
jsr UNTLK ; $f1ae in basic 4

lda $96 ;get status
beq present

Reading from the command channel is a nice idea. But if another program has already opened channel 15 for reading, this again will mess up with the device state.

But I have finally come up with a solution:

1. Scan the open files table to find an unused channel on a device (a channel that has no file open). There can be less than 15 files open, so you are guaranteed to find a free channel.
2. Open a file with this channel and filename "#9". This will try to read DOS buffer number 9, which of course does not exist (there are only at most 5 DOS buffers).
3. If the device does not exist, kernal status variable will have bit 7 set (device not present). If the device exists, this bit will be 0.

This procedure guarantees that the device state will not be disturbed (we are using a nonused channel, and nonexisting file). Using a DOS buffer name also ensures that the drive will not try to read from disk searching for a file. And using a nonexisting DOS buffer guarantees that we are not messing up with someone's data.

This has worked with my 8250. I think it should work with all other drivers (don't know about printers, though).