I am still chasing the elusive disappearing packets problem. But I have been thinking about adding a new IP device driver system call to my Q68 Ethernet driver. Which returns various information about the current state of the IP driver.
Code: Select all
IP_XINF TRAP#3 D0=7D
Call parameters Return parameters
D1 D1.W length of block returned
D2.W length of buffer D2.W preserved
D3.W timeout D3.L preserved
A0 channel ID A0 preserved
A1 base of buffer A1 preserved
A2 A2 preserved
A3 A3 preserved
Error returns
NC not complete
NO not open
BO buffer overflow
Proposed layout of returned data block
Keys for the system data
inf_ddbase $00 ;long base of driver definition block
inf_driverID $04 ;long driver ID as a 4 byte string e.g. 'Q68E'
inf_driverVer $08 ;long driver version as a 4 byte string e.g. '0.78'
inf_compID $0C ;long computer ID as a 4 byte string e.g. 'Q68 ', 'QPC2', 'SMSQ', 'QEMU'
inf_mac $10 ;6 bytes system MAC address
inf_IPadd $16 ;long system IP address
inf_subnet $1A ;long system subnet mask
inf_gateway $1E ;long system gateway/router address
inf_compName $22 ;word + up to 26 bytes system network name
inf_txpackets $3E ;long number of packets sent by the CP2200
inf_txbytes $42 ;long number of bytes sent by the CP2200
inf_rxpackets $46 ;long number of packets received by the CP2200
inf_rxbytes $4A ;long number of bytes received by the CP2200
Keys for channel data
inf_peerMac $4E ;6 bytes peer MAC address
inf_peerIP $54 ;long peer IP address
inf_peerPort $58 ;word peer port number
inf_sysPort $5A ;word system port allocated to channel
inf_sckType $5C ;byte socket type 1 = TCP, 0= UDP, -1=SCK
inf_protocol $5D ;byte channel protocol e.g 17 = UDP
inf_access $5E ;byte channel access mode (D3 on open call)
inf_sockStat $5F ;byte socket status
inf_end $60 ;end of extended info block
Sorry it's a bit wonky, But that's the best it came out as.
Is there any extra information that is wanted, or is some information not wanted, or in a different format?
Are there any other system calls wanted?
I have tried to allow for other systems and emulators to use this system trap. So should the driverID, driverVer, and compID be longer than 4 bytes to accommodate them.
Is there a limit to the values of D0 for Trap calls? I don't ever remember seeing Trap values above $7F.
If $7F is the upper limit, then there is not much room left in the IP device drivers, so should I use a D0 value outside the usual IP driver range, like $4F