leileilol wrote:

That's a standard header and MinGW or MSVC should come with it.

It's an MFC header, so not included in MSVC express.

http://stackoverflow.com/questions/3566018/ca … -vc2010-express

emendelson wrote:

Synoptic wrote:

Trying to build today's release : #include "afxres.h" not found in wines.rc

the file is indeed absent from the branch.

replace "afxres.h" with "windows.h" and try again.

Worked.
I am using VS 2013.

Following up on one of the changes merged from mainline DOSBox, I have a change in my branch that fixes ripsaw's hercules memory map fix that might be useful to implement.
I think ripsaw's change ultimately breaks the HGC graphics mode in favor of DOS programs that assume 4K mapping in non-graphics modes.

I don't have a hercules card on hand to test, but I do have this reference:

http://www.seasip.info/VintagePC/hercplus.html

I haven't found any broken games, possibly because they tend not to use 32kB mode for graphics, but I do see the potential problem. However, I think using only the graphics enable bit is not correct.

This seems to work correctly based on my testing with various games and CGA emulators (SIMCGA and Magic Key), but I'd like to get it checked on hardware because I don't know how flexible real cards might be with the upper 32kB in text mode:

1    case MCH_HERC:
2        vgapages.base=VGA_PAGE_B0;
3        if (vga.herc.enable_bits & 0x2) {
4            vgapages.mask=0xffff;
5            MEM_SetPageHandler(VGA_PAGE_B0,16,&vgaph.map);
6        } else {
7            vgapages.mask=0x7fff;
8            /* With hercules in 32kb mode it leaves a memory hole on 0xb800 */
9            if (vga.herc.mode_control & 0x2)
10                MEM_SetPageHandler(VGA_PAGE_B0,8,&vgaph.map);
11            else
12                MEM_SetPageHandler(VGA_PAGE_B0,8,&vgaph.herc);
13            MEM_SetPageHandler(VGA_PAGE_B8,8,&vgaph.empty);
14        }
15        goto range_done;

Alternatively, the problem with the Delphine installers may be fixed by giving the Hercules machine more actual pages instead of switching the memory mapping around, but again it needs to be tested on a real card:

1     case M_HERC_TEXT:
2-        if (machine==MCH_HERC) vga.draw.linear_mask = 0xfff; // 1 page
3+        if (machine==MCH_HERC) vga.draw.linear_mask = 0x7fff; // 8 pages

Hi. I've got two questions, both of which may just be because of my lack of knowledge but I'll ask them anyway. Excuse me if these have already been answered and I just didn't see.

Firstly, does this still compile in Windows using MinGW, because it's just not happening for me? A lot of "not declared in this scope" errors, which I can fix but it runs into other problems that I haven't been able to work around. Is there just something wrong with the way I'm compiling? Dosbox SVN does compile properly.

Secondly. Is the OpenGL renderer currently broken? Ykhwong's last build works, but the last release on the Github page and my Visual Studio build produce "No support for texturesize of 1024, falling back to surface" errors. I can change the code to remove the possibility of falling back to surface and then it works, but with a few glitches. This is using a Geforce GTX 780 Ti.

AFAIK OpenGL got removed in Dosbox-x

yes but I later put the OpenGL code back for 3Dfx emulation.

I normally compile with either Linux+gcc or Win7+Visual Studio 2008. Haven't tried MinGW.

Silanda wrote:

Is the OpenGL renderer currently broken? Ykhwong's last build works ...

Not really. In ykhwong's last two Daum builds the aspect ratio gets distorted when using OpenGL scaling. I don't know if the problem is in DOSBox-X or ykhwong's code, though.

Hello,

I have a question about DMA emulating in DosBox (DosBox-X). For didactical purposes, I have to demonstrate the functionality of DMA channels programming. Specifically, I want to write the video memory with some (arbitrary) data through DMA channel 0. I didn't succeed with DOsBox, neither with DosBox-X. Can you tell me if this version of DosBox supports this kind of DMA emulating ? Thank you.

