VOGONS

Common searches


Reply 20 of 29, by Serious Callers Only

User metadata
Rank Member
Rank
Member

When i use dosbox to run windows 95 games i 'autostart' the games by copying a windows shortcut* with a standard name that is a sibling file of game hdd image to the OS hdd image mount to the windows autostart directory. It's crude, but it kinda works well (and i can share the OS image, but i place it on a linux ramdisk anyway on the autoexec section of dosbox.conf).

The nastiest part of this whole process is actually copying the shortcut out after formating the game hdd images and installing the games on them because dosbox doesn't mount fat32 images in a way that they can be read so you have to deal with cylinders headers etc, and to access a windows formated hdd image on linux you need to skip the windows header. It's super nasty to manipulate. (i can copy on the dosbox shell the shortcut to the windows hdd image because it's FAT16).

Games that need cd change and have no no-cd i don't even try. I suppose a cd emulator is possible to use on the guest, but i'd much prefer that the dosbox support actually worked.

*i made the shortcut on the guest and copied it outside obviously.

Last edited by Serious Callers Only on 2017-12-20, 01:30. Edited 6 times in total.

Reply 21 of 29, by Serious Callers Only

User metadata
Rank Member
Rank
Member
TheGreatCodeholio wrote:

On a related note, I've discussed before the idea of mounting a folder as a CD-ROM drive. It's doable. All the emulator has to do is enumerate all the files and build a skeleton ISO 9660 / Joliet filesystem in memory that refers to the files, which should work fine as long as you don't change anything afterwards.

This already works in dosbox. mount D dir -t cdrom

However, as I often complain, because it's on 'mount' and not on 'imgmount' it doesn't support cd change or mp3/flac/ogg audio. And of course, windows 95 up (windows 3.11 works) doesn't see cd mounts in dosbox.

I use it to be able to play in dosbox and use hardlinks to scummvm and to save space (even isos have useless random trash bytes, ... not all but often).

I suggested extending the cue support to support a directory as the 'BINARY' part of the filesystem (with a ending slash) , but that would obviously be a breaking change for the cue format.

Reply 22 of 29, by TheGreatCodeholio

User metadata
Rank Oldbie
Rank
Oldbie

No, that just creates a drive letter that the DOSBox DOS kernel pretends is a CD-ROM drive.

I'm talking about being able to mount a folder as a CD-ROM drive in a way that a guest OS like Windows 95 will see as a CD-ROM drive. If the emulator builds a skeleton ISO 9660 / Joliet filesystem in memory around the files in the folder, and then responds to CD-ROM sector reads with either the filesystem structure or file contents, a folder could be presented to Windows 95 as if a CD-ROM drive.

DOSBox-X project: more emulation better accuracy.
DOSLIB and DOSLIB2: Learn how to tinker and hack hardware and software from DOS.

Reply 23 of 29, by Serious Callers Only

User metadata
Rank Member
Rank
Member

Actually that would be a very neat upstream contribution to imgmount. I never got a response to my idea of treating cues with a BINARY paths that ends with a slash (or replace BINARY by DIRECTORY or something like that) to reuse all the structures around changing cds and mp3 support, so if you could implement it on imgmount like that it would make mount -t cdrom completely obsolete. If it works on windows, even better.

I'd make sure it would be accepted upstream if you're hoping it happens though. Though i personally would use that patch in my ppa because it's something i 'need'.

Some games would glitch because they have weird copy protections or timings, but that's what the full bin image support is for anyway (it would be better if it worked with those normal images too).

Last edited by Serious Callers Only on 2017-12-20, 01:26. Edited 2 times in total.

Reply 24 of 29, by Serious Callers Only

User metadata
Rank Member
Rank
Member

I'm surprised though. I thought this would require a 'custom' windows driver anyway, to link the dosbox representation to the windows driver trying to read it? If not, then i thought dosbox cdrom emulation was more complex than it actually is.

Reply 25 of 29, by TheGreatCodeholio

User metadata
Rank Oldbie
Rank
Oldbie

No. As far as Windows 95 is concerned it's a CD-ROM drive on the IDE bus, that it can read data sectors from.

The idea is that on mounting a folder, the emulator takes note of what the folder contains, then builds a CD-ROM filesystem structure in memory around it.

When Windows 95 goes to read data sectors, the CD-ROM emulation will either return a part of the filesystem structure it made, or part of a file from the host, depending on what sectors are being read. Windows 95 will see a CD-ROM filesystem that DOSBox-X is faking on the fly from the contents of the folder that it saw when you mounted the folder.

No special drivers are needed in Windows 95 to do this. This trick only requires Windows 95 to recognize that there is a CD-ROM drive attached to the IDE controller, which it has support for built-in to the default install.

DOSBox-X project: more emulation better accuracy.
DOSLIB and DOSLIB2: Learn how to tinker and hack hardware and software from DOS.

Reply 27 of 29, by TheGreatCodeholio

User metadata
Rank Oldbie
Rank
Oldbie

The latest commit adds an option to enable/disable the ISA PnP device (and it's disabled by default now).

When I produce another Windows build the PnP device will be off by default.

DOSBox-X project: more emulation better accuracy.
DOSLIB and DOSLIB2: Learn how to tinker and hack hardware and software from DOS.

Reply 29 of 29, by TheGreatCodeholio

User metadata
Rank Oldbie
Rank
Oldbie

There won't be a driver for a long while, until I can get a better grip on Windows VXD/386 driver development.

That world is one that requires a lot of work at the ASM level.

But instead of using the official tools I am developing DOSLIB to be able to compile VXDs using Linux, Open Watcom, and GCC v7.x (i386 target), which is coming along very slowly due to all the copious details of the Windows 386 kernel in Windows 3.x/9x/ME.

Because of the combined functions in the integration driver it's going to have to be a VXD that virtualizes that device for Windows vs DOS VMs, but then provides services for other VXDs in the same driver set to use within the Windows kernel for other things (including the mouse pointer integration).

DOSBox-X project: more emulation better accuracy.
DOSLIB and DOSLIB2: Learn how to tinker and hack hardware and software from DOS.