Tokugawa Corporate Forums

Retro Japanese Computing
It is currently March 28th, 2024, 8:48 am

All times are UTC




Post new topic Reply to topic  [ 9 posts ] 
Author Message
 Post subject: VFL images
PostPosted: December 29th, 2020, 2:04 am 
Offline

Joined: January 11th, 2007, 12:46 am
Posts: 257
So... almost all the floppy drive image formats used for PC-9801 games are essentially uncompressed and unencrypted... except VFL. Also, almost all are supported by VFIC to some extent... except VFL.

The utility is fortunately still around: https://www.vector.co.jp/soft/dos/util/se012084.html

Sadly, although the documentation hints at a complete file format spec (separately, on NIFTY) I haven't had any luck locating it. The author states the images are compressed using an algorithm borrowed from LHA. Together with being able to use the utility to make test files from known uncompressed images, it's probably quite possible to reverse engineer it.

My question, though, is why? I've only ever seen two games in VFL format:

J. League Professional Soccer 1993
PlayMaker Football

Has anyone seen any more? Do any emulators support this format?


Top
 Profile  
 
 Post subject: Re: VFL images
PostPosted: December 30th, 2020, 4:17 pm 
Offline

Joined: September 28th, 2017, 10:51 am
Posts: 8
some files in my HDD

https://mega.nz/file/4J1V1YRC#d8e5lvUca ... BWRtyjpBck


Attachments:
File comment: archived files
FILENAME.zip [2.56 KiB]
Downloaded 175 times
Top
 Profile  
 
 Post subject: Re: VFL images
PostPosted: January 12th, 2021, 12:28 am 
Offline

Joined: January 11th, 2007, 12:46 am
Posts: 257
Well, ask and you shall receive. Thanks. Guess I can't weasel out of adding format support now...

Secondary request: Anyone have a NFD r1 image? As far as I can tell, VFIC only makes r0 NFDs.

r0 NFDs start with the 14-byte header: "T98FDDIMAGE.R0" I have the documentation from the author about r1 NFDs (Which should start with "T98FDDIMAGE.R1") but don't have any actual examples. There's a bunch of NFDs in the Neo-Kobe archive, but they're all the standard r0 NFDs, that I've seen.


Top
 Profile  
 
 Post subject: Re: VFL images
PostPosted: January 12th, 2021, 2:07 pm 
Offline

Joined: September 28th, 2017, 10:51 am
Posts: 8
[Starcraft] TO-KY-O
[System Sacom] ALL ABOUT MARK FLINT (only ZONE)

https://mega.nz/file/RFkQBYKJ#QjP_IrHM3 ... o3tH0VzAtM

Both are created from the product disk with the -r1d option.

I have fond memories of about 10 years ago, when I wanted to run TO-KY-O on NP2, so I made it support the nfd format.


Top
 Profile  
 
 Post subject: Re: VFL images
PostPosted: January 14th, 2021, 12:00 am 
Offline

Joined: January 11th, 2007, 12:46 am
Posts: 257
Wow, thank you!

Those are definitely .r1 files, and they boot up nicely in T98-Next too. I'll see about adding support this weekend, doesn't look like much of a change from the .r0.

NFD isn't ever a multi-disk format, is it? I didn't see anything in the documentation indicating it was.


Top
 Profile  
 
 Post subject: Re: VFL images
PostPosted: February 7th, 2021, 4:38 pm 
Offline

Joined: January 11th, 2007, 12:46 am
Posts: 257
So, got the NFD r1 files to work well enough:

Image
Image

Looks like there's some really weird disk geometry on ALL ABOUT MARK FLINT, was that part of the original copy protection that prompted you use to the r1 disk generator?


Top
 Profile  
 
 Post subject: Re: VFL images
PostPosted: February 9th, 2021, 1:36 pm 
Offline

Joined: September 28th, 2017, 10:51 am
Posts: 8
The target disk is dumped with KryoFlux and viewed with HxCFloppyEmulator.

Image
Image
Image

...I just realized that there's an error in the dump.


