Large HD images (DOSBOX)

Here you can discuss the development of patches.

Re: Large HD images (DOSBOX)

Postby Serious Callers Only » 2018-7-20 @ 17:13

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.
Serious Callers Only
Member
 
Posts: 375
Joined: 2003-4-26 @ 21:34

Re: Large HD images (DOSBOX)

Postby gulikoza » 2018-8-05 @ 02:50

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, ...).
User avatar
gulikoza
Oldbie
 
Posts: 1705
Joined: 2004-6-25 @ 14:53

Re: Large HD images (DOSBOX)

Postby ruthan » 2018-8-05 @ 03:04

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 HW.
User avatar
ruthan
Oldbie
 
Posts: 1015
Joined: 2013-3-07 @ 04:01
Location: Schwarz Wald-from France to Ukraine, from Denmark to Austria. Celts+German+Slavs melting pot.

Re: Large HD images (DOSBOX)

Postby gulikoza » 2018-8-05 @ 04:47

Sorry, no idea, never studied the differences between fat32 and fat16.
User avatar
gulikoza
Oldbie
 
Posts: 1705
Joined: 2004-6-25 @ 14:53

Re: Large HD images (DOSBOX)

Postby ripsaw8080 » 2018-8-05 @ 09:37

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.
User avatar
ripsaw8080
DOSBox Author
 
Posts: 4380
Joined: 2006-4-25 @ 23:24

Re: Large HD images (DOSBOX)

Postby ANGO » 2018-10-05 @ 17:15

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 ...
ANGO
Newbie
 
Posts: 13
Joined: 2018-8-30 @ 17:59

Re: Large HD images (DOSBOX)

Postby Dominus » 2018-10-05 @ 17:26

If you read the very first post, DOSBox doesn't support more than 2GB (unless I missed the patch going into SVN).
User avatar
Dominus
DOSBox Moderator
 
Posts: 7914
Joined: 2002-10-03 @ 09:54
Location: Ludwigsburg

Re: Large HD images (DOSBOX)

Postby ANGO » 2018-10-06 @ 05:40

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


... I did not see that. Sorry and Thank you.
ANGO
Newbie
 
Posts: 13
Joined: 2018-8-30 @ 17:59

Re: Large HD images (DOSBOX)

Postby Serious Callers Only » 2019-6-27 @ 12:15

The sandbox on the last few commits (ie: fopen_wrap) broke this patch... i may or may not fix depending on how this goes.
Serious Callers Only
Member
 
Posts: 375
Joined: 2003-4-26 @ 21:34

Re: Large HD images (DOSBOX)

Postby kjliew » 2019-6-27 @ 22:39

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 viewtopic.php?f=41&t=34642#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,
Code: Select all
$ 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.
kjliew
Member
 
Posts: 394
Joined: 2004-1-08 @ 03:03

Re: Large HD images (DOSBOX)

Postby Marty2dos » 2019-7-03 @ 00:33

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.
Image

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.. :)
Marty2dos
Newbie
 
Posts: 35
Joined: 2013-6-04 @ 01:43

Re: Large HD images (DOSBOX)

Postby Serious Callers Only » 2019-7-08 @ 09:54

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 viewtopic.php?f=41&t=34642#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,
Code: Select all
$ 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.
Serious Callers Only
Member
 
Posts: 375
Joined: 2003-4-26 @ 21:34

Re: Large HD images (DOSBOX)

Postby jmarsh » 2019-7-08 @ 11:23

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.
jmarsh
Member
 
Posts: 179
Joined: 2014-1-04 @ 09:17

Re: Large HD images (DOSBOX)

Postby kjliew » 2019-7-08 @ 22:58

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 :happy:

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.
kjliew
Member
 
Posts: 394
Joined: 2004-1-08 @ 03:03

Previous

Return to DOSBox Patches

Who is online

Users browsing this forum: No registered users and 2 guests