VOGONS

Common searches


Large HD images (DOSBOX)

Topic actions

Reply 40 of 58, by Serious Callers Only

User metadata
Rank Member
Rank
Member

Bumping this since this patch starting failing to apply since r4130. I may try to fix it for myself on the ppa but i'd prefer this was fixed in the thread.

And i mean 'fixed' as a diff, not a executable being shared ofc.

edit:'fixed' it on the ppa by hacking around it on this commit (the voodoo patch is just a 'drift' update and not relevant), not sure if it's subtly broken or not because i don't really understand the code.

There were only two 'real' changes that caused the patch to fail on recent revisions on drive_fat.cpp.

One was very simple to fix, a new function variable assignment was introduced instead of being inline...

the other, a cleanup 'if' was expanded greatly on this upstream commit (this is a clone repository) https://bazaar.launchpad.net/~i30817/do ... ision/4028 (line 731), that was changed by the original patch to do the opposite that upstream does, i moved the original part out and recreated what the original patch did (left created_successfully == true, assigned 'fattype = FAT32' and returned) and left the rest of the conditions assigning 'created_successfully = false;' for the new error cases. I'm not sure this really works considering how the rest of the file interacts with both the patch and the new code at upstream r4130, whatever.

I only use this patch on large windows 95 games i want to run on dosbox (which requires fdisk formated native images), so it's a borderline use anyway.

Reply 41 of 58, by gulikoza

User metadata
Rank Oldbie
Rank
Oldbie

That 'if' is just a quick hack to allow unrecognized (fat32) or unformatted images to be mounted. DOSBox will obviously not read those drives, but they can be used inside booted OS (if supported).

An unsupported "fattype = FAT32" is assigned to these drives (even if the image is unformatted), this flag is checked later in fatDrive::FindFirst to stop reading the files and return empty 😀. Because the entire 'if' is a "Sanity check" which we want to avoid in this case, you can just use the entire new 'if' conditions and apply the same modifications (created_successfully == true, ...).

www.si-gamer.net/gulikoza

Reply 42 of 58, by ruthan

User metadata
Rank Oldbie
Rank
Oldbie

BTW how much work would be make proper FAT32 support for Dosbox?

Gulikoza: Im still using you Dosbox glide build from 2011, thanks for it, could you recommend some successor with same topmenu options and Glide support?

Im old goal oriented goatman, i care about facts and freedom, not about egos+prejudices. Hoarding=sickness. If you want respect, gain it by your behavior. I hate stupid SW limits, SW=virtual world, everything should be possible if you have enough raw HW.

Reply 44 of 58, by ripsaw8080

User metadata
Rank DOSBox Author
Rank
DOSBox Author

There is no need to modify the FAT drive sanity checks -- doing so opens the door to problems. Just use a "-fs none" switch if you want to mount an unformatted or FAT32 image for booting.

Reply 45 of 58, by ANGO

User metadata
Rank Newbie
Rank
Newbie

All hints are not working for me!

Could someone please post a working empty 5 GB hd image which is working in normal Dosbox/DosboxSvn ?
If you compress the image, it have a size of about 1 MB.

I only got working imgaes till 2 GB from here: https://sites.google.com/site/dotalshoff/games/dosbox
But I need an image of 5gb ...

Reply 46 of 58, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator

If you read the very first post, DOSBox doesn't support more than 2GB (unless I missed the patch going into SVN).

Windows 3.1x guide for DOSBox
60 seconds guide to DOSBox
DOSBox SVN snapshot for OS X (10.4-10.14 ppc/intel 32/64bit) codesigned for gatekeeper
DOSBox SVN with SDL2 snapshot for OS X (10.7-10.14 intel 64bit) codesigned for gatekeeper

Reply 49 of 58, by kjliew

User metadata
Rank Oldbie
Rank
Oldbie
Serious Callers Only wrote:

The sandbox on the last few commits (ie: fopen_wrap) broke this patch... i may or may not fix depending on how this goes.

