Re: Display problem of an old application in Hercules mode

Posted on 2011-02-07, 14:19

by

by ripsaw8080

in DOSBox Games/Apps

in DOSBox Games/Apps

h-a-l-9000 wrote: why would it choose exactly 640 pixels? Because when it writes 0x46 (1120 pixels), the register contains 0x28 (640 pixels), so the imagined sanity-check would be to ignore the weird value.

---

Re: Display problem of an old application in Hercules mode

Posted on 2011-02-07, 05:14

by

by ripsaw8080

in DOSBox Games/Apps

in DOSBox Games/Apps

The application errors out with an "Incorrect display adapter" message in official releases of DOSBox, but the port 0x3bf fix for Spacewar in current source has fixed that. ET16N.COM is specifically for MDA/Hercules, so there's not much it could misdetect. I wonder how something like this software …

---

Re: Display problem of an old application in Hercules mode

Posted on 2011-02-06, 19:26

by

by ripsaw8080

in DOSBox Games/Apps

in DOSBox Games/Apps

Can hack it into displaying correctly: case 0x01: //Horizontal displayed chars + if (val==0x46) val=0x28; if (vga.other.hdend ^ val) VGA_StartResize(); vga.other.hdend=(Bit8u)val; break; 0x28 (40) yields 640 horizontal in graphics mode, so why it writes 0x46 (70) is puzzling. It appears the value is …

---

Re: Display problem of an old application in Hercules mode

Posted on 2011-02-06, 16:55

by

by ripsaw8080

in DOSBox Games/Apps

in DOSBox Games/Apps

Seems like there's a few unhandled CRTC registers being used: 23609344: INT10:Function 8E00 not supported 23609401: INT10:Function 9100 not supported 23688783: BIOS:INT16:Unhandled call DB 23688932: INT10:Set Video Mode 7 23688932: INT10:Set Video Mode 7 23688932: MOUSE:New video is the same as the …

---

Re: Display problem of an old application in Hercules mode

Posted on 2011-02-06, 16:04

by

by ripsaw8080

in DOSBox Games/Apps

in DOSBox Games/Apps

I have a TSR program that simulates some text modes using hercules graphics by hooking INT 10h and intercepting all text display functions. DOSBox's shell bypasses the INT 10h interface and calls its text display function directly, so the simulated text modes don't work properly with the shell; …

---

Re: terminator future shock crashing

Posted on 2011-02-05, 08:04

by

by ripsaw8080

in DOSBox Games/Apps

in DOSBox Games/Apps

If you didn't change anything, then you're using defaults. Generally you should use the default of memsize=16. If you feel like experimenting you can try more: 24, or 32. BTW, the directory cache problem I mentioned before, that was with SkyNET, not Future Shock; got them mixed up.

---

Re: terminator future shock crashing

Posted on 2011-02-04, 22:28

by

by ripsaw8080

in DOSBox Games/Apps

in DOSBox Games/Apps

There was a directory cache problem with TFS when transitioning between certain levels and loading saved games that is fixed in current source. However, the problem caused DOSBox to crash, not the game itself, so might not be the issue here. Are any non-default settings being used in DOSBox? In …

---

Re: Memory Leak 32meg dosbox grows to over 1gig of memory

Posted on 2011-02-01, 00:35

by

by ripsaw8080

in DOSBox General

in DOSBox General

You also might want to consider using hal's megabuild of DOSBox, because it rolls the clock over at midnight (I think). Official DOSBox does not advance the date or roll the clock over, which can be a problem for some applications that are left running "24/7".

---

Re: Memory Leak 32meg dosbox grows to over 1gig of memory

Posted on 2011-01-31, 23:29

by

by ripsaw8080

in DOSBox General

in DOSBox General

High memory use can occur when there are many incomplete searches for individual files. Don't know if that's the case here, but it's a definite possibility. There was some kind of security application with the issue, which you can read about here , and maybe the workaround program in that thread …

---

Re: Black Knight - Marine Strike Fighter

Posted on 2011-01-28, 19:36

by

by ripsaw8080

in DOSBox Games/Apps

in DOSBox Games/Apps

The installer on the CD has a bug with hard drives that have a 32K or larger cluster size, causing it to think the drive has negative free space. It is a fault of the installer, although DOSBox could prevent the problem by reporting a smaller cluster size for folder mount drives. Note that the …

