ripsaw8080 wrote on 2020-04-28, 10:41:

TheGreatCodeholio wrote on 2020-04-28, 08:10:

the LSB masking only affects reading the counter.

Yes, but the question is if it should apply when the counter is written. I realize it would halve the number of possible frequencies that can be selected, but the difference is perhaps small enough to be indistinguishable. It seems more like what the hardware would do than making a special case of a counter value of 1.

According to Intel's documentation, there does seem to be somewhat different handling for even and odd values. Though it always counts by 2 and counts down from an even value the documentation implies that there is a one cycle delay before it reloads the counter every other countdown.

Reading the documentation says that for mode 3, it would seem the counter is loaded with the value with the LSB removed and counted down by 2 for each half of the square wave. Note that if you do that with 1 or 0 it comes out 0, which then means the longest period possible. So it's probably not much of an addition to silicon at all. The documentation seems to imply the first half of the square wave has one additional clock cycle of delay before reloading and going LOW to start the process again, if the initial counter was an odd value.

http://hackipedia.org/browse.cgi/Comput ... 9%29%2epdf

I'm not sure this post goes here or should be a separate thread but, trying dosbox-x and confronted with nothing but annoyance. Trying and failing to set cycles to max, doesn't recognize standard dosbox command to set, okay I think, I'll just write the conf and see what dosbox-x is doing to set cycles, dosbox-x doesn't recognize standard dosbox writeconf command.. readme? not seeing anything there, built in menu, try setting cycles as "max," runs locked as snail slow, reopen menu, reset/never left "fixed" x cycles. so.. yeah.. perhaps it's me being retarded but it comes off as dosbox-x being retarded left, right and center. What's the super secret members only option for setting max cycles?

awgamer wrote on 2020-07-25, 04:14:

I'm not sure this post goes here or should be a separate thread but, trying dosbox-x and confronted with nothing but annoyance. Trying and failing to set cycles to max, doesn't recognize standard dosbox command to set, okay I think, I'll just write the conf and see what dosbox-x is doing to set cycles, dosbox-x doesn't recognize standard dosbox writeconf command.. readme? not seeing anything there, built in menu, try setting cycles as "max," runs locked as snail slow, reopen menu, reset/never left "fixed" x cycles. so.. yeah.. perhaps it's me being retarded but it's comes off as dosbox-x being retarded left, right and center. What's the super secret members only option for setting max cycles?

What do you mean by “dosbox-x doesn't recognize standard dosbox writeconf command”? “writeconf” is not a standard DOSBox command, just an option of e.g. the config command, which is also supported by DOSBox-X. For setting max cycles in DOSBox-X, you can certainly do this in the config file too. DOSBox-X does come with a sample config file named dosbox-x.reference.conf, with comments for all of its options, and you can also find its contents online at:

Link to: dosbox-x.reference.conf

config writeconf. I erred, it does do that, it doesn't do "cycles max." tarded. Turns out dosbox-x did set to a "max" cycles and reports in its own way, "3000%," which runs quake timedemo like molasses(16fps vs 74.) Is there a way to get dosbox-x to run at full speed or is that it? edit: with cycles auto "100%," it's producing the same 16fps as "max" "3000%."

awgamer wrote on 2020-07-25, 04:14:

I'm not sure this post goes here or should be a separate thread but, trying dosbox-x and confronted with nothing but annoyance. Trying and failing to set cycles to max, doesn't recognize standard dosbox command to set, okay I think, I'll just write the conf and see what dosbox-x is doing to set cycles, dosbox-x doesn't recognize standard dosbox writeconf command.. readme? not seeing anything there, built in menu, try setting cycles as "max," runs locked as snail slow, reopen menu, reset/never left "fixed" x cycles. so.. yeah.. perhaps it's me being retarded but it comes off as dosbox-x being retarded left, right and center. What's the super secret members only option for setting max cycles?

Unless something broke the config command, config -writeconf followed by a filename should write the configuration to the file specified. However DOSBox-X by default writes only the settings you changed in that case. To get all settings, use config -all -writeconf filename.

It sounds like you're saying cycles max is broken. Anyone else here confirm this?

EDIT: You may be seeing poor performance as well because DOSBox-X defaults to normal core, other branches may default to dynamic core.

Nope on your edit, dosbox-x says it's using dynamic. edit: selecting show details from the main menu shows variable cycles of 132xxx-150xxx% so would suggest max is working, which would mean dosbox-x is just that slow compared to regular dosbox.

fyi: downloaded from: https://www.emucr.com/2020/07/dosbox-x-v0833-20200630.html
extract & run, then with the built in menu, selecting cpu>core>dynamic core, cpu>edit cycles>backspace delete "fixed 3000," type in max, click OK.
mount dir with phil's dosbench: https://www.philscomputerlab.com/dos-benchmark-pack.html, bench quake timedemo at 640x480.

