[Freedos-user] freedos 1.3 on vm or real machine
Hello I have a question: on freedos 1.3 or 1.2 i can't write the * without going to the numeric keypad. KEYB PO,858 available: 858, 850, 860 also can't write: ã ä â á à ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] retro gamer review of FreeDOS 1.3
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 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 > Freedos-user@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/freedos-user > ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] retro gamer review of FreeDOS 1.3
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 Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] retro gamer review of FreeDOS 1.3
Hello. Thank you Eric and Jim. I'll do a search and i let you know how it turned out On Thu, Mar 10, 2022 at 10:04 AM Jim Hall wrote: > One program to fix the "runtime error 200" is Robert and Marek's TSR tool, > which we include in FreeDOS 1.3: > > http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/repositories/1.3/pkg-html/tp7p5fix.html > > > But as Eric said, you can find lots of tools on the Internet to fix this > too. Or you can run SLOWDOWN as another workaround. > > On Thu, Mar 10, 2022, 2:30 AM Eric Auer wrote: > >> >> Hi! Runtime error 200 usually is an overflow in timing >> code of Borland or Turbo Pascal, if you search the web >> you will find various tools which patch it or work it >> around :-) The overflow happens because your computer >> is too fast. So you can also try to slow it down, e.g. >> using FDAPM SPEEDn where n is a digit (but that might >> crash, be prepared to hard-reset or power cycle if so) >> or using various "SLOWDOWN" resident tools for DOS. As >> runtime error 200 is widespread, as said there also are >> tools which to either load as TSR (they will patch the >> affected code in RAM) or can be used to modify affected >> EXE files on disk (remember to backup the original EXE). >> >> Regards, Eric >> >> >> >> > Tyrian >> > >> > tyrian.exe - Runtime error 200 at 0006:374c >> > setup.exe - Runtime error 200 at 0002:24ED >> > >> > Fuzzy >> > >> > fuzzy.exe - Runtime error 200 at 0003:361B >> > main.exe - Runtime error 200 at 0003:361B >> >> ___ > Freedos-user mailing list > Freedos-user@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/freedos-user > ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] retro gamer review of FreeDOS 1.3
One program to fix the "runtime error 200" is Robert and Marek's TSR tool, which we include in FreeDOS 1.3: http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/repositories/1.3/pkg-html/tp7p5fix.html But as Eric said, you can find lots of tools on the Internet to fix this too. Or you can run SLOWDOWN as another workaround. On Thu, Mar 10, 2022, 2:30 AM Eric Auer wrote: > > Hi! Runtime error 200 usually is an overflow in timing > code of Borland or Turbo Pascal, if you search the web > you will find various tools which patch it or work it > around :-) The overflow happens because your computer > is too fast. So you can also try to slow it down, e.g. > using FDAPM SPEEDn where n is a digit (but that might > crash, be prepared to hard-reset or power cycle if so) > or using various "SLOWDOWN" resident tools for DOS. As > runtime error 200 is widespread, as said there also are > tools which to either load as TSR (they will patch the > affected code in RAM) or can be used to modify affected > EXE files on disk (remember to backup the original EXE). > > Regards, Eric > > > > > Tyrian > > > > tyrian.exe - Runtime error 200 at 0006:374c > > setup.exe - Runtime error 200 at 0002:24ED > > > > Fuzzy > > > > fuzzy.exe - Runtime error 200 at 0003:361B > > main.exe - Runtime error 200 at 0003:361B > > ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] retro gamer review of FreeDOS 1.3
Hi! Runtime error 200 usually is an overflow in timing code of Borland or Turbo Pascal, if you search the web you will find various tools which patch it or work it around :-) The overflow happens because your computer is too fast. So you can also try to slow it down, e.g. using FDAPM SPEEDn where n is a digit (but that might crash, be prepared to hard-reset or power cycle if so) or using various "SLOWDOWN" resident tools for DOS. As runtime error 200 is widespread, as said there also are tools which to either load as TSR (they will patch the affected code in RAM) or can be used to modify affected EXE files on disk (remember to backup the original EXE). Regards, Eric Tyrian tyrian.exe - Runtime error 200 at 0006:374c setup.exe - Runtime error 200 at 0002:24ED Fuzzy fuzzy.exe - Runtime error 200 at 0003:361B main.exe - Runtime error 200 at 0003:361B ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
