Image Map Image Map
Page 2 of 2 FirstFirst 12
Results 11 to 20 of 20

Thread: I overclocked my IBM 5150...

  1. #11
    Join Date
    Jan 2007
    Location
    Pacific Northwest, USA
    Posts
    34,097
    Blog Entries
    18

    Default

    Why would clocking the refresh at a higher rate be beneficial? If you check some 1980s articles on 5150/60 speedup, there was code to reduce the refresh rate. The 5150 is supposed to aim for a 2 msec refresh, when in fact, a much lower rate is perfectly decent. Refresh on the 51x0 occupies about 10% of overhead.

  2. #12

    Default

    Quote Originally Posted by Chuck(G) View Post
    Why would clocking the refresh at a higher rate be beneficial? If you check some 1980s articles on 5150/60 speedup, there was code to reduce the refresh rate. The 5150 is supposed to aim for a 2 msec refresh, when in fact, a much lower rate is perfectly decent. Refresh on the 51x0 occupies about 10% of overhead.
    Fair enough, I'm still learning when it comes to this stuff. It seems that faster is not always better. I'll try to see if I can find some of the articles you mentioned. Yet another data point to add to my research, thanks!

  3. #13
    Join Date
    Jan 2007
    Location
    Pacific Northwest, USA
    Posts
    34,097
    Blog Entries
    18

    Default

    If you can't find any, I may have a copy of one in my files. However, the business of the refresh was used by a couple of (unscrupulous) outfits advertising a "speedup" for your PC. You may also find references to the trick on SIMTEL20.

  4. #14

    Default

    https://www.reenigne.org/blog/how-to...-dram-refresh/

    So in an overclocked state the IBM 5150 would definitely not need to refresh every 72 cycles since more cycles would occur over a duration

    Interesting

  5. #15
    Join Date
    May 2006
    Location
    Melbourne, Australia
    Posts
    6,596

    Default

    Quote Originally Posted by rmay635703 View Post
    So in an overclocked state the IBM 5150 would definitely not need to refresh every 72 cycles since more cycles would occur over a duration
    A related diagram is at [here].

  6. #16
    Join Date
    Jan 2019
    Location
    New Hampshire
    Posts
    227

    Default

    One could change the timing of the 8253 Programmable Interval Timer with a little bit of code to gain a few more cycles back

  7. #17
    Join Date
    Jan 2019
    Location
    New Hampshire
    Posts
    227

    Default

    ... but looking at the logic diagram for the 5150, the 8253 Timer clock is driven by PCLK, which is not altered by PC-turbo, right? So the DMA refresh should remain at the standard interval when running PC-turbo, if I've interpreted this correctly.

  8. #18

    Default

    Quote Originally Posted by chris_nh View Post
    ... but looking at the logic diagram for the 5150, the 8253 Timer clock is driven by PCLK, which is not altered by PC-turbo, right? So the DMA refresh should remain at the standard interval when running PC-turbo, if I've interpreted this correctly.
    That was my understanding as well. The mod just increases the clock speed of the CPU (and co-processor if fitted). Everything else should be unaltered.

  9. #19

    Default

    It seems this thread has picked up a bit of steam so I thought I'd post some more of my thoughts on the PC-SPRINT and see if some of the more technical people here can enlighten me on some of the finer details.

    I also discovered Sergey's mod for the XT: http://www.vcfed.org/forum/showthrea...Sergey%92s-way

    This hooks into the HRQDMA and HRQWAIT signals on the XT motherboard to reduce the clock speed to normal whenever there is DMA activity.

    It doesn't appear that the PC-SPRINT does this however, in fact it seems the 5150 doesn't provide HRQWAIT at all from what I can see (I can't find any reference to it in the technical reference but maybe it went under another name?)

    That said, it looks like we can get HRQDMA from pin 10 of the 8237, so I think it would be relatively simple to add some logic around the turbo switch input to also disable the faster clock when this pin is high without any other major changes to the circuit.

    Does all of this make sense?

  10. #20

    Default

    pc-sprint-pcb-vcfed.jpg

    OK, so I've been a very busy boy since I last posted in this thread.

    I had some PC-SPRINT PCBs manufactured (pictured above) using Retro Canada's KiCAD / gerber files and have been using one in my 5150 for the past week. I have an NEC V20 CPU and an 8087-2 installed, as well as 150ns RAM. I built my PC-SPRINT with a 21.47727MHz crystal giving a CPU clock speed of 7.16MHz. This is the same as the Tandy 1000 EX and HX, for what it's worth.

    I've had zero problems so far and have tested with various games with a CGA and an EGA card. The performance difference is pretty staggering, actually. I've run a whole load of benchmarks and the improvements are in the 50-55% range across the board. I just leave the turbo mode enabled at all times, even when booting - incidentally, cold boot time has been reduced from 1:02 to 43 seconds. The new reset button is handy too.

    But it doesn't end there. As others raised some concerns about DMA I also decided to learn some KiCAD and circuit design and work on my own "PC-SPRINT v2". These arrived from PCBWay today and I have assembled one:

    pc-sprint-v2-assembled-vcfed.jpg

    ..and installed it:

    pc-sprint-v2-installed-vcfed.jpg

    The new version adds some additional logic to incorporate the DMA signals previously identified by Sergey Kiselev:

    pc-sprint-v2-new-dma-logic-vcfed.jpg

    I initially built this with a rather ambitious 24MHz crystal but the PC would freeze instantly with it enabled (even at the DOS prompt) so I have downgraded to a 22.1184MHz crystal (7.37MHz CPU clock) and that has worked perfectly fine in my limited testing so far.

    Note that I haven't hooked up the DMA side of things yet but that's next on the todo list. I think I found the right places on the motherboard based on the Technical Reference but I want to confirm with an oscilloscope before I do anything too hasty, especially as it's all working fine so far anyway.

    I documented the whole project over on GitHub for future generations who may stumble across this and get intrigued like I (and others) did: https://github.com/reesclissold/pc-sprint

    It's very much a work in progress but I've added all the details on the benchmarks I've run so far as well as all of the files for the v2. There are probably a few errors in there as I'm still learning but I felt it made sense to put all my findings in one place.

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
  •