gulikoza wrote:

Any chance of providing git repo as well? It helps me check the changes and port the patches to my git tree...

I will make sure to include the .git repo in the next release on Hackipedia. I only stopped doing that because of the sheer size of the tarballs when storing the GIT repo.

SA1988 wrote:

any chance of supporting IBM/MS OS/2 1.x?

I'd like DOSBox-X to support that too! Especially concerning OS/2 1.x which is said to divide by zero on anything faster than a 386----DOSBox-X could sidestep that bug by setting the cycles count lower, instead of following the advice everyone else offers of patching bytes in the floppy image.

However I don't expect that to work for many reasons:

1. OS/2 1.x and 2.x installation requires the use of floppies
2. OS/2 does not use INT 13h, it talks directly to the floppy controller, and DOSBox-X does not yet emulate the floppy controller I/O ports.
3. OS/2 makes heavy use of all CPU privilege rings 0-3, unlike Windows and Linux, that only make use of ring levels 0 and 3 (or ring levels 0 and 1 if Windows 3.0). I have no idea how well DOSBox emulates that since DOS games generally don't care and don't use ring levels, if protected mode is involved at all.

At one time last week, just for the hell of it, I did try to boot OS/2 in DOSBox-X. OS/2 2.0 got as far as the initial blue IBM screen, then crashed with a trap error. OS/2 2.1 showed the OS/2 logo screen briefly before also crashing with a trap error. I believe both crashes are simply OS/2 complaining that it can't detect the floppy controller.

Wine is working in Slax! Abbreviated instructions for installing a special version of Slax (similar to installing DSL linux):
1. download slax-killbill-5.1.8.1.iso
extract files to top dir of hdd image
2. syslinux.com and ldlinux.sys (from syslinux archive in prior post) copied to top dir of hdd image
3. boot a dos floppy image, mount the above hdd image, and run inside dosbox:
lock c:
syslinux -ma c:
4. exit dosbox, rename a file inside the hdd image:
isolinux.cfg to syslinux.cfg
edit lines of syslinux.cfg so the relevant append line appears as below:
label slax
kernel boot/vmlinuz
append vga=785 changes=slaxsave.dat max_loop=255 initrd=boot/initrd.gz init=linuxrc load_ramdisk=1 prompt_ramdisk=0 ramdisk_size=4444 root=/dev/ram0 rw nohotplug nopcmcia acpi=off nocd noagp ramsize=100M autoexec=flux
5. boot hdd image

This version has "wine" v0.9.17 to run Windows apps/games (copied Windows programs to hard disk image so they are accessible via directory /mnt/hda1).

Slax window manager:

Slax "wine" running win32 "Dependency Walker":

Slax "wine" running installation program for a win32 chess client:

Slax "wine" running win32 chess client:

TheGreatCodeholio wrote:

I will make sure to include the .git repo in the next release on Hackipedia. I only stopped doing that because of the sheer size of the tarballs when storing the GIT repo.

10x...I did a quick check with the 20140426 version and you could save some space if you clean up the repo. git fsck reports some dangling trees that don't get packed with git gc. Cleaning that cuts the repo down to about 45MB. The largest remaining files are the *.ncb that have probably been committed accidentally sometime in the past, but are still taking space. Cleaning those would require rewriting history (changes sha sums), but I guess you could probably bring it down to about 15MB or less if you deleted that...

TheGreatCodeholio wrote:

At one time last week, just for the hell of it, I did try to boot OS/2 in DOSBox-X. OS/2 2.0 got as far as the initial blue IBM screen, then crashed with a trap error. OS/2 2.1 showed the OS/2 logo screen briefly before also crashing with a trap error. I believe both crashes are simply OS/2 complaining that it can't detect the floppy controller.

There are numerous ways to virtualize ancient versions of OS/2 at this point, it seems. As per http://www.os2museum.com/wp/?p=2314 , does DOSBox support triple-faulting the CPU?

Jorpho wrote:

TheGreatCodeholio wrote:

At one time last week, just for the hell of it, I did try to boot OS/2 in DOSBox-X. OS/2 2.0 got as far as the initial blue IBM screen, then crashed with a trap error. OS/2 2.1 showed the OS/2 logo screen briefly before also crashing with a trap error. I believe both crashes are simply OS/2 complaining that it can't detect the floppy controller.

There are numerous ways to virtualize ancient versions of OS/2 at this point, it seems. As per http://www.os2museum.com/wp/?p=2314 , does DOSBox support triple-faulting the CPU?

