BIOS recreation?

  • SpinRite v6.1 Release #3
    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.
  • 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!

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


Active member
Sep 29, 2020
as I stumbled some years ago on a custom BIOS that enabled SLIC for a Dell Laptop which enabled installation of win7, and that works great, even to this day :D
I suspected the answer to my question for those versed would be an easy one.
*how hard would it be to write a new, custom BIOS for a system that *IS* 64bit OS capable,
but whose BIOS currently does not know (and the OEM CS indicate no inclination to support) how to read more than 2TB on HDDs/SSDs that are greater than 2TB.
*how hard is it to learn to write BIOS firmware?
*what would be the needed experience/pre-req's to be able to write said BIOS?
Thanks for the positive input.
Hardly qualified to answer that question but I was curious. Since others would be asking what is SLIC...
I think ceyarrecks was referring to this, from Wikipedia :-

Some BIOSes contain a software licensing description table (SLIC), a digital signature placed inside the BIOS by the original equipment manufacturer (OEM), for example Dell. The SLIC is inserted into the ACPI data table and contains no active code.

Computer manufacturers that distribute OEM versions of Microsoft Windows and Microsoft application software can use the SLIC to authenticate licensing to the OEM Windows Installation disk and system recovery disc containing Windows software. Systems with a SLIC can be pre-activated with an OEM product key, and they verify an XML formatted OEM certificate against the SLIC in the BIOS as a means of self-activating (see System Locked Pre-installation, SLP). If a user performs a fresh install of Windows, they will need to have possession of both the OEM key (either SLP or COA) and the digital certificate for their SLIC in order to bypass activation.[22] This can be achieved if the user performs a restore using a pre-customised image provided by the OEM. Power users can copy the necessary certificate files from the OEM image, decode the SLP product key, then perform SLP activation manually. Cracks for non-genuine Windows distributions usually edit the SLIC or emulate it in order to bypass Windows activation
  • Like
Reactions: Ceyarrecks

Cey is referring to the SLIC table ("System Licensed Internal Code") in the BIOS that enables OEM Windows installs to activate via SLP ("System Locked Pre-installation"). With an OEM Windows product key that matches the SLIC table in the OEM BIOS, Windows would self-activate without going through Microsoft.

SLIC/SLP (ver. 1.0) was introduced with Windows XP, though if you could reflash a ver. 2.0 or 2.1 SLIC table in your BIOS you could install self-activated OEM versions of Vista or Win 7, respectively. (SLIC tables were backward compatible, so a 2.1 SLIC would self-activate all three OSes.)


I don't think your BIOS is the problem, so you're barking up the wrong tree. A BIOS starts up in 16-bit Real Mode, and is never going to recognize more than 2TB drives. That's a function of Real Mode and the size of the sector registers in the MBR. Rewriting the BIOS can't change that.

When Windows boots, the startup files* kick the CPU out of Real Mode and into Protected Mode, where the operating system can then have access to 32-bit or 64-bit functions. Once in Protected Mode, the BIOS is out of the loop, and the OS can access disk drives of more than 2TB even if the BIOS could not.

Note that to install a 64-bit OS requires a 64-bit CPU. If your laptop is really old, it's CPU may only support 16/32-bit OSes. (If you had to modify the SLIC table, there's a very good chance your CPU is not 64-bit capable.) Note Steve's freeware "Securable" utility will quickly reveal if your CPU is 64-bit capable. If it's not, you're never going to get a 64-bit OS installed on that laptop, no matter what you do to the BIOS.

If your CPU is 64-bit capable, then you can install a 64-bit OS, and the BIOS doesn't matter. Remember, once it kicks into Protected Mode the OS controls disk access, not the BIOS, so a 64-bit OS can recognize GPT-style disks, including disks larger than 2TB, even though the BIOS doesn't.

However, the catch is the GPT disk has to be a secondary disk. You have to boot from a MBR disk but can use GPT for secondary disks. You can't boot from a GPT disk because the first part of the boot process relies on Real Mode and MBR, and that doesn't know what to do with a GPT disk so it would never get to the Windows startup partition to begin with.

To boot from a GPT disk requires UEFI firmware or a UEFI-capable BIOS. But that's a lot more involved than just reflashing your laptop's old BIOS, so isn't an option.

* (For clarity, I'm going to avoid calling them "boot files" because Microsoft perversely reversed the definitions so that, according to MS, the computer boots from the "System" partition and loads the operating system from the "Boot" partition)
  • Like
Reactions: Ceyarrecks
Note Steve's freeware "Securable" utility will quickly reveal if your CPU is 64-bit capable.
aye, been sitting on SecurAble forever, Thank You! for the reminder. here is the results (and am currently running win7pro64bit on this laptop) and the other, much older Dell D420 previously only expected winXP, yet refused to load Dell OEM DVD with win732bit OS until SLIC change was made. /shrug o_O

ASUS Laptop Securable Results.jpg
To boot from a GPT disk requires UEFI firmware or a UEFI-capable BIOS. But that's a lot more involved than just reflashing your laptop's old BIOS, so isn't an option.
right, and this system has space and controller for only a single drive. :(
and by "more involved" suggests something far beyond just bytes in a different configuration on the same foundation of silicon, maybe requires a different foundation entirely, huh?
oh well. maybe wearleveling will chew on that unpartitioned/inaccessible part of the drive first...

Thank you all for your input! :coffee::coffee::coffee::coffee:
From a developer perspective, the BIOS is nothing more than an API. (An Application Programmer Interface.) In essence, the BIOS is just a set of expectations, one of which is based around 16bit segmented memory accesses. So a direct answer is that it is IMPOSSIBLE to make 64 bit BIOS because the expectation is that it is 16 bit. You COULD make a new thing that would do the same kind of work (I/O being the majority of it) but based on 64 bits. The trick would be that it would only work in programs that chose to adopt your new BIOS-like thing. I don't think it would be easy or worthwhile to make a new backward compatible BIOS thing, because it's already been done... it's called the CSM (Compatibility Support Module) that is part of UEFI.
  • Like
Reactions: Dave