MGT image format and file system

clausjahn · July 2009

Hello,

I'm working now on the M.G.T. file support for my ZX-Modules applications.
I've collected some data sheets and most of them describe the internal file structure well.

But while analyzing, very often some questions occur. And that's the reason for this thread.

All the digged out MGT file format descriptions tell about single sided disks. Does anybody know how they are structured?

To remember: Normal (double-sided) images contain 10 sectors per track, 80 tracks per side and use 512 bytes per sector, so we get an amount of 819200 total bytes for the image. The directory is stored in tracks 0..3 on disk one, means we have 40 sectors with 2 directory entries per sector (256 bytes = 1 directory entry).
But what's about the single sided disks? As the directory is only on side 1 even if we have a double-sided image, I expect the directory being at the same position (and with the same size) on single-sided disks.

Is this correct?

Thanks in advance.

LCD · July 2009

Yes, thats correct. Directory always uses 4 Tracks, 20 Kb from the disc capacity:
800Kb DSDD80T = 780 Kb (20 Kb for Directory)
400Kb SSDD80T = 380 Kb (20 Kb for Directory)
400Kb DSDD40T = 380 Kb (20 Kb for Directory)
200Kb SSDD40T = 180 Kb (20 Kb for Directory)
Disciple allowed also to use SD (Single density), but +D did not allow it.
UniDOS allowed Subdirectories and to use additional tracks for Directory (Up to 79 tracks), allowing to store up to 1580 files, but this is a different story.

clausjahn · July 2009

Thanks, LCD, for the info. That helps a lot.

Do we always have image files of 819200 bytes size, no matter what kind of format we have?

But I'm still confused about that formats.

The four mentioned formats are all with double density (DD). I suppose that all of these have sector lengths of 512 bytes. I red in the RAMSOFT Disciple+ description about different densities. There may exist also low density disks with a sector length of 256 bytes. But maybe that those disks would be of less interest.

LCD · July 2009

clausjahn wrote: »

Thanks, LCD, for the info. That helps a lot.

Do we always have image files of 819200 bytes size, no matter what kind of format we have?

Yes, because RAMSoft not allowed to make images of discs other than 780Kb. All other formats are in done in compatibility mode. The problem is to find a program which can write or read 180 and 380 Kb formats on real disc. I think, these formats can be ignored because of this.

clausjahn wrote: »

But I'm still confused about that formats.

The four mentioned formats are all with double density (DD). I suppose that all of these have sector lengths of 512 bytes. I red in the RAMSOFT Disciple+ description about different densities. There may exist also low density disks with a sector length of 256 bytes. But maybe that those disks would be of less interest.

That was what I said: Single density! Only Disciple can read and write such disch (FORMAT sd1). The sector size is 256 but it was rarely used and there are no images of such discs.

clausjahn · July 2009

LCD wrote:

Yes, because RAMSoft not allowed to make images of discs other than 780Kb. All other formats are in done in compatibility mode. The problem is to find a program which can write or read 180 and 380 Kb formats on real disc. I think, these formats can be ignored because of this.

okay. Sounds good for us developers. ;-)

LCD wrote:

That was what I said: Single density! Only Disciple can read and write such disch (FORMAT sd1). The sector size is 256 but it was rarely used and there are no images of such discs.

Wonderful. I hoped that. As I saw no realistic way to distinguish the formats because of a missing format specification (as we have on +D DSK or TRD files, for example). Now I can concentrate on the 780 KB images.

I used ZX-Spin and stored some files on a new MGT disk image. The information I've got with the famous MGT2TAP utiliy is _very_ helpful here.

For the file system:
What I can tell you here that I have found very different sources:

MGT filesystem

this tells us about >28 different file types (including SAM Coup?, HDOS and EDOS system), and some unclear information about the SAM Coup? file structure.

The disciple.txt file from RAMSOFT tells the things much better, as they describe each file format in detail; but as this includes only Disciple and UNIDOS, we find only the first 14 filetypes (index 0..13) here.

I think, in RAMSOFT's description there is a bug in the description of SUBDIRECTORY (type 12), because they tell us that the bytes 210-212 of the FAT entry are same as OPENTYPE (type 10), but OPENTYPE uses the 16-bit value at offset 212-213 for storing the length of the last block. That's why I would need to produce such subdirectories for my own to see how they are stored in the FAT.

