ijor

Yes. Weak bits, fuzzy bits, and other terms, refer to the same concept. Dungeon Master for the ST indeed does have a weak sector. Although it is more sophisticated, both at the software and at the hardware level. But weak bits protection was not very popular at 16-bit systems. It was replaced with even more advanced protections. The more popular was probably data recorded with variable frequency (speed).

HWA is an option on the Happy Backup "Special Recovery" menu. It is disabled by default. We found about this with a copy of Synfile+ 1. The copy seems to work fine. This was one of the earliest Atari titles with weak bits. No. HWA doesn't create any extra sectors. Only sectors that are already present are replaced. HWA doesn't enable slow speed either.

HWA stands for Happy Wins Again. It's a feature of later versions of the Happy 810 software. I never had a Happy 810, only 1050 ones, but some strange copies we found recently lead to me research the issue. I couldn't find any documentation about HWA. Apparently it is supported by Happy versions 5.2 & 5.3 only. If anybody has any doc specific to these releases, or anything that covers HWA, please contribute. Note that HWA has no relation with the Happy Autospeed mod that can automatically slowdown the drive RPM to write tracks with more than 19 sectors. HWA is a special copy mode to deal with weak sectors, or sectors with weak bits. The Happy hardware can't create weak sectors. So technically, the Happy can't copy disks with weak sectors. HWA tries to produces a working copy by creating a track layout that has similar characteristics to one with a weak sector. It formats a track with multiple duplicate copies of that sector. To verify the presence of the weak sector, the protection reads the same sector multiple times and verifies that the content of the sector change, at least partially. This is the characteristic of a weak sector. But if there are multiple duplicate instances of the same sector number, each one with different content, then the behavior might be the same. So HWA attempts to fool the protection, and in some cases it seems it works. This method won't always work, of course. To create many multiple duplicates some of the other sectors on the track must be removed. If they are needed by the software, then this would fail. Also the protection might handle the timing in a such a way so that always the same physical sector is read. This also would make this method to fail. On one hand HWA, it is a useful feature and a clever solution. On the other hand it is cheating because the disk isn't really copied. A working copy might be created, and only in the best case. I guess, this is probably one of the reason that the HWA mode was abandoned on later Happy versions.

Minot clarification just for the record. V7 targets both the Happy 1050 and the Happy 810. But the Happy 810 must be upgraded with the rev 7 firmware, and it doesn't support the Autospeed mod. V6 is for the 1050 only.

I think you are misinterpreting that post #177. Happy uses the term "slow down" to set Unhappy mode, which disables the track buffer among other things. Has nothing to do with the Autospeed mod.

I suspect it is the other way around, you want a later version of the document. Not the latest ver 7 manual that doesn't support the slower RPM mod, but a later 5.X document.

Thanks. For some reason googling couldn't find it. Unfortunately it seems to be for a rather early version. It doesn't seem to cover features that are present on Happy 5.2 and later. So still. Anybody has a later Happy 5.2, or 5.3, software manual?

Anybody has the Happy 810 rev 5 software manual? I can find the later rev 7 manual, the happy 810 hardware installation manual, but this one seems to be missing, or at least I can't find it. Thanks

Actually it usually works, either way, covering the hole or not covering it. It is even possible to use 3.5 DD disks as HD ones by punching a second hole. But please note that just because it works it doesn't mean it is the recommended optimal condition. As somebody mentioned, most 3.5 drives select the write current automatically by sensing the HD hole. That is the whole purpose of that hole. The main reason that you can still write to 3.5 HD disks using lower write current, is because the difference in the coercivity of the media is rather small. The coercivity on 3.5 HD disks is about 10% higher than the one on 3.5 DD disks. For comparison, 5.25 HD disks have a coercivity more than twice the one of 5.25 DD disks. Most people seem to have quite a success using 3.5 HD disks formatted as DD (720K). So, for casual use is probably good enough. But YMMV. In either case you are using the drive and/or the media in a way that it wasn't designed. I'd definitely would try to find DD media if possible.

Then perhaps not for extension or any modification at all. Still the original source is invaluable for preservation, historical value and study.

Sorry for being a little off topic ... Were those really illegal clones with unauthorized use of Indus copyrighted ROM? Or were they just something like an Indus second brand?

