Old MHz display panels

[Konrad]

Remember those ancient PCs that had a front LED panel meant to display the "speed" (in MHz) of your PC? They could be toggled with the Turbo switch between "Normal" (usually 8Mhz) and "Turbo" (12/16/33MHz or whatever). In truth they weren't useful for much at all beyond advertising the capabilities of the machine and indicating that it had power (they could have been - and were - easily replaced with one or two standard LEDs).

I know these panels were configured with hardware jumper blocks to report any value desired and otherwise had nothing to do with actual computer speed. The Turbo switch simply toggled between alternate jumper presets to "update" the value shown ... though it also actually toggled the mobo Turbo as well (usually).

I don't even know what these things were called, every PC case just had one so I never thought much about them. I remember paying a little extra once to get a panel with red LEDs instead of green ones, I remember changing the display jumpers without a datasheet was more complicated than a Rubik's Cube. I found a little chitchat about these things here (http://vogons.zetafleet.com/viewtopic.php?t=10780) and here (http://www.computing.net/answers/windows-95/how-to-change-mhz-display-led-on-front-of-computer/63787.html), oddly I couldn't find a single pic. People younger than 30 may have never actually seen one of these things.

But I am inspired to recreate this old idea on modern PCs.

My initial thoughts:
it would obviously use modern display and microcontroller parts; old-style segment LEDs are obsolete, less versatile, and probably only desired when building a "retro PC" look; this project would be more akin to a Matrox Orbital (http://www.matrixorbital.com/) than a half-useless 286-era display panel
it could be merged with standard fanbus/temp/hardware monitoring functions, user controls and menus could allow easy selection of which information to display
it should draw power from the main PSU, perhaps allow a standby/sleep mode
it should constantly and accurately report the actual speed (MHz, GHz, whatever) instead of simply displaying some arbitrary preset value
if possible, it could have options to display different speeds for different pieces of hardware (processor speed, processor FSB, RAM speeds, mobo clocks, etc)
if possible, it could report the speeds of each core within a processor (I'm not sure if this would be a meaningful metric or not; though it would be interesting to measure the operational speeds of all these things throughout the boot process or when the computer freezes or crashes)
it should somehow collect all readings directly from hardware interfaces (or perhaps BIOS services?); it should *not* be dependent on the OS, drivers, or any other software ... even if it means I have to string ribbons and wires between individual mobo pins and traces - it would essentially be an independent computer
if possible, it should mimic the "Turbo" feature, allowing a single hotswitch to alternate between normal and overclocked operation (this is possible where supported by BIOS on some motherboards, so how hard can it be?:dead:)
Note my hardware interface requirement. It should display values regardless of whether Windows, linux, or the BIOS Setup program is running. I would be nice to have some kind of onboard memory, logging features, and (USB?) communication with the PC's software - but those are all complications that can wait until the basics are working.

I might indeed buy and mod a Matrox Orbital for this project, or just build something similar, or perhaps cannibalize and brainwash my ancient iPAQ PDA for this purpose. The electronics and microcode don't bother me (though they look challenging). Motherboards don't intimidate me either, I've modded a few at the component level before.

My problem is simple. Yes, I will certainly read every relevant datasheet and specification I can get my hands on. But still ... where the hell can I poke the mobo to measure the real-time performance of the parts?

Some parts seem like they'd be easy: The RAM controller chip (or the RAM banks themselves) report SPD pinouts and timing data which are standardized and should be easy to decipher, if I have to I can (probably) even upgrade to better parts to compensate for any interference in timing/signalling my probes introduce to the circuit.

Other parts seem incomprehensible. Are there FID pins on the processor I could piggyback onto? Is the signalling already so tight that the most miniscule impedence will reduce stability? If there is no way to report CPU speed through the hardware then I'll abandon this entire concept. (Component level solder rework doesn't bug me either, I enjoy it, but any ideas that involve actually getting into the components like splicing directly into a silicon die are basically impossible.)

[Kayin]

Samurize, and a color LCD.

Samurize can monitor the hardware from within Windows, and give real-time reporting on temps, speed, network output, or just about anything else.

Now out of windows, let me get back home (in a hotel room) and I have a toy that can do some of that.

[Konrad]

Samurize can monitor the hardware from within Windows, and give real-time reporting on temps, speed, network output, or just about anything else.
Yeah, there's lots of software (even Windows Gadgets) that can do that. Sending software info to a display unit isn't hard at all, every commercial display product already does that.

1) Software monitors are OS dependent. I want mine to work even when I install multiple OSs, different versions of Windows or linux or even DOS4GW for all I care. I want it to work during POST and preboot, when the system locks, even while running the BIOS Setup program. It occurs to me that it might be a useful method for identifying hardware bottlenecks and failures (and a good way to get rough "benchmark" results without actually running any software).

2) The accuracy of software monitors is limited by the capabilities inherent in all perfectly functioning software. Direct hardware monitoring (on a discrete computer which just happens to share the same chassis) can monitor hardware properties that no software can possibly see (many machine-level details are assumed to be irrelevant at the software level), plus as always the hardware simply cannot ever lie, what it is is what it says. For example, compare what a hardware RAM tester can do vs even what the best memory diagnostic/burn-in software can report.

