English Amiga Board


Go Back   English Amiga Board > Other Projects > project.TOSEC (amiga only)

 
 
Thread Tools
Old 27 June 2013, 23:54   #1
FrodeSolheim
FS-UAE Developer
 
FrodeSolheim's Avatar
 
Join Date: Dec 2011
Location: Førde, Norway
Age: 43
Posts: 4,043
Question about root block differences in UFO Uknown disks

I reported UFO - Enemy Unknown (1994)(MicroProse)(AGA)(M3)(Disk 1 of 4)[cr Bad Karma].adf in the TOSEC renaming thread, and decided to look at disks 2, 3 and 4, and compared the [a] variants to non-[a]

This is the result for Disk 4 (disk 2 and disk 3 comparisons were likewise).

i see that the [a] disks have bm_flag == VALID (-1, ff ff ff ff), while the non-[a] disks have the value 1 (??) Is this symptomatic of a faulty copy program?

While the disks may both work fine (how does AmigaDOS treat disks with bm_flag == 1?), is this a reason to prefer the [a] over the other?

The other byte differences in the root blocks are only dates (and root block checksum of course).

Another peculiarity is that the root block pointer in block 0 is 0, not 880 (this is for all disks 2, 3, and 4, both [a] and non-[a]).

Code:
ADF File Compare
================
A: DOS disk, FFS
   UFO - Enemy Unknown (1994)(MicroProse)(AGA)(M3)(Disk 4 of 4)[cr Bad Karma].adf
B: DOS disk, FFS
   UFO - Enemy Unknown (1994)(MicroProse)(AGA)(M3)(Disk 4 of 4)[cr Bad Karma][a].adf

WARNINGS FOR DISK A
===================
WARNING: Root block is at position 0, not 880
WARNING: Trying 880 anyway...
WARNING: bm_flag != 0xffffffff

WARNINGS FOR DISK B
===================
WARNING: Root block is at position 0, not 880
WARNING: Trying 880 anyway...

FILE LIST
=========
(the disks have the exact same files and file contents)

BLOCK COMPARISON
================

block 880 differ:
 - A - used
 - A - root block
 - B - used
 - B - root block

    offset 010     00 00 00 00 6a 45 d2 5a     00 00 00 00 6a 45 a9 04 
    offset 138     00 00 00 01 00 00 03 71     ff ff ff ff 00 00 03 71 
    offset 1a0     00 00 00 00 00 00 01 00     00 00 00 00 00 00 17 d2 
    offset 1a8     00 00 04 8b 00 00 03 21     00 00 03 81 00 00 02 05 
    offset 1e0     00 00 0b 92 00 00 01 00     00 00 0b 92 00 00 17 d2 
    offset 1e8     00 00 04 8b 00 00 03 21     00 00 03 81 00 00 02 05
Anyone have any words of wisdom?
FrodeSolheim is offline  
Old 28 June 2013, 00:54   #2
Galahad/FLT
Going nowhere
 
Galahad/FLT's Avatar
 
Join Date: Oct 2001
Location: United Kingdom
Age: 50
Posts: 9,016
What is the DOS header in hex for the boot block track? Should be "DOS",x, x=number
Galahad/FLT is offline  
Old 28 June 2013, 09:10   #3
FrodeSolheim
FS-UAE Developer
 
FrodeSolheim's Avatar
 
Join Date: Dec 2011
Location: Førde, Norway
Age: 43
Posts: 4,043
Quote:
Originally Posted by Galahad/FLT View Post
What is the DOS header in hex for the boot block track? Should be "DOS",x, x=number
44 4F 53 01 00 00 00 00 00 00 00 00

I don't know that anything's wrong with it, but I've been using http://lclevy.free.fr/adflib/adf_info.html, and it does not seem to simply that the root block pointer is optional - which is why I wondered about this. Perhaps AmigaOS assumes the default (880) if this value is 0, or that it was never really used?

EDIT: Actually, the ADF FAQ seems to contradict itself, another place it says that a Minimal blank floppy disk first block looks like this (so root block pointer will be 0 in this case):
0 char 4 ID 'D''O''S' + flags (0 -> 5)
4 long 1023 full of zeros

Last edited by FrodeSolheim; 28 June 2013 at 09:27.
FrodeSolheim is offline  
Old 28 June 2013, 09:34   #4
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 49
Posts: 26,554
Root block value in boot block is completely unused. Many adf images have garbage there. (aros did use it for a while but it broke many disk images..)

Bitmap valid field is DOS boolean, DOS uses 0 and -1 (DOSFALSE and DOSTRUE) when writing, usually (there may be exceptions) any non-zero value works in place of -1.

Possibly it has been validated or optimized or something by some 3rd party program?
Toni Wilen is online now  
Old 28 June 2013, 09:59   #5
FrodeSolheim
FS-UAE Developer
 
FrodeSolheim's Avatar
 
Join Date: Dec 2011
Location: Førde, Norway
Age: 43
Posts: 4,043
Quote:
Originally Posted by Toni Wilen View Post
Root block value in boot block is completely unused. Many adf images have garbage there. (aros did use it for a while but it broke many disk images..)
Thanks, I suspected this was the case...

Quote:
Originally Posted by Toni Wilen View Post
Bitmap valid field is DOS boolean, DOS uses 0 and -1 (DOSFALSE and DOSTRUE) when writing, usually (there may be exceptions) any non-zero value works in place of -1.

Possibly it has been validated or optimized or something by some 3rd party program?
Ah, thanks for clarifying, really appreciated

And yes, the bitmap valid field was 1, so not just any random garbage value. I suppose this could indicate a particular copy program has been used, one which simply uses 1 for valid (or true, generally) and 0 for false... -I assume -1 would written by most copiers...

I'll try to get this additional information added to the ADF FAQ
FrodeSolheim is offline  
 


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

Similar Threads
Thread Thread Starter Forum Replies Last Post
Just had a root around chrispy Retrogaming General Discussion 31 11 September 2010 17:51
Uknown CD32 addon ? haynor666 support.Hardware 15 06 November 2009 17:00
Root partition size on 1gig hdd? edge_david support.Hardware 3 17 February 2007 16:01
Block It! sw2001 request.Old Rare Games 4 17 November 2004 21:11
UFO Enemy Uknown. whdload version = manual protection redblade request.Old Rare Games 4 04 May 2004 04:46

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 19:41.

Top

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.
Page generated in 0.08260 seconds with 13 queries