avatar_GUNHED

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

Started by GUNHED, 16:10, 04 March 21

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

GUNHED

The CPC and Plus computers can use a variety of nvRAM expansions.

Examples are:
- CPC-Booster(+)
- Symbiface II
- LambdaSpeak III
- ... some more
- eventually the new Nova expansion from PulkoMandy

To be able to share nvRAM expansions between different Applications / users / whatever a structure of buffers, directory and checksum was proposed. The first concept was released in a disc mag some years ago. Now this concept become a fully fledged document for bigger nvRAM expansions too. Please see attached file.


You can get your applications ID here, I will curate this page and add your ID wish.


Already given Application / User IDs for nvRAM expansions:

&02 - SymbOS configuration

&09 - FutureOS configuration

&0C - LS data

&12 - TEX editor meta data

&72 - undisclosed game project (WIP)

&8B - MCP


All other numbers (1-255) are available.
You want one?
Be quick!
PM / post here  :)
http://futureos.de --> Get the revolutionary FutureOS (Update: 2023.11.30)
http://futureos.cpc-live.com/files/LambdaSpeak_RSX_by_TFM.zip --> Get the RSX-ROM for LambdaSpeak :-) (Updated: 2021.12.26)

GUNHED

http://futureos.de --> Get the revolutionary FutureOS (Update: 2023.11.30)
http://futureos.cpc-live.com/files/LambdaSpeak_RSX_by_TFM.zip --> Get the RSX-ROM for LambdaSpeak :-) (Updated: 2021.12.26)

CloudStrife

Sorry but I think it's a bit premature to give application id without even discussion about the specification... (The Nova interface is not even out !)
For example I think the 8 bytes id is not enough...And for the Nova one already identified usage is not only to be an NVRAM but to be a RAM outside the standard space...

And if we want to do something more generic for different "popular" interface, i think we should start by list the different mechanism used by different interface for memory accessing (port I/O, memory mapped etc.) and the size available on them...

GUNHED

Quote from: CloudStrife on 10:26, 08 March 21
Sorry but I think it's a bit premature to give application id without even discussion about the specification... (The Nova interface is not even out !)
For example I think the 8 bytes id is not enough...And for the Nova one already identified usage is not only to be an NVRAM but to be a RAM outside the standard space...

And if we want to do something more generic for different "popular" interface, i think we should start by list the different mechanism used by different interface for memory accessing (port I/O, memory mapped etc.) and the size available on them...

Guess, you missed some posts. Well, they are over two threads.
So in brief what I do suppose. Because this goes back a while an it the result of lot of good ideas from different active programmers.
The hardware supported up to now had rather smaller amounts of nvRAM, examples are.
- SF2
- CPC-Booster (+)
- few RTCs
For these devices a document / concept was presented in the disc mag FutureView (see video I posted)
Also there is source code available.
The new Nova card now has a far bigger amount of nvRAM, therefore the parameters and structure was adapted to fit optimal. See posted document.

In case you have some great ideas how to make things better, please post here.

IMNO a 8 bit value is MORE than enough. Or do you really think that we (one day) will have more than 255 applications working with nvRAM. Looking at the CPC scene I guess it may be a dozen one day. Even 4 Bits would be enough, but 8 bits are perfect for all future developments.  :)
http://futureos.de --> Get the revolutionary FutureOS (Update: 2023.11.30)
http://futureos.cpc-live.com/files/LambdaSpeak_RSX_by_TFM.zip --> Get the RSX-ROM for LambdaSpeak :-) (Updated: 2021.12.26)

zhulien

Please reserve me #8B for MCP so I don't need to use #BE80.

What does MCP do: currently it spawns tasks in the background of AMSDOS.  Tasks can be run from any compatible RAM bank, paused, continued etc.  They even survive a CPC reset and continue to run.  Having said that, let's consider #8B for MCP or any replacement AMSDOS / MCP-compatible multi-tasker.  I am sure there are dozens of others here that can code CPC better than me.

Even though you are allocating 256 numbers for now, why not allocate them as 256 numbers out of 16bit.  eg: #008B... then future devices could be automatically compatible with up to 8MB in size without any application code changes.

GUNHED

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.  ;) :) :)
http://futureos.de --> Get the revolutionary FutureOS (Update: 2023.11.30)
http://futureos.cpc-live.com/files/LambdaSpeak_RSX_by_TFM.zip --> Get the RSX-ROM for LambdaSpeak :-) (Updated: 2021.12.26)

m_dr_m

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:
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.

GUNHED

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.  :)
http://futureos.de --> Get the revolutionary FutureOS (Update: 2023.11.30)
http://futureos.cpc-live.com/files/LambdaSpeak_RSX_by_TFM.zip --> Get the RSX-ROM for LambdaSpeak :-) (Updated: 2021.12.26)

m_dr_m

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

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

GUNHED

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.  ;) :)
http://futureos.de --> Get the revolutionary FutureOS (Update: 2023.11.30)
http://futureos.cpc-live.com/files/LambdaSpeak_RSX_by_TFM.zip --> Get the RSX-ROM for LambdaSpeak :-) (Updated: 2021.12.26)

GUNHED

The nice Nova boards are getting more and more common. Now it's the time to pick your ID!  :) :) :)


As soon as I have the Nova (and finished up some LFS software) I will come back to this topic (a standard for nvRAM management) and provide a greater amount of supporting software.  :)
http://futureos.de --> Get the revolutionary FutureOS (Update: 2023.11.30)
http://futureos.cpc-live.com/files/LambdaSpeak_RSX_by_TFM.zip --> Get the RSX-ROM for LambdaSpeak :-) (Updated: 2021.12.26)

Powered by SMFPacks Menu Editor Mod