Author Topic: Application / user IDs for non volatile RAM (nvRAM) - Listed here - Request here  (Read 873 times)

0 Members and 1 Guest are viewing this topic.

Offline GUNHED

  • 6128 Plus
  • ******
  • Posts: 2.702
  • Country: de
  • Reincarnation of TFM
    • FutureOS - The quickest OS for the CPC and Plus
  • Liked: 1270
  • Likes Given: 2964
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  :)
« Last Edit: 15:25, 13 April 21 by GUNHED »
http://futureos.de --> Get the revolutionary FutureOS (Update: 2021.01.24)
http://futureos.cpc-live.com/files/LambdaSpeak_RSX_by_TFM.zip --> Get the RSX-ROM for LambdaSpeak :-) (Updated: 2021.07.15)

Offline GUNHED

  • 6128 Plus
  • ******
  • Posts: 2.702
  • Country: de
  • Reincarnation of TFM
    • FutureOS - The quickest OS for the CPC and Plus
  • Liked: 1270
  • Likes Given: 2964
PM received, code &72 introduced...
http://futureos.de --> Get the revolutionary FutureOS (Update: 2021.01.24)
http://futureos.cpc-live.com/files/LambdaSpeak_RSX_by_TFM.zip --> Get the RSX-ROM for LambdaSpeak :-) (Updated: 2021.07.15)

Offline CloudStrife

  • CPC464
  • **
  • Posts: 34
  • Country: fr
    • Shinra Team Website
  • Liked: 19
  • Likes Given: 2
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...

Offline GUNHED

  • 6128 Plus
  • ******
  • Posts: 2.702
  • Country: de
  • Reincarnation of TFM
    • FutureOS - The quickest OS for the CPC and Plus
  • Liked: 1270
  • Likes Given: 2964
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: 2021.01.24)
http://futureos.cpc-live.com/files/LambdaSpeak_RSX_by_TFM.zip --> Get the RSX-ROM for LambdaSpeak :-) (Updated: 2021.07.15)

Offline zhulien

  • 6128 Plus
  • ******
  • Posts: 721
  • Country: au
  • aka Vorax
    • 8bitology
  • Liked: 292
  • Likes Given: 302
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.
« Last Edit: 05:39, 12 April 21 by zhulien »

Offline GUNHED

  • 6128 Plus
  • ******
  • Posts: 2.702
  • Country: de
  • Reincarnation of TFM
    • FutureOS - The quickest OS for the CPC and Plus
  • Liked: 1270
  • Likes Given: 2964
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.  ;) :) :)
« Last Edit: 15:31, 13 April 21 by GUNHED »
http://futureos.de --> Get the revolutionary FutureOS (Update: 2021.01.24)
http://futureos.cpc-live.com/files/LambdaSpeak_RSX_by_TFM.zip --> Get the RSX-ROM for LambdaSpeak :-) (Updated: 2021.07.15)

Offline m_dr_m

  • CPC6128
  • ****
  • Posts: 261
  • Country: se
  • http://orgams.wikidot.com/
    • OrgaMS!
  • Liked: 172
  • Likes Given: 187
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.

Offline GUNHED

  • 6128 Plus
  • ******
  • Posts: 2.702
  • Country: de
  • Reincarnation of TFM
    • FutureOS - The quickest OS for the CPC and Plus
  • Liked: 1270
  • Likes Given: 2964
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.  :)
« Last Edit: 20:43, 05 May 21 by GUNHED »
http://futureos.de --> Get the revolutionary FutureOS (Update: 2021.01.24)
http://futureos.cpc-live.com/files/LambdaSpeak_RSX_by_TFM.zip --> Get the RSX-ROM for LambdaSpeak :-) (Updated: 2021.07.15)

Offline m_dr_m

  • CPC6128
  • ****
  • Posts: 261
  • Country: se
  • http://orgams.wikidot.com/
    • OrgaMS!
  • Liked: 172
  • Likes Given: 187
every bytes counts
I agree. That's why you don't want static allocations and fixed size buffers.

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

Offline GUNHED

  • 6128 Plus
  • ******
  • Posts: 2.702
  • Country: de
  • Reincarnation of TFM
    • FutureOS - The quickest OS for the CPC and Plus
  • Liked: 1270
  • Likes Given: 2964
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: 2021.01.24)
http://futureos.cpc-live.com/files/LambdaSpeak_RSX_by_TFM.zip --> Get the RSX-ROM for LambdaSpeak :-) (Updated: 2021.07.15)

Offline GUNHED

  • 6128 Plus
  • ******
  • Posts: 2.702
  • Country: de
  • Reincarnation of TFM
    • FutureOS - The quickest OS for the CPC and Plus
  • Liked: 1270
  • Likes Given: 2964
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: 2021.01.24)
http://futureos.cpc-live.com/files/LambdaSpeak_RSX_by_TFM.zip --> Get the RSX-ROM for LambdaSpeak :-) (Updated: 2021.07.15)