VOGONS

Common searches


DOSBox-X branch

Topic actions

Reply 2142 of 2397, by TheGreatCodeholio

User metadata
Rank Oldbie
Rank
Oldbie

I have a question about Tandy, PCjr, and INT 12h and the "BIOS memory size" in the BIOS data area.

This is a discussion on DOSBox-X about whether Tandy mode should report 608KB (32KB off the top) of 624KB (16KB off the top as SVN does now).

Apparently some games require the 16KB off the top to work properly, even though they then utilize the 16-color modes that require 32KB off the top.

The question is: Does Tandy/PCjr always report system memory size minus 16KB? Or does INT 10h change the reported size in the BIOS data area according to video mode? Meaning, if you set text/CGA modes, it sets the size in the BDA to total minus 16, and if you set Tandy/PCjr modes that need 32KB, sets the size to total minus 32.

Or maybe the value in the BDA is the system total and INT 12h subtracts video memory size?

Or maybe the value in the BDA is the system total minus 16, and INT 12h subtracts an additional 16KB in Tandy modes?

Or maybe it's always set to total minus 16 and MS-DOS is supposed to adjust the MCB chain accordingly on INT 10h?

I could easily just hack in what I know, but I'd rather do what the real thing does to get these games to work.

I have a Tandy and a PCjr, I just need to get them out of storage and find the CGA to VGA adapter as well.

https://github.com/joncampbell123/dosbox-x/is … mment-804956006

DOSBox-X project: more emulation better accuracy.
DOSLIB and DOSLIB2: Learn how to tinker and hack hardware and software from DOS.

Reply 2143 of 2397, by mothergoose729

User metadata
Rank Oldbie
Rank
Oldbie
Bruninho wrote on 2021-02-10, 13:07:

Yeah, no glide for me then. almeath's files are for 32-bit version of Intel macOS 10.4.x, what we need is 64 bit version for Intel Macs on Catalina and above (I'm on Big Sur).

I'm a little late, but here you go. I was able to get glide pass thru working recently by downloading nglide, unpacking the executable with 7zip, and placing the files in the same directory as dosbox. Then I made sure that the 32bit "SDL1" version was the executable I was actually running. Seems to work ok. You can use the configurator for nglide to do things like fullscreen and select your resolution, ect.

I have to run dosbox in windowed mode because none of the scaling options seem to work properly, but when glide starts it goes fullscreen.

If you want to use dosbox x for windows then you will need to place the glide2.dll file in your VM system folder, or what I do is put it in the same directory of the game I am trying to run. It isn't worth much to do that right now though because the performance is pretty bad. The lack of proper MMX makes running most 9x games pretty hard.

Reply 2144 of 2397, by ripsaw8080

User metadata
Rank DOSBox Author
Rank
DOSBox Author

Some observations I made years ago with Tandy 1000 BIOS and Tandy DOS 3.30 in PCEm:

When configured for 640 kB of memory: the word at 40h:13h (memory size) is 270h (624 kB), the word at 40h:15h (true memory size) is 280h (640 kB), and these memory values do not vary as the result of video mode changes.

INT 12h only returns the word at 40h:13h (memory size) in AX, nothing more.

The -16 kB memory size behavior of BIOS appears to relate to the amount of system memory, but it is done for 640 kB which is what official DOSBox supports. However, it's possible that some games were only tested on specific memory configurations and do not adapt correctly for 640 kB.

In testing, Ghostbusters needed memory size of 624 kB for graphics to work correctly. Being a booter, DOS is of course not involved. If DOS does react to the graphics memory region in some way then I suspect it would only be in MCB management, not in modifying BIOS data (that would be hack-ish).

The 624 kB memory size definitely seems strange to me because switching to graphics mode can destroy the DOS MCB chain if any headers happen to be high up in memory. Some (if not all) games seem to be careful not to tread on this "common area" between system and graphics memory, but some cracked boot disk games locate their INT 13h handlers at the top of memory, setting the stage for a crash when a Tandy system switches to graphics mode, but those cracks were likely only tested on an IBM PC.

Reply 2145 of 2397, by BloodyCactus

User metadata
Rank Oldbie
Rank
Oldbie

as someone who has a 1000sx and wrote a util to manage the graphics memory, only the word at 0x413 changes.

any game that assumes > 16kb will destroy any MCB headers. you need to run a util to set it to 32kb or more like first thing (and they work by modifying the MCB chain headers).

