ijor

malers, on Thu Apr 12, 2012 2:36 AM, said:

I'm afraid I don't have a specific model recommendation. Yes, C64 people should be in a similar situation, but last time I checked they still didn't support C64 write back. So don't count of C64 people having (at least not yet) more experience than us on the matter.

In general, I would try to avoid if possible the oldest drives. The more newer drives tend, naturally, to have electrical characteristics more similar to HD drives. Use the shortest (and best, ideally shielded) possible cable. Do not connect two drives at the same time. If present and possible, remove any resistor termination pack from the drive (but then you might need to put it back when connecting the drive to some other hardware).

Quote

I doubt very much they would ever do something like that (but I don't blame them). If we want a public raw dump repository we would need to arrange for that by ourselves.

kenjennings, on Fri Apr 13, 2012 9:24 PM, said:

I remember reading some kind of explanation long ago. I can't say for sure if it is the real reason, and now I don't even remember where I read it

What I read is that it was just a simple, silly, but actually harmless bug on the very first 810 firmware. The 810 hardware uses a very old FDC (the actual floppy controller) that has an inverted data bus interface. So you must invert any data that you send to or receive from the FDC. The bug was that they forgot to invert the bytes for the actual data sectors (or they inverted it twice, don't remember)

Once the drive was released with the bug, and once disks were written and mastered inverted ... then every future compatible drive had to follow through.

phaeron, on Fri Apr 20, 2012 12:09 AM, said:

Yes, internal RAM address is always fully decoded. Each RAM row (one byte) is selected by a single address only. As implied (but you are right, not explicitely enough) by the schematics, each row is selected by a wide NOR that is activated by a single and unique combination of the address signals.

Quote

Yes, the LFSR logic has a full 63 stages sequence. Under "normal" ANTIC operation, the LFSR is reset at the start of the line, and it would never advance past the 48th stage. Each one of the first 48 stages (after LFSR reset) of the LFSR selects one RAM row, the other 15 stages (there is no stage with all bits zero) don't select any RAM row.

So if ANTIC, for some reason, attempts to access (read or write) internal RAM at any of the 15 last stages of the LFSR, no actual RAM would be selected.

I admit I was a bit lazy on that part of the schematics. I would need somehow to make this more clear and explicit.

malers, on Wed Apr 4, 2012 9:33 AM, said:

There is currently no readily available software to write back VAPI images. We have a couple of programs in different development and testing stages. But my main problem is (as many others) lack of time. Currently I can barely find the time to write this message. Hopefully I'll have some more time in a couple of weeks or so.

The hardware devices best suited for writing back copy protected 8-bit disks are the ones working at the flux transition level. The three ones that I'm more or less familiar are the Discovery Cartridge, the Catweasel and the Kryoflux. They should be able to write back every single 8-bit disk.

It should be possible to write back most, but not all, of the protections using less powerful hardware. This includes Happy and similar enhancements (Duplicator, Speedy, etc), and also The Chip and the Super Archiver.

Bryan, on Wed Apr 4, 2012 7:21 PM, said:

Yes, that's the main drawback of the Kryoflux for the purpose of writing back 8-bit disks. It can handle 360K drives, at least some of them, but the electrical interface is not ideal. Older drives require stronger pullups and higher current buffers.

This doesn't mean that the Kryoflux can't work with any 360K drive at all, neither it means that it is completely impossible to write back DD disk on an HD drive. But it is not the ideal hardware for this purpose.

OTOH, the ideal hardware is useless without the correct software ...

Reading DD disks on an HD drive is less of a problem except for the flippy side, which most HD drives can't without a hardware mod. Most DD drives do can read the flippy side without any hardware mode, by physically flipping the disk (as you would do on a 1050 or 810 drive). Some people believe that this method is useless for preservation purposes, because the index pulse is lost. But in the worst case, you still can, at the very least, read non original flippy disks with most DD drives.

Bryan, on Tue Apr 10, 2012 10:37 AM, said:

Yes, you don't want to copy flux transitions blindly. This would be using a hardware digital copier like an (so called) analog copier. I think we talked several times (possibly more at the ST subforum) about the drawbacks and limitations of analog copiers. One additional issue that is particularly nasty for many 8-bit disks is the location of the track write splice point.

Having said that, is very possible to implement software that would copy most, if not all, protections reliably without any manual identification, and without creating any kind of master images. But this is not trivial, and it is much more work than just copying flux transitions blindly.

Bryan said:

Yes.

fiath, on Wed Apr 11, 2012 12:31 PM, said:

As I said in another thread, please be careful with this. That is a good technique for retry and verifications purposes. But this will provoke in many cases too many retries, which is bad karma to some "fragile" original disks, like many Synapse ones.

Bryan, on Tue Apr 10, 2012 3:32 PM, said:

I insist in an idea I also mentioned in the other thread. Let's post all raw dumps in some public place. This way we won't depend, at least not exclusively, on the scarce time of somebody else (including SPS people, but also including me) to post process the dumps.

phaeron, on Mon Mar 19, 2012 9:18 PM, said:

Well, I obviously can't argue with you about waveform periods, pitches, etc. Certainly not my stuff. But I can tell you that I actually measured the 1050 step rate sometime ago, and it is just slightly over 20ms, not 26 ms.

The half step rate is about 10.16ms, or 20.32ms per track. To be precise, when seeking, there are approx. 10.16 ms between each physical movement of the stepper.

Note that the total seek time is not the same as the step rate multiplied by the number of (half) tracks. There is a significant one time overhead per each seek. And some firmware versions sometimes perform an extra back and forth half step.

phaeron, on Tue Jan 31, 2012 1:15 AM, said:

Where on the samples do you see the 26ms? Or there are some more samples other from the ones posted here?