Just a quick update to let you know how things are progressing.
I have been focused on the "virtual computer", the AT API (i.e. the functions that an AT will use to get access to Nxt info) and the first two use cases.
Prototypes for the Lottery and Dormant Funds Transfer (aka "dead man's switch") have been written in NxtAT machine code with the former having been checked with test data (I will do the same for the latter tomorrow).
Both programs come in at under 500 bytes and require less than 160 bytes of memory (which I think is pretty good).
The instruction set I have come up with is 39 op codes so far (including the SUB_LEQ one for James) and the C++ NxtAT machine emulator has been extended to be able to use test data for returning values from the pseudo API function calls (this should make it easier to create test cases).
The 11 API functions that so far comprise the AT API (in order to satisfy the two test cases) are as follows:
01. get a time stamp value for the last block in the blockchain
02. get txid for the first tx after the provided time stamp
03. get a time stamp value for a given txid
04. get ticket for a given txid
05. get source account for a given txid
06. get balance of own account
07. pay account balance to a given account
08. get NXT amount for a given txid
09. get tx type and subtype for a given txid
10. get the AT owner's account
11. get first 64 bits of AM data
Note that a "time stamp" is expected to include the transaction # (not id - I mean # of the tx in the block). I have discussed this with CfB and that will likely be the lower 40 bits of a 64 bit "unix time" shifted to the left with the remaining 24 bits for the transaction # (allowing for a max. 640K txs per second which I am assured Bill Gates agrees we'll never need more than).
Also the "ticket" will be the lower 64 bits of an SHA256 hash of the tx id after the block id of the block 1440 blocks in the future is added to it (if no such block exists it will return 0).
It may seem odd to have an API function for a "ticket" but I get the feeling that there might be more than one type of "game" that will want this functionality (so seems better to just have an API for it rather than needing more byte codes and API functions).