Yes, I understood. My point was just about the pull up resistors. Don't know why yours didn't work, but likely it was for a different reason. Btw, I recommend to put back the WD1772 when you can. Even when the WD1770 should mostly work fine. The different timing might affect some copy protections.

As Pera said, the PSG ports are very fragile and they are known to get damaged quite easily. It would be strange that you had the same issue at both computers, but it is conceivable I guess. It depends on the specific 5.25 drive. Some work fine, depending mostly on the pullup resistors. The older the more dangerous because they sometimes have very strong pullup resistors. Of course that drives designed specifically for the ST are just fine, except that they require a slower step rate.

Some (but not all) 354 Atari drives have logic that make them incompatible with double sided drives. You might need to bypass the board adapter in the 354 and connect the Gotek directly to the external connector somehow.

Yes, that is perfectly possible, but that doesn't contradict my point. Less reliable doesn't mean that it won't work, certainly doesn't mean that every single copy would fail. Btw, are you sure that was copied from an original disk? That image is quite strange, it seems like a hack. That version of Synfile is supposed to have a weak sector on track 3, and it is verified (or at least it seems so). But track 3 on your disk has, instead, multiple stables (non weak) duplicates of the same sector !!! The protection check is obviously "fooled" thinking it verified a weak sector, but just because the protection check is "naive" and doesn't verify the rest of the sectors on the same track. Either it was a human made hack, or either Happy 810 software was much smarter than I though. There are other tracks that seem to be altered intentionally because it couldn't be copied, such as track 11 that "originally" has 34 sectors.

The guide is great, just a small comment. It is not accurate that the SA can copy tracks with up to 28 sectors, it cannot. Neither the SA, neither the Happy can copy tracks with more than 19 sectors (except some very special cases). You need at least a BitWriter, or a flux level device like the SCP or Kryoflux to copy those tracks. The SA (and the Duplicator, and some versions of the Happy 810 as well) attempts to copy tracks with more than 19 sectors by slowing down the drive. This might create in some cases a working copy. But the original track layout and protection is not re created. The original protection was almost never created by slowing down the drive. The "slowed down" copy might work depending on how the software checks the protection, but IMHO this is really just a cheating workaround. Furthermore, the copy will be less reliable. As a consequence of writing at a significant slower RPM, the written density would be higher. Not only this makes the recording more fragile. This also produces a considerable frequency shift when loading the copy (which would read the disk at nominal RPM).

I agree that the SCP is probably the best option for Atari 8-bit disks currently, especially if you are mainly interested in writing back images. The Kryoflux is almost as good for the purpose of creating images, might be even better if you have a custom modified drive for accessing the flippy side automatically. As noted in other thread, the DYI version of the Greaseweazle is, by far, the cheapest option. However, if you want (or need) one of the more advanced versions and you purchase a fully assembled unit, then it is not really much cheaper anymore. Might be even more expensive than the SCP if you are located at the US and you would need to pay international shipping. The Greaseweazle also has some software limitations, but being at the software level, they might be solved in the near future. As cwilbar noted, it is better to use a 48tpi (360K) drive for writing back, and in that case you don't need to bulk erase the disks.

A Gotek with the HxC firmware can "play back" almost all protections using the newer HFEv3 image format. There is a software issue however to convert from other formats successfully. The Goex uses the FlashFloppy firmware instead. And I don't know how good and accurate is the FlashFloppy support for HFEv3 images. It am even less certain about a Goex that uses SD cards instead of an USB pen drive; timing might be less accurate. Btw, I guess your Goex is just fine. What was the issue that it didn't work for you before?

Hi Candle, Isn't there enough demand to make a new version with a modern FPGA or CPLD? I know it would require voltage level shifters, but even then it would probably still be cheaper than using an ancient FPGA. Let alone that you would have lots of logic space available. Just a thought

In first place, it is important to note that there is no way to guarantee you will not destroy or physically damage some of the disks. That is always a risk regardless you clean them first or you don't. You should warn the original owners if you consider that is important. I would just dump most disks without cleaning them first, and only clean those that have obvious, visible signs of being extremely dirty. I do think that cleaning, if performed gently and carefully doesn't present a significant risk. Follow Keatah and The Doctor recommendations on how to perform the cleaning. Now, the major issue is those disks that tend to develop grooves and sometimes starting to loose the top binding layer. There is not much you can do in those cases, except to thoroughly clean the heads before and after dumping any "suspicious" disk. Some titles like Zeppelin or Blue Max are among the most "risky", in this sense. Please dump 5 revolutions per track and, again, include, one extra track (tracks 0-40). It might be reasonable to reduce the number of revolutions to 3 for the most risky disks. But the effectiveness of this depends a lot on the specific software and firmware of the dumping device.

