News:

Printed Amstrad Addict magazine announced, check it out here!

Main Menu

DSK questions

Started by ThomH, 16:04, 14 August 17

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

ThomH


Per the documentation:
Quote
The following bits are used from NEC765 status register 1: [b0, b2, b5, b7]
The following bits are used from NEC765 status register 2: [b0, b5, b6]
So, to turn that sector into something on disk:

       
  • ST1 b0 is missing address mark. Implying this sector doesn't actually exist? So why is it stored?
  • ST1 b2 is no data and its meaning depends on the command issued. So what does it mean here? Its meaning for read data is sector not found, which would suggest the entire sector should be omitted but then why is it stored? Its meaning for read ID is ID not found, giving the same question. Its meaning for read track is first sector not found, giving the same question again.
  • ST1 b5 is CRC error, which makes sense.
  • ST1 b7 is end-of-cylinder, which also doesn't appear to tell me anything relevant to that sector?
  • ST2 b0 is missing data address mark. So I guess that means the ID field was present but a corresponding data field wasn't found. I can just omit the data field.
  • ST2 b5 is data CRC error, which also makes sense.
  • ST2 b6 indicates that the user requested data but the disk found deleted data, or vice versa. Presumably I should assume the imaging software was requesting data, so this implies deleted data?
So what's the normal meaning given to these bits when attempting to reconstruct disk contents? It seems to me that only three of them — the two possible CRC errors and the missing data address mark — are actionable?


Also, what am I supposed to do with the track filler byte? I don't see a way that the file format can specify that a sector exists and not give me the current contents.


Also, re: 8kb means 0x1800 bytes; presumably what I'm supposed to do is read 0x1800 bytes from the file, then stretch or compress that so that it exactly ends on the index hole? So no padding afterwards, no CRC. What about if such a sector occurs near the end of a track and there isn't space for 0x1800 bytes? Just truncate?


Additional questions:


With the John Elliott extension, both data rate and encoding are explicit. Given that the rest of the format is specified in terms of "if an FDC765 read this disk, results would be X", is it actually valid to have FM data encoded at the MFM data rate? A disk probably couldn't actually hold that. And the converse, MFM data stored at the FM rate — surely an FDC765 couldn't actually read that?


The Simon Owen extension is more straightforward, but presumably if I see a 16kb sector then I should write only as much as I can physically fit? The way it's phrased as "the full 16K will be stored" presumably means "will be stored ... inside the DSK image", as there's no way to fit that 16kb onto a floppy.


Also, are there any known disk images using either of the John Elliott or Simon Owen extensions?

arnoldemu

DSK is not suitable for copy protections - in the beginning it was ok but it's better to use hfe or other lower level disk images for better accuracy.

You will also find that some can't be written back, i.e. you can't reconstruct the track, because the described data can't physically fit into the track.

The dsk is kind of a "what you will see" if you read it using the nec 765 and not the true structure of the track.

So for example if you had two id fields, followed by 1 data field, then nec would see that as 2 sectors and this would be stored in the dsk this way, but in reality it's mfm structure is very different, so you'll need to work out what is suitable.

Quote from: ThomH on 16:04, 14 August 17
Per the documentation:So, to turn that sector into something on disk:

       
  • ST1 b0 is missing address mark. Implying this sector doesn't actually exist? So why is it stored?
  • ST1 b2 is no data and its meaning depends on the command issued. So what does it mean here? Its meaning for read data is sector not found, which would suggest the entire sector should be omitted but then why is it stored? Its meaning for read ID is ID not found, giving the same question. Its meaning for read track is first sector not found, giving the same question again.
  • ST1 b5 is CRC error, which makes sense.
  • ST1 b7 is end-of-cylinder, which also doesn't appear to tell me anything relevant to that sector?
  • ST2 b0 is missing data address mark. So I guess that means the ID field was present but a corresponding data field wasn't found. I can just omit the data field.
  • ST2 b5 is data CRC error, which also makes sense.
  • ST2 b6 indicates that the user requested data but the disk found deleted data, or vice versa. Presumably I should assume the imaging software was requesting data, so this implies deleted data?
