ijor

That's a completely different scenario. The problem is not the Uart, neither is the speed. The problem is the communication with the software and the Uart. In cases like the Fujinet that is straightforward. The Uart is closely coupled to a microcontroller, that essentially can control the Uart with cycle accuracy, or very close to it. OTOH, an emulator runs under a general purpose operating system, and doesn't have much real time control. Furthermore, it doesn't talk directly to the Uart, but through a stack of kernel drivers that have no real time meaning. In some cases, like when using USB adapters, their exact behavior is not even fully documented. Even then, of course that is not unfeasible, and there are multiple SIO2PC like applications that can do the job. The reliability usually depends on the specific platform, OS, adapter and drivers. But emulator have to peform an extra step. An emulator must synchronize that non-real time, non accurate, serial exchange with the emulated system that runs under its own timing that is also non real time. Unavoidably, one, or both will loose accuracy. Still feasible, at least in some cases, with varied reliability. You might say it's technically feasible, but unfeasible to make it reliable and accurate under most platforms and systems. That's why it is not a very popular feature for emulation.

Actually the atari++ emulator does support connecting to a real Atari disk drive through a 1050-2PC cable: But this feature is not much favored by emulators nowadays. Doing any "real time" synchronization with an external connection is becoming more and more difficult with modern PCs. The fact that modern PCs don't have a standard serial port anymore doesn't help much either. If you search you'll find this was already discussed several times on the forum.

It can't be programmed with an EPROM burner, the ROM is factory programmed. One could think that there should be a model variant that does have EPROM, but if exists, it is not mentioned in the datasheet. It is possible to use it with external ROM, but this usage is not compatible with the ST keyboard.

Many titles have two or more minor variations and releases. That's much more common than what you might think. I have seen all sort, including cracks or hacks (such as for unlimited lives) recorded over original disks. Sure, take your time. We appreciate

No. The problem is that there wasn't a consistent usage on how the options were flagged, and how the tracks were packed or interleaved at the file header. So it is difficult to detect and match the tracks exactly for single sided 96 tpi images. Just use double stepping and there would be no problem. I didn't check the images. But yes, the problem is only with 96 tpi images.

It has (almost) nothing to do with the index hole. SCP images, and to a lesser extent also ATX images, store analog characteristics of the disk. Two dumps, even taken from the same physical disk with the same drive are very unlikely to match exactly. As DjayBee suggested, why just not upload somewhere the entire set of dumps you made. Everything helps, even just for verification.

I agree, that's why I said earlier there is an issue of how the flags at the file header are used inconsistently. Some images produced by older version of the SCP software are even worse. Perhaps a command line option to force a specific interpretation of the track list would be appropriate.

The image seems to be ok. As I suspected, it is just the 96 tpi layout that is not interpreted correctly by most tools including a8rawconv. Congratulation on your new title!

Yes. Basically track 40 (the 41th track) might contain extra information such as duplicator signature. Many times is blank. But the extra time and the extra storage space for the extra track is not very significant, so it is worth to include it.

Interesting. Thanks for the post. Note however that there were several similar projects and some of them were actually produced and sold commercially. The main reason was that at some point it was much cheaper to build a clone using a PC drive than buying a 1050, especially in some overseas countries. But these project normally had a custom board specifically designed for this purpose and with a custom firmware. It is quite a different task to attempt to use a PC drive on a 810 (or 1050) using the original Atari logic and firmware. Of course, using a full height floppy drive makes things much easier. But were they cheap and widely available? I think I never seen one personally. I owned a couple of full height hard disks, but never full height floppies. They must have been obsolete quite early?

Again, please dump one more track (--ecyl=40). Check the other thread for an explanation.

I think this is an a8rawconv buglet that can't process SCP 96 tpi (80 tracks) images. This in turn might be because there were some inconsistency on how the flags were marked on the SCP file header. You might be able to tell by looking at the a8rawconv output in verbose mode. Or if you want to be sure, post the SCP image dumped without any options. I'll check it and let you know.

Sorry if I was a bit too harsh. But I do think you were definitely wrong. You said "there would be no point in attempting to dump extra tracks for Atari 8 bit software", and that is certainly not correct, there is a point. And I did wanted to stress the importance because otherwise people would forget to include the extra tracks when preserving disks. I should add that is not 100% accurate to say that the Atari can't never reach and read data on track 40. A stock drive can't, but an enhanced drive like a Happy or SuperArchiver certainly can. Conceivable, data on track 40 might have been used as a special copy protection method for a disk that was designed to run only on an enhanced drive. As a matter of fact, we have seen some special protections on some european titles for enhanced drives. I don't recall a case on track 40, but I wouldn't rule it out it exists. In theory yes, although most software will ignore it. But in this case it won't help. The duplication signature is usually not part of a regular sector. Sometimes it is even not on track 40 but on a "regular" outer track. This is because usually it is recorded on the first unused track. So if the specific title uses, say, only tracks 0-29, the signature might be on track 30. But even then you still won't be able to read it with a standard drive because, again, it is (usually) not inside a normal sector.

