TheGreatCodeholio wrote:

SA1988 wrote:

if you want to add optional aha-1540 emulation, I've got the manual and documents about it 😀

Off the top of my head, "AHA-xxxx" means some kind of Adaptec SCSI host adapter? Sure, why not?

For emulations sake, is that chipset on ISA or PCI cards? Are there drivers for it for DOS and Windows 9x?

ISA card, and drivers are available for almost every OS in existence as it was one of the very first SCSI adapters in the world, from 1986/1987.

Datasheet/Manual/Document for complete emulation.
http://files.mpoli.fi/hardware/HDD/ADAPTEC/154XA.ZIP

Cool. That would probably help with the fact that the Windows NT 3.1 installer supports SCSI CD-ROM but lacks support for ATAPI CD-ROM because it predates the standard. The emulation might allow Windows NT 3.1 to be installed straight from the CD-ROM instead of having to copy it to the hard disk image first.

Is there any way to compile dosbox-x with the equivalent of the glide patch? (The one which uses a modified GLIDE2X.OVL and a glide wrapper, not the one that's already in it that directly emulates Voodoo cards with OpenGL.) Using the existing Glide support in dosbox-X I get 10-15 FPS in Tomb Raider Voodoo Rush version, while many years ago with the Glide patch I got over 20 fps on a slower computer.

Alternately, is there some other Dosbox version that I can compile using the Glide patch that is not many years old?

You can apply the glide patch to plain Dosbox SVN

Alternately, does anyone have a prebuilt 32 bit dosbox-X for Mageia Linux 5? I would assume the dynamic core would help with the speed, but I am on a 64 bit system and the dynamic core doesn't exist. Cross-compiling dosbox-x as 32 bit is beyond my expertise.

Edit: Regular SVN with the glide patch does work for me (except for a glitch that I can work around.) I still wonder if I'd be able to get full speed if I run dynamic core.

And another TR question: Is there a way to run Tomb Raider Unfinished Business 3DFX version with the glide support in dosbox-X? For regular Tomb Raider, there seem to be two 3dfx versions, one of which is statically linked and one which uses a separate glide2x.ovl. The statically linked one works with dosbox-X glide support.

However, for Unfinished Business there doesn't seem to be a statically linked version. The only one is one that uses a separate glide2x.ovl. Is there a way to get this to work with dosbox-X? (Note: I cannot get it to work with the dosbox Glide patch, because of a glitch that affects both TR and UB, but which I can't work around for UB.)

Yes, you can use 3dfx glide2x.ovl and it should work.

I have not been able to get UB to work. Is there a particular one I need? If so, what's the size and md5sum of a glide2x.ovl that works? Also, do I need glide2x.dll or is that just for Windows?

Note:
-- I can run tomb.exe (statically linked glide version) with Dosbox-X and it works, proving that I did build and configure Dosbox-X for Glide.
-- I can run this UB executable with plain SVN Dosbox with the Glide patch and it works (except for the glitch), proving that I am indeed using a Glide-enabled UB.
-- Attempting to use Dosbox-X and UB together will run, but won't use Glide. If I actually delete the glide2x.ovl it will not run at all, so the file is seen by Dosbox-X--it just doesn't work. (I did not, of course, use the same glide2x.ovl that is used with the Glide patch.)

Also, Windows 3.1 crashes for me in the most recent Dosbox-X. I used the same installation and the same dosbox.conf that works using SVN plain Dosbox. The machine is svga_s3.

SA1988 wrote:

if you want to add optional aha-1540 emulation, I've got the manual and documents about it 😀

I dumped my AHA-1542CF (both the BIOS and the Z80 microcode) for MESS some months ago, in case someone wants to take a look at it. It should be in every MAME ROMset by now (or I can provide it if neccessary)

Darkstar wrote:

SA1988 wrote:

if you want to add optional aha-1540 emulation, I've got the manual and documents about it 😀

I dumped my AHA-1542CF (both the BIOS and the Z80 microcode) for MESS some months ago, in case someone wants to take a look at it. It should be in every MAME ROMset by now (or I can provide it if neccessary)

ok nice, and looking at the manual I have, I have difficulties emulating the incoming and outgoing mailboxes under emulation of the aha1540.

I'm going to update the Visual Studio project files in my branch to work with the Community edition of VS 2015. Any objections?

well make sure that it is still compatible with at least 2010.

SA1988 wrote:

well make sure that it is still compatible with at least 2010.

Erm... since when has Visual Studio willingly exported project files to an older version of itself? 😀

However, there does seem to be a well known hack, though I'm not sure it works between 2015 and 2010:

