Starting with the next release, pressing Backspace four times in succession reinitializes SpinRite's video interface. 
-
SpinRite v6.1 Release #3 Guest:
The 3rd release of SpinRite v6.1 is published and may be obtained by all SpinRite v6.0 owners at the SpinRite v6.1 Pre-Release page. (SpinRite will shortly be officially updated to v6.1 so this page will be renamed.) The primary new feature, and the reason for this release, was the discovery of memory problems in some systems that were affecting SpinRite's operation. So SpinRite now incorporates a built-in test of the system's memory. For the full story, please see this page in the "Pre-Release Announcements & Feedback" forum.
/Steve. -
Be sure to checkout “Tips & Tricks” Dear Guest Visitor → Once you register and log-in please checkout the “Tips & Tricks” page for some very handy tips!
/Steve. -
BootAble – FreeDOS boot testing freeware
To obtain direct, low-level access to a system's mass storage drives, SpinRite runs under a GRC-customized version of FreeDOS which has been modified to add compatibility with all file systems. In order to run SpinRite it must first be possible to boot FreeDOS.
GRC's “BootAble” freeware allows anyone to easily create BIOS-bootable media in order to workout and confirm the details of getting a machine to boot FreeDOS through a BIOS. Once the means of doing that has been determined, the media created by SpinRite can be booted and run in the same way.
The participants here, who have taken the time to share their knowledge and experience, their successes and some frustrations with booting their computers into FreeDOS, have created a valuable knowledgebase which will benefit everyone who follows.
You may click on the image to the right to obtain your own copy of BootAble. Then use the knowledge and experience documented here to boot your computer(s) into FreeDOS. And please do not hesitate to ask questions – nowhere else can better answers be found.
(You may permanently close this reminder with the 'X' in the upper right.)
Starting with the next release, pressing Backspace four times in succession reinitializes SpinRite's video interface.
And that'll work without interrupting whatever else it's doing at the time?
A further question please Steve:
As well as us being able to wake the board's graphics via keystrokes, and being able to do so while SpinRite is still the active program running in that DOS / text environment, would it be feasible for SpinRite to send the same graphics-reset signal to the board's graphics as it (SpinRite) exits back to a command prompt?
(Or if the graphics is already being reset by design as SpinRite's exits, then please disregard this thought!)
I'm imagining a near-future scenario (pending arrival of the anticipated non-DOS/text versions of SpinRite) where I might - for one silly reason or another - cause SpinRite 6.x to exit to the command prompt before I had 'restored' the display using this (imminent) 4-backspace-key sequence ... hence leaving me again with a visibly unresponsive ZimaBoard ... sitting at a command prompt that I then couldn't see ... !?
Thank you again.
As well as us being able to wake the board's graphics via keystrokes, and being able to do so while SpinRite is still the active program running in that DOS / text environment, would it be feasible for SpinRite to send the same graphics-reset signal to the board's graphics as it (SpinRite) exits back to a command prompt?
(Or if the graphics is already being reset by design as SpinRite's exits, then please disregard this thought!)
I'm imagining a near-future scenario (pending arrival of the anticipated non-DOS/text versions of SpinRite) where I might - for one silly reason or another - cause SpinRite 6.x to exit to the command prompt before I had 'restored' the display using this (imminent) 4-backspace-key sequence ... hence leaving me again with a visibly unresponsive ZimaBoard ... sitting at a command prompt that I then couldn't see ... !?
Thank you again.
I'm reluctant to do that since this is generally an edge case issue that will not affect most of SpinRite's users and since resetting the video causes a somewhat significant period of black screen while the video system is resynchronized (newer monitors appear to take quite some time for who-knows-what reason). I wouldn't want that to happen every time anyone exited from SpinRite.
So... Any power user who had the FreeDOS "mode" command handy could either blindly enter "mode 80" to fully reinitialize the video system. Or, such a power user could invoke SpinRite using a batch file that first ran SpinRite (adding whatever power user commands they might wish), then, upon SpinRite's exit, automatically issued the "mode 80" command to always reinitialize the video.
So... Any power user who had the FreeDOS "mode" command handy could either blindly enter "mode 80" to fully reinitialize the video system. Or, such a power user could invoke SpinRite using a batch file that first ran SpinRite (adding whatever power user commands they might wish), then, upon SpinRite's exit, automatically issued the "mode 80" command to always reinitialize the video.
I'm anxious to give it a try. I started a level 3 run on an old WD 120G IDE drive last night, and then I turned off the monitor for what seemed like 5-10 minutes, and that was all she wrote. Screen was black for 16 hours until this afternoon when I was sure it was done processing based on the activity light on the PCIe>>IDE interface card.Yep. I've been testing it extensively. It's transparent.
I'm guessing that the Zimaboard must not have any sort of CMOS battery because it seems like every time I run Spinrite, the logs have times that are wildly inaccurate.
Gottit!I'm reluctant to do that since this is generally an edge case issue (... snip ...) Or, such a power user could invoke SpinRite using a batch file that first ran SpinRite (adding whatever power user commands they might wish), then, upon SpinRite's exit, automatically issued the "mode 80" command to always reinitialize the video.
I understand 100% ... and as you have confirmed the effectiveness of the mode 80 command (which you'd also mentioned briefly above), I will do exactly that in my existing 'SR' batch file
Simple and elegant!
My ZimaBoard did come with an installed CMOS button-cell (a variant on a 2032 button-cell) but it ran flat within a few days after I started using the board.
I'll guess that yours has reached end-of-life too. See below for a battery replacement suggestion.
On mine - with the dead battery - before I ran a DOS session I was first launching CasaOS for a short spell (or maybe I was launching my Linux Distro: sorry I forget which worked best) in order to synchronise the board's internal clock from some relevant NTP source ... then rebooting onto my SpinRite thumbdrive while keeping the power on the board.
I soon got tired of this dance, so I eventually dismantled the ZimaBoard and replaced its CMOS button-cell.
The button-cell is a variant with solderable tags, and the replacement I used after a bit of searching was a:
Panasonic BR-2032/VCN
I got mine (in UK) from RS Components Ltd., via their online store at uk.rs-online.com.
RS Stock No. (in December 2022) 7450916.
Price £15.50 for a pack of three.
(I have no association with RS Components except as a long-time customer.)
I just snipped off the original button-cell - keeping the wires at maximum length and keeping a note of their polarity - and soldered on the replacement cell. I used some heatshrink tubing to insulate both the bare case on the battery as well as the terminals.
There is no neat and tidy receptacle for this button-cell 'inside' the ZimaBoard, so I just used a double-sided sticky pad to hold it in a somewhat 'comfortable' spot on the board ... not obstructing airflow around any of the chips, for example.
In my Autoexec.bat file onto which I boot before I run a (separate) batch file to start SpinRite, I now include the two DOS commands ...
Date /T and
Time /T
... just as a sanity check - or for the day when this replacement CMOS button-cell might also expire
Excuse this long post!
Hopefully helpfull.
Note that a BR2032 is a rechargeable lithium button cell, and thus should never be replaced with a more common CR2032 cell. The BR2032 cell can however simply be charged up by leaving the board powered for 24 hours, and setting the clock sometime during this period, and remembering to power it up at least once every 24 months to keep the cell charge up. They should last decades in use, and thus really should not need changing, though a new board likely will have a flat cell, needing charging for 24 hours, because the cell will have discharged itself in the conductive plastic static protection wrap. Thus I would say new boards be in a case, and power on and leave on for 24 hours before you even use them, to ensure the cell also is charged up.
I've had the Zimaboard turned off overnight it remembered the time this morning. I wonder if it just needed some runtime to get the battery charged.
@SeanBZA , do you happen to know for sure that the Zimaboard has the ability to charge the CMOS battery? I've never heard of such a thing, though I think it would be quite a fantastic feature if true.
@SeanBZA , do you happen to know for sure that the Zimaboard has the ability to charge the CMOS battery? I've never heard of such a thing, though I think it would be quite a fantastic feature if true.
Hmmm! ??
The Panasonic technical spec's for the BR button-cell I referenced above say it's a 190 mAh Lithium Polycarbon Monofluoride battery ... and (hence) is not a rechargeable battery.
I haven't kept the old button-cell from my board to double check its marking here, and I suppose it's possible I might have sought and found and installed the wrong substitute button-cell, but - if I was a betting man - I'd bet you I was extremely diligent in my searches at the time for its replacement, and I would have taken my cues directly from the marking on that old button-cell.
(TL;DR ... Had decades careers in electronics and computers and am very aware that offering the wrong advice on a topic like this could be frankly dangerous.)
It's also possible that different marques of Zimaboard had circuitry designed for either primary cells or for rechargeable cells.
So on your point @SeanBZA, and taking it as a note of caution, I should have included in my post above a recommendation that ...
... the reader should verify the cell-type on their own board before attempting to replace theirs.
Perhaps another ZimaBoard owner - who experiences (let's say) an 'exhausted' cell - could confirm to us here that theirs recovers after a 24 hour period of power-on?
The Panasonic technical spec's for the BR button-cell I referenced above say it's a 190 mAh Lithium Polycarbon Monofluoride battery ... and (hence) is not a rechargeable battery.
I haven't kept the old button-cell from my board to double check its marking here, and I suppose it's possible I might have sought and found and installed the wrong substitute button-cell, but - if I was a betting man - I'd bet you I was extremely diligent in my searches at the time for its replacement, and I would have taken my cues directly from the marking on that old button-cell.
(TL;DR ... Had decades careers in electronics and computers and am very aware that offering the wrong advice on a topic like this could be frankly dangerous.)
It's also possible that different marques of Zimaboard had circuitry designed for either primary cells or for rechargeable cells.
So on your point @SeanBZA, and taking it as a note of caution, I should have included in my post above a recommendation that ...
... the reader should verify the cell-type on their own board before attempting to replace theirs.
Perhaps another ZimaBoard owner - who experiences (let's say) an 'exhausted' cell - could confirm to us here that theirs recovers after a 24 hour period of power-on?
Yes the BR are a regular cell, got confused with the VL and ML series. So it would seem the board batteries are just flat, either long storage, or high current draw off the board in power off. Solution is to put a bigger cell in there then, instead of a BR2032, use a bigger one, and also clean the board with isopropyl alcohol thoroughly before plugging it in, and allow to dry.
I can confirm that this is working for me in v6.1 - PR5.04Starting with the next release, pressing Backspace four times in succession reinitializes SpinRite's video interface.
I posted a question about this subject in the Zimaboard forum at the Icewhale Community Forum, where I provided a link here to this thread on the GRC Spinrite Forum.
icewhale.community
Zimaboard video disabled after turning off computer monitor when in DOS
When I am running FreeDOS based programs on a Zimaboard, that runs past bedtime, I turn off the computer monitor to reduce light shining into the hallway, and when I turn it on in the morning the screen is blank and I can’t get anything to show on screen. I know that the DOS program is running...
icewhale.community
Similar threads
- Contains 5 staff post(s)