Top
 Profile  
 
 Post subject: Re: VFL images
PostPosted: February 13th, 2021, 7:55 pm 
Offline

Joined: January 11th, 2007, 12:46 am
Posts: 257
Hmmm... yes, every one of those oddly-positioned sectors appears to show some kind of read issue:

Image

The data within the sectors appears to be just long repetitions of the same value, as you've shown there, so I suspect they aren't "real" or a valid result.


Top
 Profile  
 
 Post subject: Re: VFL images
PostPosted: February 10th, 2022, 1:08 am 
Offline

Joined: January 11th, 2007, 12:46 am
Posts: 257
For the morbidly curious, my notes on reverse engineering the VFL format. Unfortunately, as the actual data is compressed by track with some kind of LHA-variant compression, it's going to be a bit of a chore to figure out.

Code:
The documentation says the following disk types are supported:

2HC(1.44M)
2HD(1.25M)
2HC(1.21M)
2DD(720kB)
2DD(640kB)
2D (360kB)
2D  (8インチ ) 注:2HDとしてファイル化されます
1S (8インチ ) 注:fオプションが常にONになります

Compression technique described as follows:

1.1 If all tracks have the same data, do not create a file.
2. Look at FAT and don't file unused clusters.
3. Compress for each track. I borrowed the LHA algorithm.
(Reference material 1)

VFL's have the magic word: VOL_FILE0100 (First 12 bytes), VFZ's: VFZ_FILE0010

It appears the next 12 bytes (0xC through 0x17) serve as the volume label, in text;
purpose of 0x18 - 0x1F unknown

0x20 WORD Cylinders [77 in example]
0x22 WORD Bytes Per Sector [1024 in example]
0x24 WORD Sectors Per Side (Heads * Sectors)?  [16 (8*2) in example]
0x26 WORD Bytes Per Side (Heads * Sectors * BytesPerSector) [16384 (1024*2*8) in example]
0x28 WORD Bytes Per Sector Again? [1024 in example]

Next 18 bytes are unclear, but the same in all the examples:
01 00 01 00 02 00 05 00 06 00 C0 00 0B 00 C6 04 01 00

Starting at offset 0x3C, we have a null-terminated string of 40 bytes (41 including the null terminator at 0x64)
Following that is another null-terminated string of 122 bytes (comment field?) with the null terminator at 0xDF
The 32 bytes after that string (0xE0 - 0xFF) appear to be reserved and set to zero

Starting at offset 0x100 appear to be a series of 16-byte header entries (Not identical to NFD's 16-byte headers)
They run through 0x5CF, for a total of 1232 bytes in our example,  77 entries, one for each cylinder
So these are presumably 16 byte track headers of some sort (As these entries can be completely identical, it's unlikely they contain any geometry values)

16 Byte Track Headers:

0x0 DWORD Offset - Appears to be an absolute offset from the start of file to the data chunk for this track, for example, the first value is always 1536 (0x600)
          Blank entries at the end will point to the end of file (i.e. they're set to the total file size)
0x4 WORD Chunk Size - Set to zero for blank entries, size in bytes of the chunk after compression? [Always < 16384 in example]
                 Yes, appears to be that, added to the Offset, should give you the start of the next chunk
0x6 BYTE Type Flag - Set to 01 if this track is all one value and not stored;
                      Set to 02 for normal stored tracks...
                 Set to 00 value for ?? Value, DWORD at 0x4 matches offset to next chunk [16384 in example, 8x2x1024?]
0x7 BYTE Fill Byte - Apparently the fill byte if the previous byte was set to 0x01; 0xE5 is a common value.
            If Type Flag <> 1, then this will be 0x00
0x8 WORD ?? - Set to zero for Flag 01 entries, but not for 00 or 02
0xA WORD ?? - Set to zero for Flag 00 and 01 entries
0xC WORD Allocated Bytes - Generally 16384 in our example, except for the last couple entries (zero for blank)
0xE WORD Reserved - Always 0x0000


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 9 posts ] 

All times are UTC


Who is online

Users browsing this forum: No registered users and 15 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group