The source here: SamDos tells some more about the SAMDos files. I hope that all lets me come to a correct conclusion about the internal file structure, because I want to write a read/write interface.

LCD · July 2009

clausjahn wrote: »

I used ZX-Spin and stored some files on a new MGT disk image. The information I've got with the famous MGT2TAP utiliy is _very_ helpful here.

Great!

clausjahn wrote: »

For the file system:
What I can tell you here that I have found very different sources:

MGT filesystem

this tells us about >28 different file types (including SAM Coup?, HDOS and EDOS system), and some unclear information about the SAM Coup? file structure.

Never saw this wiki. Very useful, and has corrected some of my information about UniDOS. Very compressed information, but I think, there is no need to support SAM files becaues no one will need to convert SAM files from MGT images because SAM emulators do not support TAP files and there are no other disc systems to convert files from/to. Only reading, to display screens (Like in Retro-X disc master) or convert from/to binary files may be useful.

clausjahn wrote: »

The disciple.txt file from RAMSOFT tells the things much better, as they describe each file format in detail; but as this includes only Disciple and UNIDOS, we find only the first 14 filetypes (index 0..13) here.

Yes, the disciple manual was extended and extremly useful because there are all hook-codes described. There are not many filetypes because RAMSOFT was a Speccy group and not for SAM, and Disciple ignored all SAM-Type files.

clausjahn wrote: »

I think, in RAMSOFT's description there is a bug in the description of SUBDIRECTORY (type 12), because they tell us that the bytes 210-212 of the FAT entry are same as OPENTYPE (type 10), but OPENTYPE uses the 16-bit value at offset 212-213 for storing the length of the last block. That's why I would need to produce such subdirectories for my own to see how they are stored in the FAT.

I do not supported UniDOS yet, so you will be right. I have not checked Ramsofts Disciple manual yet about this. Maybe Directory entry simply do not use these bytes.

clausjahn wrote: »

The source here: SamDos tells some more about the SAMDos files. I hope that all lets me come to a correct conclusion about the internal file structure, because I want to write a read/write interface.

The read interface is easy, but Writing is much harder. I wish you much success.

clausjahn · July 2009

LCD wrote: »

Never saw this wiki. Very useful, and has corrected some of my information about UniDOS.

Famous!

LCD wrote: »

Very compressed information, but I think, there is no need to support SAM files becaues no one will need to convert SAM files from MGT images because SAM emulators do not support TAP files and there are no other disc systems to convert files from/to. Only reading, to display screens (Like in Retro-X disc master) or convert from/to binary files may be useful.

Yes, agreed. Sounds good. Well, I could display SAM files in the disk image viewer (byte view or sector view), but would not load them as files in the block editor view. I would let the FAT reader mark the FAT entries as being "reserved", so the SAM files would still be present when writing back the MGT/IMG/DSK file.

LCD wrote: »

I do not supported UniDOS yet, so you will be right. I have not checked Ramsofts Disciple manual yet about this. Maybe Directory entry simply do not use these bytes.

Yes, may be. I really could only display things that can be verified. If I could produce some of these UniDOS directories, I could verify. If this is not available, they will be marked as "reserved", as SAM files.

LCD wrote: »

The read interface is easy, but Writing is much harder. I wish you much success.

Thanks! The implementation of a MGT support will result in a display that is pretty much like the disk viewer I wrote for DSK (+3) and TRD files. As the image structure is a bit different, I have to extent my common disk usage routines so that they match to MGT/IMG/DSK images as well.

LCD · August 2009

Crisis wrote: »

Hardware types: Hardware IDs:
[0Ch] Network adapter [00h] ZX-Interface 1

On the hardware list you have only ONE network adapter but DISCiPLE has absolutely a Network adapter so thats [0Ch][01h]

Yes, and it is Interface 1 compatible. I tested it succesfully some years ago, to transfer programs between a Spectrum with Interface 1 and microdrives and Spectrum with Disciple and Disc drive. I think the hook codes are compatible too. Does it deserve a own entry.

clausjahn · August 2009

Crisis wrote: »

Hardware types: Hardware IDs:
[0Ch] Network adapter [00h] ZX-Interface 1

