flashfloppy
flashfloppy copied to clipboard
keirf
DSK Oric Atmos.
greetings keirf, I attached information to know if you can implement the dsk files of the computer Oric -1 / Atmos. I attach documentation.
P.D .: I have not yet been able to test the beta that you sent me for lack of time.
The document appears to describe the filesystem used for Oric disks (when using Sedoric). All I care about is:
- What is the usual disk image format used for Oric disk images?
- What is the physical track layout used for Oric disks (eg. how many sectors per track, how many bytes per sector)?
Actually the filesystem structure is not an important consideration for FlashFloppy, so the document you attached is not as helpful as it first appears.
The DSK file format in Oric.
Preliminary observations
The de facto standard for Oric disk images is the DSK format. Unfortunately, this extension hides two different file formats.
• The oldest, which only stores the high-level structure of the disk (tracks and sectors), which is perfectly valid for storing standard discs generated by Oric's most common disk operating systems. But it is not suitable for storing discs with a special format or with protections. These disks are identified by the ORICDISK signature at the beginning of the file.
• The new format, which is much more complex. This one also stores the tracks and sectors, but is not limited to that, it also saves all the meta-data stored on a real disk to help the controller's electronics, to identify the different locations of the floppy when it is rotating ; Track headers, synchronization marks, checksums, gaps, etc. ... These disks are identified by the signature MFM_DISK at the beginning of the file.
It is possible to convert a DSK image from the old format to the new format, using the old2mfm program.
The old format (ORICDISK).
(all data is stored in the little endian format)
Headboard
The old DSK files start with a header of 256 bytes:
• A signature of 8 bytes in length: ORICDISK • Number of faces (32 bits) • Number of tracks (32 bits) • Number of sectors (32 bits) • The rest of the header contains unused data.
An example, the header in the old format for Sedoric 3.0 would be:
• 4F5249434449534B? ORICDISK • 02000000? 2 faces • 50000000? 80 tracks • 11000000? 17 sectors • 246 bytes null
Disk data
After the 256 bytes of the header, the disk data comes with the following scheme:
• All the data of the first face go first, all the data of the second face after (if the disk is double-sided). • All sectors are in natural order, track by track, sector by sector, in increasing order. • A size is assumed for the sectors of 256 bytes.
The new format (MFM_DISK)
(all data is stored in the "little endian" format, the data is in hexadecimal notation, the number of bytes used in decimal)
Headboard
The new DSK files also start with a header of 256 bytes:
• A signature of 8 bytes in length: MFM_DISK • Number of faces (32 bits) • Number of tracks (32 bits) • Geometry type (32 bits) • The rest of the header contains data not used, but reserved for future extensions, such as the handling of discs of the BD-500 unit.
Geometry.
This new field indicates how to interpret the rest of the data, the existing types of geometry are:
- First all the tracks on the first side, followed by all the tracks on the second side.
- All the tracks of the cylinder 0, then those of the cylinder 1, etc. ... (the tracks on each side are interspersed)
In the Oric type 1 is used, type 2 is used mostly in platforms other than Oric.
Example, the header in the new format for Sedoric 3.0 would be:
• 4D464D5F4449534B? MFM_DISK • 02000000? 2 faces • 50000000? 80 tracks • 01000000? Geometry type 1 • 246 bytes null
Disk data.
After the 256 bytes of the header, come the disk data arranged according to the following scheme (we assume that we are using the Oric format, type 1 geometry)
• Each track contains 6400 bytes, only 6250 are useful data, the rest are filler to complete a multiple number of 256. • The location of the sectors on the track depends particularly on the format, the number of bytes per sector (256 or 512), and the number of sectors per track (8, 9 or 10 sectors of 512 bytes, or 15 to 18 sectors of 256 bytes).
To locate a particular sector, the most reliable way is to simulate the way the controller works. Analyzing all the data of the track as if it were an authentic magnetic track, locating the synchronization data, then the sector and data headers until arriving at the correct sector.
Track data.
Note: Apparently, this track start is optional.
A track begins with a sequence of data, some are fixed, and other variables:
IBM FORMAT 4E (* 80) 00 (* 12) C2 C2 C2 FC 4E (* 50)
SEDORIC FORMAT 4E (* 40) 00 (* 12) C2 C2 C2 FC 4E (* 40)
That makes a total of 146 bytes for a diskette with IBM format, and 96 bytes for one with SEDORIC format.
A variable number of bytes of 4E value may be present at the end of the track
Data of the sector.
Each sector begins with an identification sequence, some information about the sector itself, some synchronization data, the useful data to load, and some end-of-sector data:
Synchronization data. 00 (* 12) A1 A1 A1 FAITH Track number Expensive. Sector number Number of bytes per sector (1 = 256 bytes, 2 = 512 bytes). 16 bit CRC
Data 00 (* 12) A1 A1 A1 FB 256 or 512 bytes with useful data. ?? 16 CRC bits? It has not been checked yet
End of sector 4E (* 12/30/40/80 bytes depending on the number of sectors and their size).
Do you know how relatively common the two formats are? The old format is easy to support. The new one less so and I'm not sure how many users there would be for the invested effort on that one.
greetings, the sedoric format is used more in relation to the Oric community.
The forum is http://forum.defence-force.org
Games have already been developed for this system now, but if you find it difficult to implement it or take time it depends on you, I just want to contribute to improve the flashfloppy project so that it is operational in the community in retro systems, you may have other projects to be able to implement other systems.
Thanks for everything and receive a greeting.
What I mean is: Plain Sedoric disks can be represented by both old (ORICDISK) and new (MFM_DISK) formats. But which format is more prevalent? ORICDISK is easy for me to support, but is that useful by itself these days?
I have downloaded the tocec of the dsk files from oric and the most used is the MFM_DISK
there are other dsk that use ORICDISK, but at the statistical level the most common is MFM_DISK
Can you attach one old style and one new style to this ticket for me to work with? Or point to a download?
Hi! Any news on this? With the Cumana Reborn drive now being distributed to a core group of Oric devs/users, adding Oric .DSK support to FF is as relevant as ever. Anything I can do to help?
Not sure if that can help, but the source code of my FloppyBuilder, which has been used to generate a number of DSK files for recent games and demos uses the following code:
http://miniserve.defence-force.org/viewvc/projet1/public/pc/tools/osdk/main/FloppyBuilder/
(The tool in question is a part of the OSDK: http://www.osdk.org/index.php?page=documentation&subpage=floppybuilder)
Hi there,
The link @Dhebug added to his previous comment is now dead as he recently moved his whole SVN repositorty to OSDN.
Therefore, the correct link to his FloppyBuilder source code is now: https://osdn.net/projects/oricsdk/scm/svn/tree/head/public/pc/tools/osdk/main/FloppyBuilder/
+1 for this request from my side. One of those users that recently obtained the Cumana Reborn drive for my Oric Atmos that uses FlashFloppy firmware. Also, as far as I understand, the 'new' format is the format almost exclusively used nowadays.
@keirf, Hi Keir and first of all thank you for this awesome piece of software! On the subject of "old" vs "new" format, while I understand it would be easier for you to support the "old" format, it actually would be pretty useless for the Oric community, as many disk images only work with the new format, and in any case we already have a utility to convert from the old to the new format (but not the other way round as some "new" disks cannot be converted to the old format). So really, if you would at some point consider implementing Oric DSK format in FlashFloppy, you should only consider the new MFM format. It would actually be a very useful and welcome addition in the Oric community as we currently have no way to convert back from HFE to DSK and no utility to extract individual files from HFE images (while we do have tools for DSK images).