This is the first time I hear of 86Box supporting .HFE, now .MFM we do support, but the problem with the standard .MFM format is that it's inadequate - the amount of bitcells is rounded to the nearest byte so if the track wraps around in the middle of a sector, that sector is unusable, and all the data (RPM, etc.) is only stored once for the entire disk instead of per-track and per-side. I did create my own version of the .MFM format that addressed these problems and even submitted it to the developer of HxC but it never got accepted. He did begin working on .86F support instead but I'm not sure what state that's currently in.

However, none of the above emulators fully simulates the operation of FDC.

What exactly is not simulated by 86Box? It internally converts every inserted floppy image to a MFM (or FM)-encoded surface if it's not already one, and processes the data bit by bit, decoding the various address marks, etc. Though, of course, it's not perfect, so there may be edge cases where it returns the incorrect error.

Battler wrote on 2024-06-02, 23:24:

This is the first time I hear of 86Box supporting .HFE

I think I got 86Box and IBMULATOR messed, sorry.

Battler wrote on 2024-06-02, 23:24:

What exactly is not simulated by 86Box?

PM sent.

Thanks for dropping this interesting title and protection.

The protection code seems fairly robust - the code is heavily obfuscated, with lots of self-modifying code, anti-debugger measures and direct disk controller access to read the protection track. If you trip up the protection in the wrong way it will start writing to the disk, which is concerning! Ultimately you can handle emulation of this title if you set the 'wrong cylinder' flag properly.

Track 7 is identical on both sides of the disk and has the following sector layout:

1Track 7
2    [c:80 h:0 s:5  n: 5]
3    [c:80 h:0 s:5  n: 3]
4    [c:80 h:0 s:6  n: 3]
5    [c:80 h:0 s:7  n: 3]
6    [c:80 h:0 s:8  n: 1]
7    [c:7  h:0 s:5  n: 2]
8    [c:0  h:0 s:9  n: 1]
9    [c:0  h:0 s:11 n: 1]
10    [c:0  h:0 s:12 n: 1]
11    [c:7  h:0 s:6  n: 2]

As you can see only 2 sectors on Track 7 have the correct cylinder field, and on Side 1 they all have the wrong head. The protection checks them individually then issues a Read Track command, again with an invalid cylinder field.

MartyPC 0.3.0 will run this directly from the PRI:

The disk image is full of write splices. From what I can tell, EliaShim produced pre-made 'protection diskettes', similar to what Vault did with Prolok. You'd purchase them and put your program on it, so it explains why the disk does not look professionally duplicated.

GloriousCow wrote on 2024-10-06, 22:09:

MartyPC 0.3.0 will run this directly from the PRI

This is interesting.
If MartyPC will support keydisk protected PRI images, it will be wonderful that the "Laser hole" and the "Cops Copylock II" protection type also be emulated.
Refer to :
Laser hole protection : https://forum.winworldpc.com/discussion/9472/ … -dbase-iii-r1-0
Cops Copylock II protection : https://forum.winworldpc.com/discussion/14689 … -copy-protected

ultrahrc wrote on 2024-10-09, 14:10:

If MartyPC will support keydisk protected PRI images, it will be wonderful that the "Laser hole" and the "Cops Copylock II" pro […]
Show full quote

If MartyPC will support keydisk protected PRI images, it will be wonderful that the "Laser hole" and the "Cops Copylock II" protection type also be emulated.
Refer to :
Laser hole protection : https://forum.winworldpc.com/discussion/9472/ … -dbase-iii-r1-0
Cops Copylock II protection : https://forum.winworldpc.com/discussion/14689 … -copy-protected

PROLOK already works - I wrote a long blog post on Vault and their protection schemes:
https://martypc.blogspot.com/2024/09/pc-flopp … ult-prolok.html

I've been looking at Cop's Copylock II - one problem is I have not been able to make a working floppy of it from kyroflux in the first place. I've re-dumped my copy and it looks identical to the original, but it gets "General failure reading drive a". I wonder, did it need an AT+ disk controller? It also checks drive timings and measures RPM, which MartyPC doesn't emulate at the moment. There's also a Cop's Copylock III, but I haven't seen anything actually protected by it.

But my goal is to support every copy protected diskette for the PC.

GloriousCow wrote on 2024-10-09, 15:03:

Cop's Copylock II

Looks like is does some of the same stuff as CodeSafe

1[:isa3:fdc_xt:fdc] command seek 16
2[:isa3:fdc_xt:fdc] command done (seek) - results=(none)
3[:isa3:fdc_xt:fdc] command sense interrupt status (fid=0 20 10) (':maincpu' (99D20))
4[:isa3:fdc_xt:fdc] command read data mt mfm sk cmd=e6 sel=0 chrn=(17, 120, 0, 128) eot=09 gpl=28 dtl=ff rate=250000
5[:isa3:fdc_xt:fdc] command done (data) - results=(40,20,00,11,78,00,00)
6[:isa3:fdc_xt:fdc] command seek 16
7[:isa3:fdc_xt:fdc] command done (seek) - results=(none)
8[:isa3:fdc_xt:fdc] command sense interrupt status (fid=0 20 10) (':maincpu' (99D20))
9[:isa3:fdc_xt:fdc] command read track mfm cmd=62 sel=0 chrn=(16, 0, 1, 512) eot=09 gpl=28 dtl=ff rate=250000
10[:isa3:fdc_xt:fdc] command done (data) - results=(00,24,10,10,00,01,02)
11[:isa3:fdc_xt:fdc] command seek 16
12[:isa3:fdc_xt:fdc] command done (seek) - results=(none)
13[:isa3:fdc_xt:fdc] command sense interrupt status (fid=0 20 10) (':maincpu' (99D20))
14[:isa3:fdc_xt:fdc] command read track mfm cmd=62 sel=0 chrn=(16, 0, 1, 8192) eot=09 gpl=28 dtl=ff rate=250000
15[:isa3:fdc_xt:fdc] command done (data) - results=(00,24,20,10,00,01,06)

The demo disk puts a number of sectors crossing the index, so i suspected it will attempt to read them and detect discontinuities.

My visualization doesn't overlap the end of the track with the start of the next, but those last few sectors do.