http://stackoverflow.com/questions/20486230/h … al-studios-2010

TheGreatCodeholio wrote:

I'm going to update the Visual Studio project files in my branch to work with the Community edition of VS 2015. Any objections?

Absolutely none here! Thank-you GreatCodeholio for doing this, I've been trying for over four months now to try to find a way to compile either daum or this branch with VS 2015. Great going!

Just finished compiling DOSBox-X w/vs2015 this morning. Works Great! One bug to note though, dosbox will not recognize/mount hard disk images larger than 2GB. Has anyone else witnessed this new behavior?

"New behavior" ? I thought that was by design. (2 GB is generally the FAT16 limit.)

No, I know that. What I'm talking about is where you type "imgmount c 'image file' -ide 1m" and instead of mounting it it says "image must be on a host or local drive". This is a new bug since the project was updated to vs2015. It doesn't do this in the latest vs2008 release on github..... The latest commit that allows you to compile on vs2015 does however. If I mount the directory of the image as C with the normal mount command and type DIR, only files (including hdd images) <=2GB are found in that diectory.

Like I said, this bug is here only ever since Codeholio updated from vs2008 to 2015. Tested on both 32/64 bit builds.

Gui55 wrote:

No, I know that. What I'm talking about is where you type "imgmount c 'image file' -ide 1m" and instead of mounting it it says "image must be on a host or local drive". This is a new bug since the project was updated to vs2015. It doesn't do this in the latest vs2008 release on github..... The latest commit that allows you to compile on vs2015 does however. If I mount the directory of the image as C with the normal mount command and type DIR, only files (including hdd images) <=2GB are found in that diectory.

Like I said, this bug is here only ever since Codeholio updated from vs2008 to 2015. Tested on both 32/64 bit builds.

So, Microsoft has decided that their runtime should emulate O_LARGEFILE in Linux? [http://linux.die.net/man/2/open]

To explain, Linux by default denies access to a process if the file is 2GB or larger unless you use O_LARGEFILE. The C library then provides open() and open64(). If you define _FILE_OFFSET_BITS == 64 it uses a #define to map open to open64 for you. This is only done on 32-bit as far as I know, only because so many programmers used int and long for file offsets (one example that comes to mind is the source code to ARJ and the support code in it to compile on Linux). There is similar mapping for lseek/lseek64.

There is also a corresponding fopen() and fopen64() provided by GLIBC in Linux that has the same effect with fseek/fseeko depending on which version you use. You use the newer version if your code uses off_t instead of just int or long.

So the question is: if Microsoft is doing this in their library, what is the alternate form of open/fopen that removes the 2GB limit? There is nothing in their MSDN documentation about this limit or how to remove it. If they don't provide a way out, then I may have to rewrite the code to use lower-level open() and lseek() functions instead and hope that's not where the 2GB limit is imposed. My past cynical experience with Microsoft "helpful" changes like that is that they probably didn't provide a way for fopen() to go past 2GB and they probably don't care, but we'll see.

edit: these comments are based on my observation that at a good portion of the disk image code uses fopen/fseek/fread functions.

edit: I see some report on what they changed, but I don't see anything about fopen() and readdir() unable to see 2GB or larger files: http://blogs.msdn.com/b/vcblog/archive/2014/0 … io-14-ctp1.aspx

Okay. I verified that fopen64() is used in the disk code, so it should work. Now here's where the code falls down in VS2015: the stat() call in dos_programs.cpp line 2359. Apparently in the latest C runtime, stat() refuses to report on files 2GB or larger (again, Microsoft probably learned Linux's trick of needing stat64() and O_LARGEFILE to indicate support for 2GB or larger files).

Now here's the part that I don't understand:

In Linux, when open() does not provide O_LARGEFILE and the file is 2GB, open() returns -1 and sets errno to EOVERFLOW, which makes sense.

Microsoft's runtime just returns an unknown errno value. strerror() then returns "Unknown error".

But the behavior seems sane, since their runtime has several versions of stat() that vary depending on how large time_t is and how large the st_size field is:

https://msdn.microsoft.com/en-us/library/14h5k7ff.aspx

You know, it would really help if you could (for example) provide the errno in question...

I guess it's just a matter of not #defining the right macros everywhere so that part of the runtime is 32bit while another part is 64bit and you get residual stack parameters interpreted as error codes or something. Similar to what happens when you mix the debug and the non-debug versions of the runtime.

I have never seen these errors you're having myself, but then again I haven't switched to 2015 completely yet (only on a VM for testing). fopen() should work on files >2gb without any problems... it would be a major bug otherwise that I'm pretty sure *someone* would have caught during the three RC cycles they made...