Export thread

  • 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.)

UEFI Booting

#1

M

Mervyn Haynes

I think this topic deserves it own thread!
As we know most new PC will not have the ability to boot into legacy mode, so cannot take part in this.
I have 3 laptops, 2 which have legacy mode, but 1 does not, they are all Dell XPs 15s.


#2

Steve

Steve

@Mervyn Haynes: Once we open the various ReadSpeed forums, it was my intention that the “Booting DOS” forum there would be the place for this. There's already been some general discussions of this, here, and it's not clear to me that there's much more to say about it other than none of this stuff will boot on any UEFI-only system for the time being. And for those systems that can (with some nudging) boot to DOS, that forum will be the place where our DOS booting gurus (and we have a bunch here) will be able to help others. (y)


#3

M

Mervyn Haynes

@Mervyn Haynes: Once we open the various ReadSpeed forums, it was my intention that the “Booting DOS” forum there would be the place for this. There's already been some general discussions of this, here, and it's not clear to me that there's much more to say about it other than none of this stuff will boot on any UEFI-only system for the time being. And for those systems that can (with some nudging) boot to DOS, that forum will be the place where our DOS booting gurus (and we have a bunch here) will be able to help others. (y)
Don't get me wrong Steve, I grew up with DOS, and loved it. I remember trying to get close to that mythical 640k lower memory as possible with memory managers.
But times move on, and I think this UEFI matter needs addressing sooner rather than later.
What do other forum members think?


#4

Steve

Steve

It's NOT a quick and small thing, Mervyn. It means removing all DOS dependency from SpinRite and converting it from an application of DOS to its own mini OS. Given that everyone wants a SpinRite update, and that NO earlier PCs have any need for this, it makes far more sense to make SpinRite much more useful to nearly everyone first, and then tackle what will not be a small change.


#5

Barry Wallis

Barry Wallis

It's NOT a quick and small thing, Mervyn. It means removing all DOS dependency from SpinRite and converting it from an application of DOS to its own mini OS. Given that everyone wants a SpinRite update, and that NO earlier PCs have any need for this, it makes far more sense to make SpinRite much more useful to nearly everyone first, and then tackle what will not be a small change.
Sad, but true.


#6

P

PHolder

When you bought SpinRite, you received no promise that it would work on new things not then invented. (At least I don't believe @Steve would be crazy enough to make such promises.) He's doing his best to add support for some devices that came out after SpinRite 6, but I don't think you can fairly expect him to support an entirely different system architecture for free. 6.1 is meant to be a free update to add support for [very] large drives and a faster means to scan them. 7.0 will presumably be a re-write to support the current state of the art in booting (UEFI) but will not necessarily be a free upgrade for older version owners.


#7

Barry Wallis

Barry Wallis

When you bought SpinRite, you received no promise that it would work on new things not then invented. (At least I don't believe @Steve would be crazy enough to make such promises.) He's doing his best to add support for some devices that came out after SpinRite 6, but I don't think you can fairly expect him to support an entirely different system architecture for free. 6.1 is meant to be a free update to add support for [very] large drives and a faster means to scan them. 7.0 will presumably be a re-write to support the current state of the art in booting (UEFI) but will not necessarily be a free upgrade for older version owners.
It's a pleasant surprise that Steve is doing all he can to support all current drive architectures and sizes within the "must be able to boot to DOS" constraint for free for all current SpinRite owners.


#8

internet

internet

I remember trying to get close to that mythical 640k lower memory as possible with memory managers.

now THAT is a blast from the past! 😂

thanks for the memories!


#9

M

Mervyn Haynes

now THAT is a blast from the past! 😂

thanks for the memories!
Remember QEMM?


#10

Barry Wallis

Barry Wallis

Remember QEMM?
I used QEMM.


#11

Happenstrance

Happenstrance

Remember QEMM?
No, I remember RAMLink with an Action Replay mark VI plugged into the passthrough port. That thing could hold all 14 sides of the AD&D games Pool of Radiance and Curse of the Azure Bonds from 5¼" floppies plus an instance of GeOS in memory!

I've no idea whether SpinRite would work on that thing LOL.


#12

M

Mervyn Haynes

I used QEMM.
Also remember using Memmaker & MSD to see how all the drivers were loaded into high memory. It made a difference which order you loaded them, as some would reduce their size after being loaded, so it made sense to load them first. But QEMM was the best one to use, I think once I did get only about 1K used in lower memory!

Ah, the good old days

I think I have gone off topic on this post!!!! ;)


#13

A

AlanD

I remember those days. I managed to get about 635KB free with the networking stack loaded as well ( Novell Netware over token ring)


#14

Steve

Steve

386MAX was my memory manager of choice. QuarterDeck's QEMM was good too. But Bob Smith's 386MAX had a few additional bells and whistles. :)


