PDA

View Full Version : Warm boot vs. Cold boot...



alank2
February 26th, 2018, 01:07 PM
I know a cold boot is from power on. In the case of CP/M it will mean that ROM should be enabled, who knows the state of memory, and the full boot process needs to occur.

What exactly is a warm boot?

Just a reset of the Z80? Does execution at 0x0000 reload CP/M? or just parts of CP/M?

durgadas311
February 26th, 2018, 02:44 PM
For CP/M BIOS, cold boot means that CP/M is starting from scratch - the first time this memory image of CP/M has been run. It must initialize all of CP/M (BDOS as needed, CCP). The exact condition of hardware at cold boot is dependent on the platform. ROM may or may not be enabled, hardware initialized, etc. It's basically a coordination between the ROM (or whatever power-up start there is) and the BIOS.

A warm boot is what an application program does to return to CP/M, and generally requires less initialization and in some cases needs to transfer status from the application. It's basically a return to CCP, except that CCP cannot be assumed to be present.

For CP/M 2.2., there are two main methods that a program returns to CCP. One is to preserve the CCP stack (and avoid overwriting CCP in memory) and return directly. This is a case where a program must know the size of a CP/M component - the CCP - in order to avoid overwriting it. The other return method is to jump to 0000H, performing a warm boot via the BIOS.

alank2
February 26th, 2018, 03:35 PM
Did systems have a cold reset and warm reset buttons? I'm thinking more in terms of a hardware reset instead of an application exit.

durgadas311
February 26th, 2018, 04:01 PM
I had never seen warm reset buttons, just a reset button which asserted the RESET signal to the CPU and peripherals (and associated hardware). For the schematic that Jonny posted, I suspect the intent was that the reset button was for hung programs, essentially forcing a JMP 0000H without affecting the rest of the hardware - so the BIOS could execute the warm boot code. It would be a good way to get out of a hung program without rebooting CP/M, although I'm not sure it saves you much unless you plan to debug the program postmortem. Interesting idea, anyway.

alank2
February 26th, 2018, 05:02 PM
I was somewhat going off of Grant's CP/M system here:

http://searle.hostei.com/grant/cpm/CPMSchematic1.2.gif

It looks like his warm reset just resets the Z80.
The cold also resets the SIO and CF and reenables the ROM.

I can see that real CP/M systems may have been configured differently though!

durgadas311
February 26th, 2018, 06:00 PM
Yeah, I was looking at the same schematic. I never saw a computer with cold and warm reset buttons before. Seems like more of a specialized feature. For commercial purposes, probably not worth adding. For one reason, too difficult to try and document/explain to the general public!

Plasmo
February 26th, 2018, 06:57 PM
Several of boards I designed have "RESET" and "NMI" buttons. There are a several reasons for separate buttons: the memory are dynamic RAM and reset causes the DRAM controller to reset as well, but not the NMI button. Reset also forces reload of the monitor from the secondary storage (serial EEPROM or compact flash). NMI is connected to the non-maskable interrupt, so it forces the processor to output its internal registers without affecting the memory content or peripherals. NMI is mostly for debugging purpose, but sometimes you can use it to force into supervisor state so to alter device configurations.

Chuck(G)
February 26th, 2018, 07:35 PM
Also see the "CP/M Alteration Guide".

TRAP/NMI should probably properly be used to report bus, memory or hardware (deadman timeout because of a missing board) errors. That's what we used it for. You could also use a CTRL+key to activate the TRAP routine, which just activated a brief debug routine. You could enter "G" to continue execution, which would continue from the interrupt point.

RESET reset everything and jumped to the boot code in ROM. Again, a two-key combination.

WSM
February 26th, 2018, 07:49 PM
Plasmo: There is a potential problem when using NMI on a basic Z80 or Z180 under CP/M. The hardware effectively issues a jump to location 66h ... HOWEVER ... location 66h is within FCB1 which is used by both the CCP and many application programs as the default FCB. It requires extra hardware in order to circumvent this possible overlay, either to switch back to ROM or to modify the actual restart address.

Chuck(G)
February 26th, 2018, 08:51 PM
I believe the ZX Spectrum used a trick like that.

Of course, the 8085 traps to 0024H, which is not a problem.