I have a much simpler and less intrusive patch at https://www.vogons.org/viewtopic.php?f= ... 42#p674876
And, it still works for SVN. No extended INT13h, but you still get around 8GB of image in DOSBox by using CHS translation of C/255/63 instead of C/16/63, which has always been supported in DOSBox, but was crippled by not using 64-bit file offsets.

There is no IMGMAKE with my patch since it is meant to be simple. IMGMAKE is redundant, just use dd.

For creating DOSBox compatible HDD image with "-size 512,63,255,C", with max C=1023,

$ dd if=/dev/zero of=dsk.img bs=512 count=`echo $[(( (C+1) *255)+1)*63]`

The code was verified by using DOSBox INT13h to write and read out the last 512-byte sector at FILE_OFFSET64 of IMAGE_SIZE - 512.

Reply 50 of 58, by Marty2dos

User metadata
Rank Newbie
Rank
Newbie

In my Fork "DOSBox Optionals", i had adapted imgmake & the Large HD Support Patch in the past up to 8GB. I use this in combination with PartitionMagic [Old Version] (under DOSBox format to NTFS) for Win95 or Win98 Hardrives and i mount the HDDS with autohdd. DOSBox takes the HD Geometriy self.

----
IMGMOUNT C ".\VDOSBOX\HDD_IMAGE\BootWind9x.img" -t autohdd
IMGMOUNT D ".\VDOSBOX\HDD_IMAGE\HDExtended.img" -t autohdd
BOOT -l c
----
https://github.com/MartyShepard/Dosbox--Optionals-

Current Version is r4219, on my Hdd is actual r4252 and i play and test it actual with Jagged Alliance 2 v2.12 and other Games. This is more Windows Specified Build.
aufnhame00427.jpg

PS:
I do not do advertising for my build because I think I'm not good at offering it to the public. I use the version more for private purposes. eq: Win95 and Win98 with up to 1GB memory, Borderless Mode, 3DFX Resolution up to 8k etc.. 😀

Reply 51 of 58, by Serious Callers Only

User metadata
Rank Member
Rank
Member
kjliew wrote:
Serious Callers Only wrote:

The sandbox on the last few commits (ie: fopen_wrap) broke this patch... i may or may not fix depending on how this goes.

I have a much simpler and less intrusive patch at https://www.vogons.org/viewtopic.php?f= ... 42#p674876
And, it still works for SVN. No extended INT13h, but you still get around 8GB of image in DOSBox by using CHS translation of C/255/63 instead of C/16/63, which has always been supported in DOSBox, but was crippled by not using 64-bit file offsets.

There is no IMGMAKE with my patch since it is meant to be simple. IMGMAKE is redundant, just use dd.

For creating DOSBox compatible HDD image with "-size 512,63,255,C", with max C=1023,

$ dd if=/dev/zero of=dsk.img bs=512 count=`echo $[(( (C+1) *255)+1)*63]`

The code was verified by using DOSBox INT13h to write and read out the last 512-byte sector at FILE_OFFSET64 of IMAGE_SIZE - 512.

Can this run installed windows 95 after letting it format the disk?

The patch is simple indeed. Why hasn't upstream accepted it?

Also i'm sorry Marty2Dos, but unless it's on patch form already, i'm not interested. My life is hard enough, and i'm not about to become a patch creator or adopt another codebase than upstream as base.

Anyway i think i'm not going to change now i already 'fixed' the patch and have a lot of windows 95 hd images created by its imgmake. The one serious advancement i want here is native filesystem directory mount support that works with windows 95/98 (maybe by replacing its code to rip out fdisk and related direct write functions). That would help a lot with copy on write support for larger windows games too.

Reply 52 of 58, by jmarsh

User metadata
Rank Member
Rank
Member
Serious Callers Only wrote:

The patch is simple indeed. Why hasn't upstream accepted it?

Because it's not portable code. Those functions only exist for glibc, breaking osx/xcode and visual studio builds.

Reply 53 of 58, by kjliew

