Nova - NVRAM + RTC for Amstrad CPC - Latest news from PulkoTronics

[PulkoMandy]

Hello there!


While discussing UniDOS implementation with OffseT he asked me if it would be possible to add some non-volatile RAM to the CPC. This works like RAM, but the content is not erased when the computer is off. The idea is to store UniDOS configuration there. Currently it is stored in the Albireo SD card, but this isn't convenient if you don't have an Albireo.


We then also talked about other problems, such as the need for extra RAM for UniDOS to work with non-Albireo devices where a filesystem is needed on the z80 side (with Albireo that is not needed, the hardware implements the filesystem and exposes high level file access commands).


So I researched how to do this and came up with this interface. It includes 8K or 32K of NVRAM (depending on which chip you use) and a real-time-clock (because NVRAM chips have that, and, why not?).


Schematics: http://pulkomandy.tk/drop/nova_cpc_nvram.pdf


Some technical details:


The interface uses port FE82 for mapping the NVRAM in and out. It is possible to map it at any multiple of &2000.


The high 4 bits determine the base address.


For example:

Code: [Select]

OUT &FE82,&0x ' to map at 0000-1FFF
OUT &FE82,&2x ' to map at 2000-3FFF
...
OUT &FE82,&Ex ' to map at E000-FFFF

The NVRAM, when it is enabled, masks 8K of RAM or ROM and replaces it with its own contents.

The low 4 bits determine what is mapped:

Code: [Select]

OUT &FE82,x8 ' map the first 8K page
OUT &FE82,x9 ' map the second 8K page
OUT &FE82,xA ' map the third 8K page
OUT &FE82,xB ' map the fourth 8K page

For the 8K version, only page 4 is available.

Any other value for the 4 low bits unmaps the NVRAM and restores the normal RAM or ROM behavior.

In the fourth page, the last 8 bytes are not normal RAM, but can be used to read and write the time from the realtime clock. So your CPC can know which day and time it is. In the other pages (if available) there is only RAM.

Access to the RTC works this way (assuming the interface is mapped at 6000-7FFF):

Code: [Select]

POKE &7FF8,&40
year = PEEK(&7FFF)
month = PEEK(&7FFE)
day = PEEK(&7FFD)
weekday = PEEK(&7FFC)
hour = PEEK(&7FFB)
minute = PEEK(&7FFA)
second = PEEK(&7FF9)
POKE &7FF8,&00


All values are in BCD format (4 bits for tenths, 4 bits for units)


To set the time:

Code: [Select]

POKE &7FF8,&80
POKE &7FFF,&21 ' for 2021
POKE &7FFE,&02 ' february
' ... and so on ...
POKE &7FF8,&00

Any comments? Suggestions? Questions? Did I make some mistakes in the schematics?

[Targhan]

So, another interface for those who don't have the Albireo?

[IanS]

Any comments? Suggestions? Questions? Did I make some mistakes in the schematics?

Looks interesting.
Not sure I've thought this through properly, but rather than being able to map it into lots of locations, could you mask the read and write signals. So you could read from main memory and write to NVRAM or vice-versa without having to write to the config port inbetween. It would allow you to copy chunks of data with LDIR etc.
Does tha make sense?

[GUNHED]

Any comments? Suggestions? Questions? Did I make some mistakes in the schematics?

At first I was tempted to say "Can you make this compatible to one of the few existing nvRAM expansions (with RTC)", like SF2, CPC-Booster or others.

After continuing reading, I think this is a great idea!
So I would like to support it with FutureOS.
Can you please set me on the "I want to buy one" list, in case there will be one?

[PulkoMandy]

Looks interesting.
Not sure I've thought this through properly, but rather than being able to map it into lots of locations, could you mask the read and write signals. So you could read from main memory and write to NVRAM or vice-versa without having to write to the config port inbetween. It would allow you to copy chunks of data with LDIR etc.
Does tha make sense?

That would be nice, but possibly not as easy to do.


I think with the ability to map it at different addresses, you can always find a place where you can put it in a way that doesn't interfere with the data you want to copy in or out.

[TotO]

For information, you can replace the X-MEM / Y-MEM / Z-MEM RAM module using:
- SST M48Z512Y for 512K Zero power RAM
- SST M48T512Y for 512K Time keeper RAM

Depending of your usage, your memory is not lost when you power off (like using the external PSU on the MotherX4) and you can have access to the embedded RTC using few bytes of the standard memory address. It was an option when the Z-MEM was released, but the interest was limited considering the price for a very uncommon usage in 2017.

[IanS]

Did I make some mistakes in the schematics?

A1 missing from address decoding, is this deliberate?