Plasmo
February 26th, 2018, 09:52 PM
Plasmo: There is a potential problem when using NMI on a basic Z80 or Z180 under CP/M. The hardware effectively issues a jump to location 66h ... HOWEVER ... location 66h is within FCB1 which is used by both the CCP and many application programs as the default FCB. It requires extra hardware in order to circumvent this possible overlay, either to switch back to ROM or to modify the actual restart address.

That's a good point. I designed in a NMI button for the Z280 SBC, but didn't have the needs to use it, yet. Memory location 0x0-0x1FF is "magical" because it was overlay with the compact flash data register when cold bootstrapping immediately after reset. It is simple to jam the data bus with NOP when the NMI button is pressed until the NMI service routine is reached (or when address rolls over to 0x0), but that's a lot of complexity to explain. Hmmm...

Edit, another thought, NMI is supervisor mode, so I can set up MMU page so the supervisor page is swapped in when NMI is asserted.

durgadas311
February 27th, 2018, 04:53 AM
Plasmo: There is a potential problem when using NMI on a basic Z80 or Z180 under CP/M. The hardware effectively issues a jump to location 66h ... HOWEVER ... location 66h is within FCB1 which is used by both the CCP and many application programs as the default FCB. It requires extra hardware in order to circumvent this possible overlay, either to switch back to ROM or to modify the actual restart address.

Definitely. This generally discouraged systems from using NMI. The one place I remember (H89-37 I think) it was for the completion of a disk I/O. The driver had to save the data at 0066H (3 bytes) and setup a JMP, then start the disk I/O, and then restore contents on completion. Another place (Kaypro) it used special circuitry to essentially un-HLT, I forget what else the driver had to do.

Keep in mind, NMI technically performs a *CALL* to 0066H, so you have to make sure that there is RAM wherever the SP might be pointing... if you swap in ROM on NMI you might be unable to return to the running program - if that was a goal.

Plasmo
February 27th, 2018, 03:32 PM
Since the Z280 SBC has plenty of memory to burn, I'm incline to just swap in a new 64K memory block pre-loaded with the NMI handling routine. The hardware can do the memory swap when NMI is asserted, but there is a lot of software yet to be written to dump out CPU registers and examine the memory content of the original 64K. Probably more works than it is worth.

Chuck(G)
February 27th, 2018, 04:12 PM
The problem with NMI and TRAP (depending on CPU) is that both push the PC onto the stack. The problem is that there's no way ahead of time to guarantee that the stack contents are valid; thus, there's no guarantee that returning from a TRAP or NMI is going to work--and remember, neither honors the interrupt enable flag status.

Putting that aside, the easiest solution seems to me to be latching the edge of NMI/TRAP and waiting for the next M1 status, then strobing a single one-byte RST instruction onto the bus. No need for bankswitching or other fancy stuff. You get the return address from the RST = 0067H as a way of telling how you got there.

Just tossing something out for consideration.

alank2
March 1st, 2018, 01:10 PM
For banked systems, which bank is active during a warm reboot?

What if the wrong bank was active in the MMU when the warm reset button is pressed?

Does reset clear 0x0000 to point to bank 0 ?

Aren't the vectors for BDOS and warm boot and other goodies at 0x0000 in bank 1 in CP/M 3 ?

durgadas311
March 1st, 2018, 02:06 PM
For banked systems, which bank is active during a warm reboot?

What if the wrong bank was active in the MMU when the warm reset button is pressed?

Does reset clear 0x0000 to point to bank 0 ?

Aren't the vectors for BDOS and warm boot and other goodies at 0x0000 in bank 1 in CP/M 3 ?

You are pointing out some good issues with the warm reset button "feature". The BIOS entry points are in common memory, so should always be accessible. The BIOS warm boot entry cannot assume any bank, as it might be called from the program directory in bank 1 or via BDOS function 0 (I'm not sure the exact path, so bank 0 might be switched in - we'd need to check). The warm boot code could force a particular, known, bank, and usually does. The CP/M implementations that I've done all replicate "page 0" (or the lower part of it) to all banks, to ensure interrupts work from any bank. This replication is done in warm boot (as well as cold boot) in case the user has meddled, using a "golden copy" in some bank other than 1.