leileilol wrote:

Hi […]
Show full quote

Hi

Trying to compile dosbox-x's git as of today in mingw errors 'abort was not declared in this scope' on core_normal/prefix_none.h

GCC 4.7.2

I haven't compiled dosbox-x before

my motivation is voodoo related and I want to toy with the Voodoo OpenGL code 😀

Try adding #include <stdlib.h> to core_normal.cpp, core_normal_286.cpp and core_normal_8086.cpp.

On Linux systems at least, abort() is defined in stdlib.h

I have a question about this commit in mainline dosbox:

http://sourceforge.net/p/dosbox/code-0/3904/

I thought CRTC registers on EGA were read-only. I can't speak for Tandy since I never owned one. Are there clone cards that have read-only registers vs other clone cards with read-write registers?

Guys,

I've been thinking about the development of DOSBox-X and it's emulation. As much development as I am doing, I'm genuinely concerned that as I work on the code I might be breaking fragile PCjr and Tandy hardware emulation or other bits of emulation I have no hardware to test. DOSBox/DOSBox-X has a lot of general code with special cases. I'm concerned that while the special cases make DOS games happy, it doesn't actually emulate the hardware well. DOSBox-X intends to make retro-development possible, but that's hard to do if the emulation is misleading.

I think one way to deal with this concern, would be to take DOSBox-X and branch it off into versions that specialize in one particular hardware configuration (many of them, in fact!). Each version would remove code not related to that platform and maintain the code only around it's hardware, system calls, and BIOS. There would be one for Tandy, one for PCjr, one for original IBM 5150 hardware, one for specific 386 systems, etc. There would also be branches that focus on Sound Blaster, VGA chipsets, EGA, etc. The main DOSBox-X branch would continue development as the branch that merges the specialized branch changes back into general code that covers all the bases. The idea is that the specialized branch would be the reference code for emulating that hardware configuration, NOT the main branch. If the main branch continues to be the reference, then readable knowledge of the older hardware gets lost in the mush and that emulation code will only become harder to maintain as the original hardware originally dies. If the specialized branch is the reference code, then the developer can focus only on what his hardware does and not have to worry about any of his changes breaking other hardware emulation in the same codebase.

In other words, improve emulation of specific configurations as separate branches without distraction by all the other configurations. No knotty code to wade through to fix emulation of your specific hardware.

It goes without saying that improvements in the main DOSBox-X master branch might trickle back into the specialized branches too.

Another concern is documentation. In each branch it would be nice if notes, comments, photos, screenshots, video captures, etc. were collected in a Documentation directory, enough to continue developing emulation even after the original hardware dies. I plan on doing the same on my end, recording myself poking and prodding VGA hardware and uploading it to YouTube as well as notes in the source tree. I will be doing the same with old hardware I have as well. I also have the DOSLIB project on my end to test the emulation, the specialized branches would have their own test programs as well. The goal of the test programs is to make sure that both the hardware and the specialized branch of DOSBox act the same way when the program does it's thing. As long as the test programs cover a lot of ground, then emulation will only improve.

Sound good?

I had the feeling for a while now that you are doing too much with Dosbox-x. Meaning that main Dosbox kept to games-only for a good reason and when you came and made Windows 9x much stabler and added much needed ide-controller stuff to a booted Dosbox, I was very glad. Windows 9x gaming is something that I think Dosbox could do very well and nothing really exists for this.
But over time and especially since I follow dosbox-x on github, I feel that you were getting side tracked in what *I* thought you were aiming at. Fixing demos and such seems such a waste of time since to me demos are a one time only "wow" thing, while gaming is something more.
So, please don't get me wrong, your post seemed the perfect oportunity to speak up, but ultimatively it's your project and I think I made heavy assumptions on what *I* wanted it to be not what you are actually aiming at 😉
Anyway thanks for your hard work 😉

Well, demos happen to be good test fodder, especially early demos, because they do so many weird hardware-specific tricks with the DOS machine that they tend to bring out errors in the VGA emulation, or mistakes in the DOS kernel. And despite that I just found out a recent 2015 demo "8088mph" does some really bizarre things to CGA hardware that drives DOSBox's CGA emulation absolutely nuts.

