PC Diagnostics from Micro2000
Micro2000, PC Diagbostics, Computer Repairs
Home | Site Map | Contact Us   
1 800 864 8008
Company Products Press Room Resellers Support Sales En Español Free Tech Tips Shop Online
Thursday, February 23rd 2017  
Micro-Scope Diagnostic Suite is a bundle of the two of our best, most comprehensive diagnostic products, Micro-Scope & USB-Scope, to give you the fastest, easiest, and most accurate hardware testing functionality on the market!

The Importance of O/S Independence

Many of our customers want to know what the specific advantages are to them of having diagnostic software that is operating system-independent, like MicroScope, rather than one of the many programs that run under DOS and Windows, some of which are less expensive.

Almost all of the IBM-type personal computers in the world run a general-purpose operating system such as Windows, DOS or Linux. General purpose means it allows the user to run a wide variety of applications, everything from word processing to video games. The operating system (OS) provides the basic interface for the user, and in the background it runs all of the hardware.

This means that if an application needs data from the disk drive, it's actually the OS that finds the data, decides where to put it in RAM, and then makes it available to the application. The application does not know the actual physical location of that data, either in RAM or on the hard drive. Every other action the application takes that involves hardware is more of the same, with the OS running interference in the background.

Now, this is normally a very good thing. It would be quite cumbersome if every application had to contain the code to manage disk I/Os, keystroke and mouse input, video etc. It would be worse yet if the user had to deal with all of that, because everyone would need to be a trained technician just to get anything done on a computer.

However, problems arise if the application is trying to troubleshoot or benchmark the hardware. For example, how can you test a specific sector of a hard drive if the operating system (in conjunction with the drive controller and the BIOS) decides where the data will go on the drive? And if the operation fails, how can we determine if the drive mechanism or the controller was at fault? All the application knows is that it hands data off to the OS for disk storage and then gets it back in altered form or not at all.

Another example is memory testing. Normally the OS assigns a block of memory to an application, which can play around within that block by using something called logical addressing. The application knows where specific contents are relative to the other contents of the block, but it doesn't know where the block is physically located in memory, which makes it very difficult to know just which chip or module is at fault when an error occurs. To complicate things even more, most systems use a cache, which stores the RAM contents being currently used by the CPU in order to provide faster access to those contents. When a memory test writes to memory and then reads back different data, did the error occur in the RAM or in the cache?

The tests for most other hardware will run into some kind of OS interference similar to the ones above, and we will have a couple of additional examples in a moment. By now though, you are probably wondering how MicroScope is able to avoid these problems.

When we say that MicroScope is OS-independent, that doesn't mean it can run without an operating system. Every application must have an operating system, or it must include one. MicroScope comes with its own operating system, and a system boots up to our OS in order to run the MicroScope routines. This OS is one that is written especially to allow diagnostic operation of the hardware, for instance to access a specific memory or disk location.

In order to do this, it was necessary to write the operating system and the diagnostic routines in something called Assembly language. This programming language is considered a low-level language because each instruction in the program represents one instruction for the CPU. The instructions must still be translated into ones and zeroes for the CPU but otherwise nothing gets changed, which allows for very precise control by the programmer.

By comparison, most programming languages are what are called high-level languages. In these, each line in the program may represent many, many CPU instructions. The programmer's written code has to be run through another program called a compiler, which translates each program line into a set of CPU instructions, determines the order they will run in, and assigns them all relative locations within the compiled program. Right from the beginning, the programmer has lost control over where the CPU instructions will be located in memory, or even within the program itself, because it's all determined by the compiler program.

Almost all diagnostic programs other than MicroScope are written in one of these high-level languages. When you add the fact that they will run under an OS designed to operate the hardware completely in the background, it's easy to see why MicroScope allows for greater precision and superior accuracy.

In wrapping this up, let's look at just two more examples. Occasionally a second hardware device will mistakenly get set to the same IRQ as something already in the system. This causes errors of course, because the CPU can't tell which device is requesting an interrupt. Windows is not capable of considering that a second device might be using an assigned IRQ, since this is not an allowed circumstance, and therefore will not report the second device to the user or to a diagnostic program. MicroScope handles this situation easily, and lets you locate the offender with just a couple of keystrokes.

Last, consider a simple request for information, such as CPU speed. If an application running under Windows wants this data it must ask Windows for it, which will then return the value that's been set in CMOS. This may or may not be an accurate value, and certainly won't tell you if the CPU chip is being over-clocked. With this and any other system information, Windows also won't actually tell you (or the diagnostic) whether the data is coming from a direct measure of a hardware device (almost never), or from a reading of the CMOS or other stored information (almost always). On the other hand, MicroScope lets you have it both ways, and tells you which is which.

Micro-Scope Diagnostic Suite


Micro-Scope Diagnostic Suite

 
Home Privacy Policy Tech Support Policy Copyright Info Contact Us EnEspañol