#15

Vela Nanashi

Vela Nanashi

Ah nostalgia feels...

I remember QEMM and all the hard work to get memory freed up, also I remember 2M iirc that allowed 1.44mb floppies to be formatted larger than that, I probably have a few of those floppies around heh, I doubt I will see the data on them again though (unless I can breathe life into the table legs (current job for my two 286 IBM servers) that I rescued when they got decommissioned, that have 2.88mb drives, those should be able, with dos, to run 2M and get access to the diskettes unless those have faded.

Also because I liked norton commander and um 4dos iirc command interpreter, that I wrote batch scripts for to help automate some tasks I wanted to do. I resisted for so long to start using windows (any version), and one of the few programs I enjoyed there was that card thing, that allowed keeping short notes, and that seems to not exist for current windows, I am sure one can find a program like that again though, but I have better things to hold my snippets of data now (maybe others will like the combination of notepad++ and cherrytree for keeping data).

I dislike how after win98se the fight was lost with keeping windows properly stripped down, I mean I got somewhat close in winxp too, but now win7 and later it is really hard to have full control of what processes are allowed to remain running, I do not know each of them and what they do anymore and that is unsettling. I would prefer a computer that only runs processes that I know what they do, and that actually do something that I want them to do, not a billion useless background tasks, this is my computer not Microsofts.

At any rate rant over :)


#16

M

Mervyn Haynes

386MAX was my memory manager of choice. QuarterDeck's QEMM was good too. But Bob Smith's 386MAX had a few additional bells and whistles. :)
386Max, that was the other one I could not think of.

But after purchasing QEMM there was not much point (cost wise) of buying another memory manager. Also I think people were very loyal to the manager they purchased back then, and poo hooed all the others.


#17

D

DanR

Remember QEMM?
Yep. Used it a long l-o-n-g time ago! :)


#18

M

Mervyn Haynes

I still have to manage DOS memory, as I use Virtualbox sometimes to play the old 1990 games, but have found DOSBOX does a better job with games. But not all.


#19

Barry Wallis

Barry Wallis

I still have to manage DOS memory, as I use Virtualbox sometimes to play the old 1990 games, but have found DOSBOX does a better job with games. But not all.
I will have to try that. I stil have some 16-bit games I would like to play.


#20

M

Mervyn Haynes

I will have to try that. I stil have some 16-bit games I would like to play.
What ones do you want to play?
I think the most demanding one for lower memory I remember was Falcon 3


#21

Barry Wallis

Barry Wallis

What ones do you want to play?
I think the most demanding one for lower memory I remember was Falcon 3
Mostly the Zork games after they moved to using graphics (e.g., Zork Zero, Beyond Zork). I can play the text-based Infocom games via an interpreter I have.


#22

PHoganDive

PHoganDive

FYI, there is a box set of Infocom games, with 33 of them :) Here's a link to a review.



#23

Barry Wallis

Barry Wallis

FYI, there is a box set of Infocom games, with 33 of them :) Here's a link to a review.

Thanks!


#24

M

Mervyn Haynes

Mostly the Zork games after they moved to using graphics (e.g., Zork Zero, Beyond Zork). I can play the text-based Infocom games via an interpreter I have.
You should try some demanding games, for DOS, like Strike commander, Wing commander, or my favorite of all time Ultimate Underworld 1 & 2


#25

linuxkidd

linuxkidd

Ya, overall the 386MAX was a bit better... I however was stuck using QEMM since it worked great with DESQview -- I ran pcboard BBS in the background and Windows in a second session using DESQview.. :)

good times!


#26

PHoganDive

PHoganDive

My favorite DOS game was Descent, with a full 6 axis of motion freedom. You can still get many of the old games on GOG.com :)


#27

Barry Wallis

Barry Wallis

