Closed jtsiomb closed 6 years ago
The plot thickens. I'm able to read the disk correctly back through the serial port with cloanto's amiga explorer, and comparing that adf with the original shows no differences. Yet checkdisk still marks at least 20 sectors as bad. I guess maybe amiga-explorer manages to read the problematic sectors correctly with multiple retries, but other code might not try as hard which results in the corruptions I mentioned in some games.
Hi. Very interesting results, could be magnetism, but I guess equally it could be me encoding the MFM data incorrectly. Difficult to say. Does it sound like cloantos amiga explorer is re-reading tracks over and over again? The only other possibility is the timings being slightly off but not sure about that either (although the reader is very forgiving)
The plot thickens. I'm able to read the disk correctly back through the serial port with cloanto's amiga explorer, and comparing that adf with the original shows no differences. Yet checkdisk still marks at least 20 sectors as bad. I guess maybe amiga-explorer manages to read the problematic sectors correctly with multiple retries, but other code might not try as hard which results in the corruptions I mentioned in some games.
Not sure if it's re-reading a lot because it doesn't provide much feedback while it works. However your tool when writing with verify, takes different amounts of time to write and verify some tracks, which is clearly detectable by the uneven cadence of the stepper motor. Not sure if that means you're re-reading it more than once or not.
Ideally I think I should write some code in the amiga to read the tracks, and see what I get.
Another data point is that some game disks fail to boot at all with kickstart 1.3, but manage to proceed further with kickstart 3.1. I know for a fact that the trackdisk.device was re-written from scratch for kickstart 2.x, and I guess the new version might be more fault-tolerant and able to recover where the original code (and trackloaders in many games) fail to read properly.
Hoping the new V2.1 will resolve the writing issues, will have to wait and see I guess
I backported your changes to my AVR version of the firmware, and I'm afraid I'm still getting checksum errors on the amiga, while still reading back correctly the written disks on the pc.
I guess this was the change most relevant to this issue: https://github.com/jtsiomb/usbamigafloppy/blob/master/fw/src/avrfloppy.c#L517 I'm pretty sure I didn't introduce any bugs while manually back-porting your changes from the diff, but feel free to take a look.
Edit: maybe I should buy an arduino and try to run your original firmware, just to eliminate the possibility that I introduced the error in my version.
Very strange! I will continue to investigate!
On 14 Mar 2018, at 01:45, John Tsiombikas notifications@github.com wrote:
I backported your changes to my AVR version of the firmware, and I'm afraid I'm still getting checksum errors on the amiga, while still reading back correctly the written disks on the pc.
I guess this was the change most relevant to this issue: https://github.com/jtsiomb/usbamigafloppy/blob/master/fw/src/avrfloppy.c#L517 I'm pretty sure I didn't introduce any bugs while manually back-porting your changes from the diff, but feel free to take a look.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.
Hi Rob. Have this all built and have had a couple of successful writes of DOS disks. Most times, when the disk has successfully written, I can run it through a checkdisk and see alot of Checksum errors. I have recompiled the 2,1 from source with the same results. Is there any further information I can give you as I think this is an awesome project.
Hi
Yes i have had a few reports of this and am trying to find the cause as the verify works so obviously I’m a lot more forgiving. I’m waiting for some better analysis kit to arrive to try to see what’s going on as with this old oscilloscope I have it’s impossible.
I’m trying to find out if the checksums are on specific sectors (eg ones at the start or end of a track) or just random. This will give me something to work towards
If you know not any tools that can report which sectors have the errors that would be helpful...? I’m going to post a query on EAB
Regards
Rob Smith Creative/Frontend/Backend Developer http://robsmithdev.co.uk
On 25 Mar 2018, at 10:58, dragonbane notifications@github.com wrote:
Hi Rob. Have this all built and have had a couple of successful writes of DOS disks. Most times, when the disk has successfully written, I can run it through a checkdisk and see alot of Checksum errors. I have recompiled the 2,1 from source with the same results. Is there any further information I can give you as I think this is an awesome project.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.
Update now available - you will need to update the Arduino and windows software
Regards
Rob Smith Creative/Frontend/Backend Developer http://robsmithdev.co.uk
On 25 Mar 2018, at 10:58, dragonbane notifications@github.com wrote:
Hi Rob. Have this all built and have had a couple of successful writes of DOS disks. Most times, when the disk has successfully written, I can run it through a checkdisk and see alot of Checksum errors. I have recompiled the 2,1 from source with the same results. Is there any further information I can give you as I think this is an awesome project.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.
Excellent! the issue seems to be fixed. I can write disks without checksum errors now, and KS1.3 manages to load them just fine!
Can't wait to try this. Thanks for everything! :)
I've been experimenting with writing disks, with inconsistent results. I'm using a variation of your hardware design using a standalone AVR instead of an arduino, for which I've sent you an email yesterday (please check your spam if you didn't receive it).
The issue I'm encountering is that sometimes I'm writing an ADF, and read it back correctly (diff between the read-back version and the original returns no differences), but when I put the disk in my amiga 500 and run a checkdisk with X-copy it finds a bunch of errors. And indeed sometimes graphics in games I've written this way are corrupted, or they failed to run at all. To make sure the disks are not the issue, I try to transfer the same ADF file to the same disk through a serial cable with transwarp, and there are no errors.
The floppy drive I'm using in conjunction with the AVR hardware is a regular PC floppy drive (mitsumi d359m3d) which is naturally an HD drive. Might this be a problem of insufficient magnetization by the PC drive? The floppies I'm using are DD, so the drive should be able to detect that and change the flux if such a thing is necessary I guess. I have not so far tried connecting the internal amiga drive to the AVR to see if it makes any difference.
Any ideas ?