VOGONS


First post, by Kydnurse

User metadata
Rank Newbie
Rank
Newbie

I was wondering if someone could tell me how to get the text in MM1 to slow down enough for me to read it. I have DosBox running the game just fine, I haven't needed to make any adjustments to make the game run. I tried adjusting the frameskip and cycles to help with slowing down the text, but it dosn't seem to work. Any help would be welcom, just keep in mind I am not dos savvy and please keep it on a kindergarten level 😊

Thanks,
Kydnurse

Reply 1 of 16, by eL_PuSHeR

User metadata
Rank Moderator
Rank
Moderator

What is exactly what you tried? Slowing down DOSBox should be an easy task. The problems arise when you try otherwise... 😁

Hint. Use the slowest core available. I think it's FULL core.
Reduce CPU Cycles.
Use FrameSkip=0

It should slow down as much as you want.

Intel i7 5960X
Gigabye GA-X99-Gaming 5
8 GB DDR4 (2100)
8 GB GeForce GTX 1070 G1 Gaming (Gigabyte)

Reply 2 of 16, by Kydnurse

User metadata
Rank Newbie
Rank
Newbie

I had slowed down the cpu cycles, but I guess not enough (is there such a thing as too slow--I mean enough to hurt my computer?) I got the text to slow down enough to read most of the time. I had to take the cpu cycles below 199 to do that. My Frameskip is 0. I don't know what CORE is or where to find it. (sorry). I am just happy that this game runs!

Thanks for being patient and for your help!
Kydnurse

Reply 3 of 16, by eL_PuSHeR

User metadata
Rank Moderator
Rank
Moderator

Edit dosbox.conf inside your DOSBox folder using notepad. You can then edit it.

Intel i7 5960X
Gigabye GA-X99-Gaming 5
8 GB DDR4 (2100)
8 GB GeForce GTX 1070 G1 Gaming (Gigabyte)

Reply 5 of 16, by MisteRL

User metadata
Rank Newbie
Rank
Newbie

Here is another solution for those people like me who cannot find a satisfactory cycles setting. Open the Hex editor of your choice and change the following three lines in mm.exe:

0000 0860: C3 51 F7 26 DA 00 B9 03  00 D3 E8 8B C8 D1 E8 03
0000 0870: C8 41 51 E8 90 FC 0A C0 78 09 59 E2 F5 B8 00 00
0000 0880: E9 06 00 59 B0 00 E8 C0 FC 50 58 59 C3 FF FF FF

to:

0000 0860: C3 51 89 C1 51 52 B9 00  00 BA 00 04 B4 86 CD 15
0000 0870: 5A 59 90 E8 90 FC 0A C0 78 09 E2 E8 B8 00 00 90
0000 0880: E9 06 00 90 B0 00 E8 C0 FC 50 58 59 C3 FF FF FF

Gives you about 3 seconds (key stroke interrupts) to read the text, regardless of cycle setting. Works on the MM6 Collectors edition version of Might and Magic Book I.

Last edited by MisteRL on 2010-03-16, 21:40. Edited 1 time in total.

Reply 7 of 16, by MisteRL

User metadata
Rank Newbie
Rank
Newbie

I have tried setting the delay to 9 (slowest), but even then I had two choices regarding MM I:

a) I could reduce cycles until the game became unplayable slow and still could barely see the messages.

b) Or I could run the game at acceptable overall speed and not even notice that there were message I missed.

Hence the above patch. In case anyone else should ever run into this problem I have created an executable for easy patch application.

http://www.mediafire.com/?nn2tyyjtljh

Just copy it into the same directory as MM.EXE and execute it from Windows not DOSBox.

Btw., I have played through most of the game with the patch and so far no problems.

Reply 8 of 16, by UndeadHalfOrc

User metadata
Rank Newbie
Rank
Newbie

MisteRL, I just hexedit the offsets you recommended, works great now!

1000 cycles seem to be the best (runs more than fast enough, and you get ample time to read messages)

The game is much more playable now! 😀

How did you discover those offsets?

