Extracts from: "Looking for Rob Northen originals images"

Original text Looking for Rob Northen originals images

(Ijor) Rob Northen CopyLock protection has a portion of one sector with a different bit-rate than the nominal one. A different bit-rate means that it will take a different amount of time to read. The code reads the "protected" sector measuring the time it takes, does the same with a "normal" sector; and then compares the time. If the difference is at least the expected one, the code assumes the disk is original. In all disks I've seen the "protected" sector is #6 on track 0. The protected sector also has a key that it is used to decrypt the software. The idea is that you can't use the protection on one disk to decrypt a different game. Some disks have a few additional disk checks. And there is an earlier CopyLock protection that is much simpler and can be copied with a software copier. There are several variants of the code. Most of them include a PACKER. A code for stopping debugging and hacking. The packer executes encrypted code by tracing each instruction, decrypting the next and re-encrypting the previous one. That's why when the protection is run it runs very slow. Most of the time the protections runs only once as a wrapper to the main code. Others it's embedded in the main code and can be run several times during run-time. The Packer was also used by other disk protections. Probably they licensed the Packer separately from the on-disk copy protection.

(Zippy) The ST floppy drive reads the track at the same speed as normal, but the data either comes into the floppy controller slower or quicker than normal depending on whether the drive motor was speeded up or slowed down during writing. I experimented with disc protection a bit, just with a "long track" by slowing down the drive (which was basically how the "proto-scan" ST/AMIGA protection system worked). There was a utility which displayed the floppy RPM in real-time and you could adjust the motor speed up/down about 5-7% and it still worked OK. If you speeded up the drive then the disc would rotate quicker meaning the time for a single rotation was reduced... the FDC would write data at the normal rate so the track would be shorter (less bytes) than normal. Conversely, if you slowed the drive speed down then you could write more data during a single rotation. When reading the track back in at normal speed the bytes of the "long track" would be shorter and coming in quicker than normal, with a "short" track the bytes would be longer and coming into the FDC slower. The rob Northen protection varied the drive speed (during writing of the keydisk) only on 1 sector, and then compared how long it took to read that sector back in in relation to how long it took to read one of the normal sectors from the same track.

(Ijor) In a “normal” ST system the FDC writes at a bit-rate of 250 Kbps (one bit every 4 microseconds). The bit-rate (so to speak) on the magnetic surface depends also on the rotational speed of the drive. Technically there is no such thing as bit-rate in the disk, but there is density instead. The mechanical motion of the disk has the effect of translating distance (density) to time (bit-rate) and vice versa. So the final bit-rate produced when reading, depends both on the written bit-rate and the relation between the rotational speeds of both drives (the drive used when writing and the current drive used when reading). Normally both drives would rotate in theory at the same speed (300 RPM) and then the read bit-rate would be “exactly” the same as the written one. Obviously that in practice, there are always small differences, and even the speed of any drive is not exactly constant. But the difference normally is very small and you “read” what you “write”. But this doesn’t need to be the always the case. The drive used when writing might rotate at a very different speed. Actually, almost all ST (and modern) original disks were written with a drive rotating much faster. For speeding duplication, duplicators typically use “faster” drives at a minimum of x2 (600 RPM), x3 (900 RPM) or even x4 (1200 RPM). The written bit-rate must be altered proportionally to compensate for the faster rotational speed. If using an x2 speed drive, the duplicator’s controller uses a bit-rate twice as fast (500 Kbps). So it is important to understand that alterations on the “destination drive speed” and on the original bit-rate written by the controller, are equivalent. A drive rotating twice as fast, or a controller writing twice as fast, has exactly the same effect. And if both are altered in the same proportion, the effect is nullified.

[Leonard  wrote] In that case, did the ST floppy engine slow down when reading that "slow sector" ?
(Ijor) No. Within certain limits, the reading FDC will adapt itself to the bit-rate coming from the disk drive. This is thanks to an FDC component called “PLL” (Phase-Lock Loop). The full explanation is a bit complex. Probably there are good on-line descriptions about how a PLL work (PLL is not restricted to drives). Just Google PLL. The important point for our purpose is that the FDC will deliver data to the computer at the rate sent by the drive. So if the disk was written at a faster bit-rate, the FDC will take less time to read a sector.