3) Hardware can report real performance measures that are transparent to the software. I might find that a game/program (or even software monitor) running on one version of Windows will run at different hardware speeds in another version, even when the same results are reported by the software.

4) Software does often lie, if inadvertently. When I run CPU-Z or Everest, can I know with certainty that each item reported is actually measured from real performance data, or is it just what the datasheet for the item says it should be? (ie, is the software essentially just the modern version of the ancient lying LED panels, reporting the arbitrary data it "should" say instead of what's really there?) Sure, my hardware won't necessarily monitor the finest level of detail, but best to avoid talking to an uninformed liar as much as possible.


Now out of windows, let me get back home (in a hotel room) and I have a toy that can do some of that.
Suspense. Aw, don't leave me hangin' man!

[Kayin]

CPU-Z reads off the clock generator. I don't know of a more accurate way to do it.

I have a POST code reader with the port 80 display on a ribbon cable. It reads voltages off the PCI slot as well. The main issue with your idea is that it's not that easy, and it won't really work like you want. For example, the only place to pull the thermal information about the CPU from is in Windows, the sensor is in-die and inaccessible.

Further complicating all this? Once you're in windows, the BIOS hands off all information and is deactivated. There is no way really short of software to pull the info, which means it is 100% inaccesible in DOS. (That should have died years ago, BTW-what are you still doing in it?) It's chancy in Linux, depending on distro (Ubuntu, if I remember) but the only other way involves hardcore hardware hacking. If you want to know what it entails, I'll gladly let you know what I know, but you may not want to go to the added complexity and expense.

[Konrad]

CPU-Z reads off the clock generator. I don't know of a more accurate way to do it.
CPU-Z is kickass, no doubt, and amazingly accurate. But it wants Windows and still operates on the software layer. BIOS-level reporting is more accurate/reliable, and hardware-level reporting is better still.


I have a POST code reader with the port 80 display on a ribbon cable. It reads voltages off the PCI slot as well. The main issue with your idea is that it's not that easy, and it won't really work like you want. For example, the only place to pull the thermal information about the CPU from is in Windows, the sensor is in-die and inaccessible.
I have an ancient double-edge (PCI/ISA) 80h POST card too, it's not as good as yours (doesn't read voltages) and I haven't actually needed to use it for many years. It did help inspire me, though.