You should try some demanding games, for DOS, like Strike commander, Wing commander, or my favorite of all time Ultimate Underworld 1 & 2
Sorry, those aren't my cup of tea. However, I am replaying Baldur's Gate: Enhanced Edition on my PC these days.


#28

M

Mervyn Haynes

I know this thread got a little off track with DOS games, but a few people are now asking about UEFI. Seems to have had a renascence! Steve said he would not be looking at this until SR7, so that could be years of yet, given that SQRL took 7.


#29

Barry Wallis

Barry Wallis

I know this thread got a little off track with DOS games, but a few people are now asking about UEFI. Seems to have had a renascence! Steve said he would not be looking at this until SR7, so that could be years of yet, given that SQRL took 7.
But SQRL was started from scratch. He had to write the architecture and document the protocol before even thinking about the code. SR is a mature product that is evolving with the times. I'm not trying to minimize the work needed to divorce SR from DOS, I'm making the point that it is much les in terms of overall work.


#30

M

Mervyn Haynes

I'm not trying to minimize the work needed to divorce SR from DOS, I'm making the point that it is much les in terms of overall work.
Are you a betting man Barry? I would be prepared to offer a spread bet of 3 years for a working version of 7. If I were to offer $100/month either way, how would people take my bet?
I am presuming people know what a spread bet is.


#31

P

PHolder

I'd not take that bet. @Steve has no experience developing UEFI code that I am aware. It will probably not go quickly... And it's questionable how much existing code can be reused. (Any screen/user I/O may need to be completely redone, for example.)


#32

M

Mervyn Haynes

I'd not take that bet. @Steve has no experience developing UEFI code that I am aware. It will probably not go quickly... And it's questionable how much existing code can be reused. (Any screen/user I/O may need to be completely redone, for example.)
So would you bet long or short?


#33

M

Mervyn Haynes

So would you bet long or short?
To put another way guys, forgetting about the betting.
Do you think SR 7 will take less or more than 3 years?


#34

Barry Wallis

Barry Wallis

I generally only bet when I have a reasonable chance of winning (reasonable >= 90%) [that's why I've never played the lottery]. In this case I have no way of determining with any degree of certainty how long it will take Steve to complete SR V7. Why? Because he himself doesn't put out a schedule so I have nothing to base my bet on. He could get it done in less than three years or it could be more. Also, is that three years after 6.1 or three years from now (not that it would make a difference to me).

In my early programming days I learned structured programming and was trying to introduce it to my company's programming department. I was given a programming task which I broke down into discreet modules. I knew from experience that each module would take an average of one day to code, test, fix and integrate. When I completed my design I told the staff (and my manager) how long it would take me to complete the program. They were amazed when I came in exactly on time. The benefit of this approach was when I was given an unrealistic schedule, I could tell them what a realistic schedule would be and negotiate from there.

The difference between @Steve's work and mine (back then) is that he doesn't have to deliver on a set schedule. However, like him, I too strive for zero defects in my finished project (I stopped calling them bugs a long time ago).


#35

M

Mervyn Haynes

I generally only bet when I have a reasonable chance of winning (reasonable >= 90%) [that's why I've never played the lottery]. In this case I have no way of determining with any degree of certainty how long it will take Steve to complete SR V7. Why? Because he himself doesn't put out a schedule so I have nothing to base my bet on. He could get it done in less than three years or it could be more. Also, is that three years after 6.1 or three years from now (not that it would make a difference to me).

In my early programming days I learned structured programming and was trying to introduce it to my company's programming department. I was given a programming task which I broke down into discreet modules. I knew from experience that each module would take an average of one day to code, test, fix and integrate. When I completed my design I told the staff (and my manager) how long it would take me to complete the program. They were amazed when I came in exactly on time. The benefit of this approach was when I was given an unrealistic schedule, I could tell them what a realistic schedule would be and negotiate from there.

The difference between @Steve's work and mine (back then) is that he doesn't have to deliver on a set schedule. However, like him, I too strive for zero defects in my finished project (I stopped calling them bugs a long time ago).
So, +or- 3yr from now. What is your opinion?


#36

Barry Wallis

Barry Wallis

So, +or- 3yr from now. What is your opinion?
Sorry that I was verbose and wasn't clear. There isn't enough information available for me to form an opinion.


#37

M

Mervyn Haynes