You probably don't need this. The software you will normally use, including a8rawconv, already knows how to compensate for this automatically. So it is much better to store the dump exactly as was produced by the drive. You can always post process the data if needed in the worst case (although, again, you normally will not need it). But if the dump was somehow altered, there might be no way to go back. May be the Greaseweazle software needs that for converting the dump to an ATR file image itself. If so, it is, IMHO, broken. Just convert it using a8rawconv instead.

I don't have personal experience with the greaseweazle, but that doesn't look right. In first place, don't include the original RPM or bitrate. The dumping software is not (or should not be) concerned with that kind of information. With those parameters it might alter the dump and that's exactly what we don't want. We want the dump to contain the information as was produced by the drive, verbatim, without any kind of interpretation. The interpretation should be performed by post processing software without altering the original dump. The last track depends on the kind of drive you use. For a typical 96 tpi drive it should be 82 (see my posts on the other thread about why to include some extra tracks). Also make sure that it includes 5 revolutions.

Sorry but you are wrong. Just because a standard Atari drive can't access those tracks, that doesn't mean that there is no useful information there. I explained this several times already. Search for duplicator signatures. You should find some posts of mine about the subject ... an "interesting" example is here: Please do not disseminate false information, especially for something sensitive as preservation. Thanks.

Sorry, forgot to comment about that .. Yes, please dump at least one extra full track at 48 tpi, or two at 96. That would mean tracks 0-40 and 0-81 respectively. Sometimes, but not always, those extra tracks have useful information

As noted, the main limitations are around reading the flippy side, or writing back. Otherwise, almost any drive will work. Btw, note that there is also now a free DIY alternative to Kryoflux and SCP:

It won't work. Not without too much pain. As the doctor is saying, everything is feasible. But here it might require major surgery. It is much easier trying to adapt a full height drive as cwilbar suggested. Mainly because full height drives have the bare mechanism separated from the digital logic, and most of the logic is discrete anyway which makes it much easier to adapt. Even then I'm not sure you can (easily) change the rotation speed from 300 RPM back to 288 RPM on every full height drive. But of course, a full height drive would be very expensive to ship internationally and they are not that easy to find anyway.

I might have something. Will probably PM you later

This doesn't have much to do with the specific drive. Some drives do are slightly worse than others depending on the pressure exerted by the heads. But it mostly depends on the media much more than the drive. Most Synapse disks of the period are known to be extremely fragile and they could be destroyed by being read (actually, just by rotating with the head engaged) in any drive including an 810 or 1050. Blue Max and Zepellin are probably the worst titles, in this sense. Just for the record, 3.5" drives, at least normal PC ones, rotate at 300 RPM, not at 360 RPM.

Sorry, but with all due respect, I think you don't know what you are talking about. Did you actually try that? Did you also test the difference writing with or without a track buffered write? Did you tested the time that it takes in each case to copy a simple copy protected disk? I guess you didn't. Note that you can nowadays perform most of these tests under emulation thanks to Altirra full drive Happy/SuperArchiver emulation capability. The old Archiver/Chip is rather limited. The Super Archiver alone can create weak sector, but can't copy some titles like the Synapse or ECA supertracks (Syncalc, Archon II, etc). The Super Archiver + BitWriter combination can indeed copy almost all Atari 8-bit and the copies would run on any disk drive. I don't think this is the case. I think the main reason is that the Happy simply lacks the hardware capabilities to actually copy those disks. Happy eventually produced the Discovery Cartridge for the Atari ST. This cartridge can copy virtually every floppy disk and not just for the Atari, but for virtually any platform, except those disks with physical alteration like laser burn holes. Furthermore, it produces digital file images so that you send them to somebody else. So it doesn't seem like he was looking for legal coverage.

Well, it depends. But seems you are more interested in a hard drive functionality. Then, as other recommended, it might make be much better to get a hard disk (emulator).

As I said already, this is not necessarily anymore if you are using a Gotek with a recent HxC firmware version.

The SA doesn't have enough RAM to hold the Happy code, let alone the track buffer. It can't even "emulate" a stock 1050 (run the exact original 1050 firmware relocated) as the Happy does. The Happy Archiver emulator was written by Bob Puff. It's called "Happy To Chip" and it was released by CSS long before the SA. So obviously it emulates The Chip, not the Super Archiver. But it is perfectly possible to implement an updated version that would emulate the Super Archiver except, of course, for the Fuzzy Sector Maker and the slow speed mods because they are not present at the Happy. Sure Bob could have released an updated version but guess he wasn't interested in creating more competition with his own product. Now, if you mean that the original Chip (and not the Super Archiver) was superior than the emulated Archiver running on the Happy, I'm not sure that would make much sense. Btw, there is also an Archiver for the Happy 810 that was written by Gustafson himself and published by Spartan.