Hardware interface for thermal information is easier than you think ... I recently attempted to feel out the plausibility of my idea in this (http://www.thebestcasescenario.com/forum/showthread.php?t=24157) thread, but there appeared to be no interest and I've since just gone ahead and experimented with the concept anyways (results are a bit ugly but it works, though calibration was a bitch). Exact parts vary on each mobo; I tested the concept on my old Socket 478 IBM/Intel D865GKD board which uses an LM85B1MQ part (National Semiconductor LM85 Hardware Monitor with Integrated Fan Control, datasheet (http://www.datasheetarchive.com/pdf-datasheets/Datasheets-22/DSA-424074.html)). As it turns out, this part doesn't need to actually contain the thermal sensor, but the I/O signals through it's pins can be deciphered to extract the temps (and fan rpms) of the sensors to which it's logically attached. I envision piggybacking a connector (like the one shown here (http://rocky.digikey.com/weblib/Assmann/Web%20Photos/AR20-HZL-TT-R.jpg)) above the chip, then attaching wires/ribbons to the relevant pins. I don't mind soldering, reworking, moving or replacing mobo components, I don't mind tapping "shunts" directly into the PCB traces where needed. Obviously my hardware monitor would be semi-parasitically attached (soldered!) to the mobo itself, it's not at all the sort of thing you can quickly drop into any PC, even one with an identical mobo.

(I could even inject regulated voltages into my LM85 part, fooling or forcing it to control the fans any way I like instead of leaving it to the BIOS. Even simply installing the right resistors between the LM85 pins and mobo traces would trick the BIOS into seeing other temps/rpms or controlling the alarms and fan speeds at different temp thresholds. Not really interested in doing that, just saying it's possible and not too complex.)

A similar approach can be used to monitor I/O signals on the frequency synthesis chip (always located in close proximity to the universal 14.31818 and 32768Hz crystals), the memory controller chips (always located adjacent to the RAM banks), the voltage regulator chips (part of the VRM circuitry surrounding the processor), and any of the many signal traces routed into the main chipset parts (82865G and 82801EB in my case; it's just not practical to connect directly to pins under large BGA-mounted chips). Even a PCIe, AGP, or PCI bus can be monitored; especially if there's a nearby controller/buffer chip. Almost anything can be monitored if you can find a point in the circuit to tap into, it just becomes a question of choosing which information is useful/interesting and which is meaningless.

What I don't know how to do is directly monitor the processor. I don't even know if individual processor cores can be monitored with external hardware (that is, does each core communicate individually with anything on the mobo or are they all a single "black box" that interact through some other on-die interface logic). My primary interest in this entire project hinges on being able to report core processor speeds.


Once you're in windows, the BIOS hands off all information and is deactivated.
The BIOS constantly runs. It provides low-level INT/IRQ/DMA services to the entire chipset (including (G)MCH, ICH, drive controllers, LPC bus, keyboard controllers, UARTs, RTC-NVRAM, and the like), to all onboard hardware (including all the adapter cards, though most actually install their own runtime BIOS), and to the OS software. It also constantly runs all the mobo hardware monitoring services (and alarm overrides) regardless of what else the computer is doing. What you refer to as the "clock generator" used by Windows/CPU-Z is an example of an always-running-in-firmware BIOS service, the data could just as easily be displayed by software running on an MCU as by software running on the mobo-socketed CPU, provided there's an electrical interface.

Using my mobo-hacking methods you can even install an MCU to emulate (or alter) the behaviour of the BIOS, even when the BIOS isn't a nicely socketed discrete chip but instead coded into the flash segments of the NB, SB, or Winbond-style "Super I/O" chips. I suspect that a project of that sort would require so much detailed reverse-engineering of the mobo that you might be better off building an entire mobo from scratch.


... DOS. (That should have died years ago, BTW-what are you still doing in it?)
lol, I've asked myself the same question. I still sometimes bump into DOS tools (mostly for oddball device programmers that operate through an RS232 port) which just won't run properly from a Windows command prompt, DOSBox, or VM software - a real nuisance when you keep getting bad burns on $20 OTP parts. Once every year or two I like to play a few hours of stupid old DOS games (UFO, TFTD, MoO, MoO2, Armada 2525 lol) and I find an MS-DOS 6.22 boot session is just less of a hassle than tinkering with DOS configuration problems in Windows. Even so, I could probably delete DOS forever and not miss much.