UPDATE: I found a solution.

I changed my Sylvania G (original, non-Meso) netbook to Windows XP/Linux dual-boot to test some software I’m working on, and discovered that while Windows XP certainly does boot and run in general on the G, some kind of system timer or timing loop is severely out of whack!  I wanted to use my little G as a portable gaming machine from the Windows XP install, and to my horror, ZSNES couldn’t decide what speed it wanted to run!  Now, I’ve never had a single issue with ZSNES on any computer I’ve ever tried it on, even preferring the Windows port of it over the Linux native one, and not once has a problem existed with ZSNES that I couldn’t find an easy fix for, until now.

I’ve been researching the matter and gathering evidence, and I may have a potential answer to the problem.  Linux requires activation of the VIA C7 Enhanced PowerSaver module e_powersaver to clock the VIA C7 CPU properly between 400 and 1200 MHz; apparently the default speed of the CPU is only 600 MHz instead of 1200 MHz, because Linux installs without e_powersaver and Windows XP report a ~600 MHz processor where a 1.2 GHz one exists.  Here’s the extremely weird part, though: if I check the System control panel shortly after bootup and read the clock speed, sometimes it registers a clock speed of 198 MHz (about 200 MHz) which isn’t even one of the ACPI P-states for the VIA C7-M 1.2 processor.

I’ve unlocked the Windows HAL options (I’ll post how to do that at another time) and switched between ACPI Multiprocessor PC (the default for the image I used) and ACPI Uniprocessor PC and MPS Uniprocessor PC, all of which use the local APIC for IRQ routing but the MPS variant of which doesn’t theoretically touch ACPI.  Nothing seems to have helped.  I have two working theories as to what’s going on here, and how it might be fixed:

1. A calibration loop in Windows a la BogoMIPS in Linux is being screwed up by the VIA C7, or
2. The VIA C7’s PowerSaver feature is ignored or incorrectly used by Windows (via generic ACPI P-states) and it’s throwing off some kind of timer that ZSNES relies on for proper emulation of the 65816 CPU and SPC audio processor.

So far, I haven’t found a solution to this problem, and Sylvania’s site is extremely unhelpful, with only Windows drivers and a new version of gOS, but no BIOS updates or further information.  I’m looking into the technical stuff on the VIA c7 now, and it looks like the solution (assuming Windows isn’t doing something sinister) lies in clever manipulation of the C7 model-specific registers (MSRs) that control the processor’s power state.  If ZSNES is mis-calibrating some kind of tight internal timing loop because of some kind of CPU clocking issue, then tweaking the MSRs may be the solution to the problem.  Unfortunately, I’m no Windows developer, so I’m not certain how I should approach the problem.  I don’t think it’s isolated to ZSNES either, but I don’t recall what I saw that justifies that belief.  In any case, I’m working on it.  It’s just one of many pesky projects I’m hitting my head against at the moment.  We’re still working on that remote access software package; in fact, someone found our site and called us, and I had to sort of turn her away.  It’s all a bit behind schedule, and there’s not really much I can do to make things proceed any more quickly.  Stay tuned…