Announcement

Collapse

Forum Rules and Etiquette

Our mission ...

This forum is part of our mission to promote the preservation of vintage computers through education and outreach. (In real life we also run events and have a museum.) We encourage you to join us, participate, share your knowledge, and enjoy.

This forum has been around in this format for over 15 years. These rules and guidelines help us maintain a healthy and active community, and we moderate the forum to keep things on track. Please familiarize yourself with these rules and guidelines.


Rule 1: Remain civil and respectful

There are several hundred people who actively participate here. People come from all different backgrounds and will have different ways of seeing things. You will not agree with everything you read here. Back-and-forth discussions are fine but do not cross the line into rude or disrespectful behavior.

Conduct yourself as you would at any other place where people come together in person to discuss their hobby. If you wouldn't say something to somebody in person, then you probably should not be writing it here.

This should be obvious but, just in case: profanity, threats, slurs against any group (sexual, racial, gender, etc.) will not be tolerated.


Rule 2: Stay close to the original topic being discussed
  • If you are starting a new thread choose a reasonable sub-forum to start your thread. (If you choose incorrectly don't worry, we can fix that.)
  • If you are responding to a thread, stay on topic - the original poster was trying to achieve something. You can always start a new thread instead of potentially "hijacking" an existing thread.



Rule 3: Contribute something meaningful

To put things in engineering terms, we value a high signal to noise ratio. Coming here should not be a waste of time.
  • This is not a chat room. If you are taking less than 30 seconds to make a post then you are probably doing something wrong. A post should be on topic, clear, and contribute something meaningful to the discussion. If people read your posts and feel that their time as been wasted, they will stop reading your posts. Worse yet, they will stop visiting and we'll lose their experience and contributions.
  • Do not bump threads.
  • Do not "necro-post" unless you are following up to a specific person on a specific thread. And even then, that person may have moved on. Just start a new thread for your related topic.
  • Use the Private Message system for posts that are targeted at a specific person.


Rule 4: "PM Sent!" messages (or, how to use the Private Message system)

This forum has a private message feature that we want people to use for messages that are not of general interest to other members.

In short, if you are going to reply to a thread and that reply is targeted to a specific individual and not of interest to anybody else (either now or in the future) then send a private message instead.

Here are some obvious examples of when you should not reply to a thread and use the PM system instead:
  • "PM Sent!": Do not tell the rest of us that you sent a PM ... the forum software will tell the other person that they have a PM waiting.
  • "How much is shipping to ....": This is a very specific and directed question that is not of interest to anybody else.


Why do we have this policy? Sending a "PM Sent!" type message basically wastes everybody else's time by making them having to scroll past a post in a thread that looks to be updated, when the update is not meaningful. And the person you are sending the PM to will be notified by the forum software that they have a message waiting for them. Look up at the top near the right edge where it says 'Notifications' ... if you have a PM waiting, it will tell you there.

Rule 5: Copyright and other legal issues

We are here to discuss vintage computing, so discussing software, books, and other intellectual property that is on-topic is fine. We don't want people using these forums to discuss or enable copyright violations or other things that are against the law; whether you agree with the law or not is irrelevant. Do not use our resources for something that is legally or morally questionable.

Our discussions here generally fall under "fair use." Telling people how to pirate a software title is an example of something that is not allowable here.


Reporting problematic posts

If you see spam, a wildly off-topic post, or something abusive or illegal please report the thread by clicking on the "Report Post" icon. (It looks like an exclamation point in a triangle and it is available under every post.) This send a notification to all of the moderators, so somebody will see it and deal with it.

If you are unsure you may consider sending a private message to a moderator instead.


New user moderation

New users are directly moderated so that we can weed spammers out early. This means that for your first 10 posts you will have some delay before they are seen. We understand this can be disruptive to the flow of conversation and we try to keep up with our new user moderation duties to avoid undue inconvenience. Please do not make duplicate posts, extra posts to bump your post count, or ask the moderators to expedite this process; 10 moderated posts will go by quickly.

New users also have a smaller personal message inbox limit and are rate limited when sending PMs to other users.


Other suggestions
  • Use Google, books, or other definitive sources. There is a lot of information out there.
  • Don't make people guess at what you are trying to say; we are not mind readers. Be clear and concise.
  • Spelling and grammar are not rated, but they do make a post easier to read.
See more
See less

Tandy 1000 A/EX/HX DMA speed-up

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    #31
    Originally posted by Trixter View Post
    Not to derail the conversation too much, but I'm publishing a video this weekend that proves the Tandy 1000 (the original) can be just a hair slower than the IBM PC, found when doing a software-controlled sound output test. The program in question used software loops for timing, and a lot of port 61h writes. The audio is audibly slower/lower in pitch than when run on the IBM PC. I'm unable to account for this discrepancy.
    Does your T1000 have a RAM card installed or is this part of a demo meant to run on an un-expanded machine? RAM access to the shared planar RAM probably is slower than a PC; faster than a PCjr but from reading the manual I don't think it's contention-less.

    If you want a data point I'd be willing to run your software loop on my SRAM EX in slow mode, but maybe that won't tell you anything useful. (especially since I have a V-20.)
    My Retro-computing YouTube Channel (updates... eventually?): Paleozoic PCs Also: Blogspot

    Comment


      #32
      Originally posted by eeguru View Post
      Most plausible theory is the 1000 did share video RAM in much the same way as the Jr. However I suspect the extra CPU waits due to the video access were more efficient than the Jr's video gate array as the 1000 was an evolution. And obviously the 1000 mapped video RAM at the end of main memory so there wasn't the nasty hole.
      A good theory, however the PCjr's slowdown at very high interrupt rates (16 KHz) is much worse than on a Tandy 1000. So the Tandy 1000 is slower, but only by 1%, just enough to be audible. On an expanded PCjr, where the main code runs out of the expansion but the interrupt is reading 4 bytes from the first 128K at 16 KHz, it's much more pronounced.
      Offering a bounty for:
      - A working Sanyo MBC-775 or Logabax 1600
      - Music Construction Set, IBM Music Feature edition (has red sticker on front stating IBM Music Feature)

      Comment


        #33
        Originally posted by Trixter View Post
        A good theory, however the PCjr's slowdown at very high interrupt rates (16 KHz) is much worse than on a Tandy 1000. So the Tandy 1000 is slower, but only by 1%, just enough to be audible. On an expanded PCjr, where the main code runs out of the expansion but the interrupt is reading 4 bytes from the first 128K at 16 KHz, it's much more pronounced.
        Paging through my copy of the DATABASE.INI for Topbench it doesn't look like there are results for an original 1000/1000A in there, the closest thing there is is a 1000 SX in slow mode. And comparing the scores for that to the scores UnknownK placed in the thread earlier suggests the original 1000 may *be* slower, slightly, than later models. 1000SX from database.ini:

        [UID989015B1]
        MemoryTest=3742
        OpcodeTest=1770
        VidramTest=2082
        MemEATest=1962
        3DGameTest=1883
        Score=4
        CPU=Intel 8088
        CPUspeed=4.77 MHz
        BIOSinfo=
        BIOSdate=19860714
        BIOSCRC16=9890
        VideoSystem=CGA
        VideoAdapter=Tandy 1000
        Machine=Tandy 1000 SX (4.77MHz)
        Description=
        Submitter=Great Hierophant

        UnknownK's score from a 1985 Tandy 1000 with a DMA memory card installed:

        [UID85086DB6]
        MemoryTest=3823
        OpcodeTest=1833
        VidramTest=2148
        MemEATest=2028
        3DGameTest=1922
        Score=4
        CPU=Intel 8088
        CPUspeed=4.77 MHz
        BIOSinfo=unknown
        MachineModel=0000
        BIOSdate=19850305
        BIOSCRC16=8508
        VideoSystem=CGA
        VideoAdapter=Tandy 1000
        Machine=Tandy 1000

        It's not a lot but it's measurably slower in every test, which is a little odd since you'd think they should be equivalent. The SX score is almost dead on with a 5150 from the database. Perhaps an original 1000 actually *is* slower. Do you have another 8088 model (EX/HX/SX) to run your test on?

        As an aside, I noticed right under the 1000SX score in the database is a score from an expanded IBM PCjr (Description=IBM PCjr running in the faster RAM of the memory expansion). The scores from that PCjr are better than the 1000SX in every category but the VidRamTest by about as much as my SRAM EX beats the DMA/DRAM HX. DMA expansions were rare for PCjr's, so... I wonder if likewise that RAM expansion doesn't burden the system with waiting for refresh cycles.
        My Retro-computing YouTube Channel (updates... eventually?): Paleozoic PCs Also: Blogspot

        Comment


          #34
          Originally posted by Eudimorphodon View Post
          I wonder if likewise that RAM expansion doesn't burden the system with waiting for refresh cycles.
          The more common IBM 128KB memory side-cars did use Dynamic RAM which would require refresh. But at least the video wasn't in contention. But even with 1, 2, or even 3 128KB side-cars, you wouldn't want to block out the entire 128KB from use by DOS unless you were specifically doing this benchmark. Each KB was $$ ($$$$ at 1980s exchange rates). I'm guessing it was something like a JR-IDE which uses SRAM and runs a hair faster than DRAM due to no refresh.
          "Good engineers keep thick authoritative books on their shelf. Not for their own reference, but to throw at people who ask stupid questions; hoping a small fragment of knowledge will osmotically transfer with each cranial impact." - Me

          Comment


            #35
            Also, re: how comparable the Tandy 1000's video ASIC is to the PCjr's, I think these scores:

            Originally posted by Unknown_K View Post
            ;Data collected by: TOPBENCH | Benchmark and detection stub | Version 0.97e
            ;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.

            [UID85086477]
            MemoryTest=4232
            OpcodeTest=2103
            VidramTest=2236
            MemEATest=2375
            3DGameTest=2152
            Score=4
            CPU=Intel 8088
            CPUspeed=4.77 MHz
            BIOSinfo=unknown
            MachineModel=0000
            BIOSdate=19850305
            BIOSCRC16=8508
            VideoSystem=CGA
            VideoAdapter=Tandy 1000
            Machine=Tandy 1000

            DOS 2.11 Boot disk, 128KB no DMA.
            Compared to these:

            [UID7F5C71D]
            MemoryTest=5926
            OpcodeTest=3584
            VidramTest=3373
            MemEATest=4392
            3DGameTest=3490
            Score=2
            CPU=Intel 8088
            CPUspeed=4.77 MHz
            BIOSinfo=COPR. IBM 1981,1983 (06/01/83, rev. 86)
            BIOSdate=19830601
            BIOSCRC16=7F5C
            VideoSystem=CGA
            VideoAdapter=IBM PCjr
            Machine=IBM PCjr
            Description=Stock, 128KB RAM. This score is accurate -- it is slower because the first 128KB of PCjr RAM is also display RAM and has an additional wait state.
            Submitter=trixter@oldskool.org

            Settle that. It doesn't look like it's completely wait-state free (and Unknown_K's scores support that with the aforementioned 10%-ish hit compared to having a RAM card installed) but it is clearly a massive improvement. (The video chip does have 16 bit access to RAM and separate video and CPU data latches, so contention would at least be substantially reduced from just that. It also looks like it may be able to generate wait states with better granularity for when conflicts do happen, although I can't say that without knowing more about how the Jr. works.)
            My Retro-computing YouTube Channel (updates... eventually?): Paleozoic PCs Also: Blogspot

            Comment


              #36
              Originally posted by eeguru View Post
              I'm guessing it was something like a JR-IDE which uses SRAM and runs a hair faster than DRAM due to no refresh.
              Yeah, that's what I was was suspecting. A Jr-IDE should be roughly the equivalent to SRAM in a Tandy for expansion RAM speed, and would be another data point for "your machine will be faster with no DMA controller unless you need it for something".
              My Retro-computing YouTube Channel (updates... eventually?): Paleozoic PCs Also: Blogspot

              Comment


                #37
                Originally posted by Eudimorphodon View Post
                Perhaps an original 1000 actually *is* slower. Do you have another 8088 model (EX/HX/SX) to run your test on?
                I do, but I'm swamped until about 1-2 weeks after VCFMW is over.
                Offering a bounty for:
                - A working Sanyo MBC-775 or Logabax 1600
                - Music Construction Set, IBM Music Feature edition (has red sticker on front stating IBM Music Feature)

                Comment


                  #38
                  Originally posted by Trixter View Post
                  I do, but I'm swamped until about 1-2 weeks after VCFMW is over.
                  So... I noticed something last night, and I was wondering if you could give me some insight on how TopBench assigns the aggregate speed number when you add a new system to the database. I was mucking around with a keyboard-less 1000 HX motherboard last night, driving it via PC Anywhere (which I don't know is actually a factor), and out of curiosity related to this "DMA speed-up" thread I ran TopBench on it to look for more confirmation/denial of the theory that one of these machines with a static RAM board is faster than the DMA board. I did the "add this machine to the database" routine, and then I ran system comparison to see how the HX with the static board compared to the EX in the database with the Radio Shack board. (The HX in the stock database has a V-20 so the EX should be the closer comparison.) Here's a screenshot of the curious result. (If you'd like the actual database numbers I can transfer them over. The screen looks like a VGA screen because it's the PC Anywhere view.)

                  20191001_184217.jpg

                  I'm curious why the result that is faster on every individual test rated a "5" instead of a "6", and was thus declared "20% slower". (Based on the "total" times my calculator says it should actually be around 8% faster?) Is the "speed number" based on some arithmetic mean of the existing scores (and thus only really valid if the whole database is re-crunched?), or a wall-clock time that might have been influenced by PC Anywhere running in the background?

                  I was already sort of curious about this because my other machine was assigned an "8" when it went into the database, but always gets a "7" when the test is run interactively. The scores will be identical, or near enough I can't imagine it mattering. (Literally a microsecond or two either way.)

                  (I apologize if this has already been answered elsewhere.)
                  My Retro-computing YouTube Channel (updates... eventually?): Paleozoic PCs Also: Blogspot

                  Comment


                    #39
                    These are all great questions, and I'm sorry if the documentation doesn't do a good job of explaining it. The details are in https://github.com/MobyGamer/TOPBENC...r/BTSUITES.PAS but the gist is this: There are five sections of code that are run, each testing a different area of performance (memory speed, general instruction exercise, etc.). Each section returns the number of microseconds (usecs) it took to run, so if you see those, lower numbers are better. However, those are not part of the Score -- they are recorded as a convenience to emulator authors, or if you want to see exactly why one Score is slightly off than another. The Score itself is the number of times the complete test suite ran in a 50ms period.

                    The goal of the Score was to keep it simple -- just a synthetic integer you could use to compute relative performance between systems. It was a reaction to the (IMO misleading and confusing) Landmark "XX.XX MHZ AT SPEED" measurement. I still think how I did it was the right decision, but where it breaks down is when you have an edge case where a very slight modification on a very slow system lets the Score calculation run just one extra loop, which is what you're seeing. One extra loop is no big deal on a faster system, but when the Score is single-digits, it can look like (in your case) a 12% jump in speed when it might really only be a 1% jump that pushed it over the edge. For such edge cases, you can determine the actual % speed difference by looking at the actual microsecond timings and comparing those instead.

                    This has prompted me to make a small change to TOPBENCH where I can put the % speed difference for the microsecond timings in that same display in your screenshot. I'll make that code change by the end of the weekend and then update this thread when it's uploaded. Hopefully that will give you more insight.

                    When I designed TOPBENCH I didn't think people would be making such small changes to very slow systems -- people usually made larger changes, like 8088->NEC V20, or 6MHz to 8MHz. Had I known people would be making tiny changes, I would probably have changed the score such that it would be # of iterations in a 100ms or 200ms period, rather than 50ms. I suppose I could release a new version that does that, and adjusts the scores to match so that they're all the same relative to each other, but that's disingenuous and inaccurate for systems that actually exhibit these edge cases, so I'm afraid the benchmark's core operation is forever frozen.
                    Offering a bounty for:
                    - A working Sanyo MBC-775 or Logabax 1600
                    - Music Construction Set, IBM Music Feature edition (has red sticker on front stating IBM Music Feature)

                    Comment


                      #40
                      Originally posted by Trixter View Post
                      There are five sections of code that are run, each testing a different area of performance (memory speed, general instruction exercise, etc.). Each section returns the number of microseconds (usecs) it took to run, so if you see those, lower numbers are better. However, those are not part of the Score -- they are recorded as a convenience to emulator authors, or if you want to see exactly why one Score is slightly off than another. The Score itself is the number of times the complete test suite ran in a 50ms period...

                      I still think how I did it was the right decision, but where it breaks down is when you have an edge case where a very slight modification on a very slow system lets the Score calculation run just one extra loop, which is what you're seeing. One extra loop is no big deal on a faster system, but when the Score is single-digits, it can look like (in your case) a 12% jump in speed when it might really only be a 1% jump that pushed it over the edge. For such edge cases, you can determine the actual % speed difference by looking at the actual microsecond timings and comparing those instead.
                      Are the microsecond timings that are recorded in the end the average for each of the loops over the 50ms run, or just the amount of time a given (first,last?) run of that individual code tree took? That's where I'm still a little puzzled, because in this bizarre edge case the times for *all* the individual tests were lower (faster), but the aggregate score was lower (less total runs executed).

                      I've noticed that I can significantly ding the interactive Topbench score (at least on these bottom-of-the-barrel machines) by, for instance, grabbing the mouse and whirling it around. I assume that happens because it's possible for interrupts to impinge in the middle of the 50ms loops and knock an individual execution out? If that's the case then I imagine PC Anywhere's diddling with the serial port could be responsible for the lower synthetic score and the result will make more sense after I work out how the heck I'm going to put a keyboard on this thing?
                      My Retro-computing YouTube Channel (updates... eventually?): Paleozoic PCs Also: Blogspot

                      Comment


                        #41
                        The microsecond timings are run-once; they are neither an average, nor a count. Interrupts are always disabled while any individual test is occuring.

                        The calculation of the Score that gets into the database is also done with interrupts disabled, so that is also fine. The realtime Score, however, is done with interrupts enabled between each run to increase the responsiveness of that screen. I am not surprised that moving the mouse or smashing the keys can affect it, because I've done that myself The microsecond timings shouldn't vary that much since interrupts are disabled while each one runs; any variance would be small due to DRAM refresh. But the Score can indeed jump.

                        I could alter the realtime display so that interrupts are disabled while the Score is being calculated, but that runs the risk of borking system processes that handle communication, like mouse or network card drivers. It's bad form to disable interrupts for too long. So, for best results in the realtime display, boot clean and don't touch anything
                        Offering a bounty for:
                        - A working Sanyo MBC-775 or Logabax 1600
                        - Music Construction Set, IBM Music Feature edition (has red sticker on front stating IBM Music Feature)

                        Comment


                          #42
                          Originally posted by Trixter View Post
                          The calculation of the Score that gets into the database is also done with interrupts disabled, so that is also fine.
                          I suppose that could explain the difference in the case of the 7/8 disconnect between interactive and database add on the EX's recorded score. The head-scratcher for me is why the HX's "straight to database" score was lower than the saved one, unless PC Anywhere manages to hook onto *something* itself that lets it butt in during the score generation. (If I divide 50ms by the respective microsecond timings I get a possible 6.039 loops in 50ms for my HX+PC Anywhere vs. 5.58 loops for the canonical EX record... which now has me scratching my head how it scored a six, unless there's some variance in how tight the timing is for that 50ms period and it managed to round it up.)

                          Anyway. I guess I'll just remember if I'm looking for itty bitty differences I should stick to the individual microsecond timings.
                          Last edited by Eudimorphodon; October 2, 2019, 02:06 PM.
                          My Retro-computing YouTube Channel (updates... eventually?): Paleozoic PCs Also: Blogspot

                          Comment


                            #43
                            Originally posted by Trixter View Post
                            I'll make that code change by the end of the weekend and then update this thread when it's uploaded.
                            I guess I should have written "end of the year", sorry about that. New release is up: https://github.com/MobyGamer/TOPBENCH/releases/tag/0.40

                            The main update is that the Benchmark->Compare screen is now much clearer as to what is being compared. Systems with identical SCOREs are considered equal speed (as was always the original design). Also, each test suite's microsecond timing numbers are highlighted with a speed factor printed next to them if they're faster than the other system, so that you can see exactly why/how a system differs from another. This should make your "itty bitty differences" comparisons easier.

                            I hope this addresses your concerns, but if not, let me know.
                            Offering a bounty for:
                            - A working Sanyo MBC-775 or Logabax 1600
                            - Music Construction Set, IBM Music Feature edition (has red sticker on front stating IBM Music Feature)

                            Comment


                              #44
                              Originally posted by Trixter View Post
                              I hope this addresses your concerns, but if not, let me know.
                              Thank you. I'll be sure to take a look at it ASAP.

                              And, really, I don't think there were "concerns" really, it was mostly just having to actually grok what the aggregate numbers *meant*. The only remaining thing at all my list is just wondering why the machines I've tested are so *reliable* about scoring one higher in "add to database" than they are on on the interactive screen. IE, here's a screenshot showing the machine comparing itself to itself. (The 1 microsecond difference under "opcodes" would flip back and forth, otherwise all the numbers are rock solid.)

                              speedshot.jpg

                              I'm guessing it's just a matter of machines like this being so slow that having interrupts enabled at all makes the difference in loop count, even if you don't touch anything. (It's off even if I don't load a mouse driver, etc. Happens with the 8088 installed as well, although in that case it's the difference between a 6 and a 5 instead of an 8 or a 7.)
                              My Retro-computing YouTube Channel (updates... eventually?): Paleozoic PCs Also: Blogspot

                              Comment

                              Working...
                              X