So what's the normal meaning given to these bits when attempting to reconstruct disk contents? It seems to me that only three of them — the two possible CRC errors and the missing data address mark — are actionable?
These are the results that the nec765 would return when reading the sector. If you are reconstructing the data you are correct.

Ignore ST1 b0, ST1 b2,ST1 b7. You are correct with the others.

Quote from: ThomH on 16:04, 14 August 17
Also, what am I supposed to do with the track filler byte? I don't see a way that the file format can specify that a sector exists and not give me the current contents.
it is legacy. It can be ignored.


Quote from: ThomH on 16:04, 14 August 17
Also, re: 8kb means 0x1800 bytes; presumably what I'm supposed to do is read 0x1800 bytes from the file, then stretch or compress that so that it exactly ends on the index hole? So no padding afterwards, no CRC. What about if such a sector occurs near the end of a track and there isn't space for 0x1800 bytes? Just truncate?
8KB is N=6 which is the size the FDC will read. 0x01800 is stored because that is the maximum data field size that can actually be stored if you also take into account the crc, id field, gaps, index gap etc. It is the max used by games that use this storage method.

To handle this you should give back 8k of data, giving 0x01800 first then padding to the end.

Quote from: ThomH on 16:04, 14 August 17
Additional questions:


With the John Elliott extension, both data rate and encoding are explicit. Given that the rest of the format is specified in terms of "if an FDC765 read this disk, results would be X", is it actually valid to have FM data encoded at the MFM data rate? A disk probably couldn't actually hold that. And the converse, MFM data stored at the FM rate — surely an FDC765 couldn't actually read that?
I think the PC can. On CPC the clock rate is forced to 4Mhz, so in theory it's possible to write FM at MFM rate, but reading it back is not possible because of the data separator setup.

Quote from: ThomH on 16:04, 14 August 17
The Simon Owen extension is more straightforward, but presumably if I see a 16kb sector then I should write only as much as I can physically fit? The way it's phrased as "the full 16K will be stored" presumably means "will be stored ... inside the DSK image", as there's no way to fit that 16kb onto a floppy.
Correct.


Quote from: ThomH on 16:04, 14 August 17
Also, are there any known disk images using either of the John Elliott or Simon Owen extensions?
A few DSKs do have the extra block that Samdisks writes. I can't tell you which off hand.

My games. My Games
My website with coding examples: Unofficial Amstrad WWW Resource

ThomH

Quote from: arnoldemu on 19:23, 14 August 17To handle this you should give back 8k of data, giving 0x01800 first then padding to the end.
Yeah, if I were the FDC* then — as long as DTL isn't involved, I guess I've seen the ID, with a valid CRC, progressed to the data field, and then will stream 8kb of data, almost certainly followed by discovering a CRC error. And the rest of the 8kb of data is unlikely to be anything useful as there'll almost certainly be a PLL discontinuity when crossing the index hole, followed by a fifteen-in-sixteen chance of framing errors on whatever I obtain when I get back into the same ID and header field.


Actually, that would have been a pretty good protection mechanism — with reproduction-grade hardware, space your data exactly so as to avoid the framing error and PLL discontinuity, and leave what happens to be the correct CRC in your own data. Required condition for recognition of the original disk: a full 8kb read without a CRC error.


* though I'm not. I'm really much more interested in reconstruction of the flux stream than in how to emulate an FDC.


I'll look into HFE, though it looks like it has a lot of code overhead.

arnoldemu

