Despotik Design by ERE

[Puresox]

I am trying to get a copy of this working on Winape emulator. All the dumps I have tried fail to load ,The screen corrupts on the language select screen or nothing occurs at all. I have tried tape version also , but the same thing occurs. I have tried to get this working many times over the years , but have always come up against this same issue . However I am certain I did get one version to work, back in the recesses of my mind I can recall playing the game. I would like to try this game out again . Is it to do with settings or ? If anyone else who uses winape can get this game working could you let us know where I am going wrong with it. thanks

[Executioner]

The copy of Despotik Design on CPC Power (despotik design &copy ere informatique (1987)) appears to be completely corrupt on track 4. All sectors are showing as 256 bytes long, yet the loader attempts to read a 2048 byte sector (#29)

[TotO]

Please, get them informed about the problem. 

[Executioner]

The bottom of that page says:

Emulators: CPCE 1.94, WinCPC : Plantage
CPC++ : Ok

So, does it actually work in those emulators, and if so, how? Some secret version of the DSK specification which allows sector size data to be misrepresented in the EXTENDED format?

[Phantomz]

I am trying to get a copy of this working on Winape emulator. All the dumps I have tried fail to load ,The screen corrupts on the language select screen or nothing occurs at all. I have tried tape version also , but the same thing occurs. I have tried to get this working many times over the years , but have always come up against this same issue . However I am certain I did get one version to work, back in the recesses of my mind I can recall playing the game. I would like to try this game out again . Is it to do with settings or ? If anyone else who uses winape can get this game working could you let us know where I am going wrong with it. thanks

I just tried the cracked version from cpc-power, it loaded fine in winape 2.0 beta 1 for me, it only works when I tried 6128 mode though. 

However the original from cpc-power doesn't work.

If you want a working version of the original, try the original dump form cpcrulez

CPCRULEZ > AMSTRAD CPC > GAMESLIST > DESPOTIK DESIGN (c) ERE INFORMATIQUE

I believe this version will only work in 6128 mode too.


I've just converted the cracked disc from cpc-power to cpr, this cpr will run in winape in 464 plus or 6128 plus mode.

As I said the cracked disc on cpc-power works fine but only in 6128 mode.

The cart I've created from that disc is available here and will work in 464 plus or 6128 plus modes, I hope this helps. 

I've just tried the cngsoft cracked version, that too only works in 6128 mode.

I've just converted this cracked version too as the loading screen is the same as the original ( pass it by pressing space ) and the language select screen loads better.

The cart I've created from that disc is available here and will work in 464 plus or 6128 plus modes, I hope this helps too. 

[Puresox]

Ahh fairplay to you , thought this was long since forgotten.

[Puresox]

Stars you are! Downloaded the CPCRulez version and run in 6128 mode and works a dream, great little 12 Bar blues tune on it, now to get to grips with it .Cheers all for your efforts.

[dlfrsilver]

The copy of Despotik Design on CPC Power (despotik design &copy ere informatique (1987)) appears to be completely corrupt on track 4. All sectors are showing as 256 bytes long, yet the loader attempts to read a 2048 byte sector (#29)

Hello, it's actually a winape FDC bug. The dsk in original run perfectly on sugarbox as well as Caprice Forever 0.26, the actual 2 most advanced CPC classics emulators.

Track 4 is perfectly normal, there are no corruption whatsoever. The game loads a first time this track, and a bit after a second time.

The bottom of that page says:

Emulators: CPCE 1.94, WinCPC, (Winape!) : Plantage
CPC++, Sugarbox, Caprice Forever 0.26 : Ok

So, does it actually work in those emulators, and if so, how? Some secret version of the DSK specification which allows sector size data to be misrepresented in the EXTENDED format?

This game needs a perfect FDC emulation to run. The Remi Herbulot is not exactly a very complex protection track, and the dsk stores it exactly how the original disk has it.

It's an error in the FDC emulation, and maybe a z80 instruction set error, so can you please check what is wrong under winape ?

Cheers !

PS : to the people who want to run the original tape version, it has a nasty protection on the start, which also means to use an emulator using a perfect set of z80 instructions + flags + timings.

[Executioner]

Hello, it's actually a winape FDC bug.

No, it's not. It's a problem with the DSK image as I originally said. I have another original dump here which runs perfectly under WinAPE, and that version does have a 2048 byte sector on track 4 as it should have. I tested the version in the link on all emulators and it didn't work in any of them.

[dlfrsilver]

No, it's not. It's a problem with the DSK image as I originally said. I have another original dump here which runs perfectly under WinAPE, and that version does have a 2048 byte sector on track 4 as it should have. I tested the version in the link on all emulators and it didn't work in any of them.

Nope it's false. The protection track is made of many 256 bytes sectors, and 2 sectors declared as 2048 bytes but fake, otherwise the track would be too long if the sector size was really 2x2048 bytes.

I have tested the DSK you're talking about, and present on CPC-power, and it works under Caprice Forever 0.26 as well as sugarbox 0.26.

The other original dump you have and running under Winape is bad or too old or either generated with an old imager.

Let me illustrate exactly physically how the Remi Herbulot Copy Protection track looks like physically on the original amstrad CPC disk :

It's a track composed of 18 sectors, with a length of 6261 bytes. Each of the 2048 bytes sectors are fake, because those actually "fake", and

not real 2048 bytes sectors. To explain further, those sectors real size is 128 bytes, but in order to trick the FDC, they have been declared as

2048 bytes sectors. The consequence of a 128 byte sector declared as a 2048 bytes one is that you get a Data CRC error (normal, as the

CRC to be OK needs to be applied for the size declared).


If winape tries to load them as full size sectors, then you're wrong pal

Winape actually doesn't behaves correctly, because the FDC is not handling correctly what is contained inside the DSK.

Check the pictures :


1) The physical representation of the track. It's declared as a Size 4 sector, but it's only 128 bytes. Check by yourself below :

[attachimg=1][attachimg=2][attachimg=4]

[Executioner]

The consequence of a 128 byte sector declared as a 2048 bytes one is that you get a Data CRC error (normal, as the

CRC to be OK needs to be applied for the size declared).

Yes, but you don't get the CRC error until the FDC has read 2048 + 2 bytes, that means you have to know what would normally be read for the other bytes and the DSK image doesn't contain that information. The other questions are:

1. Why is that sector 128 bytes rather than 256 bytes like all the others, and where in the DSK image is that information?

2. If this is the normal way of representing such a format in a DSK image, what happens for the same when such a sector has been written, overwriting the other sectors? There's no information in a DSK image as to actual individual sector positions, and the sector could have a valid CRC overwriting other sectors yet the format size would be the same.

[dlfrsilver]

Yes, but you don't get the CRC error until the FDC has read 2048 + 2 bytes, that means you have to know what would normally be read for the other bytes and the DSK image doesn't contain that information.

2048 bytes is a fake information stored in the ID field. That's how the original disk is made.

There is a thing you don't seem to know afaik, it's that the upd765 used in the amstrad CPC, Atari ST and PC is a slave chip, it's interpreting what it finds on disk, and in many case, it even doesn't see how the datas are physically laid out on the disk !

What happens is it the error in the ID field makes the FDC trying to read up to 2048 bytes, but those 2048 bytes are not present on the disk. The rela amount of data is 128 bytes, as stated in the DATA Field.

It's a trick made to fool the FDC ! The DSK has not to contain this information since it does not exists !

This tricks has been used on a lot of CPC games.

The other questions are:

1. Why is that sector 128 bytes rather than 256 bytes like all the others, and where in the DSK image is that information?

Because that's how the protection is made and REALLY written physically on the original disk.

This information is written inside the DSK present on CPC-power. The problem is that Winape FDC emulation is not 100% perfect, and despotik Design needs that.

The FDC emulation inside Winape is in consequence not able to process correctly the protection track.

2. If this is the normal way of representing such a format in a DSK image, what happens for the same when such a sector has been written, overwriting the other sectors?

The protection used on despotik design as well as other Ere Informatique games is correctly described and stored inside the extended DSK format. The right question is : is the FDC behaviour correct ?

Then the sectors are overlapped inside the DSK. That's the case for the KBI-19 protection track.

There's no information in a DSK image as to actual individual sector positions, and the sector could have a valid CRC overwriting other sectors yet the format size would be the same.

Nope. The valid CRC you're talking about is then used as trick to fool the FDC and make the copy fails. The real goal is in fact to hide the DATA CRC error.

I'll post the view of a KBI-19 protection track later to illustrate my words.

[Executioner]

2048 bytes is a fake information stored in the ID field. That's how the original disk is made.

Yes, it's easy to do, you can specify whatever sector header information you want when you format the track. That doesn't make the header incorrect, just means the data is not formatted to the same length as the sector.

There is a thing you don't seem to know afaik, it's that the upd765 used in the amstrad CPC, Atari ST and PC is a slave chip, it's interpreting what it finds on disk, and in many case, it even doesn't see how the datas are physically laid out on the disk !

Yes, I do understand that.

What happens is it the error in the ID field makes the FDC trying to read up to 2048 bytes, but those 2048 bytes are not present on the disk. The rela amount of data is 128 bytes, as stated in the DATA Field.

Depending on your point of view, the error is either in the header as you say, or it is in the data itself. If you were to perform a write of this sector under normal conditions it would create a valid 2048 byte sector with the exact same header, overwriting the next few sectors headers. I know, I have done this exact thing to create the original Xexor protection.

It's a trick made to fool the FDC ! The DSK has not to contain this information since it does not exists !

The DSK doesn't contain enough information to reproduce the gap data and syncs up to the next header without making a couple of assumptions.

1. The GAP3 in the track header is correct and the same for all sectors on the track.

2. The sector has never been written to, which may cause the Gap data to move by a few bits, meaning the next sector sync information would be out by a number of bits (ie. the A1 A1 A1 FE wouldn't read as such any more). In fact the Gap3 data wouldn't even read as #4E would it?

With those two assumptions this contains enough information to know the byte at offset #120 (checked by the protection) is #44. In an ideal world, you may be able to reconstruct that by assuming the bits will be exactly aligned on the next sector header, but under certains circumstances (eg. sector writes without the exact same timing) those bits can't be predicted.

Assuming the other image I have is taken from an original disc, the sector in question was formatted as 256 bytes with a filler byte of #DD. The checksum adds up at offset #100 (#57FE) exactly as it should after formatting. This indicates it's got 256 bytes of valid data followed by a checksum (I still don't know how you determined it was 128 bytes). Luckily the sector has never been written to after formatting so the data up to the next sector header is intact, including the checksum, gap3 data, sync and address mark of the next sector.

This information is written inside the DSK present on CPC-power.

Only if the above assumptions are made about the next sector header position relative to the end of the current sector accurate to a single MFM flux transition.

The problem is that Winape FDC emulation is not 100% perfect, and despotik Design needs that.

I agree the FDC emulation is not 100% perfect. The Extended DSK format is not perfect either.

The protection used on despotik design as well as other Ere Informatique games is correctly described and stored inside the extended DSK format.

I still disagree with this statement. In this case, making the assumptions I stated you can reproduce the track layout quite accurately.

The right question is : is the FDC behaviour correct ?

[dlfrsilver]

Yes, it's easy to do, you can specify whatever sector header information you want when you format the track. That doesn't make the header incorrect, just means the data is not formatted to the same length as the sector.

The actual information was not cheated, or added by hand. It's coming from the original disk dump made with kryoflux. Hence what i say is the truth.

Depending on your point of view, the error is either in the header as you say, or it is in the data itself. If you were to perform a write of this sector under normal conditions it would create a valid 2048 byte sector with the exact same header, overwriting the next few sectors headers. I know, I have done this exact thing to create the original Xexor protection.

The error was volontary made by Remi Herbulot. This track can't be copied with a CPC FDC. The fake 2048 bytes sectors is not overwritten the next sectors on the original disk, please check carefully the graphics i posted (PS : those graphics were not made from the DSK, but from the original disk dump in flux !)

The DSK doesn't contain enough information to reproduce the gap data and syncs up to the next header without making a couple of assumptions.

The CPC FDC never see the syncs. That's one of its particularity. The Atari ST FDC sees them however

1. The GAP3 in the track header is correct and the same for all sectors on the track.

It is since Samdisk processed the DSK thru the flux dump i used.

2. The sector has never been written to, which may cause the Gap data to move by a few bits, meaning the next sector sync information would be out by a number of bits (ie. the A1 A1 A1 FE wouldn't read as such any more). In fact the Gap3 data wouldn't even read as #4E would it?

I will post the actual data of the track taken from the Aufit tool.

With those two assumptions this contains enough information to know the byte at offset #120 (checked by the protection) is #44. In an ideal world, you may be able to reconstruct that by assuming the bits will be exactly aligned on the next sector header, but under certains circumstances (eg. sector writes without the exact same timing) those bits can't be predicted.

Assuming the other image I have is taken from an original disc, the sector in question was formatted as 256 bytes with a filler byte of #DD. The checksum adds up at offset #100 (#57FE) exactly as it should after formatting.

Yes i see the checksum 57FE. But as said, this checksum is wrong because it has been calculated for 2048 bytes and not for the 256 bytes declared (only 128 bytes are seen, sorry but after checking more carefully, it appears that the sector size is also BAD ! only 128 bytes on the 256 are declared in the Data Field.

But in itself, the DATA CRC is BAD, because it's sum is based on a wrong data length.

This indicates it's got 256 bytes of valid data followed by a checksum (I still don't know how you determined it was 128 bytes).

That's how the protection is actually made. The ID field sector size declared is false, the ID Data field is false too !

Both 2048 bytes fake sectors are declared as FDC errors.

Luckily the sector has never been written to after formatting so the data up to the next sector header is intact, including the checksum, gap3 data, sync and address mark of the next sector.

Of course, since it's a false and fake sector ! Just think about it for a minute :

When the CPC FDC reads the ID field, it sees 2048 bytes, and then 8 256 bytes sectors, another fake 2048 bytes sectors, followed by another 8 256 bytes sectors.

It will fails as soon as you ask it to copy the 2 fake size 4 sectors, this when both are only 256 bytes. The CPC FDC is so stupid that he will stop !

The same principle is used reversely on the hexagon disk protection. The size declared in the ID field (the header), is only 512 bytes sector. And all the remaining data is seen as contained in a huge 5278 bytes GAP.

What is doing the CPC FDC when it sees that ? Easy : It will only read and write back the first 512 bytes declared, leaving the remaining 5278 bytes of data, because the CPC FDC is unable in hardware to copy GAP contents !!!

I agree the FDC emulation is not 100% perfect. The Extended DSK format is not perfect either.

It's not perfect, i agree with that. But the Remi Herbulot protection has nothing complicated and the DSK format perfectly store it.

Like with other games, you have in fact a FDC problem. Caprice Forever and Sugarbox have both a perfect FDC emulation, and they are

making the DSK working and loading correctly.

So i let you conclude for yourself about Winape problem on this copy protection.

I still disagree with this statement. In this case, making the assumptions I stated you can reproduce the track layout quite accurately.

The 2048 bytes sectors must not be FULL in the DSK. They are not FULL in the original dump of the disk in stream flux.

[/quote]

[Executioner]

The actual information was not cheated, or added by hand. It's coming from the original disk dump made with kryoflux. Hence what i say is the truth.

I wasn't suggesting it was added by hand, or arguing with you. The header and sector checksum are correct as a normal size 01 (256 byte) sector would be when created with a 765 format command with D5 as the filler byte. The header is actually valid. I used a similar technique to create the protection on Xexor but wrote to the sectors afterwards.

The error was volontary made by Remi Herbulot. This track can't be copied with a CPC FDC. The fake 2048 bytes sectors is not overwritten the next sectors on the original disk, please check carefully the graphics i posted (PS : those graphics were not made from the DSK, but from the original disk dump in flux !)

I'm pretty sure this track could be created using a 765 FDC in the CPC. The secret is to use D5 filler byte and never write to the #29 sector. Simply set up a format command with 18 sectors, give them all the correct headers (eg. 04 00 29 04, 04 00 44 01 etc), specify D5 as the filler byte, 12 bytes for Gap3, and look at what the 765 creates on the Amstrad. You should then be able to write data to all sectors but the #29 ones (although you may have to write twice quickly to write both copies of each of the other sectors on the same track).

Yes i see the checksum 57FE. But as said, this checksum is wrong because it has been calculated for 2048 bytes and not for the 256 bytes declared

The checksum is correct for the 256 byte field. I've added code in WinAPE to calculate the checksum of the sector and fill in the checksum/gap3/sync/header of next sector data with checksum to get it working. It calculates to #57FE.

(only 128 bytes are seen, sorry but after checking more carefully, it appears that the sector size is also BAD ! only 128 bytes on the 256 are declared in the Data Field.

I'm not sure what you mean by declared in the data field. There isn't a length specified in any MFM header, apart from the sector CHRN which specifies 2048 bytes. Yes, the CRC is wrong (for 2048 bytes) and the sector size is only 256 bytes, but why is Kyroflux thinking it's only 128 bytes? A bug in Kyroflux software perhaps?

It will fails as soon as you ask it to copy the 2 fake size 4 sectors, this when both are only 256 bytes. The CPC FDC is so stupid that he will stop !

The FDC does what the software tells it to do and will write 2048 bytes on the sector if you actually write it, but the 765 format command works differently and uses the specified format size (01) to create the checksum/gap data etc. If the CPC (Z80) doesn't tell the 765 to write that sector at all it should copy successfully, problem is there is no copier capable of giving the FDC the correct sequence of format/write commands. Maybe Xexor could with a Brain file.

It's not perfect, i agree with that. But the Remi Herbulot protection has nothing complicated and the DSK format perfectly store it.

I'm happy to assume the CRC/gap/sync/header is intact, it's better than not filling the inter-sector gap with nothing, but it's not ideal. A HFE or IPF image contains all the inter-sector information. The DSK format does not, and hence it's actually impossible to accurately recreate the data after the sector CRC in ALL cases, so there are other cases where making this assumption is not valid. (eg. most sectors that have been written to have the gap data bits shifted).

Caprice Forever and Sugarbox have both a perfect FDC emulation

I'm sure their authors probably wouldn't be able to honestly agree with that "perfect" statement either.

The 2048 bytes sectors must not be FULL in the DSK. They are not FULL in the original dump of the disk in stream flux.

Where did I ever say they were "full".

[arnoldemu]

@Executioner is correct, the DSK specification has proven to be unsuitable for describing disc protections, there is not enough information. I know samdisk adds additional information to try and recreate the data but not all dsks have this.

The best are the full MFM based dumps such as HFE, IPF, those types because they have all the necessary information.

The DSK specification was extended at a time where knowledge on protections was limited and so had bits added to make most things work although not accurately representing the real disc and also making discs that were not possible to write back.

It is also true the snapshot specification is also unsuitable - it lacks a lot of information and is unsuitable for describing a cpc with expansions. It too had basic information and was then extended for Plus, but still it is not really suitable. In fact it's only really suitable for a base CPC6128 or base CPC464 with no additional roms, hardware, ram etc.

Saying the fdc emulation in sugarbox and caprice forever are perfect is quite a statement unless you have proof. Perfect means I can run all tests I can think of and it passes all 100%

The "acid test" I wrote is meant to prove some level of accuracy. Run it against an emulator and you can know if it passes the tests I put in. All tests have been run against real CPCs and Pluses. I have not tested everything (yet) but there are a lot of tests.

I am sure sugarbox and caprice are better than other emulators in terms of disk emulation - that can be prooved.

[dlfrsilver]

I wasn't suggesting it was added by hand, or arguing with you. The header and sector checksum are correct as a normal size 01 (256 byte) sector would be when created with a 765 format command with D5 as the filler byte. The header is actually valid. I used a similar technique to create the protection on Xexor but wrote to the sectors afterwards.

The sectors of 256 bytes in size are indeed size 1.

I'm pretty sure this track could be created using a 765 FDC in the CPC. The secret is to use D5 filler byte and never write to the #29 sector. Simply set up a format command with 18 sectors, give them all the correct headers (eg. 04 00 29 04, 04 00 44 01 etc), specify D5 as the filler byte, 12 bytes for Gap3, and look at what the 765 creates on the Amstrad. You should then be able to write data to all sectors but the #29 ones (although you may have to write twice quickly to write both copies of each of the other sectors on the same track).

Nope. The Remi Herbulot protection track was made and written on an industrial trace machine. That's a common CPC owners fantasm to think the publishers were doing their copy protection on the target machine. the Remi Herbulot is an industrial copy protection, built and written on a special drive with a custom FDC controller.

When a copy protection was made on a CPC, the actual analyser i use to process IPFs recognize the dump as not duplicated, even if the programmer has added the game on a disk with the protection duplicated on it.

All Ere informatique software were duplicated and duplicated on industrial machines. That's why your explanation is just wrong about the fact that this track can be copied on an Amstrad.

I'm not sure what you mean by declared in the data field. There isn't a length specified in any MFM header, apart from the sector CHRN which specifies 2048 bytes. Yes, the CRC is wrong (for 2048 bytes) and the sector size is only 256 bytes, but why is Kyroflux thinking it's only 128 bytes? A bug in Kyroflux software perhaps?[/size]

Under Aufit i have a full view of the ID field and the DATA field, a thing you can have access to with the tool you have in hand.

The tool used is not kryoflux, but a tool called AUFIT, running on Atari ST, which use the same FDC as the Amstrad CPC, but with a bit more possibilities.

Aufit sees when i interrogated about the track that the DATA field size is even tricked.

The FDC does what the software tells it to do and will write 2048 bytes on the sector if you actually write it, but the 765 format command works differently and uses the specified format size (01) to create the checksum/gap data etc. If the CPC (Z80) doesn't tell the 765 to write that sector at all it should copy successfully, problem is there is no copier capable of giving the FDC the correct sequence of format/write commands. Maybe Xexor could with a Brain file.[/size]

The CPC FDC stops as soon as it sees the length of data it think it has to copy. The track length is 6261 bytes, and it's a long track. A track this long can't be copied by a standard CPC drive.

I'm happy to assume the CRC/gap/sync/header is intact, it's better than not filling the inter-sector gap with nothing, but it's not ideal. A HFE or IPF image contains all the inter-sector information.[/size]

[/size]
[/size]Yes the IPF image contains all the inter-sector informations.

The DSK format does not, and hence it's actually impossible to accurately recreate the data after the sector CRC in ALL cases, so there are other cases where making this assumption is not valid. (eg. most sectors that have been written to have the gap data bits shifted).[/size]

The MFM values are actually never seen by the CPC FDC, it only sees sectors, and this protection track has been written with a whole track, not sector per sector.

I'm sure their authors probably wouldn't be able to honestly agree with that "perfect" statement either.[/size]

They do. I got in my hands all the games or tools using the most umprobable copy protections, and they are all working under caprice forever and Sugarbox.

[dlfrsilver]

@Executioner is correct, the DSK specification has proven to be unsuitable for describing disc protections, there is not enough information. I know samdisk adds additional information to try and recreate the data but not all dsks have this.

For god sake, how can you say you're not aware of this know fact ?

Of course the DSK specification is unsuited for quite a number of copy protections ! This for at least 2 reasons :

1) The CPC FDC in many case is unable to see how the disk datas are exactly laid out. I've discovered this when i started dumping original disks on Amstrad CPC, and by checking the protection patterns on the stream flux dumps and the DSK dumps.

Most of the time, samdisk and the other imaging tools were either cheating when they stored the copy protection found in a disk, or even simulating the protection, which was rendering it completely different from the original content.


The Data overlay, Data over index, as well as overlapping sectors are simulated in the extended DSK format, this because most protection were written with another machine than a CPC (mostly a PC or an atari ST with custom FDC).

The best are the full MFM based dumps such as HFE, IPF, those types because they have all the necessary information.[/size]

Yes for sure

The DSK specification was extended at a time where knowledge on protections was limited and so had bits added to make most things work although not accurately representing the real disc and also making discs that were not possible to write back.[/size]

It's still the case, just try to write back a game using the KBI-19 copy protection, without a write track command impossible to do.

And there are other, as i wrote above. Those are impossible to store as it is inside an extended DSK.

Saying the fdc emulation in sugarbox and caprice forever are perfect is quite a statement unless you have proof. Perfect means I can run all tests I can think of and it passes all 100% [/size]

It is indeed the case. Like i wrote to Winape emulator author, i have tested the hardest cases on sugarbox as well as Caprice Forever, and those two pass the worst protection case, when winape just break its teeth down the carpet.

I am sure sugarbox and caprice are better than other emulators in terms of disk emulation - that can be prooved.

More than a proof : each time i dump a new batch of original amstrad CPC disks, i use them to verify my outputs. And the games works !


It can happen that some games use some nasty FDC behaviour, like reading a track like if the sectors were size 2 and redo a read but this time trying to read them while indicating they're sector size 3. If the FDC emulation is not correct, KABOOMMM ! The emulator crash.

[Nich]

For god sake, how can you say you're not aware of this know fact ?

Whoa, did someone else get out of the wrong side of bed this morning?

[Executioner]

It's no use arguing with someone who thinks they know it all and assumes you know nothing. Besides that he's obviously got it in for WinAPE and would rather criticise with statements such as "when winape just break its teeth down the carpet" than actually provide any constructive comments.

[khaz]

I do have a question though. Regardless of who gets it right with how this specific game uses its disc, it seems that you both agree than the dsk format to store a virtual copy of a disc isn't a good format. Not all the data is stored (or not in the correct way), and potentially critical data can be missing or misread, preventing software to run.

What is the ideal format to store disc images, and why haven't we switched to it yet? If HFE is better, we should redump our stuff in this format and it should be the format of choice when downloading disc images on the internet. I'm assuming that for most disc images without a complex data protection scheme, a simple conversion from DSK to HFE should be enough?

[TFM]

HFE makes some troubles over DSK. For example if I use my fast disc OS functions to read 400 KB in a row then it works fine from a DSK, but takes 10 times longer when using a HFE. I discussed that in the HxC forum, but nobody knows the source of the problem I guess. So I stick with DSK. 

[robcfg]

Just out of curiosity, are you reading disk images through an emulator or anything else?


It sounds indeed weird, because on a HxC it would be like having a real disk, and on an emulator there shouldn't be much difference unless the decode logic is too complicated.

[Executioner]

If HFE is better, we should redump our stuff in this format and it should be the format of choice when downloading disc images on the internet.

HFE is better in most ways, but totally unneccessary for the majority (99%) of disc images since their protection mechanisms are usually simple or non-existent. There are a few cases where inter-sector information is read or weak sectors are used where a HFE image could be better in order to reconstruct that information, but the extended DSK format does actually have the ability to store sectors including their gap information, it's just not used in this case, and left up to the "perfect" emulation to invent it, assuming that the format behaves exactly as per the MFM specification.

During a 765 format operation, the FDC sends write data to the floppy in order to create the track SYNC, GAP, sector SYNC, ID ADDRESS MARK, ID CRC, GAP2, data SYNC, data, CRC and GAP3 for each sector on the track. At the time the track is formatted, you should be able to read back the inter-sector data, and you can see the actual inter-sector data. If, however, you write to a sector it can cause the bit stream after the data CRC to be shifted as far as the 765 sees it, so rather than the usual gap data (ie. #4E gap data, SYNC, next sector ID), you get different bytes back from the FDC. If a protection used that changed data, there would be no way to represent it in a DSK image, except to include it with the sector data itself.

There is no real way for an emulator to know whether to make the assumption that the sector has never been written to and hence the inter-sector information is standard, and that's assuming the protection was created using a standard MFM format, which apparently Despotik Design is not (although I beg to differ on that point). Other protections like KBI actually have data written inside the gaps themselves and smaller sectors than are actually possible to produce using a uPD765 in a standard way like the CPC. There are still ways of representing this data using the DSK format though.

[Executioner]

It sounds indeed weird, because on a HxC it would be like having a real disk, and on an emulator there shouldn't be much difference unless the decode logic is too complicated.

Yes, I can't see why a HFE could possibly be slower, unless he's using an emulator that doesn't time DSK sector layout correctly.