Well, again, it depends on what is the default configuration if the files are not present, which I don't remember and might even vary across different firmware versions. That's a pre SDHC card. I would definitely try a bigger SDHC card. Even when any software that works with SDHC should be backwards compatible with older (non SDHC) cards, it is possible that they never tested a small card. So I recommend trying an SDHC card (between 4GB and 32GB).

I see. It isn't very likely that the problem is the SD card, but of course, it won't be a bad idea to try another one. Note that it might be not ready for high density cards. So I would try a 32GB card or less (not SDXC) just in case. The Goex is supposed to be a Gotek with just a different form factor. So most tips about the Gotek should apply to the Goex as well. There are a couple of differences that I see now though. One of them is that I don't see any jumpers, right? The Gotek might not work correctly if the jumpers are in the wrong position. If the Goex doesn't have any jumpers I would assume it is "factory" configured for an ST. Btw, I don't see that schematics are available, and that honestly, is too bad. Specially when the board is not 100% identical to the Gotek (as I thought initially when it was announced). The Gotek/Goex use a couple of files for configuration. I don't remember what is the default if none of them are present. But I would download the necessary files from the FlashFloppy repository: https://github.com/keirf/FlashFloppy/wiki

Are you sure you have to twist the cable? You do must twist the cable with a "normal" Gotek because an ST drive has the connector reversed in relation to standard PC floppy drives, and Gotek obviously follows the standard pinout. But The Goex is specifically designed for the ST and it is supposed to fit seamlessly in an ST chassis. I would expect that the connector on the Goex is oriented like an ST drive, and not like a Gotek or a standard PC drive. I recommend to check with the manufacturer. Note that if you connected the cable wrong, unfortunately you might have damaged some components on the Goex.

In a way, yes. 3.5 and 5.25 disks are completely different, at least in this regard. The two most common problems with old 3.5 disks are mechanical, or that they develop mould for some reason. Cleaning the disk is many times imperative because otherwise it might even not rotate at all. OTOH, 3.5 disks almost never have the problem that we have with some 5.25 disks, that the surface starts tearing from the contact with the head.

I'm not sure more complex is the most accurate term here. It's just a different situation. Also I wouldn't say the difference is one extra layer on top of the others, but instead that extra layer (if you want to call that) runs in parallel, which is quite a different thing. An emulator must synchronize two real time processes, while a SIO2PC application doesn't. Consider a SIO2PC application transmitting a frame to the serial port. Chances that might get delayed somewhere by the OS or the drivers. No problem at all, the application will wait. Chances also that the reply might get delayed. Again, no problem, the app will wait. Sometimes, depending on many factors, those delays might make the transaction to fail (say, because it would violate the SIO protocol timing and the peripheral then timeouts). No big deal neither, the app will retry. The situation is completely different under emulation. The emulated system keeps running at its own pace and doesn't expect any delays at all. So the emulator must actually freeze and delay emulation to match the delays introduced by the host. But these delays will (or at least, might) alter the synchronization that the emulator must maintain with actual real time, or otherwise the sound might get corrupted, or the video sync might fail. Furthermore, emulation is getting more and more accurate. Initially SIO emulation was at the OS SIO level. Now it is emulated at the individual byte level, or even sometimes at the bit level. This allows maximum accuracy and compatibility with software that talks directly to the hardware and bypass the OS. This obviously doesn't make things easier for our purpose and it would actually increase the latency and create even more timing distortions. The most practical way to handle this is probably to buffer a complete SIO transaction as when enabling what emulators call SIO patch. And this probably would work, at least in most cases, although of course, timing won't be accurate. But if you buffer whole transactions and timing won't be very accurate, then some people might ask what's the whole point of this. At the end of the day, there is no much motivation to implement something that won't be very useful for most people, it won't be very accurate, and the reliability would depend on several external factors that the emulator can't directly control. But both Altirra and Atari800 are fully open source, so you or anybody that is motivated enough, is free to implement it.