[GUNHED]

Using nvRAM will lead to the situation that multiple applications would love to store their data in it.
In CPC world this could be:
- UniDOS
- iMPdraw
- Orgams
- ... and others...

Now, we do need a kind of concept to share nvRAM between applications.
How to do that?
Well, a while ago a concept was presented already.
If we agree to this concept, then we all can use any nvRAM for different applications


Please go to second 48!

Here is the concept (source code available):

https://youtu.be/xh2JvhlqM7A?list=PLB9WpPEFtpk38K2CrQEQ1hcC6bmjorklC&t=48

[Targhan]

Now that I think about it, what could be done would be to have any application to "reserve" a slot?
For example, we need more memory for a SNA rom, we could "ask" for, say, a 1k buffer?
Maybe apps could "declare" their page for other apps not to overwrite it. But I guess that would have to be managed via software, not hardware, via convention? For example, each "page" could declare a tag ("SNARKOS10", "ORGAMS45") to know whether the page is free or not...
But maybe I didn't understand the concept, sorry if that's the case.

[PulkoMandy]

A1 missing from address decoding, is this deliberate?

It is not deliberate and I have fixed it now. Thanks for checking!

Now that I think about it, what could be done would be to have any application to "reserve" a slot? For example, we need more memory for a SNA rom, we could "ask" for, say, a 1k buffer?

