Amiibos (new N toys) are "made of" TOPAZ.
Amiibo TOPAZ Specs:
Block0 contains the UID, and is locked (not writable)
Blocks from 1to 12 are unlocked (writable)
Block13 is locked (data seem to be always 0x5555AAAA124C0600
Block14 is the lock bits/OTP and it is locked (data seems to be always 0x01E0000000000000)
Block15 is unlocked (writable); (data seems to be always 0x000000000000FFFF)
Blocks from 16 to 63 are unlocked (writable)
ATQA = 0C00
Memory = 512 Bytes
Blocks = 64
Each block = 8 Bytes
The official TOPAZ command set is the following (7bits commands):
REQA = 26h [0 1 0 0 1 1 0] --> Request Command, type A
WUPA = 52h [1 0 1 0 0 1 0] --> Wake-up, type A
RID = 78h [1 1 1 1 0 0 0] --> Read ID – Use to read the metal-mask ROM and UID0-3 from block 0
RALL = 00h [0 0 0 0 0 0 0] --> Read All (all bytes)
READ = 01h [0 0 0 0 0 0 1] --> Read (a single byte)
WRITE-E = 53h [1 0 1 0 0 1 1] --> Write-with-erase (a single byte)
WRITE-NE = 1Ah [0 0 1 1 0 1 0] --> Write-no-erase (a single byte)
The CRC (2 bytes) shall be the 16-bit version as specified under CRC-CCITT – for definition see ISO/IEC 14443-3:2001(E) Annex B: CRC_B.
CRC is NOT used with REQA & WUPA commands.
More info in the datasheet linked in the 1st line.
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".