Just want to add that "config -writeconf filename" or "config -all -writeconf filename" definitely works at this time. In older DOSBox-X versions (before 0.83.2) there were indeed some bugs in the config command, but they apparently have been fixed in recent versions. The editing cycle function (including changing to "max") is also working, but I have not done any benchmark yet.

I was thrown because along with cl "cycles max" not working, setting to max doesn't indicate set as max, these two & being slow I concluded setting to max wasn't working when in actuality it is but is really slow for whatever reason.

DOSBox-X does not allow you to specify config commands on the dosbox-x command line, unless you type "CONFIG" in front of it. So the syntax is "config -set cycles=max", or in the config file, set it as

[cpu]
cycles=max

Or if your using the built-in configuration GUI, make sure you SAVE the settings after modifying them.

_Rob wrote on 2020-07-25, 18:07:

DOSBox-X does not allow you to specify config commands on the dosbox-x command line, unless you type "CONFIG" in front of it. So […]
Show full quote

DOSBox-X does not allow you to specify config commands on the dosbox-x command line, unless you type "CONFIG" in front of it. So the syntax is "config -set cycles=max", or in the config file, set it as

[cpu]
cycles=max

Or if your using the built-in configuration GUI, make sure you SAVE the settings after modifying them.

If you want to specify config options directly from the command line, e.g. "cycles=max", you can do this in DOSBox-X too, just by setting "shell configuration as commands" to "true" in [dos]. Then you can type the following directly from the DOSBox-X command line:

cycles=max

Like I said, tarded.

awgamer wrote on 2020-07-25, 21:05:

Like I said, tarded.

Explain how requiring the user to explicitly use CONFIG to change a setting is "tarded"?

I ran into an issue some time ago where I was trying to run a program with a specific name and it refused to run because the shell kept interpreting it as the name of a setting and printing it's value. I traced it down to that feature and commented it out. But then I was nice enough to add a dosbox.conf option to re-enable it, because I understand DOSBox users might want the original shell behavior, or maybe their dosbox.conf expects it.

Perhaps I should just remove that option (and require using CONFIG), and call the commit the "awgamer change"?

Wow, the nerve of some "awgamer"... *rolls eyes*

DOSBox is an incredibly complex project to modify, there's bound to be some bugs in it. Calm your tits...

Taking a fundamental standard DOSBox command and making it a default disabled config option for a corner case is retarded. On the one side you have the rare occurrence of that one program that conflicted and the microscopic audience that will run it, on the other you have the vastly larger number of DOSBox users using the standard often used DOSBox cycles command, hmm, who to default a config option to and who to break functionality and have go hunt down a solution. I'm guessing the number of people using dosbox-x is small because this would blow up an inbox otherwise.

>DOSBox is an incredibly complex project to modify

Yes, can be a complex project to modify, my contributions sprinkled all throughout the DOSBox code base, this isn't one of them. -Linus Torvalds cantankerous tier DOSBox contributor.

awgamer: I also think it is pretty reasonable to make that feature disabled by default in DOSBox-X, because that is simply not how a real DOS system (MS-DOS, PC-DOS, DR-DOS etc) works, and it can also cause much confusion and name clashes. It might work for vanilla DOSBox because DOSBox is officially for DOS games *only* and it does not have many options there, so the chance of name clash is relatively small. On the other hand, DOSBox-X goes way beyond DOS gaming, and it has so many more features and also gives more options to users to customize the DOS virtual machine, so the chance of name clash with this feature enabled is much higher, and also it is essentially not how a real DOS system works. Please do not expect all DOS emulators to work exactly the same, as they all have their own focuses and priorities (DOSBox-X is not just another fork; it has many goals and features beyond original DOS). However, for users who might want the original DOSBox shell behavior, DOSBox-X already gives an option for them to enable the feature for compatibility purpose, so I think it has already done what it could do (it is possible to add a menu option though to let the users quickly enable this feature from the menu, but it should be disabled by default).

..and as I explained, it's not, and "not how real DOS system works" is meaningless, it's a naming conflict. Just as nonsense is the notion of an ubiquitous use of cycles exe/com/bat outside of games.. no.

awgamer wrote on 2020-07-26, 00:59:

..and as I explained, it's not, and "not how real DOS system works" is meaningless, it's a naming conflict. Just as nonsense is the notion of an ubiquitous use of cycles exe/com/bat outside of games.. no.

You are ignoring the very simple fact: DOSBox-X is a DOS emulator, not a DOSBox emulator. Can you use the “cycles” command in MS-DOS? No! Just to make it easier for you to understand - DOSBox-X cares more about DOS emulation, not DOSBox emulation (even though some kind of backward compatibility for it is available, but not always or guaranteed). Very simple. No more nonsense.

>not a DOSBox emulator.

The stupid, it hurts.

awgamer wrote on 2020-07-26, 01:16:

>not a DOSBox emulator.

The stupid, it hurts.

Does not matter, that is how it works. If you don’t like it, then don’t use it (nobody forced you to use it). Very simple.

Yes, confronted with this many assuredly have arrived at that conclusion, without bothering to mention issues like I have, I'm cantankerous but I'm nice that way.