avatar_PulkoMandy

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

Started by PulkoMandy, 21:10, 24 February 21

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

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:


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:


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


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:


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? :)
Targhan/Arkos

Arkos Tracker 2.0.1 now released! - Follow the news on Twitter!
Disark - A cross-platform Z80 disassembler/source converter
FDC Tool 1.1 - Read Amsdos files without the system

Imperial Mahjong
Orion Prime

IanS

Quote from: PulkoMandy on 21:10, 24 February 21Any 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

Quote from: PulkoMandy on 21:10, 24 February 21
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?
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)

PulkoMandy

Quote from: IanS on 23:08, 25 February 21
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.
"You make one mistake in your life and the internet will never let you live it down" (Keith Goodyer)

IanS

Quote from: PulkoMandy on 21:10, 24 February 21Did 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
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)

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.
Targhan/Arkos

Arkos Tracker 2.0.1 now released! - Follow the news on Twitter!
Disark - A cross-platform Z80 disassembler/source converter
FDC Tool 1.1 - Read Amsdos files without the system

Imperial Mahjong
Orion Prime

PulkoMandy

Quote from: IanS on 15:17, 26 February 21A1 missing from address decoding, is this deliberate?

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

Quote from: Targhan on 00:10, 27 February 21Now 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.

Quote from: TotO on 09:11, 26 February 21For 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.  ;D

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.
"You make one mistake in your life and the internet will never let you live it down" (Keith Goodyer)

PulkoMandy

Quote from: GUNHED on 16:36, 26 February 21
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

Quote from: PulkoMandy on 20:40, 27 February 21
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.
Quote from: PulkoMandy on 20:40, 27 February 21We 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.  :)
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)

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


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

Quote from: TotO on 09:11, 26 February 21
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

Quote from: zhulien on 12:09, 03 March 21Sounds 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)
"You make one mistake in your life and the internet will never let you live it down" (Keith Goodyer)

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)

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.
"You make one mistake in your life and the internet will never let you live it down" (Keith Goodyer)

GUNHED

Quote from: TotO on 08:12, 05 March 21
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. ;D :) :)
Quote from: TotO on 08:12, 05 March 21Reserving 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.
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)

PulkoMandy

Quote from: zhulien on 12:07, 03 March 21
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 :D

zhulien

what if you had multiple methods to have a config file as follows?


1. load a c:/unidos folder if one is found using amsdos before you intercept it
2. make an amsdos util that lets you config a custom unidos rom, not perfect but should be very workable
3. cater for backed up ram options - this could work really nicely, like a BIOS does on a PC
4. look at how i have designed the loading of drivers in my driver spec, see if that method is desirable for unidos? (basic uses rsx's to dynamically load drivers which can be run from a batch job in the case of m4 or even run"disc" if you wanted to use that type of method.


I think actually the NV Ram idea is a really good idea, I just couldn't justify an entire Mx4 slot for a card that offered that alone.  In theory the GODIL FPGA could offer it inside the FPGA core - but i didn't yet try it on my CPC after reading the inconsistent compatability on a ZX Spectrum.  could a small circuit board that sits under the Z80 in the z80 socket give NV RAM?


I wonder if #Duke could implement some (256bytes? 1024bytes?) NVRAM within the M4?  That would mean around 1000 users would have NVRAM with only a software update.

Duke

Quote from: zhulien on 17:30, 07 March 21
I wonder if #Duke could implement some (256bytes? 1024bytes?) NVRAM within the M4?  That would mean around 1000 users would have NVRAM with only a software update.
Actually the STM M4 has a 4KB battery backed up SRAM, but since I got rid of the battery option rather early (pcb v1.0.2 iirc). It's going to be no use. However for a file system driver, the M4 provides plenty of memory at runtime, just use my ROM_CWRITE commands, infact my amsdos replacement could have a very tiny CPC RAM footprint, if I was bothered about it (I did consider it early, but compatiblity is plenty good, that I think it may not be worth it). /Offtopic

PulkoMandy

Quote from: zhulien on 17:30, 07 March 21
what if you had multiple methods to have a config file as follows?

1. load a c:/unidos folder if one is found using amsdos before you intercept it
2. make an amsdos util that lets you config a custom unidos rom, not perfect but should be very workable
3. cater for backed up ram options - this could work really nicely, like a BIOS does on a PC
4. look at how i have designed the loading of drivers in my driver spec, see if that method is desirable for unidos? (basic uses rsx's to dynamically load drivers which can be run from a batch job in the case of m4 or even run"disc" if you wanted to use that type of method.


I don't understand 1. If you use AMSDOS, you can load it only from a floppy. And on my CPC I don't even have AMSDOS available at all, only UniDOS. It already saves its settings on the Albireo SD card, but it results on some extra access to the SD card.


2 would work for permanent settings, but not for changing things. UniDOS for example has to store the current directory and drive somewhere so it can restore it when you run a game or tool that reinits the ROM.


I will let OffseT comment on the other things if he wants to because I'm not involved in the software things.


As for this not doing much and not justifying an expansion slot on its own, you are right. However, it allows me to keep the prototype simple. Later I can see about integrating it with another one of my cards if that's useful.


I know OffseT has installed several expansions directly inside his Plus (there is a lot of empty space inside anyway) so that's an option too. It's not so easy to do from only the z80 socket however, as you need access to some other signals (RAMDIS and ROMDIS at least)

Powered by SMFPacks Menu Editor Mod