[Leonard  wrote]  Do you mean the data are written with another floppy rotational speed ?
(Ijor) Not exactly. Changing the drive speed was sometimes used as an “amateur” way of creating or copying some protections. But it is too unreliable and too cumbersome for professional use. And it is probably even unfeasible to change the speed of the drive accurately enough in the middle of a track. Instead of altering the drive speed, the controller bit-rate when writing was altered. Obviously, electronics are faster and more reliable than mechanics. A standard FDC uses a constant bit-rate (assuming a constant density, clock and modulation). But advanced controllers allow for changing the bit-rate “on the fly”. That’s how a duplicator’s controller created the protection. And that’s how a Catweasel or a Discovery Cartridge can copy CopyLock disks using a standard speed drive.

[Zippy  wrote]  I always thought they just had very accurate control of drive RPM speed and varied it during writing the protection, but of course as you say it's a lot easier and more reliable to vary the bit rate of writing the data, with a constant RPM of the drive.
(Ijor) Well, some older (8-bit) commercial disks were indeed protected modifying the drive speed. And some Atari 8-bit hardware copiers had a switch that allowed to change the speed. Cheaper models had a manual switch, others was electronically controlled by the software/firmware. But this was for producing long/slow tracks, and only when advanced controllers were not available or not affordable. This can't be done fast and accurately enough in the middle of a track, as the CopyLock protection requires. Even modern hard disks and CD-DVD readers take a significant spin-up time.
It is interesting to note that measuring the sector time in the ST is not so easy. This is because the DMA chip seats in the middle between the CPU and the FDC (you can disable DMA if you want, but it won't help). Not so difficult for CopyLock, but harder for other one:  There is another ST protection, more advanced than CopyLock if you want, that has a variable bit-rate in the very same sector. The sector is divided in sections and each section has a different bit-rate. The average is the normal/nominal one! Actually CopyLock has a variable bit-rate in the protected sector as well. But the protection doesn't check this. It just checks if the average rate is slower enough than other sector.

[Leonard  wrote] How does PASTI image-maker work for rob Northen disk ? I mean, if you read an original track, you get all data, but you can't know if a sector was written at higher speed or not ? Did PASTI image include disk data + timing info on each sector ?
(Ijor) Yes

[Leonard  wrote] You said if it stay in a range, a drive can write data at higher bitrates, and data is still readable on a classic ST. What's the size of the range ?
(Ijor) I don't know the exact range, but it is quite small for reading without errors. Something in the order of 4-5% off the nominal rate. It’s not symmetric. It seems the FDC is more tolerant for slower than faster bitrates. You can extend the range (probably to around 10%) if you don't mind getting some errors (could be useful for a protection). The exact numbers will be different for a different FDC (it mostly depends on the PLL). For example, the FDC on a PC usually has a better tolerance. Note that there is a limit imposed by the drive and the media as well. Even when using, say a Discovery Cartridge for reading and writing, you can't increase the bit-rate too much.

[Leonard  wrote] imagine an advanced controller writing at 1.5 speed. If the disk still is readable by ATARI FDC, then I can do Atari disk with 13,14 or 15 sectors per track ?
(Ijor) Sorry, no chance. There are some ways to get more data per track, but not more sectors. Actually the best way to do this is to use less sectors. Each sector has an overhead (sector header, syncs, and the gap bytes between header and sector and between two sectors). So one sector of 1024 bytes takes less space of the overall track than two 512 bytes sector. Many games use this "trick" to fit more data. You can easily fit 5 1024 bytes sectors, plus a normal 512 bytes one. And this is much more reliable than using 11 sectors per track. Combining this with a slight increase in the bit-rate, plus some gap tricks, and you can reach 6 1024 bytes sectors per track.

 (Zippy) Here's some more goodies found on my HD image, this program will help you create working Rob Northen Keydisk originals from non-working copies, if you already have 1 working keydisk. I've included the COPY_ROB.PRG as well as the source code file and the 2 included binary files so you can change/assemble your own version if required. If you have a working keydisk and a non-working copy off an original this program will write the copy back over the working keydisk and change the "magic number" to the correct value, thus creating a working original. In theory this should work with PASTI but I haven't tested it, so you may need a proper ST (with at least 1 MEG RAM) for it to work 100%. There are full instructions on the help screens in the program. The magic number is calculated from the fist part of the sector (which is written at normal speed)... so by ending the write command mid sector (before it overwrites the different speed part) you can change the magic number and still leave the protection fully intact.

(Bit5) ... and in addition -from the master himself- a tool to verify the written keydisk and print out the magic key number. Of course it is encrypted but it doesn't contain tons of garbage code like in the protected programs. Just search for $4afc as usually.

(Ijor) Btw, this shows one the main failures of the CopyLock protection. Not the fact that the key can be changed, this is not easy to defeat reliably. But the fact that the key can be read with normal tools. This way a "supplier" can easily make a non-working copy and send it to a cracker. This can't be done with other protections.

(Leonard) First of all I understand Rob Northen protection (thanks to Ijor) : a sector is written by different speed (using different hardware). Then the original game code can test that sector using internal clock ( measuring time needed to read sector). Now some people speak about "key" and "decryption". It seems that you can write a "valid key" on a illegal copy, and make things works.
Could you explain a bit more ? Is the protection reading a key data on the "speeded sector" ? Is it working even if the sector is read at low speed ? Did someone have info about the ciphering algorithm used ? I'm very curious about the mixing of these two techniques: anti-copy sector using speed, and strange "hidden disk key" feature. Could someone help me to understand how these two techniques are working in "Rob Northen" system ?

(Bit5) Yes, the "speeded sector" contains the data for calculation of the magic key. The algorithm is quite simple as you can see below. It may be different in several programs. The key won't be calculated in case the protection validation fails. But, who cares ? You have all input you need when you copy the sector best match. This is one of the weaknesses mentioned before. All the routines for reading the sector or calculation are encrypted. The idea behind this is quite good but there is the next weak point...

Code:
00000298   [7000                        moveq.l #$0,d0
0000029A   [323c 0003                   move.w  #$3,d1
0000029E   [204b                        movea.l a3,a0               ;buffer at $5cc
000002A0   [9098                        sub.l   (a0)+,d0
000002A2   [51c9 fffc                   dbra    d1,$2a0
000002A6   [b0bc b34c 4fdc              cmp.l   #$b34c4fdc,d0       ;'Rob Northen Comp'
000002AC   [660c                        bne.s   $2ba
000002AE   [323c 0001                   move.w  #$1,d1
000002B2   [9098                        sub.l   (a0)+,d0
000002B4   [51c9 fffc                   dbra    d1,$2b2
000002B8   [2c00                        move.l  d0,d6               ;d6=the magic key

buffer - first 32 bytes of sector 6

000005CC   52 6F 62 20 4E 6F 72 74  68 65 6E 20 43 6F 6D 70   Rob Northen Comp
000005DC   78 DC 60 F3 6E 35 5A 80  E4 13 C8 27 90 4F 20 9E   xÜ`ón5Z€ä.È'O ž

 

(Leonard)  so the "key" is only a 32bits key in D6 ? Do you have the code of the decryption routine ? (where d6 is used ?)
Other point I don't understand: if you copy the disk, the read of sector6 will not take the same time, I agree. but, the data you read are the same as original. If protection is only based on the key it won't work. Do I don't see how "readinf time" is used in the computation of d6. (at least it's not in the routine you provide).

(Zippy) The sector timing part isn't used in the calculation of the "key". Basically they check the sector timing and if it matches what they're looking for (i.e. the disk is not a copy) then the key is calculated from those few bytes and then passed back by the protection code to the main program. If the sector timing check fails (disk is a copy) then the routine passes back "zero" in D0 instead of the magic "key" number. The code which does all those disk reading + calculation routines is all encrypted and only decrypted one instruction at a time by the trace routine. There were two sorts of Rob Northen protection, what I called the "internal" and "external" check:

This made it quite a nice protection and not so easy to find and hack. At this point I had developed my own hacking cartridge which allowed me to freeze the ST at any point and dump out the entire contents of RAM for examination. So I'd freeze it at the same point while running from the working original game and from a non-working copy, then compare the entire game area of RAM for any differences... usually I could spot the few long words which had been changed by the protection routine.
The "external" type of protection was basically an encryption wrapper around the programs main file, so when you loaded the program from the AUTO folder you found it was fully encrypted and the front end went straight into the Rob N trace encryption stuff. If the disk protection check passed then the program was decrypted and run as normal, if it failed then the decryption didn't work and the game would crash or reset. They would sometimes have "internal" type checks inside the main program as well as it being completely encrypted by the "external" check as well.

(Leonard)  So If I understand well, the protection is based on the key value. The speed-sector is only a first "copy test" at the very beginning of the protection process. A cracker only have to remove the test of the speed sector to crack the protection ? (because even if the sector is read at low speed, its data should be correct).
Now I can say the system is poor only because there is only 1 secret bit in the disk: "original sector" or "not original sector". Just remove that 1 bit test and it's ok. Better protections (on PC CD) are those who can put many secret (non duplicable) bits. These protections are a bit harder to remove if well used. (and it's never the case on PC)

[Leonard  wrote] A cracker only have to remove the test of the speed sector to crack the protection ?
(Zippy) In theory yes, but in reality, no. Because the whole trace encryption thing was only decrypted to reveal what was going on inside it quite late in the day of the ST scene, so personally I never hacked a Rob N protection by this method 'cause I never even knew what was going on inside all that trace encrypted code. It didn't matter though, all you had to know was that it would pass out the magic number in D0, or maybe alter the contents of some pre-set addresses. Any other hacks I saw always just removed the checks for the magic number, or forced it to the correct value with e.g. a MOVE.L #$ABCD1234,D0 instead of running the block of protection code. I don't know if anyone ever hacked it by decrypting all the trace stuff by hand to change the sector speed check, but I doubt it. It would take way too much time and all Rob N would have to do would be change a couple of instructions and the whole job of decoding it by hand would all have to be done again, so not realistic to hack every game like that.
[Leonard  wrote] Now I can say the system is poor only because there is only 1 secret bit in the disk: "original sector" or "not original sector". Just remove that 1 bit test and it's ok.
It was weak in that respect, but because this weakness was very well hidden inside the trace encryption it was never exposed and exploited... so overall I think it was a very good protection system, it's just that it was usually implemented very poorly. In some games (e.g. Cadaver) where they used multiple checks and the trace encryption modified multiple external addresses with hidden EOR.L instructions inside it was actually pretty tricky to hack.

(Zippy) This is the keydisk check supplied by Rob N for inclusion in games. I also have the decrypted source.

(Ijor)
[Leonard  wrote] Is the protection reading a key data on the "speeded sector" ? Is it working even if the sector is read at low speed ?
(Ijor) The key is written at normal bit-rate. The first portion of the protected sector, where the key resides, was recorded at nominal bit-rate; only the rest has a slower one. This is why the code posted by Zippy works. If they wanted, they could have written the key and the whole sector at a “protected” bit-rate. I’m not 100% why they didn’t. One possibility is that they were concerned about reliability. When you alter the bit-rate, you increase the chances of getting read errors. You don’t mind getting an error in the portion where you have no key, but you can’t afford to read a wrong key.

[Leonard  wrote] The speed-sector is only a first "copy test" at the very beginning of the protection process.
(Ijor) Not always. Some programs make the protection check several times during the game. In some cases at every level.

[Zippy  wrote] The code which does all those disk reading + calculation routines is all encrypted and only decrypted one instruction at a time by the trace routine.
(Ijor) Not exactly. The actual reading and measuring must be done at real time, so it was not traced. They had a mechanism to enter and exit “trace” mode. I don’t remember if they used an “Illegal” or “address error” exception.
(Zippy) Yes of course, I was forgetting that... obviously some timing critical stuff and control of h/w registers would have to be done with the trace decryption disabled.

[Bit5  wrote] It's not as easy as you might think because of the real-time de- / encryption in trace mode via $24, or some kind of checksum for program code, but you're right. Knowing the right breakpoint in STEEM debugger you can bypass the sector check easily ...
(Ijor) Nowadays is extremely easy. Just use a PASTI breakpoint for reading sector 6, track 0. And if you want the trace code, use Steem’s debugger logging facility, enable “Trace” logging.

(Zippy) My cartridge was actually very simple, it worked by exploiting a very useful feature of the standard BIOS code which controlled how memory was cleared after a reset. When the ST is reset execution jumps to the BIOS ROM, checks for a cartridge then continues through setup stuff before booting from drive A. How memory is cleared depends on whether it's a cold or warm reset, it detects a warm reset by comparing the 3 "MEM VALID" variables at $420, $43a and $51a looking for certain longwords, if those are present then memory is only cleared as far as the previously stored "PHYS TOP" (top of physical ram) variable at $42e. If the longwords are not present then a cold reset is presumed and ALL memory is cleared.
On my cartridge I had a switch on the +5v line, allowing the cart. to be disabled so that programs couldn't detect it... so to dump memory I would hold in the reset button, switch the cartridge on and then release the reset button. 68000 execution would jump to the BIOS, then to my cartridge code which copied all RAM from 0 to 512K into the area from 512K to 1MB. It would then setup the 3 "MEM VALID" variables to the correct values, then set the "PHYS TOP" variable to 512K, and finally exit back into the BIOS.
BIOS code would continue to setup, check for cold/warm reset and find a warm reset condition therefore only clear ram up to 512K (as set by the cartridge code, even though my ST had 2.5MB!). Then it would continue to setup the hardware/video and boot from the floppy.
I'd boot off my MonST floppy disc to find a perfect copy of the lower half meg of ram located at 512K and above, all ready to be disassembled and examined.
That would basically allow me to freeze the ST at any point and then examine RAM contents fully intact with the usual tools like MonST, without having to develop major amounts of code to setup all the hardware again after a reset. Obviously I didn't have access to any of the registers at the freeze/reset point, but even so it was very useful. If it hadn't been for that then I'm sure I wouldn't have been able to hack nearly as many of the most highly protected games on the ST.

[Ijor  wrote] Nowadays is extremely easy. Just use a PASTI breakpoint for reading sector 6, track 0. And if you want the trace code, use Steem’s debugger logging facility, enable “Trace” logging.
(BIT5) I agree with that, nowadays it is quite simple. Thanks your PASTI there is no need to modify or remove the Rob N stuff. It works fantastic for me.
(Ijor)  Well, in this case I wasn’t talking about using a PASTI image. I was talking about using Pasti.Dll for breaking into the CopyLock protection check routine. Because Pasti.Dll adds breakpoint at the FDC level, you just need to enable a breakpoint when the protected sector is read. This will of course works with a PASTI image, but will work as good with a non-working ST/MSA image as well. You might have already noted this. But there quite some many new cracks surfacing lately. Probably most of them are done from a PASTI image.
(BIT5) Just an idea for future releases. Since the tool, provided by Zippy, end writing in the middle of the protected sector some (unimportant?) original data are lost. By knowing the content of the PASTI image it should be possible to build-up an own keydisk image. Imo a non-working standard image can be converted into a working keydisk image without the lost of any data. So a plain ST is not required anymore. What do you think about that?
(Ijor)  For public preservation we want images taken from original disks and not from copies (disregarding if they are working or not). But if you want to make your own hacking, then yes, that would be possible. I don’t know, might be we’ll use this kind of stuff in extreme cases. It is possible that there are some extremely rare games that no original copy survived. In these cases we might try to preserve a copy, at least while no original is found. But it is unlikely this will happen with CopyLock’ed disks. I’d suppose that the rarest games are probably from smaller companies, or non-English games.

Leonard  For anyone who wants info about Rob Northen protection , here is a great interview from the guy himself . http://members.tripod.com/whdloadrules/rob_northen_interview.html
(Ijor)  I think a couple of points are worth to mention:

Quote:
From memory, I think the 'slow' sector had to take at least 15% longer to read than the other sectors or it failed the protection test ...
Seems that his memory is not too good. It is just ~3% slower, not 15%.
 
Quote:
A floppy diskette duplication machine called the Trace 1006 was used to create the keydisks. This was by far the most popular machine used by the commercial disk duplicators. It consisted of a Unix box with a floppy disk controller board and a 3.5" and 5.25" disk loader. Mine cost me £15,000 in 1990.
It is amazing that RN was completely unaware that the Discovery Cartridge (already available a couple of years earlier) could have been used to produce the key disks, for just U$150 !!! He could have saved himself a "few" bucks.

Leonard  Hi Ijor, I wanted your opinion about my idea of copying Rob Northern disk without modifying the code:
The protection itself rely on the fact one particular sector (sector 6 track 0) is read slower than others ( about 3% as you said). The test code in the protection just test "slower", not "how many slower" (I mean if the sector 6 is read three times slower, the game should run properly).
(Ijor) Yes, that is correct.

Leonard  My first idea was to create a 1024bytes sector it will take longer time to load.
(Ijor) Not a bad idea at all ...

Leonard  Unfortunately there is two problems:
 1) the client code is made to load 512bytes, so loading 1024bytes could scratch some useful code.
(Ijor) Well, not really. Replacing a normal sector with a 1024 bytes one is usually harmless. When a sector is read, the “sector count” register on the DMA chip is usually set to 1. But “sector count” for the DMA chip just means how many 512 bytes blocks to transfer. So it doesn’t matter how many bytes the FDC chip will deliver, only the first 512 ones will be transferred to main memory.
(Leonard) Really ? Humm I though it was "automatic" (I mean, if I have a low level FDC routine, I don't have to change anything to my routine to load 1024 bytes sectors (exept ptr+=1024 instead of +=512 of course). So you mean if I want to load 1024 sectors, I have to change somewhere a count=1 by count=2 ? Or did I miss something ?
 
 2) The protection code test the reading speed by looking at the DMA pointer. So even if the sector is physically 1024bytes long, the "profiler" routine will returns after 512 bytes.
(Ijor) Yes, unfortunately it checks the DMA pointer. If it instead would monitor the FDC interrupt line, then this “trick” would indeed work. May be he considered this, don’t know.

Leonard  So it came a second idea, but here you have better knowledge then me about these strange disk techniques: I remember "FastCopy Pro" can format disk that are a bit faster than disks formatted with GEM. I remember someone explain me that these tracks contains wrong "sector header", and make the sector-search phase a bit faster than standard disk. (btw if you can explain me better I'm very interested by that "fast format" technique).
Anyway if we could speed some sectors by writing dummy headers, do you think there is some technique to slow down things ?
(Ijor) Third party formatters use a couple of tricks to make “track” reading faster. The actual time that a particular sector is read is not altered. Specifically, the idea is to reduce the time between reading one sector and other, or between one track and the next one. Not the actual sector reading time.
(Leonard) I understand, so it can help for my purpose. Anyway could you explain me in detail that technique ? I heard it was to speed up only time between track (seek time), in a way the new track sync is found faster just because of a dummy (wrong) sector header. is that true ? Anyway, do you think now, 10 years later, we can imagine a way to copy a rob Northern disk using Atari only and without modifying the code ? I like challenge and that one sounds pretty cool to me

Ijor
(Leonard wrote)
So you mean if I want to load 1024 sectors, I have to change somewhere a count=1 by count=2 ?
(Ijor) Yes.
The DMA chip is completely unaware of the sector size. Actually, the DMA chip has no knowledge about when and what kind of operation you are performing with the FDC. The only “things” that DMA knows is: the direction of transfer, the target (FDC or HDC port), and the number of bytes to transfer in 512 bytes units.
(Leonard wrote) Anyway could you explain me in detail that technique ? I heard it was to speed up only time between track (seek time), in a way the new track sync is found faster just because of a dummy (wrong) sector header. is that true ?
(Ijor) Yes. This is because TOS performs seeks with a “Seek with Verify” FDC command. When the FDC performs this command it first does the actual physical seek, then it tries to find a sector header (just a header, it doesn’t look for the sector data) with a matching track number. Then TOS issues the actual sector read command to the FDC.
So the sequence of events is: The head is positioned on the right track. A sector header is read. And lastly the desired sector is read.
In a standard formatted disk this will have the following effect: The FDC would need to “wait”, at least, for a full sector between reading the header (by the Seek with verify) and the sector. This is because every header is followed by a full sector. And this is assuming the sectors are smartly skewed/twisted across tracks. Otherwise, as it is the case of a TOS or DOS formatted disk, the wait would be almost a full revolution.
But with the additional extra header inserted by custom formatters the “wait” is much smaller. This is because the first sector comes right after the extra header. In other words, the first sector on the track is found right away after performing the Seek with Verify.

(Leonard wrote) So if I want my trackload demo runs very fast, it's no use to ad a dummy sector, I can just do a "seek" instead of "seek with verify", am I right ?
(Ijor) Yes, just make sure you have a good retry logic in case of errors.
(ggn wrote) Well, isn't this a bit dangerous? You'll have to be very certain that the disk will be 100% error-free for a long time
(Ijor) No, it is not dangerous or risky. Only the seek is done without verify, the actual reading is always done with verification.

Leonard it remembers the guy who reads AMIGA disks on PC using two floppy drives, pretty cool idea !
(Ijor) This is not just a “cool” idea, it is a f* genial and brilliant one. And for those who don’t know who made it, it was Vincent Joguin. The same guy that made Disk2FDI, Fast, and the HD6301 emulation for Saint.


Copyright and Fair Use Notice
This web site contain copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available in our efforts to help in the understanding of the Atari Computers. We believe this constitutes a 'fair use' of any such copyrighted material. The material on this site is accessible without profit and is presented here with the only goal to disseminate knowledge about Atari computers. Consistent with this notice you are welcome to make 'fair use' of anything you find on this web site. However, all persons reproducing, redistributing, or making commercial use of this information are expected to adhere to the terms and conditions asserted by the copyright holder. Transmission or reproduction of protected items beyond that allowed by fair use notice as defined in the copyright laws requires the permission of the copyright owners.

e-mail to Jean Louis-Guerin This page is maintained by DrCoolZic (Jean Louis-Guerin).
If you have any comments please send me an e-mail (remove _REMOVE_)