Here is the code I wrote:

mov ax,3 ; video mode
int 10h

mov al,0fh
out 0dh,al ; reset DMA

mov al,100b
out 08h,al ; command register: deactivating DMA

mov al,94h ;1001.0100b
out 0Bh,al ; mode register: channel 0, write mem, autoinit, incr.address, block transfer mode

mov al,0fh
out 0fh,al ;mask register - mask channels 0,1,2,3

mov al,0Bh
out 87h,al ;page register

mov al,00h
out 00h,al ; initial address register
mov al,80h ; so the initial addres is: B.8000h
out 00h,al

mov al,0feh
out 01h,al ; initial counter register
mov al,0ffh
out 01h,al

mov al,00h
out 0fh,al ;unmask channels 0,1,2,3

mov al,00b
out 08h,al ; command register: activate DMA

mov al,0100b
out 09h,al ;request register: starting data transfer

...but nothing happens in the video memory

Victor_76 wrote:

Hello,

I have a question about DMA emulating in DosBox (DosBox-X). For didactical purposes, I have to demonstrate the functionality of DMA channels programming. Specifically, I want to write the video memory with some (arbitrary) data through DMA channel 0. I didn't succeed with DOsBox, neither with DosBox-X. Can you tell me if this version of DosBox supports this kind of DMA emulating ? Thank you.

...but nothing happens in the video memory

Hm... first of all, DOSBox/DOSBox-X is written primarily for DMA that goes to/from system memory and a device, not video RAM and a device. I've honestly never tried that scenario. 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.

There is one scenario I can think of that might work but I have no idea if it actually does: if your code will be running on anything between a Pentium and Pentium III with both ISA and PCI slots. I *think* some Intel PCI-ISA bridges *might* support incoming ISA DMA that can be translated to PCI cycles and directed to a PCI VGA card, I'm not sure. Such chipsets might simply have the same limitation of "it must be system memory". It would have to be a chipset made prior to the removal of ISA DMA signalling. This is territory I've not yet explored on PC hardware.

Second, what ISA device will be providing data on DMA channel 0? If I were you, I would try such code through DMA channel 1 instead, then have the code initiate auto-init DMA recording from a Sound Blaster card and see if anything shows up in VRAM. If it actually works you should see garbage on your screen that loosely resembles whatever your sound card is picking up from it's inputs. But test it first by directing it towards system RAM to make sure the DMA is actually moving. But, like I said, I highly doubt any motherboard chipset would support the extra work to cycle DMA from one ISA device to another like that.

Perhaps this is good test fodder to add to DOSLIB.

Create an aur package for the GIT version of dosbox-X branch. My username is winstonwu91

https://aur.archlinux.org/packages/dosbox-x-git/

This should be merged with the main branch of DosBox. Why should I have to have 10 different copies of DosBox residing on my computer, each one carrying a feature that SHOULD be in the main branch, but apparently the official developers decided not to put in?

videogamer555 wrote:

This should be merged with the main branch of DosBox. Why should I have to have 10 different copies of DosBox residing on my computer, each one carrying a feature that SHOULD be in the main branch, but apparently the official developers decided not to put in?

Well... DOSBox has different goals than DOSBox-X. It's been stated pretty clearly on these forums that DOSBox (the main branch) cares only about getting DOS games to run. DOSBox-X cares more about accurately emulating the hardware and documenting what PC hardware is like through emulation, and for retro-coding. Daum's branch I'm sure has it's own general agenda and goals.

I'd rather see an open source project like DOSBox develop in the form of several concurrent branches that borrow from one another, than as one branch that everyone has to fight over to get the feature or bugfix they want implemented. As concurrent branches everyone gets what they want to add out of it while helping DOSBox as a whole develop further.

TheGreatCodeholio wrote:

Well... DOSBox has different goals than DOSBox-X. It's been stated pretty clearly on these forums that DOSBox (the main branch) cares only about getting DOS games to run. DOSBox-X cares more about accurately emulating the hardware and documenting what PC hardware is like through emulation, and for retro-coding.

The best way to make sure that games run as intended, is to emulate the hardware that the games had to run on, as correctly as possible. Don't take any shortcuts, or make optimizations in the software that makes the software be less accurate in emulating the hardware. That sounds like what DosBox X is going for. And because (as I stated) that is ultimately the BEST way to emulate even for GAMES (which is what the main branch of DosBox is going for), then it seems that the X version and the normal version of DosBox actually both have the SAME GOAL (just worded slightly differently). Yes, fewer optimizations in the software means it is going to take a lot more CPU power to run, than if accuracy was sacrificed in order to make optimizations. But on modern PC's that extra CPU load shouldn't be a problem, as modern CPUs are BLAZING FAST.

Ideally, every piece of hardware inside the case of a PC would be emulated in software with some code, so that the real-time-clock, crystal-oscillator, CPU, BIOS, ISA-bus, serial-port, parallel-port, PS2 mouse port, Keyboard-port, etc, absolutely EVERYTHING found in an old DOS-running PC would be emulated in the software.

To emulate a keyboard for example, a keyboard would NOT just be assumed to be connected. Instead you'd select from a menu "plug in keyboard" and the software's code that represented the emulated keyboard, would be "connected" to the software's code that represented the emulated computer's PS2 port and interface circuits that connect the PS2 port to the CPU. All the signal paths in the emulated computer would carry data (via software code in the emulator), in the same way that real signal paths would actually carry data in a physical computer.

videogamer555 wrote:

That sounds like what DosBox X is going for.

Not really, no.

And because (as I stated) that is ultimately the BEST way to emulate even for GAMES (which is what the main branch of DosBox is going for)

DOSBox-X is not substantially better at running any games than regular DOSBox.

videogamer555 wrote:

Ideally, every piece of hardware inside the case of a PC would be emulated in software with some code, so that the real-time-clock, crystal-oscillator, CPU, BIOS, ISA-bus, serial-port, parallel-port, PS2 mouse port, Keyboard-port, etc, absolutely EVERYTHING found in an old DOS-running PC would be emulated in the software.

Has it not occurred to you that there are other emulators out there designed with such accuracy in mind? MESS, Bochs, and PCem, for instance.

You will find that in the case of something like Bochs that the extra CPU load is in fact quite severe. An increasingly famous but tangentially related example is BSNES, which aims for cycle-accurate emulation of a system running a 3.58 MHz 16-bt CPU – and will not run at full speed on anything but the fastest of systems.

DOSBox's architecture has one thing I like that helps emulation a lot and that is the event-based timing. The PIC event code allows for very accurate timing while not dragging down emulation speed. This I think is what allows DOSBox to do such accurate sound and video emulation at a reasonable speed on today's CPUs. It's "good enough" emulation that still runs at a good reasonable speed.

videogamer555, I have thought of writing an emulator that emulates the hardware down to the hardware level, like when the CPU fetches a byte from the ISA bus, there's literally a struct that holds boolean values representing the 100 or so pins of the ISA bus connector, and changing the boolean value triggers a message to one or more C++ classes to act on the change (also following a timestamp), and the emulated ISA cards could carry out the address decode to decide whether to respond, etc. So in that way it could emulate the bus signals involved in memory or I/O transactions at extreme precision. During that emulation, the internal workings of the 486 could be emulated where one component is doing an instruction decode while a few other units are busy in a pipeline acting on the past couple instructions and the arithmetic unit is busy computing the effective address for "LEA ECX,[ESI+EAX+1234h]". Meanwhile another part of the code accurately counts the VGA dot clock and updates another struct that represents the analog/digital signals on the VGA connector according to emulation of the DAC, memory controller, etc. of the video card. A virtual VGA monitor would sample the VGA signal struct and construct a virtual raster on the screen complete with gamma correction. The whole design could benefit from modern multi-core processors to emulate components in parallel. Would that be accurate enough?

