FeedingDragon wrote:

I still think being able to specify a window location for individual configurations (ok for each game,) would be "nice".

If I'm not mistaken, you can make a batch file that sets the environment variable and then launches DOSBox.

You are correct.

I could use AutoIt as well (actually that's what I use instead of batch files in Windows, for the most part.) It adds another step and more programming though, along with a ton of extra files. Ok, maybe not. Going to have to look into command line parameters for AutoIt now. If I can ever get anyone to spring for getting VFD signed, I still plan to get that up and running again. It seems to be more stable with Win3.1 in DOSBox than a mounted directory (and a lot easier to manage than mounted image files.) Though, I may be testing those on my ISA system in the not to distant future (fingers crossed, the rest of my parts should be here tomorrow or the day after.)

That's a minor thought, for the games that run in Windows3.1, a floppy drive "half" mount option. A (or B) drive is mounted as "empty", then can use mount or imgmount to finish it later. If it's half-mounted, then the mount -u would just put it back in that "empty" state.... Don't know what that would take though. May be too difficult to implement. Maybe an exception to the mount/imgmount command such as "mount a -fd?" with ? being the drive "type" (1.44, 1.2, 720, 360, etc...) that is reported. Would only work for A or B and only if it isn't already mounted. OK, just an errant thought.

fyi - In Win3.1, for some reason, if I don't have an A drive mounted, then the "drive" pull down lists are invisible. The drives are there, I just can't see them. Random clicking will result in "I is not a valid drive" type errors. My temp fix for now (until I can get VFD up and running, or something else comes along,) is to mount an empty directory as A.

Collecting my random comments and thoughts from elsewhere into here, and some are certainly repeats I'm just adding my vote to, and I understand the real way to get any of this is to code it myself. I hope not too many already exist in DosBox and I'm just showing my ignorance. 😀 All that said, I'd love to see these features in future dosbox versions:

* A way to pre-load keystrokes from inside dosbox.conf in a way that can answer early dos game questions like 'K'eyboard or 'J'oystick, 'C'ga 'E'ga 'V'ga, '1' No Sound '2' PC Speaker '3' Sound Blaster so I don't have to answer them every time I run the game. Example game: Pango asks Color Monitor (Y/N)? and Joystick (Y/N)? before getting to the game menu.

* paste OS clipboard text as keystrokes

* redirect/capture all keystrokes, joystck, and mouse inputs to a data file. And maybe the ability to replay that file back into dosbox, though that's a much more advanced feature.

* "screenshot" text mode screen as .txt or html/rtf color text or some such. (I thought DOSBox used to have this, but I couldn't find it. My bad memory? "Lost" feature? Poor google skills on my part, showing my ignorance?)

* The 'more' pagination utility for dos game instruction files - add my vote. Someone said piping redirects work already? I'm surprised we don't have 'more' then, I thought that was the only hold up. 😀

* A nice and free Edit utility on the Z: drive.

* "Opcode cycle counting Core" to get closer to "real XT" and other "slow" machines speed - the next step closer to cycle perfect 5150, 5160 and similar stable emulation targets for the pre-386 games. I hope it is as easy as not just counting 1 cycle per opcode, and instead having an opcode cycle-count lookup tables for different chips; but I know the problem is not "easy". And after that, I assume questions of cycles stolen for memory refresh and cannonical CGA/Mono/EGA speeds will come up.

* SuperZaxxon. I didn't know about the game until I learned DOSBox has trouble with it; I gave it a try and saw the issues, and now I have an unreasonable burning desire to play it unsatisfied by breaking out the actual arcade game. (Unless I'm just missing some config steps to get it running correctly, and am just ignorant? Anyway, fun with video emulation indeed!)

* "EasyBBS Mode" - not sure if this is a dosbox feature or just needs knowledge on my part and an easy install package, but it'd be fun to easily access a BBS running in one dosbox from another dosbox even if only on the same computer. I know some have gotten it to work, but the "follow these steps" were daunting last I looked. But to have a dosbox setup to relive FIDO and door games easily... {happy sigh}.

* Even more improved joystick -> keyboard mapping. Recently I tried a cheap but "nice" Sabrent gamepad with Captain Comic, trying to map the D-Pad "Hat Control" directions and 1234 buttons to the keyboard directions & fire/action keys, but it didn't really work more than marginally. It could be my ignorance and a messed up config, or bad hardware that looks OK in windows joystick config, but the mapping seemed to work only intermittently and I suspect software/mapping improvements could be made.

---
Nice-to-have extensions for writing new games or in-dosbox menus; these are not actual classic games, I know.

* Choice command-like app that can display graphic menus included on z: drive. (Yes, yes, I'll write one then we talk. Fair enough:)) I'm thinking like "Litude's Ansi Menu bat file launchers for early Apogee Trilogies of games" uses ANSI chars and Choice; something that loads a CGA/EGA/VGA/etc. image and then acts like Choice.com to select batch file options. Example: press 1-5 to choose which Commander Keen episode to launch, but a graphical menu image showing title graphics from each game.

* dirtree utility on the z: drive. I remember being happily addicted to that utility back in the day.

* built-in norton commander like file manager, with bonus ability to browse 'host' as well as dosbox and mount/refresh/unmount/swap images as appropriate.

* built-in video and sound "test/config" app to compare display and sound modes, pick one, and save the .conf file - more about comparison and tweaking than configuring. "Just use a front-end", I know. 😀

* Mount a zip file (.7z, whatever) as a drive, readonly or bonus points if actually writable. At least "fake" writable for the session.

* Floppy disk image that is read-only and unchanged even if "save files" are written, and "delta" disk image with the new data. Even better if could be done with directories - source directory is read-only, all changes like save and config files written to redirected alternate directory.

* Create image files from within dosbox, i.e. "mount b floppy.img -new 360k", same with hard drives and even 'writable' ISOs.

* A way to include a zip file or directory's files on the Z: drive from dosbox.conf. More about organization, I suppose, since modifying 'path' and mounting an odd drive like q: is functionally the same AFAIK to put utilities in an accessible place.

* a canonical second "dosbox.conf" file extension/type like .dos or .dbgame for click-to-launch in supported OSs - Windows and Mac for certain, I don't know about Linux. I can invent an extension on my computer, but community support is everything on this feature. Example: "Pango.dos" is a dosbox.conf file that launches Pango.exe in dosbox with correct settings and autoexec, and in the same directory "Infiltrator.dos" launches Infiltrator with its correct config settings and autoexec.

---
Programmer extensions probably in "extension" bios or vai ports or some such for using dosbox for new games:

* Joystick axes and buttons beyond what dos allowed (ie. all the items on two PS3/4/Xbox 360/1 gamepads for head to head play, or on a full flightstick HOTAS).
* Random number function
* Png/Jpg, etc. image decoding to memory (ie. INT 0xDB ah=10 ES:DI -> "sprite1.png" DX:BX -> target memory location, dx:bx -> 0 means return decompressed memory size needed)
* Ogg/Mp3/Wav, etc. sound decoding to memory, or playback "bios" interface (same as above for sound)
* Text file format reader: ini/.config reader, XML reader?, for easy modern config file support in new dos games.
* Timer/timespan/stopwatch bios function more like modern GetTickCount or millisecond resolution clock for easy game timing / frame duration measuring
* quickload a large datafile into XMS "upper" memory in real modes to avoid the pain of doing the the real dos way

* quick / easy video double/tripple buffering via "cheating" emulation to save memory. Example: in VGA hirez 640x??? mode, but actual image being displayed is in emulator memory, and "video memory" in dosbox can be altered without changing display. Then trigger a function, and the newly composed frame is queued up to become the display frame at the next flicker-free moment while the emulated dos code is drawing the new frame in "video memory" at 0xA0000. Also with features like "background image automatically copied into frame" so game only hast to draw the sprites on top of the easy no-memory-required background image, or even that background image is a viewport/rectangle on a much larger "scrollable" background. (I guess this is basically emulating a 2D graphics accelerator card that maybe never existed? Put some sprite drawing and collision code, and you've got an overpowered Atari. Sounds good to me. 😀 )

* Testsuite/automated test report mode? Run through a suite of regression tests (CPU, Video, Audio, Joystick etc.) and spit out the results file. Particularly good for pre-release testing and 3rd party patch reality checking.

---
The dosbox debugger is a grand little thing, but intentionally limited as I understand, so I have a grand and unlikely vision:

* "Debugger Services" API (like, across network sockets for "remote debugging" from same or different machine), with features similar to a real cpu and richer: code breakpoints, memory access breakpoints, single step, memory & registry access, opcode decoding, "pause"/break right now; basically the building blocks for 3rd party debugger and memory cheat/trainer apps, and possibly a way to achieve saving & loading state, though that may not be the right design for that.

(That took a while to write, but it was a fun walk through dreamland and avoiding of other projects. 😁)

There is a reason that the devs don't look at this thread anymore...

Because it's always such a great idea to open up and say, "hey users, what do you want? Sky's the limit." 😀 As that dilbert I can't find says - "at least there's a process, even if it's wearing a paper bag on your head and being beaten by whiffle bats."

Ah, well, it's not like I'm demanding anything or have expectations that these get done - though SuperZaxxon support would be cool, being an actual classic game, but I know it's already on the list. Why, I'd just hate for our hero devs to get depressed and think no one valued them anymore. On the other hand, they've done such great work that all the stuff we need to play classic games on modern machines is mostly done, just little things like 'the more utility for text files' and dreams of huge building-block things like running linux, win9x, cycle perfection in PC/XT/286 era emulation where it might matter, and dosbox as a platform for rapid retro programming really remain. 😉

Piping would be nice. This would also enable the 'pre-loading of keystrokes' requested above. However I can see why it hasn't been added, since it would be a lot of work to implement and would only be used by a small minority of users.

There's also the problem that it doesn't dispense coffee. This needs to be looked into.

This would also enable the 'pre-loading of keystrokes'...

I hadn't thought of that. Any game that hooks the keyboard itself wouldn't work that way, but these games probably are just using the dos/bios routines during startup anyway, so perhaps some would. I'll have to give that a try in real dos and see what happens, thanks for the idea.

As I understand, one problem with many wishes is the cross-platform nature of DOSBox, so any emulator UI is a harder problem than if it just were a Mac app or something. I wonder, would it help to have a "UI Services" architecture, basically an API for accomplishing things like the "hold right control down to run at max speed during loading bypassing the cycles=fixed 400 temporarily" - the API would do the 'max speed' bit, and a platform-centric host would do the 'holding right control down' bit? Of course, maybe that is the way DOSBox already works, and it's just a hard, low priority problem that hasn't caught dev attention.

That reminds me - is the keymapper (Ctrl-F1) run from inside the emulator as native code, or is it really a special dos program that runs under emulation and so can be a "cross-platform UI" without any specific UI requirements? I'll have to look that up sometime, unless someone is willing to comment.

I remember using ECHO XYZ|GAME.EXE to push keystrokes to games with annoying startup questions. I remember this worked with Thunderstrike for one, but don't remember if it worked with PANGO. (I do remember writing a hack to change its annoying default control keys to QAOP though.)

There was also a tool called 'Key-Fake' that allowed you to do this with carriage returns and other control codes

I tracked down this site with Key-Fake and others, including StuffIt, apparently "advanced" enough that it might work for games like Pango - timer options, not just keyboard buffer stuffing. I'll have to give it a try, thanks for mentioning it.

Two of the requested features listed in this thread, Long File Name (LFN) support and copy/paste support have been already implemented recently.

Related forum threads:
Long File Name (LFN) support
Mouse copy/paste support

Latest Windows binary + required DLLs, zipped:
http://bit.ly/12jANWF

1) When run with -noconsole command the DOSBox creates
stderr.txt, stdout.txt
The offer is to make a switch/option to turn off creating of these files. Or to set absence of these files by default (when run with -noconsole) and then a switch/option to turn them on for those who needs them.

2) Many people prefer portable variants of DOSBox, not install ones. I know it's easy to make a portable DOSBox from installation, but as some prefer a portable, maybe it's better to place both variants for download: installation by .exe and portable .zip. I see such approach at ykhwong's site.

Has anyone made a patch to set the CGA palette? A whole new look for CGA games, would think that would be interesting.

rpr wrote:

I'd like to use DOSBox to run some old database programs compiled with Clipper (I have only EXEs, not the source). In DOSBox the programs can use non-English keyboard layout, which doesn't work if the programs run in MS Windows 7 (I've tried all compatibility modes).

But, the programs print to LPT1: port which is not supported in DOSBox. Is there a chance that LPT1: will be supported any time soon?

--rpr.

I would like to second this feature request. I don't necessarily need to be able to print to the port, I just need it to be recognized like an old LPT port. Way back in the DOS days, one way that software developers would copy-protect their software was by using a hardware key. You would get a hardware key that plugged into your printer port and the software would check it was in place before it would run. I have such a bit of software and it seems to run in DOSBox, but it won't recognize the fact that the key is plugged in. It does't seem like it would be a difficult thing to simply turn on the printer port, but you guys are the experts. Thanks for your consideration.

BatteryChucker wrote:

Way back in the DOS days, one way that software developers would copy-protect their software was by using a hardware key. You would get a hardware key that plugged into your printer port and the software would check it was in place before it would run. I have such a bit of software and it seems to run in DOSBox, but it won't recognize the fact that the key is plugged in. It does't seem like it would be a difficult thing to simply turn on the printer port, but you guys are the experts.

I'm not sure if you know this already, but those are called "dongles", and there are already numerous threads about them. One person even developed a patch that allows the dongle to be dispensed with entirely, if it's a particular type of dongle and the data from the chip inside can be read.

Otherwise, support for parallel-port passthrough is already available in the SVN Daum build of DOSBox, though it is principally geared towards printing and may not work with a dongle. Certainly, you should not expect it to work with a USB-to-parallel port adapter; you will need either a motherboard with a parallel port or a PCI card with a parallel port on it.

Jorpho wrote:

I'm not sure if you know this already, but those are called "dongles", and there are already numerous threads about them. One person even developed a patch that allows the dongle to be dispensed with entirely, if it's a particular type of dongle and the data from the chip inside can be read.

Otherwise, support for parallel-port passthrough is already available in the SVN Daum build of DOSBox, though it is principally geared towards printing and may not work with a dongle. Certainly, you should not expect it to work with a USB-to-parallel port adapter; you will need either a motherboard with a parallel port or a PCI card with a parallel port on it.

All that said, the developers of DOSBox still won't support you:
DOSBox IS NOT SUITED TO RUN YOUR NON-GAMING DOS APPLICATION

Jorpho wrote:

'm not sure if you know this already, but those are called "dongles"

Also better known in some places as "HASP" 's, Hardware Against Software Piracy

Wow I wasn't able to log in for years due to a forum bug but it worked now! Great!

I know DOSBox has been progressing slowly since it got such an excellent compatibility rating but there's still a few features I'd like:

- CRT emulation - the current filters are pretty standard "smoothing" stuff but a lot of retro gamers like the old classic CRT look which also smudges the jagged pixels a little

- better PC speaker emulation - I've been playing some PC speaker games lately and the sound really is nowhere near as cool as it sounded on a real PC speaker. Real PC speaker would use the computer case as a kind of hall - the sound would bounce off the insides causing a warmer, more vibrant sound. The emulated PC speaker sounds rather flat and dull compared to it. Even ignoring the effect of the reverberation inside the case, I got a feeling the emulation isn't quite right either?

Good to have you back, red!

red_avatar wrote:

- CRT emulation - the current filters are pretty standard "smoothing" stuff but a lot of retro gamers like the old classic CRT look which also smudges the jagged pixels a little

As far as CRT emulation is concerned, there is a shader in Dosbox Daum that does exactly that. It even emulates curvature, I think it's quite accurate.