Resolved Keyboard input not being recognized.

[MatthewVGreene]

I'm not sure if this is the correct section to post this in but here goes:
I dropped the SpinRite exe onto the flash drive that has ReadSpeed on it to get SpinRite running on my UEFI only machine. Everything went great until the Level 3 op started (3 because of a SSD). As soon as the operation began, my computer would not respond to ANY keyboard input. Is this a known thing? And should i disregard until SpinRite6.1?

 

[PHolder]

get SpinRite running on my UEFI only machine

I don't understand your posting because SpinRite 6.0 (and even 6.1 when available) does not run under UEFI.

 

[DanR]

I do not understand your posting either. ReadSpeed 1.0, SpinRite 6.0 (and, when available, SpinRite 6.1) all require a BIOS boot into a DOS environment.

If your system is indeed UFEI only, i.e. no BIOS option, then how do you get your ReadSpeed USB to boot???

 

[AlanD]

I assume that your keyboard is USB. Do you have the USB drivers in your DOS boot setup? It may be that USB support is provided by the BIOS until you start running SpinRite, but from then on, you need the USB driver loaded as well.
Alternatively, if your machine has a PS/2 port, and you have a PS/2 keyboard, try that.

 

[Steve]

I'm not sure if this is the correct section to post this in but here goes:
I dropped the SpinRite exe onto the flash drive that has ReadSpeed on it to get SpinRite running on my UEFI only machine. Everything went great until the Level 3 op started (3 because of a SSD). As soon as the operation began, my computer would not respond to ANY keyboard input. Is this a known thing? And should i disregard until SpinRite6.1?

Hey Matthew,

The phenomenon of SpinRite losing keyboard control once it actually starts running is known. We typically see it on Apple Mac machines because they use a USB keyboard internally. But it could theoretically affect other non-Apple machines as well.

The trouble is that in order to perform its on-the-fly multi-screen multitasking with the drive access running in the background -- because SpinRite v6 uses the BIOS for its drive accesses -- SpinRite stops using the BIOS for its keyboard reading and instead reads directly from the keyboard hardware. If the machine in question (like Apple Macs) does not provide hardware-level emulation of the keyboard hardware, SpinRite won't "see" anything from the keyboard once it has started running.

This will be resolved in SRv6.1 since it will not be using the BIOS for its bulk data transfers.

 

[MatthewVGreene]

Thanks all for the responses! Yes, it is a USB keyboard. I'll just bide my time until 6.1.

 

[MatthewVGreene]

I don't understand your posting because SpinRite 6.0 (and even 6.1 when available) does not run under UEFI.

Then I must be mistaken somehow. A flashdrive formatted by SpinRite would not boot on my machine. I assumed this was because of UEFI. ReadSpeed on a flashdrive boots just fine. Apologies for any confusion.

 

[MatthewVGreene]

Hey Matthew,

The phenomenon of SpinRite losing keyboard control once it actually starts running is known. We typically see it on Apple Mac machines because they use a USB keyboard internally. But it could theoretically affect other non-Apple machines as well.

The trouble is that in order to perform its on-the-fly multi-screen multitasking with the drive access running in the background -- because SpinRite v6 uses the BIOS for its drive accesses -- SpinRite stops using the BIOS for its keyboard reading and instead reads directly from the keyboard hardware. If the machine in question (like Apple Macs) does not provide hardware-level emulation of the keyboard hardware, SpinRite won't "see" anything from the keyboard once it has started running.

This will be resolved in SRv6.1 since it will not be using the BIOS for its bulk data transfers.

That is exactly what I witnessed! Thanks! Looking forward to 6.1!

 

[DanR]

A flashdrive formatted by SpinRite would not boot on my machine. I assumed this was because of UEFI. ReadSpeed on a flashdrive boots just fine.

Ahhhh! SpinRite and ReadSpeed format media differently. SpinRite creates a basic FreeDOS environment for SpinRite 6.0 to run in.

ReadSpeed, on the other hand, creates a more sophisticated FreeDOS environment for ReadSpeed (and, eventually, SpinRite 6.1) to operate in.

