I am a hamfisted meddler when it comes to such things, but I thought there would usually be some clue in the form of a text string in the first few lines of the file in a hex viewer that would give you a clue what it was packed with.

Sure, I already looked through with hexaedit but didn't see anything obvious. Sometimes the signature of exe packer is intentionaly removed to obfuscate. I would't wonder if he used his own algo. BTW NSSI also use some kind of exe encryption/pack & protection against modification. I didn't googled any attempt to modify Speedsys. I found old homesite on webarchive and mailed the author but there's very little chance he respond after so many years, just a try...

Probably a longshot, but once in a while WinRAR can detect what packed an exe and unpack it.

Edit: BTW, speedsys came to be made just a bit after the classic DOS era IIRC, so it might not be a "classic" one, but "something clever" that came along later.

I tried with 7zip but no way. The file is very entropic, if packed the compression ratio is near to 100% so it confirms it's already packed or encrypted. My mail was returned from ***email.ru so no idea how else contact him. Who knows he's still alive (the war in russia /UA...).

I'll try with debugxv by Japheth, the latest version has capability to set breakpoint at specified I/O port address so maybe I could try to skip it. BTW on my Core i7-2600K Speedsys also hangs but during reading MSRs. It's similar issue. I guess he tries to read non-existing MSR in my CPU (because basic CPUID match some PIII family but he probably don't check extended CPUID) and it falls in some exception...

Damn, I'm screwed. Tx486DLC doesn't have CR4 neither debug extension, it has only DR0-7 so I can't set breakpoint on IO access 🙁

I also search and look for some datasheets and it seems there's no difference in CPU config regs range CO-CFh but who knows what else Speedsys is trying to read. I hoped I'll see it in debugger but I can't...

Cx486DLC: However, each I/O port 23h operation must be preceded by an I/O port 22h operation, otherwise the second and later I/O port 23h operations are directed off-chip and produce external I/O bus cycles. Accesses to I/O port 22h with an index outside of the CO-CFh range also result in external I/O cycles and do not affect the on-chip configuration registers.

TI486DLC: Each I/O port 23h data transfer must be preceded by an I/O port 22h register selection, otherwise the second and later I/O port 23h operations are directed off-chip and produce external I/O cycles. If the register index number is outside the COh-CFh range, external I/O cycles will also occur.

Yeah, I traced it via DarkDebugger (need stepping, breakpoint at I/O didn't work).
You can see that Speedsys attempts to read config reg. FEh from port 22/23h that is not valid for this CPU so it's passed to bus cycle and crashed the chipset. When I skipped this I/O operation Speedsys started and performed CPU benchmarg - I got ~11 points.but as it run limited in v86 mode it didn't do mem/cache tests.
Now I would need to find a way how to patch it at runtime or how to block I/O access to port 22h as I'm unable to patch existing EXE...

Nice work. This is fun stuff to read.

Meanwhile it happened that one guy on other forum, seeing by dbg effort, has just uplodad sources of Speedsys 4.79 WIP on Github under GPL (as author permitted), huh! He got it a long time ago from Vladimir when his mail worked yet. But no changes was made for the whole time, waiting for now. Sources seems to be pure asm work. I just need to grab some newer TASM to recompile. I already located the problematic routine doing invalid I/O on cyrix. A hotfix would be easy but I'd like to do it properly. Question is if I can reliable recognize 486DLC/SL* from other Cyrix via some regs/cpuid to branch the code that way it will not have any side effect on other CPUs...

RayeR wrote on 2025-04-13, 12:10:

Sources seems to be pure asm work.

That's surprising. Maybe a lot of assembler is included, but if I remember correctly, last time I debugged speedsys, it looked a lot like the main executable is Turbo Pascal compiled code (before packing). Do you have a link to the GitHub repository? Google doesn't seem to find it yet.

Here https://github.com/bttrx/speedsys
no *.pas there, build batch calls TASM.

RayeR wrote on 2025-04-13, 15:38:

Here https://github.com/bttrx/speedsys
no *.pas there, build batch calls TASM.

Thank you. So obviously, I misremembered some things. It's great to have the source code public.

Btw the source was given by Vladimir in 2006 but it stucked in private closet 19 years, without any change...

Thanks for finding this. I need to build a QR feature that lets people post results to a website.

Here's the hotfix for 486DLC/SLC, so I finally got it benchmarked 😀

RayeR wrote on 2025-04-14, 00:26:

Here's the hotfix for 486DLC/SLC, so I finally got it benchmarked 😀

Lovely!

Would the screenshots be more usable for you if they were exported in GIF format?

If someone would like to programm a GIF encoding module in assembler it could be used instead of PCX. I think that PCX is much simpler format (using RLE compression?) than GIF. I think it's not necessary, everybody can use some external utility to convert PCX to any other bitmap format...

Wow thanks. Just discovered some issue with my new tx486sxlc2 and then just today the hotfix. Wow. Thanks !!!

RayeR wrote on 2025-04-14, 00:26:

Here's the hotfix for 486DLC/SLC, so I finally got it benchmarked 😀

thanks for the patched version!
great work!
time to update it in my setups 😁

That is very nice ~

I do wonder, how hard would it be to skip the memory testing without skipping the cache testing ?

Tiido wrote on 2025-04-14, 19:17:

I do wonder, how hard would it be to skip the memory testing without skipping the cache testing ?

I don't think I understand what you mean. With SST478, as included in Phil's dosbench, if you press "space" while the extended memory is being tested, the "memory test" is skipped, but the throughput benchmarks, which shows the effect of the cache is still performed. Isn't that what you are asking for?