--/\-[ Stu : Bloody Cactus :: [ https://bloodycactus.com :: http://kråketær.com ]-/\--

Reply 2146 of 2397, by TheGreatCodeholio

User metadata
Rank Oldbie
Rank
Oldbie
BloodyCactus wrote on 2021-03-23, 21:09:

as someone who has a 1000sx and wrote a util to manage the graphics memory, only the word at 0x413 changes.

any game that assumes > 16kb will destroy any MCB headers. you need to run a util to set it to 32kb or more like first thing (and they work by modifying the MCB chain headers).

INT 10h will change memory size at 0x413 to either (true memory size - 16KB) or (true memory size - 32KB), right?

And MS-DOS does nothing about the MCB chain, basing it on the (true memory size - 16KB) reported at system startup?

Or is Ripsaw right and INT 10h does not change anything, and INT 12h and 0x413 always report (true memory size - 16KB)?

DOSBox-X project: more emulation better accuracy.
DOSLIB and DOSLIB2: Learn how to tinker and hack hardware and software from DOS.

Reply 2147 of 2397, by BloodyCactus

User metadata
Rank Oldbie
Rank
Oldbie
TheGreatCodeholio wrote on 2021-03-24, 00:38:

INT 10h will change memory size at 0x413 to either (true memory size - 16KB) or (true memory size - 32KB), right?

int 0x10 is bios. DOS does not hook int 10h and will not change the memory based on video mode change. I have tandy dos 3.3 and I dont remember it doing that, and I know dos 5/6 do NOT do that.

int 0x10 does nothing to address 0x413 on my tandy 1000sx

when tandy boots, its bios sets it to ALWAYS be -16kb because there are no bios settings, it can never change on bootup, it is always -16kb from top of real memory.

TheGreatCodeholio wrote on 2021-03-24, 00:38:

And MS-DOS does nothing about the MCB chain, basing it on the (true memory size - 16KB) reported at system startup?

DOS builds its MCB chain on startup from the BIOS setting, the tandy bios sets it to 16kb when it initializes on power up.

TheGreatCodeholio wrote on 2021-03-24, 00:38:

Or is Ripsaw right and INT 10h does not change anything, and INT 12h and 0x413 always report (true memory size - 16KB)?

when tandy starts up it sets 0x413 as -16kb of real size.
int 0x12 reports that value. that value can change (ie: using my tandy gfx ram utility).

int 0x10 does not change the value at 0x413.

any game using tandy 320x200x16 colour mode uses 32kb ram, if the top of memory + MCB's are set incorrect, that game will corrupt DOS and crash.

--/\-[ Stu : Bloody Cactus :: [ https://bloodycactus.com :: http://kråketær.com ]-/\--

Reply 2148 of 2397, by ripsaw8080

User metadata
Rank DOSBox Author
Rank
DOSBox Author
BloodyCactus wrote on 2021-03-24, 01:22:

when tandy boots, its bios sets it to ALWAYS be -16kb because there are no bios settings, it can never change on bootup, it is always -16kb from top of real memory.

According to the BIOS code, it seems that 16 kB is NOT subtracted if an EGA or VGA card is installed, which does make some sense. However, it makes no difference in DOSBox, where the combination is not (yet) possible.

Reply 2149 of 2397, by TheGreatCodeholio

User metadata
Rank Oldbie
Rank
Oldbie
ripsaw8080 wrote on 2021-03-24, 05:53:
BloodyCactus wrote on 2021-03-24, 01:22:

when tandy boots, its bios sets it to ALWAYS be -16kb because there are no bios settings, it can never change on bootup, it is always -16kb from top of real memory.

According to the BIOS code, it seems that 16 kB is NOT subtracted if an EGA or VGA card is installed, which does make some sense. However, it makes no difference in DOSBox, where the combination is not (yet) possible.

I appreciate the help guys, I was able to update DOSBox-X to emulate the described behaviors, and then I was able to fix the code so that the PCjr and Tandy modes can emulate less than 640KB of conventional memory. PCjr and Tandy games should run properly in DOSBox-X again. One game "Mickey's Space Adventure", calls INT 12h, subtracts 16KB, and then converts from KB to paragraphs and uses that as the segment to draw to. That behavior absolutely requires the (total - 16KB) behavior. The same game, if run in PCjr mode, requires that you configure DOSBox-X to emulate a PCjr with 128KB of RAM. If there is any extra RAM past the base 128KB, the game will corrupt itself and crash because of said behavior, because unlike Tandy, the PCjr system memory mapped as video is always at the top of the 128KB.

DOSBox-X project: more emulation better accuracy.
DOSLIB and DOSLIB2: Learn how to tinker and hack hardware and software from DOS.

Reply 2150 of 2397, by ripsaw8080

User metadata
Rank DOSBox Author
Rank
DOSBox Author

A solution for Mickey's Space Adventure, and similarly afflicted games, with machine=pcjr in official source is to use a LOADFIX -88 command. It allocates the memory below the PCjr's video memory window, forcing the program image to load above the window.

Reply 2151 of 2397, by TheGreatCodeholio

User metadata
Rank Oldbie
Rank
Oldbie
ripsaw8080 wrote on 2021-03-24, 06:17:

A solution for Mickey's Space Adventure, and similarly afflicted games, with machine=pcjr in official source is to use a LOADFIX -88 command. It allocates the memory below the PCjr's video memory window, forcing the program image to load above the window.

I fail to see how that fixes the game. DOSBox SVN emulates a PCjr with full 640KB of RAM, right? That means the BIOS data area and INT 12h indicate 640KB of RAM.

In the linked issue tracker, I found that the game determines what segment to write using INT 12h and subtracting 16KB. The PCjr video memory is just under the 128KB mark, so writing to 640KB - 16KB or 624KB - 16KB isn't going to solve that in PCjr mode.

DOSBox-X project: more emulation better accuracy.
DOSLIB and DOSLIB2: Learn how to tinker and hack hardware and software from DOS.

Reply 2152 of 2397, by ripsaw8080

User metadata
Rank DOSBox Author
Rank
DOSBox Author
TheGreatCodeholio wrote on 2021-03-24, 06:32:
ripsaw8080 wrote on 2021-03-24, 06:17:

A solution for Mickey's Space Adventure, and similarly afflicted games, with machine=pcjr in official source is to use a LOADFIX -88 command. It allocates the memory below the PCjr's video memory window, forcing the program image to load above the window.

I fail to see how that fixes the game. DOSBox SVN emulates a PCjr with full 640KB of RAM, right? That means the BIOS data area and INT 12h indicate 640KB of RAM.

In the linked issue tracker, I found that the game determines what segment to write using INT 12h and subtracting 16KB. The PCjr video memory is just under the 128KB mark, so writing to 640KB - 16KB or 624KB - 16KB isn't going to solve that in PCjr mode.

The game calls INT 12h for the Tandy machine, it does not for the PCjr machine. Games with PCjr-specific graphics support tend to use the video memory window at segment 1800h, which does not vary in location.

Reply 2153 of 2397, by BloodyCactus

User metadata
Rank Oldbie
Rank
Oldbie

Right, PCJR and Tandy are not the same with graphics ram.

pcjr has its video memory at a fixed location, not matter how much base ram you had! (always at 128kb). tandy always moved it at top of ram.
pcjr triggers irq5 for every vertical retrace , tandy does the same and uses irq 2 for hard drives which was a pain, but the 1000SX has a dipswitch to disable IRQ5 video retrace.

--/\-[ Stu : Bloody Cactus :: [ https://bloodycactus.com :: http://kråketær.com ]-/\--

Reply 2154 of 2397, by Wengier

User metadata
Rank Member
Rank
Member

almeath:

As you mentioned earlier DOSBox-X performed slower than SVN for your games in macOS, unfortunately. There are many libraries used by DOSBox-X, but I am sure the performance issue has nothing to do with this patch. You can take as many libraries or features from DOSBox ECE or DOSBox-X into your own build as you want to suit your needs.

P.S. The DOSBox-X Team will eventually find out the exact cause for the said performance issue, although this may take some time. Having a goal of implementing emulations in a complete and accurate manner never stops us from trying to improve the performance too, of course. Porting the dynamic_x86 core from SVN to DOSBox-X 0.83.7 was a very good example of such efforts.

Last edited by Wengier on 2021-04-13, 21:39. Edited 1 time in total.

Reply 2155 of 2397, by almeath

User metadata
Rank Member
Rank
Member
Wengier wrote on 2021-04-07, 05:09:

As you mentioned earlier DOSBox-X performed slower than SVN for your games in macOS, unfortunately. There are many libraries used by DOSBox-X, but I am sure the performance issue has nothing to do with this patch. You can take as many libraries or features from DOSBox ECE or DOSBox-X into your own build as you want to suit your needs.

P.S. The DOSBox-X Team will eventually find out the exact cause for the said performance issue, although this may take some time. Having a goal of implementing emulations in a complete and accurate manner never stops us from trying to improve the performance too, of course. Porting the dynamic_x86 core from SVN to DOSBox-X 0.83.7 was a very good example of such efforts.

Thanks, I appreciate all the work you put into the DOSBox-X branch, and I still use it for certain specific purposes. I fall back to SVN when I need the raw speed, and I have also enjoyed progressively working my favorite ECE and X patches into it. Staging has diverted too far from SVN (different coding) which precludes me from incorporating others that I find interesting, such as the extensive improvements to Gravis Ultrasound. On the speed issue, I am really at a loss to explain it, as I have a 9900k system and I highly doubt it gets bogged down in any way, so there must be something specific hiding somewhere in the code. As mentioned on the Github site, I am always happy to help with further testing. Happy to take this up in the DOSBox-X sub-forum as well.

DOSBox SVN for macOS (x86-64) - customized with Munt MT-32, Nuked OPL3, 3dfx Voodoo, Extra RAM, Large HD, and more.
https://github.com/almeath/DOSBox-SVN-64-bit-for-macOS

Reply 2156 of 2397, by jmarsh

User metadata
Rank Oldbie
Rank
Oldbie

All the stuff DOSBox-X added to the dynamic_x86 core to "handle page faults" is mostly nothing but a huge slowdown. Nearly all memory accesses performed by that core (dyn_read_byte/write_byte/read_word/write_word) already handle faults correctly and the remaining opcodes that can cause problems (pusha, popa, etc) are still unfixed. My suggestion would be to rip the whole lot out, if there's anything that it does actually fix it can be implemented in a more optimal way.

Reply 2157 of 2397, by TheGreatCodeholio

User metadata
Rank Oldbie
Rank
Oldbie

I just made a commit to DOSBox-X that adds COLOR_CMP to S3 XGA emulation. I'm not sure if anything in Windows 3.1 or DOS uses it, but it helps Windows 95 DirectX games do their color key based 256-color transparency BitBlts. Think DOSBox SVN could use it?

https://github.com/joncampbell123/dosbox-x/co … fee0297a50d9d21

https://github.com/joncampbell123/dosbox-x/co … d3c5fea5d55f82f

https://github.com/joncampbell123/dosbox-x/issues/2418

DOSBox-X project: more emulation better accuracy.
DOSLIB and DOSLIB2: Learn how to tinker and hack hardware and software from DOS.

Reply 2158 of 2397, by ripsaw8080

User metadata
Rank DOSBox Author
Rank
DOSBox Author

I haven't seen any Windows 3.x games that use the COLOR_CMP feature, at least not yet.

Related to DOSBox's emulation of S3 hardware acceleration, in various Win3 dialogs an "Unhandled draw command 3" log message occurs, which according to the Trio 64 spec is "poly fill solid". The absence of support for the command and associated coordinate register values may cause some Win3 dialogs to not appear exactly as intended, though I don't notice anything that looks wrong, and the paintbrush tool in the Paintbrush app included in Win3 draws nothing. In addition to draw command 3 there are a bunch of other draw commands on the Trio 64 that were apparently not carried over to the Trio V64+, which may be why they weren't implemented in DOSBox, but so far I only know of command 3 cases.

Reply 2159 of 2397, by TheGreatCodeholio

User metadata
Rank Oldbie
Rank
Oldbie
ripsaw8080 wrote on 2021-04-08, 08:54:

I haven't seen any Windows 3.x games that use the COLOR_CMP feature, at least not yet.

Related to DOSBox's emulation of S3 hardware acceleration, in various Win3 dialogs an "Unhandled draw command 3" log message occurs, which according to the Trio 64 spec is "poly fill solid". The absence of support for the command and associated coordinate register values may cause some Win3 dialogs to not appear exactly as intended, though I don't notice anything that looks wrong, and the paintbrush tool in the Paintbrush app included in Win3 draws nothing. In addition to draw command 3 there are a bunch of other draw commands on the Trio 64 that were apparently not carried over to the Trio V64+, which may be why they weren't implemented in DOSBox, but so far I only know of command 3 cases.

We must be using different drivers then, Paintbrush works fine here. I'm using drivers for the older S3 Vision864 boards, I think.

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

DOSBox-X project: more emulation better accuracy.
DOSLIB and DOSLIB2: Learn how to tinker and hack hardware and software from DOS.