Never tried, yet. I doubt it, to be honest.

Jorpho wrote:

TheGreatCodeholio wrote:

At one time last week, just for the hell of it, I did try to boot OS/2 in DOSBox-X. OS/2 2.0 got as far as the initial blue IBM screen, then crashed with a trap error. OS/2 2.1 showed the OS/2 logo screen briefly before also crashing with a trap error. I believe both crashes are simply OS/2 complaining that it can't detect the floppy controller.

There are numerous ways to virtualize ancient versions of OS/2 at this point, it seems. As per http://www.os2museum.com/wp/?p=2314 , does DOSBox support triple-faulting the CPU?

Hm... based on booting OS/2 1.0, no. I see DOSBox crash from infinite recursion in CPU_Interrupt+CPU_Exception trying to handle exception 0x0D.

And OS/2 v1.1 crashes DOSBox with error message "CPU_SetSegGeneral: Stack segment with invalid privileges"

v1.2 actually seems to work, but gets stuck on a copyright message. DOSBox's debugger shows it's in an infinite loop polling port 0x3F4, which is normally associated with the floppy controller. Which means v1.2 is not going to work in DOSBox anytime soon until I can get floppy controller emulation implemented.

TheGreatCodeholio wrote:

gulikoza wrote:

Any chance of providing git repo as well? It helps me check the changes and port the patches to my git tree...

I will make sure to include the .git repo in the next release on Hackipedia. I only stopped doing that because of the sheer size of the tarballs when storing the GIT repo.

How about a mirror? There's http://repo.or.cz/, if you don't like Github and BitBucket.

How about a mirror? There's http://repo.or.cz/, if you don't like Github and BitBucket.

Done: https://github.com/joncampbell123/dosbox-x

Great, thanks!

Edit: Wow, I hadn't yet looked at the source. The BUGS, NOTES and PLANS directories are gold mines.

Thank you for creating a github project for dosbox-x! It's very simple to follow your rapid progress. For others, I did find a way to construct a "patch" file from each committed change to the dosbox-x tree. I first navigate to the list of commits: https://github.com/joncampbell123/dosbox-x/commits/master. Second, I click on a commit of interest, and the url in the browser will reflect that commit; such as this one: https://github.com/joncampbell123/dosbox-x/co … e90968969dbeb82. Third, I append ".diff" to the url and a patch file opens which is compatible with the "patch" tool.

I typically move the patch compatible diff file to the dosbox directory and type the following to apply the patch: patch -p1 < name_of_patch.diff

This way may work, too:
git diff > name_of_patch.diff

If the patch file includes adds, deletes, or renames, then this is the method of patching source code:
git apply name_of_patch_file

The above git methods do not require an installation of the git package, just the git tool.

-------------------------------
Here is a shortcut for downloading multiple patches (for advanced users without git package):
1. obtain wget, following is Windows version: http://users.ugent.be/~bpuype/wget/
2. copy URLs of each patch url to a text file, such as a file named "urls".
3. from a bash shell: for i in `cat urls`; do wget --no-check-certificate $i.diff; done

I might figure this out when I have free time this weekend... but if anyone can help me with this:

I noticed that when using the dynamic core, throwing a C++ exception doesn't always work, it's like the exception fails to make it up the call stack where try...catch is waiting and the C++ runtime acts as if nobody caught it. The best example was last night when I changed the INT 19h, keyboard, and port 92h reset emulation to throw a C++ exception to force unwinding up the stack back to main. If I was running the dynamic core, the exception never made it back up to the main function and DOSBox aborted with a message about an uncaught exception. When using any other core the exception worked reliably.

Related to that, is that whenever the dynamic core is involved, GDB is not able to do a proper stack trace beyond the point where the dynamically generated code called the callback function. I find it mildly annoying when something goes wrong and I need to determine how it got there.

Somehow, I think the failure for C++ exceptions to make it is related to the inability of GDB (and the C++ runtime) to trace the stack properly through the dynamic core. If the dynamic core could be updated to generate a stack frame that GDB and C++ runtime recognize, that might resolve these issues.

"wd" had insightful posts on the design of the dynamic core, such as this one: Re: Ideas about speeding up the dynrec. I also wonder whether the x86-dynamic and the dynrec cores both show the same issue as described above.

