Some questions

peter_j · **Posted:** February 8th, 2012, 7:32 am

1. Does anyone know where I can find specifications on the various floppy image formats - fdi, fdd, dcp, dcu, dip, etc? D88 I do know. I am trying to find the side/track/sector structures specifically. ( Where is that encyclopedia ashura when you need him? :wink:

)

2. This is what comes of not doing any PC98 for years - is there a screenshot key in Anex? For the life of me I can't find it.

Thanks,

Peter

kobushi · **Joined:** May 15th, 2010, 1:35 am **Posts:** 701

peter_j wrote:

2. This is what comes of not doing any PC98 for years - is there a screenshot key in Anex? For the life of me I can't find it.

No, but np2 does :wink:

In the newer fmgen builds, you can use the FUNCTION= option to define a custom shortkey to any menu item. See function.txt.
For example, to map the screenshot key to Esc, add this line near the top of the ini file.

Code:

FUNCTION=00 1b fd 9e

I don't have much detailed information on floppy image formats, but this site is a good place to start.
http://melog.info/archives/2004/09/30223144.html

There's some good info in the comments.

Anna_Wu · **Joined:** May 21st, 2011, 7:33 am **Posts:** 377

Quote:

2. This is what comes of not doing any PC98 for years - is there a screenshot key in Anex? For the life of me I can't find it.

Try to press ALT(left) + F1 as example. You can use the keys F1-F9
A file in .bmp format (anex86_1.bmp) should be saved in your Anex86 root folder.
Basically it is a save state file which content the bitmap image as screenshot in the header.
Convert the .bmp in another format (.png, .jpg...) or reconvert the .bmp file to get a smaller size, if you need the image only.

peter_j · **Posted:** February 8th, 2012, 1:32 pm

Thank you both for the help.

That link you gave, kobushi, is helpful. It seems, after the file header, the sectors are just splurged out without headers themselves, on DCP/DCU, and, it seems, FDI.

That BMP, Anna Wu, is quite something LOL - a whole pile of stuff at the end of the actual BMP.

Anna_Wu · **Joined:** May 21st, 2011, 7:33 am **Posts:** 377

Quote:

That BMP, Anna Wu, is quite something LOL - a whole pile of stuff at the end of the actual BMP.

Yes, it is a hybrid file (screenshot + save state)

Easy to test.

View the anex86_1.bmp file as screenshot by using a image viewer.
Load the anex86_1.bmp file as load state by pressing the ALT + F1
keys in the Anex86 - Setting window (not in the window for the emulation).

peter_j · **Posted:** February 9th, 2012, 4:11 am

There seem to be at least 2 very different formats of .fdd files. One has a header starting VFD1, the other looks like a straight sector dump. VFic says the .fdd format is from Virtual98, but the docs for that are very short and don't seem to mention anything about .fdd format. Can anyone shed any light?

BTW the old Tosec set I have jumbles up these .fdd files together - yet I cannot believe they are the same thing. VFic fails on a number of them and produces some strange output on others.

peter_j · **Posted:** February 11th, 2012, 3:49 am

Mucking about with floppy images can be really confusing!

I realise this stuff is not everyone's cup of tea, but if anyone has any comments I'd appreciate them. I am trying to work this out so I can compare via CRC the actual sector data regardless of format, removing headers and padding. The story so far...

FDD type 1.

Appears to be a straight sector dump and shound probably be a HDM

FDD type 2.

Starts "VFD" then a version number a few bytes later.
Big header.
Header length in bytes 229,230,231, reversed ( little endian ). ( Address of first sector data ).
From kobushi - "The last official update of mkfdd produces "VFD1.00" files." Try patching any higher version to this.

FDI

4096 byte header, then straight sectors.

DCU/DCP

162 byte header.
Can be short ( ie: empty sectors at end truncated ).
Gets padded with E5 hex on conversion to FDI by VFIC.

DIM

256 byte header.
Length constant.

DIP

256 byte header.

NFD

Long header.
Bytes 273, 274 and I presume 275 = header length reversed.
Byte 14 looks like a version number. VFIC gives issues if this is > 0.
Pads E5 hex at end
One v.1 file I have seems to have either a duplicate or another floppy within the file. Is this a multi-image format?

HDM

Straight sector dump. See also HD*.
I did find one with a 162 byte header - probably a DCP/DCU mis-named.

Padding

Many types pad to the full length with hex E5, FF, 00.

:?:

peter_j · **Posted:** May 15th, 2014, 10:08 am

I am trying to slowly document any info I can find on these formats, and posting here for reference. One useful source I had half forgotten is:

http://melog.info/archives/2004/09/30223144.html

I would welcome any corrections.

Other info, as we go...

____________________________________________________________________________

HDB File - N88-BASIC format

Head 0 Track 0 - FM encoding - 26 sectors of 128 bytes = 1 track
Head 1 Track 0 - MFM encoding - 26 sectors of 256 bytes = 1 track
Head 0 Track 1 to Head 1 Track 77 - 26 sectors of 256 bytes = 152 tracks

Size = 153*26*256 + 26*128
Size = 1018368 + 3328
Size = 1021696

360rpm
Straight sector dump - no headers etc.

Also found as .2HD, which applies to other layouts as well.

____________________________________________________________________________

HDM File - Usual format

2 heads
77 tracks
8 sectors/track
1024 bytes/sector
MFM encoding

Size = 2*77*8*1024
Size = 1261568

360rpm
Straight sector dump - no headers etc.

Also found as .2HD, which applies to other layouts as well.

____________________________________________________________________________

