I am sorry, I cannot help you with C# or Delphi code. The alternative way is to send commands (apdus) via serial port if you know how to send bytes over a serial port; I can tell you some apdus examples (obtained reversing the commands sent through USB/Serial communication) but you will have to figure out the rest yourself.
As far as I can tell no demo for ISO15693 in Delphi.
You need to send raw commands to talk with standard ISO but unsupported tags (unsupported = no source code or no already-made software available); raw commands are called "pass_through" commands in SL500F manual (page 40 of the included manual) and is managed by the "Transcieve" button in the included software; for example sending 02 2B (Get System Information) will give you a series of infos (bytes) about the tag, including UID (crc is auto-mamanged by the SL500F).
They are stored somewhere, 99% in sector0block0. Block0 is called manufacturer block in nxp datasheets. Uid is there so atqa and sak are. Last 2 bytes are manufacturing data (extrapolated by me studying other nxp datasheets). Every bit answered by a tag must be stored in the chip so i suppose those data are taken from block0 which is read only in official tags (as any manufacturer info usually is).
I am not sure about "all 98 are mpcos" because mpcos is more expensive than a real mifare and I found this "98" in very cheap tags (some of them, used for the same exact puropose) were NXP mifare (with specific atqa+sak) and some of them were sak=98; I don't think they used mpcos for such a "cheap" use, I think they are GemEasy8000 tags (real mifare, not mpcos-emulated). Link.
I agree with the pm3 test ! Anyway tags (even chinese ones) are structured to answer with SAK after the specific SELECT command and they "answer" the bits contained in byte5 (starting from byte0). In no other part of the chip that value is stored. The only question is how to interpret it but reading datasheets all 8 SAK bits must be considered as "SAK-bits", without leaving out the MSB.
Curiously nfc-tools make the same questioning-interpretation:
From the first block, the manufacturer data, can be determined if you are dealing with a 1KB or a 4KB tag. It can be done using the ATQA part of block0 in bytes 8 and 7 (stored in reverse order). Byte 6 contains the SAK (at least for the last part (4 bits)).
Even here SAK is considered as full byte (98 is specific for a mifare produced by GemPlus, I saw other examples of that manufacturer but unfortunately I don't remember PM3 answer).
I found an interesting thing in ISO14443-3 datasheet I was not aware of:
b8-b5 (1000)b: Additional information available in protocols
b8-b5 (1100)b: Default mode in protocols
b4-b1(0000)b: Other than ISO/IEC 14443-4
b4-b1(0001)b: PICC supports ISO/IEC 14443-4
So we are now sure that SAK must be considered in all its 8 bits and 1000 (b8-b5) = Additional mode in protocols (I still don't know what that means and where that additional info is stored) but with 98 whe have 10011000 so b8-b5 = 1001... maybe a specific GemPlus "mark", nothing more nothing else... but more probably "Additional info+PICC supports ISO/IEC 1443-4".
If you want to support external USB devices you must be sure that the Android mobile phone you will use has the right .ko kernel modules; those modules must support usb->serial conversion chip or direct serial communication (like in proxdroid); here is a list of the most common (thanks to jonor)
cdc-acm.ko ---> Serial module
cp210x.ko ---> Prolific USB->Serial module
cypress_m8.ko ---> Cypress USB->Serial module
ftdi_sio.ko ---> FTDI USB->Serial module
Each module must be compiled for the kernel in use in the mobile phone. They are not all necessary, you need to find which chip is inside the ACR122U (a picture of ACR122U internals is needed).
If needed I can provide an I9300 modified kernel (Siyah 1.9.0-MOD) with the above mentioned kernel-specific modules (always thanks to jonor).
The second step will be understanding how to send the correct commands through USB via ACR122U APDUs (here you can find a detailed datasheet); for example at page 13 you can see how to use mifare auth. Remember that hardware clones can use different undocumented APDUs to send commands to the tag!
The best way will be sniffing an USB communication to see which commands are sent by the official software to the reader you want to talk with.
GOOD LUCK IKARUS !
In that way you can also support the SL500F device!