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.

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

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

It seems to be working well now. Thanks for your help!!

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:

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

to:

10000 0860: C3 51 89 C1 51 52 B9 00  00 BA 00 04 B4 86 CD 15
20000 0870: 5A 59 90 E8 90 FC 0A C0  78 09 E2 E8 B8 00 00 90
30000 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.

Don't forget that while inside combat, you can change the DELAY by pressing D.

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.

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?

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.

got to check the asm in both cases to see how the calibrates itself.

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.

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

1           ; cx initialization here
2l_wait: push cx
3           push dx
4           mov cx,0h
5           mov dx,400h
6           mov ah,86h
7           int 15h
8           pop dx
9           pop cx
10           ; MM1 read input function here 
11           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.

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.

@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.

http://www.gog.com/en/forum/might_and_magic_s … ppears_too_fast
More people are happy with it

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.