The choice of project then comes down to how much accuracy do you care about and where? DOSBox-X cares about accuracy to emulate as much as possible about pre-2001 DOS/Windows compatible hardware, but without taking away too much emulation speed. DOSBox is fast enough to run "blood" and "quake" at roughly Pentium MMX 166MHz speeds on my hardware. For the Windows 95 testing I do, and the DOSLIB development I do, DOSBox/DOSBox-X is "good enough" accuracy that only needs refinement in it's behavior. The event-based emulation in DOSBox means that effort in accuracy is focused on where it's needed. Look in src/hardware/vga_draw.cpp sometime to see what I mean: PIC_AddEvent calls to trigger a callback once per virtual scanline and another per vertical retrace. It's so good many DOS demos that use raster trickery already work properly now.

But there are times, for myself and other people, where an emulator at the level I wrote about for videogamer555 would be nice too. If accuracy matters that much, you could use that emulator with the understanding the whole thing would run very slowly, but it would provide you with an understanding of all the things that go on in a PC. Want to take up the challenge of writing something like that videogamer555? I'll even contribute some code to give it some hardware to talk to. You could write it in C++ if you want to use object oriented design for flexibility, just don't go C++ class & template crazy like most programmers tend to do. I recommend developing with the SDL library so that your work could be compiled for Windows, Linux, Mac OS X, etc... What do you say videogamer555?

for the fdc issues, you may also take a look at Battler's work on PCem-X (fork of PCem with enhancements for the floppy controller, and it even allows for 3-mode ones) on forum.softhistory.org (it's where it's stored) or Sarah's latest rv (revisions) on her bitbucket site, and meanwhile, is it possible to tweak the DOSBox-x menu for the storage (drives) to allow switching during OS emulation (in addition to the "plain" DOSBox mode) without triggering the DOS DTA? Overall, this is really a great improvement since the last one that I compiled! 😁

I might take a look at PCem/PCem-X for floppy emulation. My fork only has the basic read/write commands and seek emulation.

I've also thought of that problem as well where I want to change the CD-ROM or floppy to any arbitrary image I want while running a game or Windows 95. I was thinking of taking the QEMU approach where you can call up a command line window on top of the running game/OS and run some of the builtin commands (instead of QEMU's "switching screens" approach). And then when that is added, I would also add a way to read stats and poke through the emulated RAM's contents for debugging purposes, something that would have helped debug the last few issues noted in the commit logs about EMS allocation failure and low memory corruption.

Excellent work on the FDC code so far TheGreatCodeholio! I've been compiling different builds of different commits of yours on github since last month (if they would compile). I find one very interesting feature or bug-exempt object in your current public release(s) versus Daum, and that is the FPU instructions with the normal core. While this makes Windows Me installable following the directions in your NOTES section, this also helps make some other games I have a lot more stable under win98se that utilize the proper FPU handling without an FPU-overrun crash, which is what Daum does.

TheGreatCodeholio wrote:

I've also thought of that problem as well where I want to change the CD-ROM or floppy to any arbitrary image I want while running a game or Windows 95. I was thinking of taking the QEMU approach where you can call up a command line window on top of the running game/OS and run some of the builtin commands (instead of QEMU's "switching screens" approach). And then when that is added, I would also add a way to read stats and poke through the emulated RAM's contents for debugging purposes, something that would have helped debug the last few issues noted in the commit logs about EMS allocation failure and low memory corruption.

Sounds sweet. 😀

Also, if Windows 95/98 could detect and operate the emulated 3DFX card, that would be very very useful ! 😉
I don't know how hard it would be to implement, though.