I use a Pentium MMX as my fastest dedicated PC for DOS and i usually downclock it to 50MHz FSB x 2. If some games still have issues i can use SETMUL to manipulate Pentium TR4 registers, which allow to disable exclusively CPU features like Instruction Cache, Data Cache, Branch Prediction and V-Pipelining. This helps me get around the specific Runtime Error 200 cause by Borland Turbo Pascal compiler.
Another common issue is the "Packed File is Corrupt" error. It happens because binaries compressed by Microsoft's EXEPACK actually uses the wrap around at the top of 1MB. In real mode CPU's this is never an issue, but on systems with the A20 gate on and the EXE loaded in the first 64kb of memory the .EXE will decompress incorrectly leading to that error. Just mentioning this because some people might mistake it for a problem with FreeDOS. Curiously, the error reported in Tyrian by the user João seems to have happened exactly in the first 64kb of memory, though it is not an EXEPACK error but the infamous Turbo Pascal bug. I am mostly certain that Tyrian will run fine on FreeDOS 1.3 and i should be able to test that tomorrow. On Thu, Mar 10, 2022 at 5:15 PM Bret Johnson <[email protected]> wrote: > I heard/read somewhere that the "Runtime Error 200" was actually caused > some sort of subroutine that was trying to figure out how fast the computer > is. It's certainly ironic that it doesn't work on really fast computers > since that's exactly the "problem" it's trying to address. > > The other interesting thing about it is that in most programs there is no > legitimate need to know how fast the computer is (the program is bloated > and wasting time trying to figure out something it doesn't even need to > know). Of course, with some programs (like interactive games) the speed of > interaction is critical, but those are the exceptions. A well-written > program (even an interactive game) wouldn't rely on a specific speed of > computer, anyway, as long as the computer was some "minimum". > > It's also interesting that CPU speeds are pretty much maxed out at a few > GHz. For a long time it looked like they were going to be able to keep > increasing CPU speeds, but they've pretty much reached the physical limits > of electrical physics. They've needed to figure out other ways of > increasing speeds besides creating faster oscillators. > > Some of the early attempts were things like pipelining in the CPU > (performing two CPU instructions at once) and caching, but the most common > solution nowadays is multiple cores/CPU's. Of course, that takes special > programming techniques and lots of complication at both the hardware and > software level. They're also experimenting with things like optical and > quantum computing, and even things like "three-dimensional" CPU's where > the different parts of the CPU send signals with back and forth with > magnetic waves or photons instead of signals running along "wires". > > The other interesting thing is that people are still obsessed with speed, > but sometimes speed is your enemy instead of your friend. I remember > talking to a guy one time who used to be in the Air Force and he talked > about how they still sometimes use prop-driven planes instead of jets > because the jets are too fast to do the specific job they're trying to > accomplish. > > Anyway, just some passing thoughts. > > > _______________________________________________ > Freedos-user mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/freedos-user >
_______________________________________________ Freedos-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-user
