It was an Acorn Atom, with a 1MHz 6502 and 4K of static memory.
There was a 4K gap in the memory map after the 4K of memory. So I bought 8 2114s (1K x 4bit I think) and soldered them directly on top of the existing chips, with the exception of the select pin. With the help of a few 74xx chips to do some address decoding and driving the select pins, the new memory was mapped in to the gap. I didn't really know what I was doing, but it worked.
Sometimes, not always, this is the only reasonable documentation that can be written,
If throbTheWangle is a good name, perhaps a self-explanatory name, for a function, then there's little more to say about it. It may be very easy to understand in the context of the complete API, and other documentation. However you can't not document it. That would invite understandable criticism.
There are other circumstances where there's lots more to say, and in that case the documentation should be more expansive.
An API can quite easily, and reasonably, span both extremes. The documentation should say as little or as much as is needed about a particular API, and not feel compelled to conform to inappropriate conventions.
2. AES-256 is slower than AES-128, but actually slightly weaker. Why, specifically, was AES-256 chosen?
3. What cipher modes are used, and where? I skimmed the site briefly but though some other details were disclosed,
"All symmetric cryptographic operations are based on AES-128. It operates in cipher block chaining mode for the file and folder attribute blocks and in counter mode for the actual file data."
What's the official line on how they are expected to support Safari without devices that support Safari?
The summary says that ESR put the repo on GitGub. It's actually on GitLab.
It's nice to see not everyone slavishly uses GitHub all of the time.
It was an Acorn Atom, with a 1MHz 6502 and 4K of static memory. There was a 4K gap in the memory map after the 4K of memory. So I bought 8 2114s (1K x 4bit I think) and soldered them directly on top of the existing chips, with the exception of the select pin. With the help of a few 74xx chips to do some address decoding and driving the select pins, the new memory was mapped in to the gap. I didn't really know what I was doing, but it worked.
Posting to revert accidental moderation.
Sometimes, not always, this is the only reasonable documentation that can be written,
If throbTheWangle is a good name, perhaps a self-explanatory name, for a function, then there's little more to say about it. It may be very easy to understand in the context of the complete API, and other documentation. However you can't not document it. That would invite understandable criticism.
There are other circumstances where there's lots more to say, and in that case the documentation should be more expansive.
An API can quite easily, and reasonably, span both extremes. The documentation should say as little or as much as is needed about a particular API, and not feel compelled to conform to inappropriate conventions.
2. AES-256 is slower than AES-128, but actually slightly weaker. Why, specifically, was AES-256 chosen? 3. What cipher modes are used, and where? I skimmed the site briefly but though some other details were disclosed,
From the API documentation (at https://mega.co.nz/#developers):
"All symmetric cryptographic operations are based on AES-128. It operates in cipher block chaining mode for the file and folder attribute blocks and in counter mode for the actual file data."
Of course their own client may work differently.
Commenting to abort accidental moderation.
The FUNcube Dongle http://www.funcubedongle.com/ is good value for money. It has reasonable performance, and starts at 105GBP.
How would this work if you needed to localise your application to handle some of the Middle Eastern currencies that use 1000 sub-units instead of 100?
I think that should be GBP not UKP.
It sounds like your requirements are quite a close match with AltioLive