VOGONS


First post, by Akuma

User metadata
Rank Member
Rank
Member

I just pulled out Blues Brothers, and started playing.
The character select in the beginning is so slow, I could make some instant coffee in between.
This is 'not' present if I load from pure DOS

Is there a fix out there for this ? Please let me know.

Thanks

EDIT: Went from memory instead of actually testing.

Last edited by Akuma on 2019-09-30, 15:31. Edited 3 times in total.

Reply 1 of 14, by Akuma

User metadata
Rank Member
Rank
Member

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.

Reply 2 of 14, by Akuma

User metadata
Rank Member
Rank
Member

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.

Reply 3 of 14, by Yesterplay80

User metadata
Rank Oldbie
Rank
Oldbie

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

My full-featured DOSBox SVN builds for Windows & Linux: Vanilla DOSBox and DOSBox ECE (Google Drive Mirror)

Reply 4 of 14, by Akuma

User metadata
Rank Member
Rank
Member

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.

Reply 5 of 14, by ripsaw8080

User metadata
Rank DOSBox Author
Rank
DOSBox Author

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.

Reply 6 of 14, by jmarsh

User metadata
Rank Oldbie
Rank
Oldbie

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.

Reply 7 of 14, by Akuma

User metadata
Rank Member
Rank
Member

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

Reply 8 of 14, by ripsaw8080

User metadata
Rank DOSBox Author
Rank
DOSBox Author

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.

Reply 9 of 14, by jmarsh

User metadata
Rank Oldbie
Rank
Oldbie

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:

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

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

Reply 10 of 14, by ripsaw8080

User metadata
Rank DOSBox Author
Rank
DOSBox Author

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

Reply 11 of 14, by jmarsh

User metadata
Rank Oldbie
Rank
Oldbie

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.

Reply 12 of 14, by Akuma

User metadata
Rank Member
Rank
Member
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 😁

Reply 13 of 14, by Nowhere Girl

User metadata
Rank Newbie
Rank
Newbie

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.