English Amiga Board Amiga Lore


Go Back   English Amiga Board > Support > support.WinUAE

 
 
Thread Tools
Old 13 December 2016, 22:12   #1
mark_k
Registered User
 
Join Date: Aug 2004
Location:
Posts: 2,482
Hardfile geometry issue

Some time ago I created configs which I used for accessing image files created from MO disks. Each image file is 1,303,563,264 bytes long, and I have this entry in my default.geo file:

; 2.6GB 5.25" MO disk
[1303563264]
Surfaces=1
BlocksPerTrack=51
BlockSize=1024
FileSystem=Z:\Shared\FastFileSystem_45.14_hacked


Looking at the config file though, it contains different geometry info. For example:
hardfile2=ro,IMG:Z:\dummymo.bin,109,51,2,1024,-128,Z:\Shared\FastFileSystem_45.14,uae
uaehf2=hdf,ro,IMG:"Z:\\dummymo.bin",109,51,2,1024,-128,Z:\Shared\FastFileSystem_45.14,uae


On loading that config and clicking CD & Hard drives, the IMG volume is shown in the list. Double-clicking that opens the Hardfile Settings window showing Surfaces=51,Sectors=109 which matches the figures in the config file. Notice that the Surfaces figure is what should be Sectors (= BlocksPerTrack in default.geo).

If I click the "..." button to right of the Path box to open a file requester then just click Cancel, the geometry shown in Hardfile Settings changes to Surfaces=1,Sectors=51 (i.e. as specified in default.geo). And the summary display below shows some bogus values:
79563/1/32, 2546016/2546022 blocks, 1243.2MB/1243.2MB
DOS............. [444F5301 00000000 00000000 00000000] [Too many cyls]


However if I click OK to close the Hardfile Settings window, then double-click IMG in the list again to re-open it, the geometry shown is Surfaces=1,Sectors=51 (matching default.geo), and the summary below is correct:
24961/1/51, 1273011/1273011 blocks, 1243.2MB/1243.2MB
DOS............. [444F5301 00000000 00000000 00000000]


Even if I fix the geometry shown to Surfaces=1,Sectors=51 then save the config, the just-saved config file is identical to the original one.
Attached Files
File Type: zip config.zip (3.1 KB, 23 views)

Last edited by mark_k; 13 December 2016 at 22:24.
mark_k is offline  
AdSense AdSense  
Old 19 December 2016, 19:18   #2
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 42
Posts: 19,561
This is not very good test case without matching file and file is far too large..
Toni Wilen is online now  
Old 19 December 2016, 19:24   #3
mark_k
Registered User
 
Join Date: Aug 2004
Location:
Posts: 2,482
Basically-empty HDF attached. I think I might have quick-formatted it? Sparse file in tar archive to minimise file size.

$ sha1sum -b dummymo.bin
0a7fc60925bca1014aa2575c402ace8119448a54 *dummymo.bin
Attached Files
File Type: zip dummymo.bin.tar.zip (1.2 KB, 18 views)
mark_k is offline  
Old 19 December 2016, 20:15   #4
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 42
Posts: 19,561
Looks like it should use RDB mode and physical geometry?
Toni Wilen is online now  
Old 19 December 2016, 21:41   #5
mark_k
Registered User
 
Join Date: Aug 2004
Location:
Posts: 2,482
It's basically a partition image (there was one partition covering the entire disk, no RDB). It can be accessed fine in WinUAE without RDB mode. Load config and start emulation, there's this related log output:

Mounting uaehf.device 2 (0):
FS: mounted HDF unit IMG (0000-4db2cc00, Z:\dummymo.bin)
Partition 'IMG' Dostype=444F5301 (DOS\1) Flags: 00000000
BlockSize: 1024, Surfaces: 51, SectorsPerBlock 1
SectorsPerTrack: 109, Reserved: 2, LowCyl 0, HighCyl 228
, Size 1243M
Buffers: 50, BufMemType: 00000001, MaxTransfer: 7fffffff, Mask: ffffffff, BootPri: -128
Total blocks: 1273011, Total disk blocks: 1273011
First block 0 dostype: 444F5301 (DOS\1)
RDB: fakefilesys, trying to load 'Z:\Shared\FastFileSystem_45.14', dostype 0x444F5301 (DOS\1)
RDB: 444F5301 (DOS\1) in FileSystem.resource version 40.1
RDB: faked RDB filesystem 444F5301 (DOS\1 45.14) loaded. ADD2FS=0


The partition is mounted automatically, albeit with the wrong fake geometry (as in the config file).

Now press F12, double-click the IMG entry in the list of drives to open Hardfile Settings window. Click "..." button to right of Path box. Cancel file dialog that appears. Notice the geometry shown reverts to the correct one (i.e. as specified in default.geo). Also note the bogus 79563/1/32… text.