---

Re: A small wish ...

Posted on 2011-01-24, 16:45

by

by ripsaw8080

in DOSBox Development

in DOSBox Development

While I do understand why someone would want to override DOSBox's choice of aspect ratio (accurate or not), the approach has a potential drawback in that some games use more than one video mode. You can always compile your own build of DOSBox, and aspect ratio modifications are very easy even if you …

---

Re: VSA256BC.LIB

Posted on 2011-01-17, 20:39

by

by ripsaw8080

in DOSBox Games/Apps

in DOSBox Games/Apps

If I'm reading PutPixel() correctly, only the M_LIN8 (256 color) type is supported among VESA modes, and I can confirm that changing the attributes on that type to 0x1f does make the application happy.

---

Re: VSA256BC.LIB

Posted on 2011-01-17, 18:40

by

by ripsaw8080

in DOSBox Games/Apps

in DOSBox Games/Apps

Yes, the application appears to only have a problem because the attribute bit for "BIOS output" is missing. I wasn't sure if the text functions are supported in VESA modes, but apparently they are. The various mode types in VESA_GetSVGAModeInformation() have "modeAttributes = 0x1b;" so would it be …

---

Re: VSA256BC.LIB

Posted on 2011-01-17, 16:32

by

by ripsaw8080

in DOSBox Games/Apps

in DOSBox Games/Apps

I tried using SDD 5.3a for DOS, but then the program aborts with a divide overflow error for some reason. I don't really know what I'm doing with the program, it's rather cryptic, but I got it to "run" some data and it produces a complicated screen in mode 103 that has text amongst the graphics. Do …

---

Re: VSA256BC.LIB

Posted on 2011-01-17, 16:05

by

by ripsaw8080

in DOSBox Games/Apps

in DOSBox Games/Apps

The error message is displayed when INT 10/4F01 is called to get information about VESA mode 0x103 (800x600x256) and bit 2 ("BIOS output supported" according to RBIL) of the mode attributes is not set. I tried setting the bit in the attribute and the program went on to display this: http://img37. …

---

Re: Settlers 2: tandy 3-voice not working

Posted on 2011-01-17, 00:28

by

by ripsaw8080

in DOSBox Games/Apps

in DOSBox Games/Apps

That TSR program is a hack for Thexder only, it won't do anything for other games. If you're comfortable with using a hex editor type of program you can do this: in TANDY.MDI at offset 0A17 change F2 AE to EB 16. With the hacked driver, machine=svga_s3 and tandy=on, you'll be able to experience …

---

Re: Settlers 2: tandy 3-voice not working

Posted on 2011-01-16, 23:44

by

by ripsaw8080

in DOSBox Games/Apps

in DOSBox Games/Apps

"true" is not a valid value for the tandy= setting, and will result in the default of tandy=auto being used, which means the Tandy sound support will not be enabled for machine=svga_s3, so use tandy=on. The Tandy music driver in Settlers 2 (TANDY.MDI) will only initialize if the string "Tandy" is …

---

Re: Running Innocent Until Caught with SB support

Posted on 2011-01-14, 22:11

by

by ripsaw8080

in DOSBox Games/Apps

in DOSBox Games/Apps

Put the CT-1600 (SBPro2) version of CT-VOICE.DRV in C:\SBPRO\DRV, then "SET SOUND=C:\SBPRO", use the settings you mentioned before, run the game. The SB16 versions of the driver will only work with a development build of DOSBox, it won't work with 0.74, so use the SB Pro 2 version.

---

Re: Running Innocent Until Caught with SB support

Posted on 2011-01-14, 21:01

by

by ripsaw8080

in DOSBox Games/Apps

in DOSBox Games/Apps

Use "SET SOUND=C:\SBPRO", the game adds the DRV subfolder to the path from the environment variable. FYI, some SB16 versions of CT-VOICE.DRV (around 20Kb in size), now work with this and other games in current source.

---

Re: Problem with Tandy Video (Mac OSX + DOSBox 0.74)

Posted on 2011-01-09, 05:16

by

by ripsaw8080

in DOSBox Games/Apps

in DOSBox Games/Apps

With machine=tandy the AGI games use the 4BPP line drawing, which looks to be working with bytes. Have output options other than surface been tried? There is endian stuff in sdlmain.cpp, which might be a good place to investigate if the issue is limited to certain output types.

---