Sorry that I was verbose and wasn't clear. There isn't enough information available for me to form an opinion.
Aw come on, you have to have an opinion! If not give me a guess.


#38

M

Mervyn Haynes

Anyone prepared to stick their neck out on my guess on the 3 year development timeline of SR7 & the introduction of UEFI booting?


#39

D

DanR

To put another way guys, forgetting about the betting.
Do you think SR 7 will take less or more than 3 years?
Less.

Seems like SR 6.1 ought to be a reality sometime in 2021. @Steve has said that SR 7.0 development will follow immediately after the SR 6.1 release. So, SR 7.0 could well be a work in progress a year from now. Conceivably it could be a reality a year from now, if things go well. There are, however, far too many unknowns and potential Gotchas to make any meaningful predictions or speculation. It will be when it will be.


#40

M

Mervyn Haynes

Less.

Seems like SR 6.1 ought to be a reality sometime in 2021. @Steve has said that SR 7.1 development will follow immediately after the SR 6.1 release. So, SR 7.0 could well be a work in progress a year from now. Conceivably it could be a reality a year from now, if things go well. There are, however, far too many unknowns and potential Gotchas to make any meaningful predictions or speculation. It will be when it will be.
Thank you for your honest opinion.
I think the UEFI coding will take longer, due to Steve's meticulous attention to detail.


#41

M

Mervyn Haynes

Steve wrote this in the SR dev forum, so I guess we are going to get it sooner rather that later! Wooohhh.

As Ern said, SR v6.1 does need DOS. But we've seen that systems
like yours are becoming common enough that they have changed my
priorities in favor of quickly dropping DOS in favor of native
BIOS/UEFI operation without any reliance upon DOS.


#42

M

Mervyn Haynes

Steve wrote this in the SR dev forum, so I guess we are going to get it sooner rather that later! Wooohhh.

As Ern said, SR v6.1 does need DOS. But we've seen that systems
like yours are becoming common enough that they have changed my
priorities in favor of quickly dropping DOS in favor of native
BIOS/UEFI operation without any reliance upon DOS.
Steve also wrote this in the Readspeed release history
  • So far <<knock on wood>> when ReadSpeed runs, it has run perfectly. The only trouble anyone has had, has been getting their machines to boot from their prepared ReadSpeed USB stick. The typical reason for trouble is lack of system support for BIOS booting. The move to UEFI is well underway, which explains my change in SpinRite's planned Roadmap. I will make SpinRite v6.1 available to everyone as quickly as possible. Then I'm going to immediately move to support for UEFI and liberation from DOS, which is incompatible with UEFI. This will happen ahead of SpinRite's support for USB and NVMe mass storage, which in planned to immediately follow.
How times change, below is email reply's from Gregg (his tech support guy), from the end of last year (2019), when I had no legacy option on my Dell 7590.

"All of the UEFI firmware we have encountered, so far, has also supported "legacy" BIOS functions specifically to continue to provide support for BIOS-dependent client programs."

"This is the first time that I have heard of or seen any system that cannot boot to a DOS-based external boot device (CD or USB)."

"I did forward your note to Steve so we will see what can be done for future versions of SpinRite."

"I did not hear from Steve on this particular issue . . . I usually do not since it is pertaining to future SpinRite."

"There is no time line on the next version of SpinRite nor when this particular issue will be addressed."

I would like to think I played a small part in spurring him on to get this UEFI problem sorted out! :)


#43

MrObvious

MrObvious

I wonder how hard it would be to make FreeDOS work on UEFI? I don't know much about the underpinnings, but it sounds like a lot of the core functionality would be lost anyway that FreeDOS has now. Maybe I'm wrong?

Perhaps, emulation of the functions is possible?


#44

Barry Wallis

Barry Wallis

@MrObvious: I think we will find out once @Steve starts working on it. Since all my current computers are Microsoft Surface Books and don't support legacy boot, I can't wait.


#45

MrObvious

MrObvious

@MrObvious: I think we will find out once @Steve starts working on it. Since all my current computers are Microsoft Surface Books and don't support legacy boot, I can't wait.
Likely it will be a ground up approach. The only other thing I can see Steve doing is possibly using a BSD/Linux based boot, depending on licensing (which is why *BSD may be chosen). That may be the course of least resistance and best in terms of going forward.