Yes, probably something like this will be needed. There are several ways to do this. Maybe Unidos can handle this memory as a kind of RAM disk, and apps could go through it. But it could end up being a bit complicated. We can define some simple format for what gets stored there (with an ID and length, and apps can search for some free space. Or we can just have a webpage somewhere listing existing apps using the interface and which memory ranges they need, which is simpler, but less flexible.

For information, you can replace the X-MEM / Y-MEM / Z-MEM RAM module using:
- SST M48Z512Y for 512K Zero power RAM
- SST M48T512Y for 512K Time keeper RAM

Both of these chips seem to be obsolete. The version with only 32K of RAM is still active, which should result in a bit lower prices (even if it still is not a cheap component).

Also, the idea of this interface is to use a non-standard way to map in the RAM, so that it can be used independently of the usual CPC memory. This enables using it a bit like the Multiface 2 RAM, without interference to the running CPC program. In UniDOS this will be quite useful to use it as a work buffer to implement the FAT filesystem without using the main memory in ways programs written for AMSDOS don't expect. And other usages are possible as well, for example to load snapshots in the CPC, you need some working memory. Snarkos did this using the cpcbooster memory, for example, but this means it is not so easy to adjust for use with the Albireo serial port (or other communication interfaces)

[TotO]

The CPC is an obsolete computer too. 

In fact, obsolete IC are not a problem while they are thousands in stock (the Lithium battery is enabled at the first power on). I can see the price is really low today (around 5$) compared to 5 years ago, so if peoples has usages of them with the existing expansions, they are free to exchange the memory module, they have the references now. I understand that is not your usage.

[PulkoMandy]

Please go to second 48!

A youtube slideshow for what should have been a simple text file? How interesting.

We are dealing with a larger memory here (8K or 32K vs 128 and 512 bytes in the Symbiface and the CPCBooster) and the planned usages will require more RAM than what you had.

Already planned for persistent memory usage:
- probably 256 bytes for UniDOS settings

Already planned as a kind of "scratch" area that could be easily shared between multiple apps:
- at least 600 bytes for FAT support in UniDOS (it needs a buffer to store data before it gets written to disk)
- probably also 256 bytes (or maybe a bit less?) for Snarkos

So I guess something a bit more complex should be used, where each application can specify the size it needs?

[GUNHED]

A youtube slideshow for what should have been a simple text file? How interesting.

Glad you like it, actually it's a video of a disc mag, not a text file. You can download the text and the source code from my homepage. It serves as an example. And I guess a pretty good one.

We are dealing with a larger memory here (8K or 32K vs 128 and 512 bytes in the Symbiface and the CPCBooster) and the planned usages will require more RAM than what you had.

Of course, but the RAM size doesn't matter. Just upscale the principle. In addition different block sizes could be used f.e. 32 Byte... ... ... up to 1 K or 2 K (if something needs such a huge buffer)

I don't care much which kind of solution eventually gets used - my point it that all of use (programmers) should agree to one data structure, so very different applications can actually use the same nvRAM expansion.

If you want me to draw a concept for your RAM size I an do that. Else I don't mind. 

[Sykobee (Briggsy)]

Could this be used more generically, if made easy enough to integrate?

Off the top of my head ideas, as I'm not involved and don't know what's in place already and don't want to suggest things already in the pipeline better than I can think through myself...


I guess the first 256 (or last N bytes -RTC data) bytes of NVRam could be an allocation table of some sort, to allow apps to find unused NVRam and then allocate it to themselves. Some apps would not want a lot of space, others might like more. Each entry could be an app name (8 chars) plus NVRam start address + Length allocated + state (active/deleted).


Some code to manage it could be provided for apps to integrate if they wish to use the NVRam (or maybe they can assume a ROM is available with the code already). DO we need to be allowed to have multiple entries for a single app (e.g., a game could have multiple save entries)?, or perhaps that app could call the "APPNAME[1..3]" and we only have one entry per app (simpler), or simply loop a call to findNext(APPNAME, offset) until it returns -1 and let the app deal with the multiple entries.


Over time it could get fragmented because of adding/removing entries leaving holes in the NVRam (especially if the allocation is sequential in nature for simplicity and doesn't look for deleted entries to reuse) - so a simple defrag routine could be useful to move NVRam data into contiguous memory to free up space at the end. Still, maybe implementing a full NVRam memory management system is nice and fun:D


If there is an ability to add multiple NVRam modules then maybe each could have its own allocation table, and the code could iterate through them as needed.

[PulkoMandy]

PCB routing complete 


At 32 x 65mm it is even smaller than my previous expansions. I will do a final check that everything is ok today, and then order the parts to assemble prototypes.

[zhulien]

NVRAM could be interesting - what if it was dktronics compatible but NV?


If it isn't dktronics, of course being RAM it is directly accessible once paged in, however... from a practical point of view, how does it differ to the x-mass? (which uses Disk On Modules)


Is it the price point? or availability? or are there other practical benefits?

[zhulien]

For information, you can replace the X-MEM / Y-MEM / Z-MEM RAM module using:
- SST M48Z512Y for 512K Zero power RAM
- SST M48T512Y for 512K Time keeper RAM

Sounds like a pretty good option actually, is that swapping the top chip or bottom chip?

[TotO]

Sounds like a pretty good option actually, is that swapping the top chip or bottom chip?

On X-MEM or Y-MEM it is the bottom IC. (512K RAM is printed under the IC socket)

[GUNHED]

Here you can find a document for nvRAM management in general. Please take a look ...
https://www.cpcwiki.eu/forum/technical-support/application-user-ids-for-non-volatile-ram-(nvram)-listed-here-request-here/msg198965/#msg198965

[TotO]

Why using NVRAM, while you can write persistant data into a ROM Board, a mass storage, a floppy disc?

Reserving slots means that programs will not have slots, or not use a full slot, or will waste slots (many undisclosed projects) ...
it is an archaic use of this memory done by very old 8-bit console systems that do not have backup manager implemented.

[GUNHED]

Why using NVRAM, while you can write persistant data into a ROM Board, a mass storage, a floppy disc?

Very true, but the answer may be / could be put into the topic 'psychology of CPC users and their fears to screw up their hardware or software - because they've been to lazy for a backupcopy'. Or probably I'm just wrong here.

Reserving slots means that programs will not have slots, or not use a full slot, or will waste slots (many undisclosed projects) ...
it is an archaic use of this memory done by very old 8-bit console systems that do not have backup manager implemented.

The document I proposed solves all that issues.

[PulkoMandy]

If it isn't dktronics, of course being RAM it is directly accessible once paged in, however... from a practical point of view, how does it differ to the x-mass? (which uses Disk On Modules)

The main uses are:

• For UniDOS, the goal is to store the configuration of UniDOS in a single place even if you have many storage devices connected to your CPC. Currently the "NVRAM" of UniDOS is stored in the SD card of Albireo, but soon the ROM will support other storage devices. Since the card also provides a realtime clock, UniDOS will be able to set the correct file dates in the filesystem.
• For development tools: here the idea is precisely to NOT be dktronic's compatible. You can load some code into the RAM and have it available without interference on the CPC state. Very useful if you want to debug some other code. Right, in this case the NVRAM probably isn't really needed (plain RAM could work). For example this could be used in the Snarkos ROM if we want to adapt it to Albireo. This ROM needs to fill the CPC RAM with a snapshot and then finish running its own code with no memory left, and this interface will help with that.

Both of these usages are somewhat specific. Anyway I just had fun designing a new piece of hardware. Apparently, optimizing the design to use as few logic chips as possible and then fitting them all in the available space and routing the PCB is a good way for me to relax after work (where some other people prefer to optimize ASM code instead?).


Indeed for storing other things (application settings, high scores in games, etc) I would suggest to use a mass storage device instead.


I have ordered components and PCB to manufacture the first 10 boards, I'll let you know if it actually works