But you're right, I need to get back to Windows 95. I still think a lot of crashiness with Win95 could be avoided if I put work into making the normal core handle page faults and other exceptions non-recursively. I mean in a better way than the hack I made for core=dynamic now. I plan on modifying the normal core so that it either a) completes the instruction or b) leaves CPU state unchanged if a page fault happens during the instruction decode, so that the instruction can be restarted later.

On a related note, can you help me understand why when I run DOSBox with cputype=386, some test programs are mis-identifying the CPU as a NexGen 5x86? Or why cputype=8086 is misdetected as NEC V20 by some programs? I thought it had something to do with the DIV instruction and the carry flag since the "official" test is to divide 5 by 2 to detect 5x86 vs 386, but apparently that's not quite it.

Sorry, can't help with inner Dosbox workings, I only compile snapshots, more code stuff is beyond my knowledge... I'd try to get ripsaw or other members to answer that. Maybe on #dosbox (irc.freenode.net)

TheGreatCodeholio wrote:

And despite that I just found out a recent 2015 demo "8088mph" does some really bizarre things to CGA hardware that drives DOSBox's CGA emulation absolutely nuts.

I reckon trying to emulate that one is mostly a lost cause. I have the impression that you'd need more cycle-accurate emulation than you would ever need for anything else, and that the result would only run very, very slowly. (Whatever tiny handful of programs are left written for the 5150 that people might still want to run, I can't imagine any of them having the same stringent hardware requirements, i.e. nothing but a 5150.) But that's just my feeling.

On a related note, can you help me understand why when I run DOSBox with cputype=386, some test programs are mis-identifying the CPU as a NexGen 5x86? Or why cputype=8086 is misdetected as NEC V20 by some programs?

The obvious question is, "which programs" ?

Have you checked os2museum.com ? There's one post over here:

Note I have seen code fragments which claim the way to distinguish between a 8086/8088 and a NEC V20 (or later) is to use PUSHA followed by STC because the NEC CPUs support the 80186 PUSHA/POPA but the 8086/8088 execute 60h as JMP $+2 (apparently a one-byte jump opcode).

TheGreatCodeholio wrote:

Try adding #include <stdlib.h> to core_normal.cpp, core_normal_286.cpp and core_normal_8086.cpp.

Okay done that, now it complains about 'val' not being defined, and rather cthulhu compiling error messages I can't decipher, etc.

i'm going to assume this will never compile with mingw/msys gcc 4.7.2 and it's for a modern visual studio environment I won't install, despite ./configure checking out all OK.

