Image Map Image Map
Page 1 of 40 1234511 ... LastLast
Results 1 to 10 of 400

Thread: Looking for volunteers to help test a new benchmark

  1. #1
    Join Date
    Aug 2006
    Location
    Chicagoland, Illinois, USA
    Posts
    5,633
    Blog Entries
    1

    Default Looking for volunteers to help test a new benchmark

    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.

  2. #2

    Default

    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 by IBMMuseum; November 15th, 2011 at 06:20 AM.

  3. #3
    Join Date
    Aug 2006
    Location
    Chicagoland, Illinois, USA
    Posts
    5,633
    Blog Entries
    1

    Default

    Quote Originally Posted by IBMMuseum View Post
    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.

  4. #4

    Default

    Quote Originally Posted by Trixter View Post
    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...

    Quote Originally Posted by Trixter View Post
    ...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)...

  5. #5
    Join Date
    Jan 2007
    Location
    Pacific Northwest, USA
    Posts
    30,672
    Blog Entries
    20

    Default

    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

  6. #6
    Join Date
    Aug 2006
    Location
    Chicagoland, Illinois, USA
    Posts
    5,633
    Blog Entries
    1

    Default

    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.

  7. #7

    Default

    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.

  8. #8

    Default

    Quote Originally Posted by Trixter View Post
    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!)
    From time to time the accessibility of a website must be refreshed with the blood of owners and designers. It is its natural manure.
    CUTCODEDOWN.COM

  9. #9
    Join Date
    Aug 2006
    Location
    Chicagoland, Illinois, USA
    Posts
    5,633
    Blog Entries
    1

    Default

    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?

  10. #10

    Default

    Quote Originally Posted by deathshadow View Post
    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.

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •