General Category > Technical Support

Application / user IDs for non volatile RAM (nvRAM) - Listed here - Request here

<< < (2/3) > >>

Done, the MCP got its desired Application ID.
For relatively small nvRAM expansions (RTCs for example) every bytes counts, so it may be better to use 8 bits as ID only instead of 16 bits.

IMHO it will be hard to have more than 255 applications on CPC using nvRAM.
However there is no reason to define an ESC byte for future applications.
But that's probably only needed after the internet breaks down and the CPC will take over.  ;) :) :)

Why using a centralised mapping? That's not scalable and space inefficient (e.g. space reserved by an application we don't use).

I'm in favour of a generic and dynamic approach, where each program could identify itself (e.g. a 8 bytes name like 'ErOS....'). Then this ID would be passed to generic RSX (i.e. save_settings, load_settings). The absence of such RSXs would mean no nvRAM is available.

Even more generic: use config files! Either:

* Standardized Text format (
* Bin format (IFF)Then we could factorise some helper routines, which would:

* Find the file location (e.g. in order of priority on 'nvram:' device, then 'ide:', then current directory).
* Potentially, use this same hierarchy to have global settings and directory-based local settings.
* Parse/Serialise either format.

Well, I don't really know what you mean. But go for it and write the code!

Present or absent RSX commands however are more or less only an indicator for a connected ROM (with the RSX) or intact RAM (start a binary and the RAM RSX is gone).

My proposal is specifically made for the right-now available nvRAM solutions. If there are some ideas how to make it better: Great!

If you have another better system: Great too! But then it would be desirable to have details and code.

Back to topic!
If you want to reserve an nvRAM ID for your application. Post here and pick your number.  :)


--- Quote from: GUNHED on 15:29, 13 April 21 ---every bytes counts
--- End quote ---
I agree. That's why you don't want static allocations and fixed size buffers.

--- Quote from: GUNHED on 17:27, 08 March 21 ---In case you have some great ideas how to make things better, please post here.

--- End quote ---
Was trying to.

Yes, right. Got your point. On the other side the routines get more complex if they need to deal with constantly changing sizes. So there is a balance in between. Many ways lead to Red City.  ;) :)


[0] Message Index

[#] Next page

[*] Previous page

Go to full version
Powered by SMFPacks Media Embedder
Powered by SMFPacks Alerts Pro Mod
Powered by SMFPacks Mentions Pro Mod