(I wanted to do texture buffer glsl shaders on all surfaces in OpenGL voodoo to add dithering, and the glsl-based screen filter - i've already made the shaders themselves. tldr: more voodooey voodoo emulation)

The 'val' issue also affected OSX (compiling w/ clang) and has already been fixed in the repo (as of Friday I believe).

TheGreatCodeholio wrote:

From what I understand, nobody in the software world uses anything like DMA from an ISA device to video memory or any other non-system memory, nor would most motherboards support that scenario, since that would mean having to support getting a byte/word through a DMA cycle then having to initiate another ISA cycle to put the data to a device, when it would be much simpler to assume incoming DMA is going to system memory and so on.

Any booter game that uses Int 13 to directly read picture data from floppy diskette into CGA video memory at B8000 will use DMA from the floppy controller (originally an ISA card) to video memory (on another ISA card). BIOS does not buffer the data. Try any Electronic Arts booter and see. The reason it works under mainline DOSBox is that mainline DOSBox's Int 13 emulation does not actually program DMA and floppy controller like a real BIOS would.

Trying to build the current git of DOSBox-x under Visual Studio 2013 Community Edition (just downloaded and installed).

First, I got the error "cannot open include file: 'curses.h'", which I fixed by adding pdcurses-3.4 to the VS2008 folder and adding it to the Additional Include Directories in the C++ section of the dosbox-x properties.

But I still get this error:

>cpu.obj : error LNK2001: unresolved external symbol "int __cdecl CPU_Core8086_Normal_Run(void)" (?CPU_Core8086_Normal_Run@@YAHXZ)

I don't have any idea of how to fix this. Can anyone help? Thanks!

Most of the EGA CRTC registers are write only, according to IBM's Technical Reference. Early Tandy 1000s used a discrete 6845 CRTC and later Tandys integrated almost all of one into a VLSI chip.

Ideally for gaming one needs to emulate four discrete PCs, an IBM PC, an IBM PCjr., a Tandy 1000 and a generic PC. The first three would need to be able to use their proper BIOSes and the PC and Tandy should have configurable graphics options. I suppose you could add an Amstrad PC-1512 and an IBM PS/2 into the mix, but the benefit of that is marginal.

Let's not forget things like PC98 😜

Clipboard pasting for DOSBox-x (probably works for SVN but not tested)

Important: None of the code attached to this message is my own work! I've simply taken over some code from the anonymous author of the dbDOS commercial fork, version 2.0!

As I mentioned in an earlier thread, the dbDOS commercial fork includes a clipboard pasting feature that uses a keystroke to start pasting. Someone who understands C++ could have figured out a long time ago how to take the dbDOS 2.0 clipboard feature and integrate it into standard DOSBox, but I didn't figure it until today. I used the most recent commit of DOSBox-x as the starting point:

https://github.com/joncampbell123/dosbox-x/re … 971e15c20c4.zip

The only file that needed to be modified was sdlmain.cpp. I know I should supply a diff file, but here's a full sdlmain.cpp with the changes indicated by comment lines that look like this:

1// emendelson from dbdos
2...
3// end emendelson

If you replace Jon's sdlmain.cpp with this one, you should get an exe that lets you use Ctrl-Alf-F4 to paste the contents of the Windows clipboard. Obviously, that keystroke is easy to change.

I hope someone might find this useful, perhaps even TheGreatCodeholio...

Remember: This is absolutely not my own work, but the work of the anonymous author of the dbDOS fork!

I came across a problem in this version of DOSBox-X, built under Visual Studio 2013, that isn't relevant to games, but I thought it might be useful to report it:

https://github.com/joncampbell123/dosbox-x/re … 971e15c20c4.zip

I have a project that uses DOSBox to run WordPerfect for DOS in graphic mode; I know that I shouldn't be using DOSBox for purposes like this, but nothing else comes close to doing the job well. (vDos is best for text mode, but it only supports standard VGA graphics.) If I set WordPerfect for DOS 6.2 or 5.1 to use 1280x1024 VESA graphics, and run DOSBox-X in full-screen mode, then DOSBox-X crashes; it works perfectly when DOSBox-x is run in a window. And it works perfectly in full-screen and windowed mode with 1024X768 graphics.

I was able to prevent the crash by setting fullresolution=1280x1024 or fullresolution=original, but I wonder if it's possible to prevent the crash from happening at all.

I don't know if the actual, physical screen size has anything to do with this; I tested it on a 1280x1024 monitor.

Anyway, this may have absolutely no relevance for games, but I thought it might be useful to point it out (or it might not!)

NewRisingSun wrote:

TheGreatCodeholio wrote:

From what I understand, nobody in the software world uses anything like DMA from an ISA device to video memory or any other non-system memory, nor would most motherboards support that scenario, since that would mean having to support getting a byte/word through a DMA cycle then having to initiate another ISA cycle to put the data to a device, when it would be much simpler to assume incoming DMA is going to system memory and so on.

Any booter game that uses Int 13 to directly read picture data from floppy diskette into CGA video memory at B8000 will use DMA from the floppy controller (originally an ISA card) to video memory (on another ISA card). BIOS does not buffer the data. Try any Electronic Arts booter and see. The reason it works under mainline DOSBox is that mainline DOSBox's Int 13 emulation does not actually program DMA and floppy controller like a real BIOS would.

Huh, didn't know that. So perhaps I should add test cases to DOSLIB that allows you to see what happens when DMA is directed at VGA memory vs system memory. I guess I started playing with DOS when booter games had already disappeared and that's why I figured nobody did that. I'm curious if that's only possible on earlier motherboards (pre-386) or if that works on later motherboards that have some separation between CPU, memory, and the ISA bus. That would be interesting to see if Pentium motherboards support ISA DMA directed at VGA memory when the VGA card is on the PCI bus.

emendelson wrote:

Clipboard pasting for DOSBox-x (probably works for SVN but not tested)

Thanks, but since the code seems to be Win32 based, I don't have my Windows 7 system up to test and develop it. It might be better if you git clone'd the master branch and applied it yourself to test, then submitted a diff. I also have a few questions about the code. If it needs the proper delay why just use a fixed counter? Why not enforce a fixed delay using the time (in milliseconds) obtained by GetTicks() to ensure that, for example, keys are spaced apart by at least 100ms? You might also consider using PIC_AddEvent to stuff the keyboard buffer rather than GFX_Event() calls. I'll help stub the functions so that Win32 specific code is not compiled into Linux, Mac. I might be able to figure out how to get equivalent clipboard support in Linux + X-windows (SDL 1.2 doesn't have clipboard functions, unfortunately).

