Someone in another post said they had 6+ 7010 units and asked what to do with them, so I started a response and got carried away to the point it needed to be its own post.
What started as “I need an old computer” has turned into a fairly ridiculous legacy-hardware/reverse-engineering project.
My unit is the 7010 Mini Tower edition with the i7-3770 and currently has 24 GB of RAM which will be upgraded to 32 GB soon.
Why I started this
The original reason for buying the 7010 was a Contex Chameleon TX 36 large-format scanner.
It's an older professional wide-format scanner that communicates over IEEE 1394/FireWire, and getting the original software, drivers and hardware talking again eventually turned into a reverse-engineering project of its own.
I wanted a real machine that could run the operating systems and hardware these devices were actually designed around instead of trying to make everything work through VMs and questionable modern adapters.
Then, naturally, scope creep happened.
The 7010 is now a general-purpose legacy hardware lab covering old operating systems, scanners, cameras, PCI/PCIe cards, drivers, firmware utilities and whatever other obsolete hardware I decide needs to live again.
Removable operating systems
One of the things I'm most excited about is the storage setup.
I installed a StarTech S25SLOTR trayless removable 2.5-inch SATA bay. It mounts through an expansion-slot opening in the back and connects to ordinary SATA data and power. This gave me an easy way to multiboot without all the headaches.
Shut down → eject the SSD → insert another SSD → boot.
I have around twenty 128 GB 2.5-inch SATA SSDs available for the project, including Samsung PM871b, SK hynix SC311 and various Dell/Lite-On OEM drives.
Each OS gets its own physical SSD. No giant multiboot configuration to destroy, and every environment can be independently imaged, restored or experimented with. The drives will be clearly marked so I can identify the OS and any special BIOS/boot requirements at a glance.
The current plan for the first 13 drives is:
- DOS + early Windows through Windows 3.11 — multiboot
- Windows 95 + Windows 98 + Windows 98 SE + potentially Windows Me — multiboot
- Windows XP Professional 32-bit (x86) (already in progress)
- Windows XP Professional x64 Edition
- Windows Vista 32-bit
- Windows Vista 64-bit
- Windows 7 Professional 32-bit (x86)
- Windows 7 Professional 64-bit (x64)
- Windows 8.1 Pro 32-bit
- Windows 8.1 Pro 64-bit
- Windows 10 Pro 32-bit
- Windows 10 Pro 64-bit
- Windows 11 Pro 64-bit
That leaves Drives 14–20 reserved for an Emulator/Specialty Series: Linux, recovery environments, experimental driver work, Amiga/Commodore emulation, bare-metal experiments and whatever other rabbit holes appear.
Getting some of those early operating systems running properly on Ivy Bridge hardware will be a project by itself.
NVMe as a secondary shared drive.
I've also installed one of the dirt-cheap passive PCIe-to-M.2 adapters with a 256 GB NVMe SSD.
The adapter itself is just a simple PCIe-to-M.2 carrier — the NVMe drive talks PCIe directly to the system.
The stock Dell A29 firmware doesn't contain an NVMe DXE driver, so native NVMe boot isn't expected out of the box.
I'm approaching that in stages.
First, establish that the adapter and SSD enumerate correctly and get the NVMe working reliably as secondary storage under Windows 10. Then investigate Windows 7 and XP driver support, bootloader/chain-loading possibilities and eventually adding a compact NVMe DXE driver to an experimental BIOS.(Probably version A31)
The removable SATA SSDs remain the known-good boot and recovery system regardless of what happens with NVMe.
The Bridge
This is where the project gets more interesting.
The 7010 isn't intended to do all the heavy reverse-engineering work itself. I have a much more powerful dual-CPU workstation I call WATERCOOLED.
The two machines will have a direct Ethernet connection on a small isolated network with no Internet gateway or DNS dependency. The boot drive and the NVMe are shared to create a high-speed shared workspace between them. (The plan is the NVME will be a secondary drive for each OS where portable apps / code can be placed for use)
The Dell supplies the real legacy hardware and operating-system environment.
WATERCOOLED supplies the horsepower for modifications and analysis.
That means the modern machine can analyze binaries, build tools, examine firmware, process logs and registry hives, stage drivers, back up removable SSDs and do the computationally heavy work while the 7010 actually talks to the legacy hardware.
That's the basic idea behind the Bridge.
Instead of trying to make one computer span 30+ years of PC hardware and software compatibility, each machine does what it is good at.
FireWire immediately decided to fight back
I already own two PCIe FireWire cards.
Both use a Texas Instruments TSB43AB23 IEEE 1394 controller sitting behind an ASMedia ASM1083 PCIe-to-conventional-PCI bridge.
Both cards work in my newer WATERCOOLED workstation.
Neither will allow the OptiPlex 7010 to complete a normal POST.
I've tried the intended PCIe slot as well as the lower x16-size PCIe slot, with and without the FireWire card's auxiliary power connection. The behavior follows the cards.
The auxiliary power connector isn't there to make the PCIe bridge function; it's primarily there to provide bus power to FireWire devices, so the same failure occurring with or without it is another useful data point.
The current theory is that the 7010 firmware doesn't like something about initializing the ASM1083 PCIe-to-PCI bridge.
Possibilities include PCIe link training, ASPM behavior, bridge resource allocation, SMBus interaction, legacy PCI resource handling or firmware error handling when the bridge is enumerated.
I'm still going to experiment with the cards I already have, including trying one through a simple PCIe x1 riser/extender. That moves the card physically away from the motherboard and gives me another useful troubleshooting configuration, although electrically it's still the same PCIe device and ASM1083 bridge.
I've also ordered a conventional legacy PCI FireWire card using an LSI/Agere controller as the fallback.
The OptiPlex 7010 still has a genuine conventional PCI slot, so that card completely eliminates the ASM1083 PCIe-to-PCI bridge from the equation.
If the conventional PCI card works, great — I have a clean FireWire solution for the Contex scanner.
If I can also figure out exactly why the bridged PCIe cards prevent POST, even better.
And that little FireWire problem is what sent this project completely off the rails.
We started taking apart the BIOS
Dell A29 was the final official BIOS release for the OptiPlex 7010.
We've extracted it, unpacked the firmware volumes and decoded the Setup/HII information.
The current inventory contains 100 forms, 936 questions/references and roughly 700 candidate hidden settings/references.
That's an important distinction:
It does not mean the OptiPlex 7010 secretly has 700 useful working settings that Dell simply hid from the user.
A significant amount of the firmware is generic AMI/Intel reference code designed to support multiple configurations and platforms.
But there is some fascinating stuff in there.
We've found controls relating to PCIe root ports, per-port PCIe link speed, ASPM, link-training behavior, retry and timeout settings, reserved PCI buses and memory windows, Above 4G Decoding, CPU and memory features, SATA, USB, thermal management, power management, Intel firmware features and hidden debugging/configuration functionality.
Some of those options may be particularly useful for diagnosing exactly what is happening with that ASM1083 FireWire bridge.
We're sorting the hidden options into three basic categories:
Category 1 — 7010-confirmed/useful
The hardware or function actually exists on this motherboard, the setting is relevant to the OptiPlex 7010 and there is a practical reason to expose it.
These are the settings that are candidates for eventually becoming normal accessible options in our modified firmware.
Category 2 — Research/experimental
The setting appears applicable to the 7010 and may genuinely function, but we don't yet have enough evidence to call it safe or useful.
These can potentially be exposed for controlled testing once we have a known recovery procedure.
Category 3 — Generic/dead platform code
Settings inherited from generic AMI/Intel firmware that refer to hardware, laptop features, chipset configurations or platform capabilities that the OptiPlex 7010 simply doesn't have.
They're interesting from a firmware-analysis standpoint, but there's no reason to expose them just because the code happens to be present.
In other words, the goal isn't:
“UNHIDE EVERYTHING!”
It's:
“Figure out what Dell hid that actually does something useful on this machine.”
The experimental A30 BIOS
We've already built an experimental project BIOS we're calling A30 Unlocked.
To be very clear, A30 is our project designation. There is no official Dell OptiPlex 7010 A30 BIOS.
The experimental build is based on Dell A29.
The current candidate exposes the generic AMI PCI/chipset configuration form, the Debug menu and 13 blocks that were unconditionally suppressed, while retaining the original defaults and hardware-dependent conditions.
The reconstructed System BIOS payload remains the same size as the original at 6,291,456 bytes.
The modified firmware parses correctly and the reconstructed firmware checksums validate.
But it has not been flashed.
And it won't be until the recovery side of this project is finished.
Before any modified firmware goes near my motherboard, I'm going use my CH341A programmer to externally read the SPI flash multiple times, verify that the dumps match byte-for-byte/hash-for-hash, identify exactly what flash device or devices Dell used and preserve everything unique to this particular machine.
That includes the Intel Flash Descriptor, Management Engine region, GbE configuration/MAC address, NVRAM, service information and any other machine-specific data.
I also want to prove that I can externally restore the board before deliberately giving myself an opportunity to brick it.
Being able to build a modified BIOS is one thing.
Being able to recover from a bad one is considerably more important.
Once that recovery path is proven, then the fun starts: testing which of those hidden options actually control real 7010 hardware, investigating the FireWire bridge problem and eventually experimenting with native NVMe boot support.
So what can you do with an OptiPlex 7010 in 2026?
Apparently quite a lot.
Mine is turning into a physical library of PC operating systems, a FireWire/scanner workstation, a driver-development machine, a firmware-analysis target, a PCI/PCIe compatibility lab, an NVMe firmware experiment and a bridge between modern reverse-engineering tools and several decades of obsolete hardware.
And the funny part is that none of this was the original plan.
I just wanted to get one old Contex scanner working.
Not bad for an old office Dell.
And I'm nowhere near finished with it.
And yes, If i find out the Unoffical A30 Bios works, I will release it with all the data I was able to uncover.
Source: r/SleepingOptiplex · by /u/BobVA69