ijor

Not sure if it's the default or not, but certainly it depends on the configuration. So again, check the following page at the wiki: https://github.com/keirf/FlashFloppy/wiki/Initial-Setup#hxc-compatibility-mode

Once again, did you try the AUTOBOOT image?

Did you try the AUTOBOOT.HFE image? Just in case, did you try SDHC cards, 4GB-32GB, as I recommended, right? Not the older and smaller, not the bigger and newer SDXC ones. And once again, contact the manufacturer, he might suggest some other tests.

It's just a number I found somewhere, I probably need to make it configurable and do some tests to see how far down a real FDC can stay in sync. I'm not 100% sure, but I think that Nezgar is right and the "standard" (if there is such a thing) for slow speed mods is around 266 RPM. Certainly 285 is way too fast.

If you look at atxfile.h, you will see that there was always a field, called "rate", reserved at the track header specifically for that purpose. We never used it because we never had a real need for it. But might be about time. If you want we can easily formally specify it: struct ATX_TRACKHEADER { ulong next; ushort type; ushort pad0; uchar track; uchar pad1; ushort nheaders; ushort rate; ... rate: two bytes, small endian. Defines the relation between the bitrate and RPM at which the track was recorded. It is expressed in bytes per track. An FM (single density) track recorded at nominal bitrate at 288 RPM would have the value 3255. An MFM track (either medium or double density) would have the value 6510. The field is optional and should be left at zero if not exactly known. If the field is blank it should be interpreted as the track was recorded at nominal bitrate and RPM. We can change the name to bytesPerTrack, which might be more intuitive, if you insist. But rate was the original name.

Would you mind posting a couple of those, please. Did you try other images? I guess he means AUTOBOOT.HFE which is available at the FlashFloppy download archive. See this page for instructions about that mode: https://github.com/keirf/FlashFloppy/wiki/Initial-Setup#hxc-compatibility-mode Btw, did you contact the Goex manufacturer?

It might be feasible to emulate Sally at real time using a fast modern MCU. May be with something like an Arm Cortex perhaps. But I think it is obvious that this task is much more suitable for an FPGA and I think there are already such 6502 chips replacements. A FPGA could easily do much more, not only "clone" Sally at 1.79 MHz, but could also do, i.e., a 65816 at much higher frequencies.

I know what the manual says. But, IMHO, it is not fully accurate. I would say even a bit dishonest. As I already said, it can sometimes create a working copy. But making a working copy and actually copying the track are two different things. The track layout would be different than the original; the recorded frequency would be different and the timing would be different. Actually, if the SuperArchiver can really copy tracks with so many sectors, then why they released the BitWriter? It is not much different than the Happy copying tracks with weak sectors. As we recently found out, the Happy 810 can sometimes make working copies of weak sectors using HWA mode. But that doesn't mean it can actually creates weak bits, it doesn't. It just creates a track that sometimes has a similar effect and it works in some cases. Again, such tests only confirm, in the best case, that the copy works. It doesn't confirm that the original tracks were copied accurately. Yes, of course, you do can create specific tracks with lots of sectors. That doesn't mean you can create them with an arbitrary content and at the original recording frequency (RPM). No actual protection was done like that. Try using the custom formatter to reproduce the tracks of, say, Archon II.

Well, I was thinking... a8rawconv doesn't need any kind of RPM compensation because it already expects the raw dump to be produced on a drive that has a different RPM than the one that the disk was recorded. That's the normal and common behavior. The disk was originally recorded at 288 RPM and the dump was read at either 300 or 360 RPM. But other tools might not. It is actually likely that some ST don't expect that because you don't normally have that RPM discrepancy with 3.5 disks. Both PC and ST drives use 300 RPM disregarding the density. But he is using 5.5 disks and more than likely a 5.25 drive rotating at 360 RPM. So that might explain, at least, why he needed the -RPM parameter for ST disks.

Almost all software runs, but many, perhaps most games run slower than they were designed. In many case the music sounds slower, and the general pace of the game is slower and then it is usually easier to beat. The other way around is also true. Some european games are a bit too fast when played on an US machine. Note that the country flag you see at Atarimania doesn't have much to do with this. The flag only indicates where a specific release was published. Not where the software was originally developed, which is what usually matters.

Well, the relocated code is the original 1050 ROM almost exactly, that's the whole point. The only necessary change is to somehow avoid the rom checksum error. The relocation is done automatically by the assembler as long as you have a good disassembly of the original ROM. I don't remember if I made the disassembly myself or if I got it from somewhere else because I have several.

I found my own Dehappy. It seems to run the original 1050 diagnostics just fine. At least I tried the main diagnostics under Altirra and it seems to runs ok. It certainly doesn't reboot. I didn't try on real hardware. Neither tried the long burn-in test. The loader is a bit rough. I made it for myself years ago. So error checking is minimal. myDehappy.atr

Now I remember that I read about such an utility but I could never find it. Then, I made my own "dehappy" tool and that's the one I used it. That was years ago. I searched by stuff and I can only find parts of it, but it's not complete. I would need to search my backups. It is not too difficult to recreate it in the worst case. Sorry.

That was probably by design. The extra RAM is never used by Happy own software. As Nezgar said, probably it is there only because it became cheaper to manufacture. Probably they just didn't want people starting to complain that they have a less powerful board. The ROM version is not much different. I guess they didn't want to encourage people to upgrade the ROM. I used Dehappy several times. What I meant is that I never tried using it with the original 1050 diagnostics. I though it should be available online somewhere, but I cannot find it.

There is a third party utility, called "Dehappy", that installs the original 1050 firmware relocated to Happy RAM. I didn't try, but it should/might be able to run the original diagnostics. It does. Depending on the casing of the word "pass" you have rev 1 or rev 2. See post #2 by Nezgar.

There is, at least, one third party european software for the Happy that requires 8K:

Here you are ... Original: Copy made with HWA mode: Edit: The Archiver shows 19 sectors on the copy. But this is just because it is being confused by all sectors having the same sector number and then it fails to detect where the track ends. The actual track has 17 sectors, same as the original.

Well, for the case of Synapse, all sectors on the track are replaced with a different copy of the "weak" sector. So you have them distributed all along the track. The weak sector on this title is sector 16. The copy made with HWA has 17 duplicates, each with different data, for sector 16, and nothing else. They are 17 and not 18, just because that's the layout of the original track and HWA doesn't create any extra sectors. Obviously this happen to work in this case because the software doesn't attempt to read any other sector on that track. Otherwise would fail. If you are familiar with Archiver you can check both layouts under emulation. Use Altirra with The Chip "full" drive emulation and mount the respective ATX images.

That's odd Anyway, the RPM parameter should be avoided. It modifies and distorts the data, which is very bad for preservation purposes. Of course, if you are only extracting files from personals disks, then it doesn't matter. But even then, it shouldn't be needed. May be the gw software needs it if, and only if, you are using the gw software to interpret and to convert the dumps to plain sector level images (ATR, ST). If you are using more standard tools to perform the conversion from SCP images, such as a8rawconv for 8-bit images, then it should not be needed.

That's correct. As I said already at the initial post, this HWA method could fail, and I'm sure it does fail, in many cases. I don't think it has a very smart strategy. It doesn't create new sectors, it only replaces existing ones. For the case of Synfile+ it simply replaces ALL sectors on that track. There are different types of PDB, not all involve weak sectors. But yes, for those titles with weak sectors, the PDB includes additional custom code to program the Happy drive to simulate the weak sector at run time.

Good to know. Thanks Are you sure? How it could work without the RPM parameter for Amiga images, but not for ST ones. Not sure that makes much sense. Would you mind posting an image produced without the RPM parameter?

Great interview, many thanks. I see he released the source only for the latest version of MyDos. For historical reasons, it would be great to have older versions as well. Would you mind asking him if he still has the source for older versions?

Yes, there are about a dozen Happy documents and flyers, but there is no V5.2, or V5.3 software manual. As Nezgar is saying, we are missing any documentation about the Autospeed mod, which is supported on those versions only. Conceivable there was no full manual for those versions but perhaps some kind of addendum. Disk images are less of a problem. Most are already available here. But if you have any to contribute, please do it.

Hi Cj, Please considering including one or two extra tracks. That means tracks 0-41 on 48tpi drives, and 0-81 on 96 tpi ones. Not sure about the default gw settings. Also I don't recommend including the rpm parameter. I'm not that familiar with the gw software, but we don't want it to perform any kind of interpretation to the data. So it should not need the original recorded RPM value.

Btw, I forgot completely that the Happy 6.6 Special Recovery menu does include the HWA option. But according to some Happy notes it doesn't perform "anything usual". Seems it was just a leftover from version 5 code.