Quote from: ThomH on 19:47, 14 August 17
Yeah, if I were the FDC* then — as long as DTL isn't involved, I guess I've seen the ID, with a valid CRC, progressed to the data field, and then will stream 8kb of data, almost certainly followed by discovering a CRC error. And the rest of the 8kb of data is unlikely to be anything useful as there'll almost certainly be a PLL discontinuity when crossing the index hole, followed by a fifteen-in-sixteen chance of framing errors on whatever I obtain when I get back into the same ID and header field.
DTL only works (and then not that well it seems) on sectors size N=0.


Quote from: ThomH on 19:47, 14 August 17
Actually, that would have been a pretty good protection mechanism — with reproduction-grade hardware, space your data exactly so as to avoid the framing error and PLL discontinuity, and leave what happens to be the correct CRC in your own data. Required condition for recognition of the original disk: a full 8kb read without a CRC error.


* though I'm not. I'm really much more interested in reconstruction of the flux stream than in how to emulate an FDC.


I'll look into HFE, though it looks like it has a lot of code overhead.
8K sectors is a good protection on CPC. The problem is that if you let the FDC write the data it will go past the end of track, past the index and write over the id field and data field again breaking your data.
So you have to stop the FDC or force an error to make it stop.

Overrun is not useful because FDC will continue to the end, so you must force some other condition.

Turning the motor off is good, but it takes "a bit of time" for it to slow down, and if it takes too long again it's written over your id field and data field.

Rob Scott came up with a hardware modification that worked well.

The best protections are where the data pulses have been narrowed. You can fit more data in. The PLL can handle it and will sync to it, but you can't write it back because it will do it with a different timing.

Also look into the other one CT-RAW, that is even better.


My games. My Games
My website with coding examples: Unofficial Amstrad WWW Resource

ThomH

Quote from: arnoldemu on 09:24, 15 August 17The best protections are where the data pulses have been narrowed. You can fit more data in. The PLL can handle it and will sync to it, but you can't write it back because it will do it with a different timing.
For an 8272, presumably manufacturing with invalid CRCs is also an effective strategy? At least if you put a real CRC right at the end of your sector, as I can't see a way maliciously to write a bad CRC and adding a real CRC would prevent deliberately triggering overrun, or switching the motor off to avoid writing an updated CRC at all.


That aside, having taken a second look at HFE I completely withdraw my earlier method. It's clearly a very compact and simple thing. I misread the floppy interface modes as indicative of track formatting — I think I had in mind whichever of IPF or FDI it is that defines about 30 different ways that a track can be encoded, each of them being the default way that computer X does it. I guess that field is actually just about how to implement ready, specific motor timings, etc. Not stuff about the disk per se, as much as ensuring it is played back as though it were in that machine's original drive.

arnoldemu

Quote from: ThomH on 02:29, 18 August 17
For an 8272, presumably manufacturing with invalid CRCs is also an effective strategy? At least if you put a real CRC right at the end of your sector, as I can't see a way maliciously to write a bad CRC and adding a real CRC would prevent deliberately triggering overrun, or switching the motor off to avoid writing an updated CRC at all.
It does makes it more difficult to copy without the correct tools, but it depends on how much data you put on the track, because you can format at one size (N in the format command), and write IDs with another size and cause the fdc to think a CRC is invalid. Switching the motor off is another way because, as you say, turning it off stops it from writing the crc.

Quote from: ThomH on 02:29, 18 August 17
That aside, having taken a second look at HFE I completely withdraw my earlier method. It's clearly a very compact and simple thing. I misread the floppy interface modes as indicative of track formatting — I think I had in mind whichever of IPF or FDI it is that defines about 30 different ways that a track can be encoded, each of them being the default way that computer X does it. I guess that field is actually just about how to implement ready, specific motor timings, etc. Not stuff about the disk per se, as much as ensuring it is played back as though it were in that machine's original drive.
Yes. SPF is the best, HFE is next, DSK is worst.

But in the beginning DSK was first.


My games. My Games
My website with coding examples: Unofficial Amstrad WWW Resource

Powered by SMFPacks Menu Editor Mod