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 (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?
So, another interface for those who don't have the Albireo? :)
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?
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?
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.
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.
Quote from: PulkoMandy on 21:10, 24 February 21Did I make some mistakes in the schematics?
A1 missing from address decoding, is this deliberate?
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 (https://youtu.be/xh2JvhlqM7A?list=PLB9WpPEFtpk38K2CrQEQ1hcC6bmjorklC&t=48)
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.
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)
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.
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?
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. :)
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.
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.
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?
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?
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)
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
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.
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.
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
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.
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
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)
I think I get it now, you want to read the config file from the ROM before the system comes back to the user, but that can still be done depending on the order of the ROMS if you want to fall back on other existing FS ROMS during the boot process. This does limit the system startup though in ways which are best resolved via NVRAM.
The other option as I suggested was just to let the system boot to BASIC, once in BASIC whatever existing ROMS are in place can be used to configure UniDOS before UniDOS takes over. This can be done via RSXs but still the same limitation as no NVRAM.
Then a custom-patched ROM with small BASIC ROM patcher would ultimately be the next best option without NVRAM.
As Sykobee suggested, i was thinking if you treat your NVRAM as slots like you said, but had the first slot being used by the NVRAM itself for a RAT (RAM Allocation Table). Examples of how I am setting up a RAT for banking is here:
https://docs.google.com/spreadsheets/d/1XgRVlh27K_C0-gMtroMhN8lK9mAQxVQg1x-3M42kBYo/edit#gid=1980957477
and is fast for allocations and deallocations. Just as per the examples here setup a RAT for each NVRAM if you have multiple and the same pattern should work well.
As you can see, one or more entires in the RAT can be allocated by a single driver (or application in your case). D (allocated by driver), E (extension of the allocation), F (free), A (application)... DEEF means a driver allocated 3 blocks, the first free one is block 4. When freeing the driver, the D and any subsequent E's need freeing.
Hi!
The Nova is fully working and available for sale now.
The board costs 35€ (a bit more than usual, because these NVRAM and batteries are not cheap).
Please contact me if you need one.
could a AT24C256 work as NVRAM for this purpose when plugged into one of the many serial interfaces? Usifac? Lambdaspeak?
https://ww1.microchip.com/downloads/en/DeviceDoc/doc0670.pdf
https://www.ebay.com.au/sch/i.html?_from=R40&_trksid=p2380057.m570.l1313&_nkw=AT24C256&_sacat=0
Quote from: zhulien on 12:45, 27 March 21
Could a AT24C256 work as NVRAM for this purpose when plugged into one of the many serial interfaces? Usifac? Lambdaspeak?
https://ww1.microchip.com/downloads/en/DeviceDoc/doc0670.pdf (https://ww1.microchip.com/downloads/en/DeviceDoc/doc0670.pdf)
m570.l1313&_nkw=AT24C256&_sacat=0 (https://www.ebay.com.au/sch/i.html?_from=R40&_trksid=p2380057.m570.l1313&_nkw=AT24C256&_sacat=0)
At least the LambdaSpeak III has an 128 KB EEPROM, which can of course be used as kind of nvRAM too. In this case the 128 KB are read / written through the LS I/O port. It's not banked in, but I/O is quick enough. :)
@PulkoMandy (https://www.cpcwiki.eu/forum/index.php?action=profile;u=26) So finally, how the UniDos will know at what address to look at to get its data?
And where a possible ùSNA would know where to store its own (it only needs temp data)?
Have you decided of anything to allow programs to reserve slots?
Quote from: Targhan on 11:04, 28 March 21
@PulkoMandy (https://www.cpcwiki.eu/forum/index.php?action=profile;u=26) So finally, how the UniDos will know at what address to look at to get its data?
And where a possible ùSNA would know where to store its own (it only needs temp data)?
Have you decided of anything to allow programs to reserve slots?
Perhaps a few methods could be tried in sequence to see if the NVRAM (whichever method) is available? Nova? Lambdaspeak? Serial EEPROM via Usifac? Serial EEPROM via other serial ports? I did suggest someone create an 8 serial port board in another thread - which something like this Serial EEPROM would be ideal for, perhaps an Usifac-8 (8 port). Or an Usifac-4 (4 port)? @GUNHED (https://www.cpcwiki.eu/forum/index.php?action=profile;u=2029)
Quote from: Targhan on 11:04, 28 March 21
@PulkoMandy (https://www.cpcwiki.eu/forum/index.php?action=profile;u=26) So finally, how the UniDos will know at what address to look at to get its data?
And where a possible ùSNA would know where to store its own (it only needs temp data)?
Have you decided of anything to allow programs to reserve slots?
I do only the hardware here. Contact OffseT if you want to know his plans for UniDOS.
There is 32K of space, I hope you can find an agreement on how to share it, there should be enough space for everyone!
Quote from: PulkoMandy on 19:18, 08 April 21
There is 32K of space, I hope you can find an agreement on how to share it, there should be enough space for everyone!
Therefore we got this here:
https://www.cpcwiki.eu/forum/technical-support/application-user-ids-for-non-volatile-ram-(nvram)-listed-here-request-here/msg198965/#msg198965
Or do it in which way you want, but we should all have an agreement. Else software is incompatible again.
Hi!
Version 1.2 of the Nova NVRAM+RTC expansion is now available. It is fully compatible with the previous version and fixes one small problem: the RAM/RTC was not unmapped automatically on the CPC soft reset (control shift esc, RST 0, or similar). If you have the previous version of the card, in most cases you will be fine: the UniDOS ROM (the only user of the Nova so far) takes care of blocking interrupts when accessing the device (so, no softreset can happen with the board mapped) and as an additional safety, unmaps the memory on startup when it initializes it.
If you have a convincing explanation of how this bug is a problem for you, I can swap your old version of the Nova for a new one. Otherwise, you can keep using your card safely.
The price is unchanged (35€) and thanks to usage of a programmable GAL chip (first time I do this, it was about time I get into these modern techniques), the board is just the same size as before, and a bit faster for me to assemble because there are fewer chips.
Quote from: PulkoMandy on 19:52, 25 June 21
Version 1.2 of the Nova NVRAM+RTC expansion is now available.
Please put me on the customers list, I want to support the Nova and its RTC with my software. :)
Quote from: GUNHED on 14:29, 26 June 21
Please put me on the customers list, I want to support the Nova and its RTC with my software. :)
If that's fine for you I will group the shipping together with your Willy boards (when I have these ready, probably in about 3 weeks as I have to order the PCBs for these).
Quote from: PulkoMandy on 14:49, 26 June 21
If that's fine for you I will group the shipping together with your Willy boards (when I have these ready, probably in about 3 weeks as I have to order the PCBs for these).
That would absolutely be great, but let me please have one one card of each. So others can have the Willi too (and economy is not so good at the moment for me anyway). Grouping is a good idea. Thanks! :) :) :)
it would be great to see something else added to the card as well but i guess everything added, adds to the cost. But a couple more serial ports (compatible with the others on Llambaspeak, Unifac, MiniBooster port-wise) would be cool.
Mark me down for 2 NVRAM+RTC cards if you have them.
That's a question of philosophy. Either one can create a card with a particular function OR a multi-expansion card.
Here, IMHO PulkoMandy did achieve his target, which is nvRAM and as a bonus there is an RTC. (Did I mention that I love RTCs?).
I have put a serial port in the Albireo card. I don't need more serial ports on my CPC.
Quote from: GUNHED on 10:49, 01 July 21
and as a bonus there is an RTC. (Did I mention that I love RTCs?).
I haven't yet figured out a use for an RTC. Maybe a game could change to dark at night or light at day.
Quote from: zhulien on 14:16, 03 July 21
I haven't yet figured out a use for an RTC. Maybe a game could change to dark at night or light at day.
Ah, an health mode. Well, using an RTC in an game is one of the very few things I never thought about. But for long time reality simulations - why not? :)
What's an RTC good for?
- Replacing the watch on your room's wall (use !BIGWATCH command with Dobbertin RTC or LFS RTC)
- Replacing the watch on you arm and immediately stop being a Corona breed station. ;)
- Eventually you can put a time stamp to your files (CP/M Plus and other OS)
- Use your great CPC for a variety of real time measurements
- Needed for a model car (Matchbox?) racing table for a friends son.
- Watch the time going by on your CPC (nothing is more pretty)
- Deal with updated files compared to old versions
- Control you house (heating, blinds, making coffee in the early morning etc.)
- and
- much
- more
- :) :) :)
lol
Hello,
Everyone who pre-ordered a card, your orders are ready to ship, please send me payments and shipping addresses :)
Everyone else, if you want a Nova card, there are some left in stock (and I can build more if it gets more popular)
@PulkoMandy (https://www.cpcwiki.eu/forum/index.php?action=profile;u=26) : Merci beaucoup for this great expansion. :) :) :)
Got my Nova yesterday and it works like a charm.
For everybody interested, here is the data sheet of the 32 KB nvRAM/RTC chip called M48T35Y 70MH1F. The RTC got some cool features. ;) :)
(Well, I assume we all have the 32 KB nvRAM version, right?)
Yes, all Nova cards come with the 32KB chip.
Well, the Nova card is very friendly for usage... I had a bit of time and so I added Nova RTC support to FutureOS. Here is just the German version for CPC6128 as demonstration (install the OS from DSK, start it and see the Nova's Time and Date - you can set clock and date too).
If other languages (French, Spanish, English...) are of interest, please let me know.
DSK see here...
I received my Nova boards today, many thanks. So glad that M4 support is already added to UniDOS too.
Hello,
The second batch of Nova boards is now sold out. I am now taking preorders for another batch. Anyone still wants one? Let me know!
Hello,
I have ordered components for a new batch of Nova boards. So let me know if you want one!
Bonjour PulkoMandy!
How much units of the Nova did you produce until now?
BTW: Sometime people complain about the RAM banking of the CPC, with the smart Nova expansions all problems can be solved. And - in addition - the RAM contents are really save. :) :) :)
Quote from: GUNHED on 15:28, 07 February 24Bonjour PulkoMandy!
How much units of the Nova did you produce until now?
BTW: Sometime people complain about the RAM banking of the CPC, with the smart Nova expansions all problems can be solved. And - in addition - the RAM contents are really save. :) :) :)
I Agree, if nvram was opened up then I can use it to track memory availability and usage. All applications can in fact co exist without trashing eachothers ram.
There are currently about 25-30 Nova boards in circulation, and a few more still with me. I can assemble more as needed.
Not my most successful board (FlashGordon is close to 70 units, and Gemini is about 40).
I think Albireo is even more than that, but you'd have to check with Zik, he handled the newer batches and I don't know exactly how many he made.
I think it will sell more as more software becomes available for it?
Thanks for the reply. I got all of these boards, and I like them very much.
True, the potential of the Nova still needs to be way more explored / exploited by software. :) :) :)
Absolutely Nova has a great potential - there are less good options, like Multiface 2, using BE80, using hardcoded bits of memory expansions but none of them survive resets so limits their usefulness a bit - not totally.
I don't have a FlashGordon, is there any benefit if I use M4?
The M4 stores ROM contents on SD card, the FlashGordon stores them in Flash. Both can coexist when using different ROM select areas (0-31 / 32-63 f.e.).