peter_j · **Posted:** May 15th, 2014, 11:45 am

____________________________________________________________________________

DCP/DCU Media Type Flags

See: http://en.wikipedia.org/wiki/List_of_fl ... sk_formats

First byte of file is media type.

01h: 2HD-8 sector (1.25MB) (BKDSK .HDM) (aka 2HS)

2 sides, 77 tracks, 8 sectors/track, 1024 bytes/sector = 1261568 bytes (360rpm)

02H: 2HD-15 sector (1.21MB) (BKDSK .HD5) (aka 2HC)

2 sides, 80 tracks, 15 sectors/track, 512 bytes/sector = 1228800 bytes (360rpm)

03H: 2HQ-18 sector (1.44MB) (BKDSK .HD4) (aka 2HDE)

2 sides, 80 tracks, 18 sectors/track, 512 bytes/sector = 1474560 bytes (300rpm)

04H: 2DD-8 sector (640KB) (BKDSK .DD6)

2 sides, 80 tracks, 8 sectors/track, 512 bytes/sector = 655360 bytes (300rpm)

05h: 2DD-9 sector ( 720KB) (BKDSK .DD9)

2 sides, 80 tracks, 9 sectors/track, 512 bytes/sector = 737280 bytes (300rpm)

08h: 2HD-9 sector (1.44MB)

2 sides, 80 tracks, 9 sectors/track, 1024 bytes/sector = 1474560 bytes (300rpm)(??)

11h: BASIC-2HD (BKDSK .HDB)

See HDB description.

19h: BASIC 2DD (BKDSK .DDB)

2 sides, 80 tracks, 16 sectors/track, 256 bytes/sector = 655360 bytes (300rpm)

21H: 2HD-26 sector

2 sides, 80 tracks, 26 sectors/track, 256 bytes/sector = 1064960 bytes (??rpm)(??)

peter_j · **Posted:** May 16th, 2014, 5:32 am

Some important forum posts on disk images:

____________________________________________________________________________

Ashura's Warning on Overtrack Disks

viewtopic.php?f=1&t=96&p=2926#p2926

Ashura's Warning on vfic and DIM format

viewtopic.php?f=2&t=614&p=5011#p5011

Ashura's post on D88 specs

viewtopic.php?f=4&t=261

Forum topic on image format preferences

viewtopic.php?f=1&t=526

Thread with Ashura's trick to convert MS-DOS 2DD to BASIC 2DD format

viewtopic.php?f=1&t=344

peter_j · **Posted:** May 16th, 2014, 5:58 am

VFIC Input Formats

From a hex dump of the vfic binary, it appears vfic understands the following input formats ( some natively, some by plugin I guess ):

.125
.144
.2d
.2dd
.2hd
.d77
.d88
.dbs
.dcp
.dcu
.dd6
.dd9
.ddb
.dim
.dup
.fdd
.fdi
.fil
.fim
.fix
.h01
.hd4
.hd5
.hd9
.hdb
.hdm
.nfd
.tfd
.vfd
.vfl
.vfz
.xdf

peter_j · **Posted:** May 16th, 2014, 10:45 am

DCP/DCU Header

0000h: Media Type
0001h ~ 00A1h: Track map
00A2h: All tracks stored flag
00A3h ~: Disk image

Media Type: See above.

All Tracks Stored Flag: This, in practice seems often to be set strangely or incorrectly. DCP always set to 0. DCU - 1 if all tracks stored, 0 if not.

Track Map: 160 bytes, each representing a track, 1 if present, 0 if not. Not always accurate in the real world.

Disk Image: Disk data, layout depending on Media Type. Gets padded with E5 hex on conversion to FDI by VFIC.

peter_j · **Posted:** May 28th, 2014, 4:00 pm

FDI Header First 32 Bytes

From NP source code:

Code:

typedef struct {
   BYTE   dummy[4];
   BYTE   fddtype[4];
   BYTE   headersize[4];
   BYTE   fddsize[4];
   BYTE   sectorsize[4];
   BYTE   sectors[4];
   BYTE   surfaces[4];
   BYTE   cylinders[4];
} FDIHDR;

Data is Intel DWORDs ( little endian ).

delicious · **Posted:** September 14th, 2014, 4:44 pm

x68000's PROGRAMMER'S MANUAL
http://datacrystal.romhacking.net/wiki/X68k:PM

English translation included.

etabeta · **Joined:** July 5th, 2010, 8:17 pm **Posts:** 56

I have sort of reverse engineered the .FDD format for supporting it in MESS
The file structure seems relatively easy

Code:

0xC3FC header, followed by raw sector data
    Sector map starts at offset 0xDC, with 12bytes for each sector

    Each entry of the sector map has the following structure
    - 0x0 = track number (if 0xff the sector/track is unformatted/unused)
    - 0x1 = head number
    - 0x2 = sector number
    - 0x3 = sector size (128 << this byte)
    - 0x4 = fill byte. if it's not 0xff, then this sector in the original
            disk consisted of this single value repeated for the whole 
            sector size, and the sector is skipped in the .fdd file. 
            if it's 0xff, then this sector is wholly contained in the .fdd 
            file
    - 0x5 = ??
    - 0x6 = ??
    - 0x7 = ??
    - 0x8-0x0b = absolute offset of the data for this sector, or 0xfffffff
                 if the sector was skipped in the .fdd (and it has to be 
                 filled with the value at 0x4)

the main thing to account when converting / handling these is the fact that any sector with constant value is skipped in the disk (to save space, I guess) and it has to be manually padded

Tokugawa Corporate Forums

Some questions

Who is online