• Please review our updated Terms and Rules here

CP/M on NVRAM?

M

MykeLawson

Experienced Member
Joined
Mar 21, 2014
Messages
381
Last night I got to thinking. If you had a couple of 32Kx8 NVRAM chips, couldn't you load the lower one with the 0000-0100h data and the upper one with the DC00h-FFFFh data and effectively have a running CP/M system on power on? That just seems too easy and makes me think I am overlooking something.
 
Depends on the type of NVRAM, as some/many require special protocols to write memory. If you have NVRAM (PMEM) that seamlessly writes to byte locations, then it might become more practical. Many larger systems these days are experimenting with PMEM NVRAM DIMMs, but those don't interface easily to legacy CPUs. But, the idea is to save on power-on/boot time by having everything still in memory from the last time you ran. That's also a problem, as what was left over from last time may not be what you want (especially if things crashed or otherwise failed to stop cleanly) - so you need a "chicken switch". I'm not sure if anyone has made a successful product out of having the OS actually "live" in PMEM and survive a power cycle - although I'm not keeping a close eye on that sector. I had heard of efforts to keep apps (databases, etc) in PMEM - since those are often the really big delays in booting a system.
 
another problem is that you absolutely must have a clean and orderly shutdown of the system before power-off. You must know where and how to start execution on power-up, and that includes CPU registers and state. Legacy systems, especially CP/M, do not have a "shutdown" procedure and so there must be some enforcement of a new semantic.
 
I was reading the specs on the STMicroelectronics M48Z35-70PC1 and that appears to act as a normal SRAM chip would. I was also thing of some defensive glue logic to disable any writes to those specific areas of memory to lessen the likelihood of data corruption. But still being in a somewhat of a 'CP/M learning mode' I'm not 100% sure what may change in the CP/M memory areas as the OS runs.
 
durgadas311 said:
another problem is that you absolutely must have a clean and orderly shutdown of the system before power-off. You must know where and how to start execution on power-up, and that includes CPU registers and state. Legacy systems, especially CP/M, do not have a "shutdown" procedure and so there must be some enforcement of a new semantic.
Click to expand...
I think what I'd be looking at doing would be more of a 'power the system on and CP/M would be right there' kind of thing. I wouldn't be worried about maintaining the system state from a previous session. I'd use the system, when I'm done, and back to a prompt, just power it off. Next time I want to use it, power it on and right into CP/M. I was thinking of burning CP/M to EPROM, but given the odd size it takes up in memory the circuitry to decode around it would be more trouble. And the 32Kx8 NVRAM is kinda inexpensive.
 
You don't need NVRAM - Just a NVRAM ramdisk. CP/M is a DISK operating system afterall :) And you don't need much for a quick boot - I and going to write my boot into a ROM and so far I used 4K for a bootstrap and to load the BIOS and BDOS (FDOS) and the FDOS loads CCP.BIN which is another 4K to memory and starts executing it on a hard reset or a soft reset.

If you add a ROM into your design for the RAM disk and hook it into your BIOS, then you can do much the same, and CP/M boots instantly. Or near enough, even by modern standards.

Also, since that leaves me about 54K of free "ROM" memory, I can put other boot utilities in there, and I've already modified my CCP to go looking to the "L:" drive as a path default if it can't find an executable on the logged disk.

As long as you can boot from a NVRAMDISK, then it's no worse than booting straight to code, and avoids having to maintain state information for the CPU. :)

Regards
David

edit: The "54K" of extra "ROM" memory is because I am using a 27512... Hence my Romdisk has about 62K, with two directory blocks, and all blocks 1K. So I only use 8K of it's capacity for the FDOS and CCP presently. But 8K should be more than enough to boot a CP/M system. Including bootstrap.
 
Last edited:
Unfortunately the 'state' of the system is held in the very memory you are making non volatile...

Intel used to have CPM-86 in a coprocessor (if I remember correctly). However, I believe they copied the image from internal ROM to system RAM on power-up or a reset condition.

Dave
 
Copying from ROM to RAM is definitely easier, and is how my earlier versions os emulator worked, but later I turned it into a disk that works like a normal CP/M disk... So I just boot to L: instead of A:

Though I worry sometimes about what that might do for compatability... Is there CP/M software out there hard coded to A:?
 
Note: Don't forget the Osborne 1 could battery back up the RAM while powering down all the other chips - so I guess if you had the battery backup, it was kind of like what Myke is describing.

