There is now past self 😁

A nice patch for running in DOSBOX tested at 3000 cycles:

filename: VGA.EXE
sha256sum: 3d1d585e58f8e1f79b49ad3228b9179cde93e25612ce9b31d64f98bb01ec74ea

original
< 00ccc0 08 74 fb eb 0c 90[a0 c6 77 8a 26 c6 77 3a c4 74
< 00ccd0 f8]5d 07 1f 5e 5f 5a 59 5b 58 cb 50 53 51 52 57

patched
> 00ccc0 08 74 fb eb 0c 90[b8 01 00 40 3d ff 30 75 fa 90
> 00ccd0 90]5d 07 1f 5e 5f 5a 59 5b 58 cb 50 53 51 52 57

If your checksum differs search and replace
a0 c6 77 8a 26 c6 77 3a c4 74 f8
with
b8 01 00 40 3d ff 30 75 fa 90 90

Haven't tested this in DOS yet, but it seems the slow down comes from the fade-in fade-out.

Afaict this is an issue with dosbox, it behaves fine in DOS. I have a package ready for any dosbox dev willing to confirm this.

While the version I have has an exe file called VGAB.EXE with the following cheksum, it worked with that one as well! Great finding, that always bothered me before, too! 😀

SHA256: 5AFD9D78966263DD873126B0DFA01F3DF1443CDDEE33BD0637DC80D6EDB84540
CRC32: EAE1A21A

That's great, lets hope they fix it. In the end all we have is dosbox, so better tackle those problems now 😁

Anyone have an idea where to post this issue ? I have a feeling its not going to get picked up from here.

Thanks for the report. The game is looking for specific behavior of bits 6 and 2 of the video status register before it will use the register to wait for retrace. DOSBox does not emulate the bits in question, and as a result the game decides to not wait for retrace. I have thus far not found any info about what the bits are supposed to do, and I know of no other game that cares about them.

Until the seemingly undocumented bits are emulated, at least enough to satisfy the unorthodox test the game is performing, you can get correct speed in DOSBox with a small patch to the game executable. Using a hex editor or the like, search in the executable for the byte pattern 3A C4 75 04 and change 75 to EB. This patch works somewhat better than the previously suggested one because it enables waiting for retrace and is less sensitive to the amount of cycles.

Pizza Worm might have the same issue? The fade-in/fade-out of the main title screen takes much longer than it should under DOSBox.

@ripsaw: Thanks, your patch works like a dream (as always). That assembly path is slow.. but I'm learning.

@jmarsh: I'm keeping an eye out for other games as well.

I don't see any issue with the title screen fade in Pizza Worm; looking at version 2.1G here. However, the speed there does appear to depend on cycles, and it's a real mode game from 1995, so use max cycles or an appropriate amount of fixed cycles.

Bumping this because I've come across a related issue.
Some games exhibit major slow down while polling port 3da in a loop, when running under the dynrec core.
Examples:
- Pizza Worm fade-in/fade-outs
- Keen 4 &5 at their story screens (with the scrolling text)
- Descent credits screen
- Fallout 1 loading screens and movies

The main cause seems to be timer IRQs not being serviced in a timely manner, because when the timer event runs interrupts are disabled. By the time CPU_STI gets executed, CPU_Cycles has been refilled and the dynrec core will happily use up all those cycles before checking for any pending interrupts.
I have tested adding this code to CPU_STI and CPU_POPF:

1	if (GETFLAG(IF) && PIC_IRQCheck) {
2		CPU_CycleLeft += CPU_Cycles-1;
3		CPU_Cycles=1;
4	}

which forces the dynamic core check for interrupts at the next block boundary if an interrupt is pending.

Maybe something like dyn_check_irqrequest() in dyn_x86 would be in order for dynrec?

Technically that's not correct though, STI doesn't enable interrupts on real hardware until the instruction after STI has executed. So there may be cases where STI is followed by LSS or similar which can malfunction if interrupts are immediately serviced.

jmarsh wrote on 2020-11-24, 06:44:

Technically that's not correct though, STI doesn't enable interrupts on real hardware until the instruction after STI has executed. So there may be cases where STI is followed by LSS or similar which can malfunction if interrupts are immediately serviced.

Is it me ? because it seems fixed in the latest svn 😁

Interesting. I would't say that it's so slow that I could make myself some tea in the meantime (I hate coffee 😜), but it's certainly fairly slow.
But anyway... honestly, I find myself unable to complete level 3 without cheating. No way. I only managed to do it when playing the Amiga emulated version (basically, an Amiga-to-Windows quickstart) with in-built cheats.

Nowhere Girl wrote on 2020-12-30, 16:31:

Interesting..... cheats.

PM

Hello, I don´t know nothing about editing hex or checksum, but my game is like the op, slow in the character selction, Is there any patch out there? I don´t know hot to solve this.

Alexis78 wrote on 2024-11-30, 15:05:

Hello, I don´t know nothing about editing hex or checksum, but my game is like the op, slow in the character selction, Is there any patch out there? I don´t know hot to solve this.

Patch is right above you in the thread. Download a hex editor such as "HxD" and make the following changes to the executable.

TheWiredIsUponUs wrote on 2024-11-30, 20:26:

Alexis78 wrote on 2024-11-30, 15:05:

Hello, I don´t know nothing about editing hex or checksum, but my game is like the op, slow in the character selction, Is there any patch out there? I don´t know hot to solve this.

Patch is right above you in the thread. Download a hex editor such as "HxD" and make the following changes to the executable.

Man, If I asked It is because I tried that before and couldn´t succes.

I was using Hex Workshop, a free program to edit. Being positive, what must be the exact *.exe to edit? I have blues. exe, cga.exe and key.exe.
Ok, so I don´t have VGA.EXE, so I must first look for a version of The Blues Brothers (love them!) with vga.exe.
Let´s go.