TheGreatCodeholio wrote:

emendelson wrote:

Clipboard pasting for DOSBox-x (probably works for SVN but not tested)

Thanks, but since the code seems to be Win32 based, I don't have my Windows 7 system up to test and develop it. It might be better if you git clone'd the master branch and applied it yourself to test, then submitted a diff. I also have a few questions about the code. If it needs the proper delay why just use a fixed counter? Why not enforce a fixed delay using the time (in milliseconds) obtained by GetTicks() to ensure that, for example, keys are spaced apart by at least 100ms? You might also consider using PIC_AddEvent to stuff the keyboard buffer rather than GFX_Event() calls.

I'll do my best to create a diff and post it. As I said, this isn't my code. I simply lifted it from the dbDOS fork and I don't pretend to understand it or how to change it. If I can create a usable diff, you're welcome to modify it any way you like. I'm afraid I would have no idea of how to implement the changes you suggest. The idea of using keys spaced by at least 100ms is obviously the sensible thing to do.

More after I try to create that diff in Windows 7 64-bit.

I tried to build the current git under Windows 7 64-bit using the community edition of Visual Studio; I added pdcurses-3.4 to the additional include directories, changed afxres.h to windows.h, but (again) got this error when building:

6>cpu.obj : error LNK2001: unresolved external symbol "int __cdecl CPU_Core8086_Normal_Run(void)" (?CPU_Core8086_Normal_Run@@YAHXZ)
6>C:\Users\Edward\Desktop\dosbox-x\vs2008\/..\DOSBox.exe : fatal error LNK1120: 1 unresolved externals

I'll try to build a diff for sdlmain.cpp anyway, but if you have any insight into how to fix this error, I'll be grateful. As I said, I could build with the latest commit, but not with the latest git.

emendelson wrote:

I tried to build the current git under Windows 7 64-bit using the community edition of Visual Studio; I added pdcurses-3.4 to the additional include directories, changed afxres.h to windows.h, but (again) got this error when building:

6>cpu.obj : error LNK2001: unresolved external symbol "int __cdecl CPU_Core8086_Normal_Run(void)" (?CPU_Core8086_Normal_Run@@YAHXZ)
6>C:\Users\Edward\Desktop\dosbox-x\vs2008\/..\DOSBox.exe : fatal error LNK1120: 1 unresolved externals

I'll try to build a diff for sdlmain.cpp anyway, but if you have any insight into how to fix this error, I'll be grateful. As I said, I could build with the latest commit, but not with the latest git.

Well this is probably related to the fact that I added the 286 and 8086 cores after compiling the latest Win32 build. It's possible the VS2008 project files do not yet reference src/cpu/core_normal_8086.cpp. Try adding src/cpu/core_normal_8086.cpp to the project.