Reply 9 of 16, by MisteRL

User metadata
Rank Newbie
Rank
Newbie

The DOSBox debugger DOSBox debugger was a great help in finding the delay loop that should have slowed down the messages to readable speed. With this patch it uses the PC timer which is cycle independent and it should even run smooth at max cycles. Currently, I use 2000 for my playthrough and so far it works fine.

Reply 11 of 16, by ripsaw8080

User metadata
Rank DOSBox Author
Rank
DOSBox Author

The game does something a bit odd when calculating the delay factor used later by the delay loop. INT 21h/AH=25h is called to hook INT 24h, and the offset of the handler in the DX register happens to be 39Eh, which is then used as an IO port to read from during the delay factor calculation. AFAICT, 39Eh is an unused port, and the calculation loop reads it 12,330 times while also reading the BIOS timer ticks; so perhaps some kind of IO delay would have an effect. However, it may not be the most important issue.

The message delay loop itself calls a subroutine that calls INT 21h/AH=06h/DL=FFh to read from STDIN, allowing a key press to immediately exit the loop. I have encountered other games that incorporate the code overhead of DOS functions into their timing; and because DOSBox has very little overhead for its internal callbacks, the timing can be perceptibly off. I made a TSR program that adds a 300 cycle delay to all INT 21h calls, and with it the game's message delay is just about right; and the 0-9 delay factor selectable in-game also has a noticeable effect on the delay. Note that I haven't actually counted how many instructions real DOS executes for the function in question, so 300 is just a number I've used with good results on other games that use other functions.

Reply 12 of 16, by MisteRL

User metadata
Rank Newbie
Rank
Newbie

The patch replaces the computation of the delay loop value with the following code:

           ; cx initialization here
l_wait: push cx
push dx
mov cx,0h
mov dx,400h
mov ah,86h
int 15h
pop dx
pop cx
; MM1 read input function here
loop l_wait

@ripsaw8080
Thanks for explaining how the game originally slowed down and why this does not work in DOSBox. I have to admit I was wondering too.

Reply 13 of 16, by Qbix

User metadata
Rank DOSBox Author
Rank
DOSBox Author

ripsaw: does the loop 300 times work as that experiment with reading the dos time ?
I found that io delay in a loop thing as well. I was thinking that maybe an unused port took more cycles than an used port, but that proved to be somewhat of a dead end.

Water flows down the stream
How to ask questions the smart way!

Reply 14 of 16, by ripsaw8080

User metadata
Rank DOSBox Author
Rank
DOSBox Author

@Qbix: Yes, it's the same kind of thing as with Robomaze and INT 21/2C. I made a TSR that applies to all functions of INT 21 as a way to quickly test if timing issues are related to the function overhead. The 300 cycle delay is what I used for INT 21/2C, because I counted the instructions executed for that function; but better results would be obtained for function 06 by using a more accurate count of instructions (cycles). The program and source are attached; change the loop counter in CX to vary the amount of cycles added to the function calls.

EDIT: I counted the instructions for INT 21/06/FF when no key is available, and it's around 325, so 300 isn't that far off. However, DOS calls BIOS (INT 16) to check for keys, and there is instruction overhead in that as well on real systems.

Attachments

  • Filename
    SLOW21.ZIP
    File size
    628 Bytes
    Downloads
    410 downloads
    File license
    Fair use/fair dealing exception

Reply 15 of 16, by Qbix

User metadata
Rank DOSBox Author
Rank
DOSBox Author

www.gog.com/en/forum/might_and_magic_se ... s_too_fast
More people are happy with it

Water flows down the stream
How to ask questions the smart way!

Reply 16 of 16, by ripsaw8080

User metadata
Rank DOSBox Author
Rank
DOSBox Author

Adding a realistic amount of cycles to the function won't help much for people who are trying to run the game at the default 3000 cycles. If the function overhead is ever implemented in DOSBox, it will only create a reasonable delay at lower cycles (as a game from 1987 should be using), and then all of the game should play at more-or-less accurate speed, not just the messages.