• Please review our updated Terms and Rules here

Looking for volunteers to help test a new benchmark

Trixter

Veteran Member
Joined
Aug 31, 2006
Messages
7,478
Location
Chicagoland, Illinois, USA
A new benchmarking program? For vintage computers running DOS? Really?

Yes, really. But there's more to it than that, as it's meant to help out retrogamers and emulator authors as well. Rather than lose my audience with a long post, I spent the weekend building up a website that should answer your questions and hopefully provide some insight into other benchmarking tools you may have used in the past. The benchmark is called TOPBENCH, and the website is here: http://dosbenchmark.wordpress.com/

If anyone would like to help out, please read the site a bit, download the benchmarking stub from the downloads page, and email me the output (or, for a more interesting group discussion, post it here). And I'm certainly open to suggestions too.
 
I'm still trying to test the 80C88 on my IBM PC Convertible. It has 720Kb diskette drives, and can generate something from a 1.44Mb blank. But everything I have within reach won't read them (even with the media type hole covered), and hates to generate 720Kb images on their drives (the commandline switches are still there).

I'll have to shuffle through for a mid-level system I can use as a translator, and authentic 720Kb diskettes (I do have a few around)...

EDIT: Is there a short sequence I could DEBUG in for the same effect?...

EDIT 2: I found an old post by you, and think you are referring to the "third bug" to test on the 80C8x? You are aware, as I, that the "first bug" is on the 8088 copyrighted with 1978, and fixed on the dual copyright ('79, '81) 8088 version. The 8086 was strangely not affected by that same bug as far as I know.

EDIT 3: The 80C88 in the Convertible doesn't have the "first bug" of course, verified with DEBUG...

Looking through the Technical Reference, the MC14818 RTC registers are used for saving the suspend state. It is at the common AT I/O port 70h/71h location. The "Century Byte" is at address 32h within it. Of all the surprises, it rolls over the century correctly in the BIOS (the 8086-based Model 30 did as well, but it had a different RTC chip; Some of the later, higher-end PS/2s were not Y2K-compliant that way) and shows even today's day of the week correctly (I had to use BASIC instead of DOS 3.3 to set the date).