Click OK to dismiss Hardfile Settings window then click Reset to reboot. This time the partition is mounted with the correct fake geometry:
Mounting uaehf.device 2 (0):
FS: mounted HDF unit IMG (0000-4db2cc00, Z:\dummymo.bin)
Partition 'IMG' Dostype=444F5301 (DOS\1) Flags: 00000000
BlockSize: 1024, Surfaces: 1, SectorsPerBlock 1
SectorsPerTrack: 51, Reserved: 2, LowCyl 0, HighCyl 24960
, Size 1243M
Buffers: 50, BufMemType: 00000001, MaxTransfer: 7fffffff, Mask: ffffffff, BootPri: -128
Total blocks: 1273011, Total disk blocks: 1273011
First block 0 dostype: 444F5301 (DOS\1)
RDB: fakefilesys, trying to load 'Z:\Shared\FastFileSystem_45.14_hacked', dostype 0x444F5301 (DOS\1)
RDB: 444F5301 (DOS\1) in FileSystem.resource version 40.1
RDB: faked RDB filesystem 444F5301 (DOS\1 45.14) loaded. ADD2FS=0


As I mentioned above, if you save the config then, for some reason WinUAE writes the wrong geometry to the config file.
mark_k is offline  
Old 19 December 2016, 22:20   #6
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 42
Posts: 19,561
Lets forget the geometry file for now, to reduce unknown variables. What exactly goes wrong without it? (if anything)
Toni Wilen is online now  
Old 20 December 2016, 21:31   #7
mark_k
Registered User
 
Join Date: Aug 2004
Location:
Posts: 2,482
After renaming default.geo so WinUAE doesn't use it…

Run WinUAE, load config, double-click IMG in list of drives (CD & Hard drives). The geometry shown is Surfaces 51, Sectors 109, Block size 1024, as given in the config file.

Click "..." to right of Path box, click Cancel to dismiss the file dialog.

Now the geometry shown is Surfaces 1, Sectors 32, Block size 512 and this text appears:
79563/1/32, 2546016/2546022 blocks, 1243.2MB/1243.2MB
DOS............ [444F5301 00000000 00000000 00000000] [Too many cyls]


So even though the HDF wasn't changed (file dialog cancelled), WinUAE resets the specified-in-config-file geometry to its default one.
mark_k is offline  
Old 29 December 2016, 17:59   #8
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 42
Posts: 19,561
Geometry file is loaded and parsed before all normal config file parameters have been parsed.

I am not sure what was the original plan but I think geometry file should always override everything in normal config file?
Toni Wilen is online now  
Old 30 December 2016, 20:17   #9
mark_k
Registered User
 
Join Date: Aug 2004
Location:
Posts: 2,482
I think an entry in the geometry file should be used instead of WinUAE's auto-generated (and usually bogus/needs-to-be-changed-manually) geometry. But if a geometry is specified in the config file that should be used instead.

So there may be at least two issues here:
- Opening then canceling the HDF file dialog resets geometry to default, it shouldn't change.
- When default.geo exists and a matching entry is found, and the user then saves the config file, it seems WinUAE puts the wrong values in the config file (Surfaces=51 instead of Sectors=51 in the example above).
mark_k is offline  
Old 30 December 2016, 21:06   #10
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 42
Posts: 19,561
But then what is the point of geometry file if it can never override anything? Config file will always have _some_ geometry included.
Toni Wilen is online now  
Old 30 December 2016, 22:30   #11
mark_k
Registered User
 
Join Date: Aug 2004
Location:
Posts: 2,482
When the user adds a new HDF (created from a real Amiga partition) then the geometry WinUAE uses will come from default.geo, rather than the usually-wrong automatic one.

The main point is to allow the default geometry to be taken from default.geo instead of WinUAE's bogus calculation. I say "bogus" because it often/usually doesn't cover all sectors of the image; if you're using a filesystem/partition image, you probably do want all sectors to be covered by the fake geometry.

Having geometry from the config file override that in default.geo is useful in cases where the user does want to use a different geometry; they don't need to edit or delete/rename their default.geo.
mark_k is offline  
Old 31 December 2016, 10:03   #12
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 42
Posts: 19,561
Quote:
Originally Posted by mark_k View Post
When default.geo exists and a matching entry is found, and the user then saves the config file, it seems WinUAE puts the wrong values in the config file (Surfaces=51 instead of Sectors=51 in the example above).
I can't duplicate this. Are you sure you remembered order of parameters in config file correctly? It is sectors (51), surfaces (1), reserved (2), block size (1024). Very old historic reasons. Much later added physical geometry is in normal CHS order. It can also make it more confusing when status bar shows logical geometry in CHS order (Where C is calculated value)
Toni Wilen is online now  
AdSense AdSense  
 


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools

Similar Threads
Thread Thread Starter Forum Replies Last Post
MaxFlash 4GB CF Card, shot its Geometry StarBastard support.Hardware 13 29 October 2016 13:13
HDF geometry settings critic support.WinUAE 4 25 November 2011 20:45
repair hardfile source support.WinUAE 1 14 January 2010 08:46
Hardfile not being seen MobbyG support.WinUAE 7 20 December 2005 22:18
Hardfile problems quicksylver support.WinUAE 4 17 November 2003 22:53

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 11:28.


Powered by vBulletin® Version 3.8.8 Beta 1
Copyright ©2000 - 2017, vBulletin Solutions, Inc.
Page generated in 0.21396 seconds with 12 queries