Also, I believe qemu (and perhaps bochs) have a dynarec core which may have hints toward a solution. At least they would have tremendous insight because they must have encountered the above problem a lot, (given their dynarec).

TheGreatCodeholio wrote:

I noticed that when using the dynamic core, throwing a C++ exception doesn't always work, it's like the exception fails to make it up the call stack where try...catch is waiting and the C++ runtime acts as if nobody caught it.

It maybe caused by callback function not use try... catch in SDL callback?
If in callback function want throwing exception to main function , I think it's better set a flag
let main cpu-loop check flag to do such thing.

I searched further using google on these terms: vogons dosbox debug dynamic. Found a few posts on topic, presumably this one addresses the problem with some depth: Dosbox debug - which core?.

wd wrote:

The dynamic core runs code in blocks, so you'll only get a log of the first instruction of the block, which is quite useless (bl […]
Show full quote

The dynamic core runs code in blocks, so you'll only get a log of the
first instruction of the block, which is quite useless (blocks can be
up to 32 instructions).
normal core and full core are fine. Also you can reduce the logging
information by using LOGS instead of LOG, or display more info
with LOGL.

-and-

wd wrote:

Have a look at LogInstruction() in debug.cpp, LOGS tries to keep things
compact, doesn't display FS/GS and omits some flags. LOGL is the most
readable imo (that's why it was added) but generates rather large log files.

I assume that this will not help with use of gdb, but presumably they were debugging in the dynamic core by the dosbox debugger and the above logging method. Also, wd had mentioned the hurdle of debugging a Windows guest OS in dosbox, so this hurdle must be, at least partially, related to the problem you have identified. Is it possible to combine the dosbox debugger along with special logging to identify dosbox errors?

And another post: How can I place breakpoints on 32-bit code of DOS4GW bound executable file?

ripsaw8080 wrote:

If you need to debug while in dynamic core for some reason, find this line in core_dyn_x86.cpp: […]
Show full quote

If you need to debug while in dynamic core for some reason, find this line in core_dyn_x86.cpp:

Copy code to clipboard

1block=CreateCacheBlock(chandler,ip_point,32);

and change the 32 to a 1.

However, you may not need to go through this exercise. I have traced through extender stuff before, and just because a call is executed does NOT mean it returns. Sometimes a call is just a way they push a return address on the stack to figure out who did the calling.

...[if] Ubuntu 64-bit, so you'll probably have to change the line in core_dynrec.cpp

TheGreatCodeholio wrote:

Fixes to the code to compile properly for 64-bit Linux.

Thanx. 😀 Sorry for not responding right away, I was in the process of moving to a new apartment. I need to catch up with the topic and then I'll test the last linux64 friendly version you posted. 😀

I just checked-out the last revision from github and it mostly compiles nicely until this error:

1/home/bocke/Software/source/emulacija/emulatori/dosbox-x/dosbox-x-git/src/hardware/keyboard.cpp:724: undefined reference to `CPU_Core_Dyn_X86_Run()'
2hardware/libhardware.a(memory.o): In function `write_p92':
3/home/bocke/Software/source/emulacija/emulatori/dosbox-x/dosbox-x-git/src/hardware/memory.cpp:649: undefined reference to `CPU_Core_Dyn_X86_Run()'
4ints/libints.a(bios.o): In function `Reboot_Handler':
5/home/bocke/Software/source/emulacija/emulatori/dosbox-x/dosbox-x-git/src/ints/bios.cpp:2452: undefined reference to `CPU_Core_Dyn_X86_Run()'

I remember reading that dynamic_core doesn't work with x86_64 so I tried with "./configure --disable-dynamic-core --disable-dynamic-x86", but without luck (same errors).

I'm going to try the version you posted back in april as a reference. If nothing, I'll compile x86 version for now.

Anyway thanks for the great work. 😀

bocke wrote:

I'm going to try the version you posted back in april as a reference.

Sorry, I won't. I think I remember seeing the post with a corrected x86_64 source, but can't find it right now. Trying to crosscompile from linux64 to linux32 seems to give a lot of type mismatch errors. I'll try compiling under a native linux32 later.

Some references to CPU_Core_Dyn_X86_Run() have been added on Mon May 19. Those should be protected by #if (C_DYNAMIC_X86) / endif.

Thanx Gulikoza, that worked. 😀

The affected files are hardware/keyboard.cpp, hardware/memory.cpp, ints/bios.cpp.

On a related note, maybe configure could automatically set --disable-dynamic-x86 on x86_64?