On the hardware list you have only ONE network adapter but DISCiPLE has absolutely a Network adapter so thats [0Ch][01h]

Hi Crisis,

the hardware information list is made for TZX format, exactly TZX 1.20. That's why there's only one network adaptor, even if there are many more around. Same goes for the other sections.

roko · August 2009

Crisis wrote: »

I have no idear if UniDOS-onboard-DISCiPLE has Network possibilities.
I would like to see the UniDOS DISASSEMBLY if possible.
Does it exist?

It is one of the projects Rudy Biesma (of Disciple & Plus-D disassembly fame) is working on from time to time. I have seen large chunks that are ready.

clausjahn · August 2009

I was surprised when I used a (double-density) formatted test-MGT image file: I stored some Basic programs, data arrays, numeric arrays, code files and SCREEN$ with known values so that I was able to identify the data on the sector-based disk image...

All worked fine, I found my stored data on the correct sector positions on the disk.

Then I stored about 50 files in a loop like this:

... {filling memory upwards 40000 with random bytes}
10 FOR n=1 TO 50
15 LET a$="file"+STR$(n)
20 SAVE d1;(a$) CODE 40000,800
30 NEXT n

This seem to work perfectly, after a CAT 1 I get the primarily stored files as well as the 50 new files in the catalogue,
but when I check the FAT and the sectors of the files, I see that most of the previous files have been overwritten. Not the FAT entries, but the file bodies in the sector-based areas (from track 4, sector 1 upwards).

Is this normal? I used ZX-Spin for this tests...

BTW: Also MGT2TAP founds that the file bodies have been overwritten, because I was not able to restore the original files that have been stored before the 50-files-loop with the "Save as TAP.." option. The files can be stored as TAP-files and have correct file sizes (because the FAT entries are still correct), but contain obviously overwritten data...

Very bad.

roko · August 2009

The FAT part of each CAT entry holds a linear bit map of occupied sectors, and the sectors are 'chained' by the t/s numbers in the last two bytes of each sector. Now there exists a known bug in MGT: certain errors do not flag the current copy of the bitmap in RAM as invalid. So during the next try with (say) another disk, the same (now improper) bitmap is used.
The solution for this is resetting the bitmap-flag by hand: POKE@6999,0 (for Disciple only, sorry PlusD not in my docs!)
When indeed 'original' files are overwritten, then probably a bitmap is used which was 'left over' from previous disk actions. The relevant poke could be done before another test run....

clausjahn · August 2009

Thanks roko and Crisis for your help. The POKE sounds interesting. It seems to work. :-)

Rudy · August 2009

CLEAR # does the trick for both DISCiPLE and +D (and +DivIDE), but is also closes all streams without emptying the buffers.

Rudy Biesma

clausjahn · August 2009

Dear MGT file users,

are there some MGT files around that contain sub-directories and/or microdrive files... I have none of them in my collection, nor I'm not able now to produce some... So, if somebody knows a good source, please tell me.

Thanks in advance.

clausjahn · October 2009

Thank you for your help!!!

I was able to use the UniDOS image file and I already was able to experiment with this nice OS!!! Creating directories and studying their structure is fascinating!

But still no Microdrive files of the different Disciple-based disks... Are there any?

Paul van der Laan · October 2009

Back in de day I used HiSoft Devpac to develop with and the standard cassette version of it also supports saving to microdrive. At one point I got a Disciple and found out I could use this functionality in Gens4 (the assembler in Devpac) to save my files to disk. In the directory these files would be marked as "special". I guess these are the filetypes in question.

clausjahn · October 2009

Crisis wrote: »

Hi Paul,

The 'special'-type is special indeed and unfortunately very UNdocumented.
I know TasWord3 uses 'Special' to store the textfile. With Gens4 that makes only 2 programs known to me using Special.
So we could use DiscDoctor (for Disciple of course) to check the sectors for unusual contence.
Could it imitate the 256bytes sector of an MD-file?

Oh, sounds good. TasWord3 stores special files. Well, I already implemented those, because the structure can be anything you may imagine. But it's important to test this type, of course.

About Microdrive files. They are indeed very undocumented. If there aren't any, then I will let this appear as "Custom" data with type info "Microdrive file". Must be enough at this time.

Thanks for your comments, Crisis and Paul!!! :-)

MGT image format and file system

Comments