Though I've never tried it out - just based on what was said about it.
 
Yes, if you save everything in battery-backed RAM (including temporary storage for the CPU registers - if necessary) then that 'should' work, providing you initialise the hardware 'correctly' on a restart.

Dave
 
I confess that I am trying to understand the reason to save the rigisters if I am doing a system reset or power on. In both those cases, I'm expecting the system to start from scratch; aren't I?
 
MykeLawson said:
I think what I'd be looking at doing would be more of a 'power the system on and CP/M would be right there' kind of thing. I wouldn't be worried about maintaining the system state from a previous session. I'd use the system, when I'm done, and back to a prompt, just power it off. Next time I want to use it, power it on and right into CP/M. I was thinking of burning CP/M to EPROM, but given the odd size it takes up in memory the circuitry to decode around it would be more trouble. And the 32Kx8 NVRAM is kinda inexpensive.
Click to expand...
The problem is that part of the CP/M image contains data (variables) and those variables are not initialized specifically - CP/M depends on the values being pre-initialized (i.e. by the cold boot loading of the image into RAM). You can't jump to the cold boot entry of a "dirty" RAM image and expect it to work. So, if you're not trying to "resume" the OS, you might as well just have CP/M in ROM and load it into RAM on power-up - as if the ROM were a romdisk.
 
Okay, now I understand that much better...... Sounds like the plan I conjured up is a non-starter and might as well keep things the way they are then. Oh well, on to my next brain-storm......
 
Outside of CP/M I do regularly see Z80 embedded systems that have an EPROM for startup but instead of ram it uses an M48T18 as system ram + nonvolatile storage + RTC.
 
I was referring to the Osborne 1 post #9 about battery backing up the ENTIRE RAM image (including any application that was running). A power resumption could then continue where it left off. I would assume that a POWER OFF condition would signal via a non maskable interrupt, and the CPU registers (in this case) would be significant for a resumption when the power was turned back on.

In your case, you don't care...

However, the reason CP/M is not ROMABLE is that some memory areas are treated as data storage (RAM) and, therefore, will be initialised with what they were when the power went off. If you do a COLD restart when the power comes back, you 'may' be OK. In this case, however, the RAM areas would have originally been overwritten by what was stored in those areas on disk. In your proposed case, they won't.

No harm to do some experimenting though is there...

Dave
 
True Dave. Since NVRAM is just battery backed up SRAM, a reset or POR would overwrite the data storage (scratchpad) areas that CP/M uses. I couldn't hurt to try it though.
 
My very first for business use laptop was a NEC Starlet that not only had CP/M, but also had Wordstar, Calcstar and some other programs all in ROM. It also used a static version of the Z80 and so booted up upon power on to where you left off. No boot time at all. Quite handy when using it in a car and trying to save the "C" cell batteries from being depleted before getting home.
 
cj7hawk said:
Copying from ROM to RAM is definitely easier, and is how my earlier versions os emulator worked, but later I turned it into a disk that works like a normal CP/M disk... So I just boot to L: instead of A:

Though I worry sometimes about what that might do for compatability... Is there CP/M software out there hard coded to A:?
Click to expand...
Short answer is yes. I have my cpm system boot from "C". Several programs are hard coded to put temp files and config files on "A".
submit is one of the top of my head.

joe
 
This big issue is that peripheral devices (chips, etc) will not retain configured state upon restoration of system power. Thus the CP/M drivers will now have an inconsistent view of the state of the peripherals and the reality in hardware. Your system will be most likely unusable unless you perform a restart. Even if you use NVRAM for a ram disk, the ram disk driver will need to have some code to figure out if the RAM disk needs to be recreated.
 
It's an interesting concept Myke. I wrote my version of CP/M to handle situations like this, so a warm boot actually re-establishes state and then the entry point of 0100 via the built-in monitor can be used to restart the incumbent program, or the OS can continue from there. I even assume the CCP may have been overwritten by the TPA and so load it on each warm boot, which is not a problem since I have the ROMDISK to load it from, so it's quick each time... Though this also assumes that the original program in the TPA didn't overwrite the CCP.

I guess while hardware like you describe is not likely to play nice with a stock CP/M, there's not too much modification required to make CP/M do what you're wanting to do so it's actually not an impractical exercise, and while a little complex, could be rolled out to existing machines without too much change I imagine.
 
You must log in or register to reply here.
Back
Top