User metadata
Rank Oldbie
Rank
Oldbie
Serious Callers Only wrote:

Can this run installed windows 95 after letting it format the disk?

I didn't try Win95, but Win98SE fdisk, format and install fine from start to end (use "setup /pi /nm") with jmarsh new 64-bit dyn_x86 cpu core. Very fast 😀

jmarsh wrote:
Serious Callers Only wrote:

The patch is simple indeed. Why hasn't upstream accepted it?

Because it's not portable code. Those functions only exist for glibc, breaking osx/xcode and visual studio builds.

I believe there are ways to #ifdef around the code to select the right functions that take FILE_OFFSET64 and be portable. Gulikoza's patch did something like #if defined(__APPLE__) in his patch. I don't develop on OSX/Xcode and have no way to test it. MSYS2/mingw-w64 native codes are linked with msvcrt, so I think Visual Studio builds should be fine.

The key is 64-bit file offset for the fseek() and ftell() functions. I prefer to leave it to upstream to decide a portable mechanism to select the right functions for supported platforms. Well, the fread()/fwrite() already take FILE_OFFSETS64 without any extra work, so it could be just something missed out from the upstream. Perhaps, upstream could take a second look, I would leave it for them to decide if DOS games really need over 2GB of disk image.

Reply 54 of 58, by Serious Callers Only

User metadata
Rank Member
Rank
Member

I think i may be misunderstanding some things here, is the 64 bits offsets for fseek() required for dosbox to mount (> 2gb, 8gb or less) raw FAT32 images that windows95 will later 'manage'?

Because this patch is broken again and i'm sick fixing it, but i *do* have some large windows 95 games on my collection running on dosbox, and i'd like to keep stuff working. If the games still work, i'll get rid of it, but if 64 bits offsets are needed for windows 95 to manage the raw mount, i'll probably adopt the 'simpler' patch.

The largest game being Black Dahlia, with about 5.4 gb of a image file (5395784192 bytes, exactly).

Reply 55 of 58, by Serious Callers Only

User metadata
Rank Member
Rank
Member

Right. The other patches at:

https://www.vogons.org/viewtopic.php?f= ... 42#p674876

are also currently broken, because things (bios_disk.h and bios_disk.cpp) changed... goddamit.

Reply 56 of 58, by kjliew

User metadata
Rank Oldbie
Rank
Oldbie
Serious Callers Only wrote:

The other patches at:

https://www.vogons.org/viewtopic.php?f= ... 42#p674876

are also currently broken

I just updated the rebased patch. It should work with current SVN tip.

Serious Callers Only wrote:

Is the 64 bits offsets for fseek() required for dosbox to mount (> 2gb, 8gb or less) raw FAT32 images that windows95 will later 'manage'?

Yes, 32-bit file offset max at 2GB image.

Reply 57 of 58, by Serious Callers Only

User metadata
Rank Member
Rank
Member

Thanks man, i'll probably use yours instead of the current larger patch with imgmake in my ppa if you don't mind. I don't like how i had to hack it it before with no to little understanding.
edit2: disregard the previous edit; i was testing the patches with not current source.

Reply 58 of 58, by Serious Callers Only

User metadata
Rank Member
Rank
Member

Just a quick question about the bigFAT_2G patch, since the geometry autodetection changed, for FAT16 disks, will i have to recreate images that were using 16 heads instead of 255 (which was the previous default, based on bochs)? Or i can keep using the FAT 16 windows images i already have if they're mounted by imgmount without -fs none to access them on the dosbox shell first beforer boot?

edit: nvm, figured out that all my windows 95 conf files are using the -size parameters for the hd images , so i'm not at risk of the autodetection screwing up. I am curious if windows 95 can even use/format 255 heads disks instead of the default dosbox 16, but it's not a big crisis since i'm not using the new autodetection default head number (indeed i'm using -size 512,63,8,731, ie 512 bytes per sector, 63 sectors, 8 heads, and 731 cylinders).