As more asides, almost all IBM systems that are at least a stock 386SX had a CPUID function. That enabled me to test many 486-class CPUs (Intel values at http://ibmmuseum.com/intel486.htm). On most clones (some Phoenix BIOSes mimiced the IBM call) you had to wait until your Intel 486 had a 1992 copyright to gain the CPUID in real-time.
 
Last edited:
I'll have to shuffle through for a mid-level system I can use as a translator, and authentic 720Kb diskettes (I do have a few around)...

If you come up short, I could mail you one...

EDIT: Is there a short sequence I could DEBUG in for the same effect?...

Good point. I just whipped this up, this should work:

Code:
-u 0100
13B3:0100 FB            STI
13B3:0101 B9FFFF        MOV     CX,FFFF
13B3:0104 F3            REPZ
13B3:0105 26            ES:
13B3:0106 AC            LODSB
13B3:0107 08E9          OR      CL,CH
13B3:0109 B44C          MOV     AH,4C
13B3:010B 88C8          MOV     AL,CL
13B3:010D CD21          INT     21

This turns on interrupts, sets CX for FFFF loops, then has the magic repz es:lodsb sequence. On 8088, this does not resume when the interrupt hits; on 80c88, according to ancient legends, it is supposed to and by the end CX should equal 0. In either case, I then do the OR so that cl will be non-zero if anything in CX has a bit set, then I "exit with return code", which I believe you can check with "echo %errorlevel%" but I'm not sure about that. If the error code is non-zero, it is buggy and doesn't resume (just like an 808x). If the error code is 0, then it did resume afterwards, like most CPUs including NEC Vx.

Don't trace through it line by line with debug, it may not work. I would dump it to a file and run it flat out then check the error code. And thank you for helping me get to the bottom of this.
 
If you come up short, I could mail you one...

I'm not going to come up short, if you only knew the number of systems I have around...

...Good point. I just whipped this up, this should work:

Code:
-u 0100
13B3:0100 FB            STI
13B3:0101 B9FFFF        MOV     CX,FFFF
13B3:0104 F3            REPZ
13B3:0105 26            ES:
13B3:0106 AC            LODSB
13B3:0107 08E9          OR      CL,CH
13B3:0109 B44C          MOV     AH,4C
13B3:010B 88C8          MOV     AL,CL
13B3:010D CD21          INT     21

This turns on interrupts, sets CX for FFFF loops, then has the magic repz es:lodsb sequence. On 8088, this does not resume when the interrupt hits; on 80c88, according to ancient legends, it is supposed to and by the end CX should equal 0. In either case, I then do the OR so that cl will be non-zero if anything in CX has a bit set, then I "exit with return code", which I believe you can check with "echo %errorlevel%" but I'm not sure about that. If the error code is non-zero, it is buggy and doesn't resume (just like an 808x). If the error code is 0, then it did resume afterwards, like most CPUs including NEC Vx.

Don't trace through it line by line with debug, it may not work. I would dump it to a file and run it flat out then check the error code. And thank you for helping me get to the bottom of this.

When I try to write the assembled program to diskette, I get "File creation error". I did this all the time before, and I have the correct sequence. On a whim, I try a simple "copy con".

"File creation error"...

I can copy DEBUG.COM between diskettes...

This is going to take a little longer than expected (I also want to drop an older 8086 in a Model 30 for the same tests)...
 
Thought you'd get a kick out this one: AT&T PC6300:

Code:
;Data collected by: TOPBENCH | Benchmark and detection stub | Version 0.93
;This file contains fingerprinting information about your computer.  Please
;email this file to trixter@oldskool.org with a subject line of "Benchmark" to
;help test these routines and seed the TOPBENCH database.

[UIDA2BEBDD1]
MemoryTest=1324
OpcodeTest=672
VidramTest=785
MemEATest=874
3DGameTest=635
Score=12
Machine=unknown, ID : 0000
CPU=NEC V30
CPUspeed=8 MHz
BIOSinfo=COPYRIGHT (C)   OLIVETTI 1984    (04/03/86, rev. 244)
BIOSdate=19860403
BIOSCRC16=A2BE
VideoSystem=CGA
VideoAdapter=CGA
 
Awesome, that is operating exactly as programmed and exactly as I expected. One exception: I didn't have time to change the video subsystem to "AT&T/Olivetti/Compaq 400-line" yet because I've been trying to figure out a way to detect it (as different from normal CGA) safely. I have a few ideas on how to do this:

1. Read, increment, write, then read again a byte at b800:4000 (second bank of CGA memory, if it exists) and see if it behaves like there's actual memory there. (Of course, if there is something else at BC00, I'll likely bork the adapter)
or
2. Blindly accept a machine code of #0000 as AT&T/Olivetti and whatever the model byte is on my Compaq Portable III as Compaq
or
3. Try to trace/follow int 10h,ah=40h which I believe sets 400-line graphics mode (it's either that or 48h) and if there is something other than an iret there, I win
or
4. Try to determine from the video ports if we have AT&T/Compaq or not.

I'm heavily leaning toward #4, because according to the notes at http://www.seasip.info/VintagePC/compaq3.html and http://www.seasip.info/VintagePC/cga.html, it should be trivial to read bits from ports and determine if there is a 400-line monitor attached. If you know of a better way, I'm open to suggestions.
 
I would lean towards 4 as well. 1 definitely won't work - the CGA ignores the A14 address line, so its 16Kb of RAM appears at both 0xb8000-0xbbfff and 0xbc000-0xbffff. Though I suppose you could detect that condition by setting both 0xb8000 and 0xbc000 to 0, incrementing 0xb8000 and seeing if 0xbc000 gets incremented as well. That does also mean that nothing else will ever be at 0xbc000 - if anything did use those addresses it would have been incompatible with CGA.
 
Awesome, that is operating exactly as programmed and exactly as I expected. One exception: I didn't have time to change the video subsystem to "AT&T/Olivetti/Compaq 400-line" yet because I've been trying to figure out a way to detect it (as different from normal CGA) safely. I have a few ideas on how to do this:

1. Read, increment, write, then read again a byte at b800:4000 (second bank of CGA memory, if it exists) and see if it behaves like there's actual memory there. (Of course, if there is something else at BC00, I'll likely bork the adapter)
I think you're right avoiding that one and going with number 4 -- since both the PCJr and Tandy 1K's have 32k of RAM starting at $B800... and some even have 64k (TL/SL) passing through up to C7FF:FFFF. (which is why it's often hard to add SCSI or other option ROM to those!)
 
Andrew, Jason: It turns out all three of us are wrong, because I just tried this on stock CGA, and guess what? Bits 4-7 (reserved on CGA, videoID on AT&T) default to SET instead of unset. So it always returns "3" in bits 4-5, and that value (on an AT&T) matches an AT&T board, so CGA always gets detected as an AT&T board. I was surprised; I would have expected idle/unused bits to default to unset. Well, dangit.

I think I am going to go with the "see if there's memory beyond b800" method after all, since I am in that section after I've already tested for Tandy/PCjr and wouldn't confuse the results with those adapters. I did intend to write "see if the memory can be made different two banks apart" but forgot to write it initially.

Jason, does the newest stub 0.93 still explode into smithereens on your Tandy HX, or does it produce something more useful this time?
 
I think you're right avoiding that one and going with number 4 -- since both the PCJr and Tandy 1K's have 32k of RAM starting at $B800... and some even have 64k (TL/SL) passing through up to C7FF:FFFF. (which is why it's often hard to add SCSI or other option ROM to those!)
The Tandy 1000RL/SL/TL series can have up to 768 KB of RAM installed on the motherboard: 640 KB for DOS and the extra 128 KB for video.
 
Stub v0.93 works great on my Tandy 1000 HX, 640kb memory, ROM 2.00.00, with a 2400 baud dialup modem. Go ahead - laugh - it came with the machine, dangit!! :)

Code:
;Data collected by: TOPBENCH | Benchmark and detection stub | Version 0.93
;This file contains fingerprinting information about your computer.  Please
;email this file to trixter@oldskool.org with a subject line of "Benchmark" to
;help test these routines and seed the TOPBENCH database.

[UIDF9D031C]
MemoryTest=2033
OpcodeTest=1231
VidramTest=1265
MemEATest=1600
3DGameTest=1142
Score=7
Machine=Tandy 1000
CPU=NEC V20
CPUspeed=7.16 MHz
BIOSinfo=Copyright (C) 1984,1985,1986,1987 (06/01/87, rev. 100)
BIOSdate=19870601
BIOSCRC16=F9D0
VideoSystem=CGA
VideoAdapter=Tandy 1000
 
Last edited:
Here's the result from my Tandy 1000RL (8086 @ 10MHz.) topbstub doesn't seem to agree with either FreeDOS or my extended-memory manager, so I haven't gotten a chance to test it on my 486 yet.

Code:
[UID8BC62D9]
MemoryTest=1581
OpcodeTest=615
VidramTest=754
MemEATest=811
3DGameTest=698
Score=11
Machine=Tandy 1000
CPU=Intel 8086
CPUspeed=9.54 MHz
BIOSinfo=Copyright (C) 1984,1985,1986,1987,1988 (05/08/90, rev. 16)
BIOSdate=19900508
BIOSCRC16=8BC6
VideoSystem=CGA
VideoAdapter=Tandy 1000 SL/TL
 
Last edited:
Okay, it was the memory manager (not the first time it's caused issues.) Here's the results for the 486 (486DX2/66.)

Code:
[UID6C7BE31DD]
MemoryTest=89
OpcodeTest=51
VidramTest=116
MemEATest=77
3DGameTest=37
Score=190
Machine=Compaq 286/386 or clone
CPU=Intel i486DX2
CPUspeed=66 MHz
BIOSinfo=Copyright (c) AST Researc (03/18/94, rev. 32)
BIOSdate=19940318
BIOSCRC16=6C7B
VideoSystem=VGA
VideoAdapter=VGA, Cirrus CL-GD5424, VESA, 256kb Video Memory (BIOS)
 
Here's the results from my own Tandy 1000RL -- pretty much identical to what commodorejohn got:

Code:
;Data collected by: TOPBENCH | Benchmark and detection stub | Version 0.93
;This file contains fingerprinting information about your computer.  Please
;email this file to trixter@oldskool.org with a subject line of "Benchmark" to
;help test these routines and seed the TOPBENCH database.

[UID8BC6163B65]
MemoryTest=1581
OpcodeTest=617
VidramTest=755
MemEATest=812
3DGameTest=697
Score=11
Machine=Tandy 1000
CPU=Intel 8086
CPUspeed=9.54 MHz
BIOSinfo=Copyright (C) 1984,1985,1986,1987,1988 (05/08/90, rev. 16)
BIOSdate=19900508
BIOSCRC16=8BC6
VideoSystem=CGA
VideoAdapter=Tandy 1000 SL/TL
 
I would lean towards 4 as well. 1 definitely won't work - the CGA ignores the A14 address line, so its 16Kb of RAM appears at both 0xb8000-0xbbfff and 0xbc000-0xbffff. Though I suppose you could detect that condition by setting both 0xb8000 and 0xbc000 to 0, incrementing 0xb8000 and seeing if 0xbc000 gets incremented as well. That does also mean that nothing else will ever be at 0xbc000 - if anything did use those addresses it would have been incompatible with CGA.

I've been working for days on this, looking at my AT&T tech ref, disassembling programs that detect the AT&T graphics mode (like the AT&T version of Spacewar (SWATT.EXE) which uses an undocumented port!), and scouring other resources. (Way too much effort, but I'm obsessed with getting this cracked.) Well, it turns out I can't do this either, because the extra memory doesn't open up until you actually set the mode. In regular CGA modes, A14 is as expected and 0xbc000 = 0xb8000. When I go into 640x400 graphics mode, NOW I can see the entire 32K. But that assumes I know exactly what hardware I'm looking for, which is against the whole point of detecting the hardware...

So my choices now narrow down to two methods:

1. Set mode 40h (compaq, AT&T) or mode 74h (Toshiba 3100) and then immediately do a Int 10/AH=0Fh (Get video mode) and see if it matches the mode I set
or
2. Just blindly assume that specific system models are running specific graphics adapters.

#1 is a proper detection HOWEVER I noticed it puts some cards into 40-column (or worse) mode. More troubling, setting 80x25 mode 3 did not get them back.
#2 is not a proper detection, but is non-destructive.

Probably going to check for CGA and then just match model byte and force "detection" of adapter. Oh well.
 
commodorejohn said:
Okay, it was the memory manager (not the first time it's caused issues.) Here's the results for the 486 (486DX2/66.)

So far I'm batting 1000 for the CPU and frequency detection and BIOS copyright info, woohoo! The Machine detection is always going to be goofy because there are duplicates in that space in ROM and/or returned by Int 15/AH=C0h, but all of the non-benchmark fields are expected to be edited and verified by the user.

You mentioned before that the memory manager and FreeDOS were causing problems -- you removed the memory manager and it worked, but does it also work under FreeDOS?
 
Does the 32Kb of video RAM show up if you set bit 0 of port 23C6h manually (or failing that, trace the BIOS and see what port bits it is tickling)? I suppose it's a bit dangerous to set that bit if you don't know what hardware is there (though possibly less so than setting the mode via the BIOS).

This sort of thing is why the hardware detection code in Windows used to do things like write a bit to the hard disk that means "I'm about to run a dangerous test - if this bit is set at bootup it means we never regained control after the test, so don't run that test again on this machine" so there are known to be cases where it's unsolvable.
 
Ran this benchmark on my 386 system.

Code:
;Data collected by: TOPBENCH | Benchmark and detection stub | Version 0.93
;This file contains fingerprinting information about your computer.  Please
;email this file to trixter@oldskool.org with a subject line of "Benchmark" to
;help test these routines and seed the TOPBENCH database.

[UID1BE22760F]
MemoryTest=186
OpcodeTest=122
VidramTest=194
MemEATest=139
3DGameTest=113
Score=96
Machine=AT clone
CPU=AMD Am386DX
CPUspeed=40 MHz
BIOSinfo=R(C)1985-1991,American Megatrends Inc.,All Rights Reserved.,1346 Oakbrook Dr.,#120,GA-30093,USA.(404)-263-8181. (12/12/91, rev. 0)
BIOSdate=19911212
BIOSCRC16=1BE2
VideoSystem=VGA
VideoAdapter=VGA, Tseng ET 4000 with HiColor RAMDAC, DRAM, 1024kb Video Memory

pretty cool little benchmark.
 
You mentioned before that the memory manager and FreeDOS were causing problems -- you removed the memory manager and it worked, but does it also work under FreeDOS?
Yeah, only the memory manager was the problem. It seems to be more restrictive than EMM386, it caused problems with some of the SB16 utilities too.
 
Back
Top