Apparently your UEFI system likes the ReadSpeed formatting but not the SpinRite formatting.

 

[PHolder]

A flashdrive formatted by SpinRite would not boot on my machine. I assumed this was because of UEFI. ReadSpeed on a flashdrive boots just fine. Apologies for any confusion.

Copy your copy of SpinRite on the flashdrive that does boot and you should be golden.

 

[MatthewVGreene]

Ahhhh! SpinRite and ReadSpeed format media differently. SpinRite creates a basic FreeDOS environment for SpinRite 6.0 to run in.

ReadSpeed, on the other hand, creates a more sophisticated FreeDOS environment for ReadSpeed (and, eventually, SpinRite 6.1) to operate in.

Apparently your UEFI system likes the ReadSpeed formatting but not the SpinRite formatting.

Great observation! Thank you.

 

[Barry Wallis]

Apparently your UEFI system likes the ReadSpeed formatting but not the SpinRite formatting.

How is that even possible?

 

[DanR]

How is that even possible?

I do not know.

But the evidence in this thread seems to substantiate it.

 

[Steve]

How is that even possible?

SpinRite doesn't format drives with a partition sector. ReadSpeed/InitDisk, does. The earliest releases of InitDisk gave users the option of whether or not to use an MBR (Partition Table.) But in some of that early experimentation we found that whereas some BIOSes would NOT boot without an MBR, =ALL= BIOSes would boot with one. So we learned something and the option was removed.

 

[Barry Wallis]

SpinRite doesn't format drives with a partition sector. ReadSpeed/InitDisk, does. The earliest releases of InitDisk gave users the option of whether or not to use an MBR (Partition Table.) But in some of that early experimentation we found that whereas some BIOSes would NOT boot without an MBR, =ALL= BIOSes would boot with one. So we learned something and the option was removed.

Thanks for the elucidation @Steve.

 

[MatthewVGreene]

For anyone who is curious, here is an overview of my system:
**my OS drive is encrypted with VeraCrypt**


OS Name Microsoft Windows 10 Home
Version 10.0.19042 Build 19042
Other OS Description Not Available
OS Manufacturer Microsoft Corporation
System Name CYBERPOWER-DESK
System Manufacturer Gigabyte Technology Co., Ltd.
System Model AX370M-DS3H
System Type x64-based PC
System SKU Default string
Processor AMD Ryzen 7 2700 Eight-Core Processor, 3200 Mhz, 8 Core(s), 16 Logical Processor(s)
BIOS Version/Date American Megatrends Inc. F50d, 7/2/2020
SMBIOS Version 3.2
Embedded Controller Version 255.255
BIOS Mode UEFI
BaseBoard Manufacturer Gigabyte Technology Co., Ltd.
BaseBoard Product AX370M-DS3H-CF
BaseBoard Version x.x
Platform Role Desktop
Secure Boot State Off
PCR7 Configuration Binding Not Possible
Windows Directory C:\WINDOWS
System Directory C:\WINDOWS\system32
Boot Device \Device\HarddiskVolume3
Locale United States
Hardware Abstraction Layer Version = "10.0.19041.488"
User Name CYBERPOWER-DESK\matth
Time Zone Pacific Standard Time
Installed Physical Memory (RAM) 16.0 GB
Total Physical Memory 15.9 GB
Available Physical Memory 11.1 GB
Total Virtual Memory 23.2 GB
Available Virtual Memory 12.4 GB
Page File Space 7.21 GB
Page File C:\pagefile.sys
Kernel DMA Protection Off
Virtualization-based security Not enabled
Device Encryption Support Reasons for failed automatic device encryption: TPM is not usable, PCR7 binding is not supported, Hardware Security Test Interface failed and device is not Modern Standby, Un-allowed DMA capable bus/device(s) detected, TPM is not usable
Hyper-V - VM Monitor Mode Extensions Yes
Hyper-V - Second Level Address Translation Extensions Yes
Hyper-V - Virtualization Enabled in Firmware No
Hyper-V - Data Execution Protection Yes

If anyone has more questions, I'll happily answer!