keithI think I’ve stumbled on something.
I don’t think I’m capturing enough data.
13,824 has been my magic number forever. It was larger than the 13,800 that Marco used in afr.c. But I’m beginning to question this.
Note that sector 4 is my bad sector!
My current disk, cyl 6, lower track layout:
first whole sector starts here:
sectors 5-10: 1034, 2122, 3210, 4298, 5386, 6474
GAP: gap is ~846 bytes (8408-(6474+1088))
sectors 0-4 positions: 8408, 9492, 10580, 11668, and sector 4 : 12756
If you add 1088 to 12756, you get 13,844 lo and behold past my reading marker!!
I’m not sure I have a reference for largest gap? Maybe I can check the bits per track in the floppy material and derive my answer from that…
I’m thinking of upping this to 16,384 just to be safe….. I’ll get back to you.
Note that there was not enough room for sector 4 to be read in at the beginning. I’m 20 bytes short on this sector at the end, but worst case is even higher. Like at least 1088-1034 or 54 bytes. Plus whatever the gap maxes at…….
Well, that was definitely it.
I am now reading full normal disks with zero “hard” errors. Didn’t have to retry even a single track across my last disk.
WinUAE properly loads and runs the 450k animation that is on the disk, and it md5sum’d out perfectly, so we are good.
I’m confused about a couple things:
1> my test disk refuses to be read, I get a million errors on all the tracks. A couple real disks work, so who knows.
2> ADF Opus complains and complains about Root Block checksum error on startup, and when copying files I get a million “adfReadNextFileBlock: seqnum incorrect” errors, but then the files copy 100% correct.
I think I might not be writing the ADF right or something.
I copied the method from afr.c, where I’m just storing all the sectors in order(0-10), 512 bytes per sector, from cyl 0 to cyl 79, with the lower sectors coming first and then the upper sectors coming next.
I wish I could take ahold of AmigaOS sources to see how big is the gap which I believe is written on the disk just before actual track data will be written.
In DiskMonTools’ MFM Editor there is a ‘2000’ value shown on screen as some gap preset size. So 11968 (11 sectors 1088 bytes each) plus 2000 gives 13968. Slightly bigger than Marco’s. I wonder if that gap size can be seen in some OS includes or headers.
The MFM Editor reads 16K at most, so maybe 16K is quite robust.
On the other hand, should you ever want to read HD disks, they would likely provide (22 sectors 1088 bytes each) 23936 bytes, plus the gap.
Well my FRAM is 32kbytes, so my hope was to keep one track under 16k so that I could potentially load two at a time. Or load the same track twice, etc.
Since it’s 32K, HD disks should be no problem, but they are off my radar screen right now for things to do.
I’ll check into the gap size and post it if I find anything.
My problems from last night became pretty clear this morning.
I did a DIFF between a transdisk of a floppy .adf, and my .adf. At least 782k matched in one chunk, and then there were others that matched in some cases, and didn’t in others. I couldn’t figure out what the heck was going on because all checksums matched.
It turns out that I’m somehow either skipping or missing tracks. My routines for reading a floppy are are sloppy (maybe I’m a poet and don’t know it) and in the interest of speeding things up I was shortening pauses between actions. My software would hang every now, but it would automatically resume, so I figured all was well.
I’ve got to take a serious look into where I need what type of delay. I’m pretty confident that will fix this.
How do you see you’ve missed/skipped a track?
Speaking of disk heads stepping, 3ms is the minimum time between step pulses, and you should wait at least 18ms after the last step.
Official Commodore Amiga low density floppy track gap is 830 raw MFM bytes of 0xAA.
Wow! Where did you get this from?
I happened to get a couple of RKRM books – just imagine how rare these can be in Russia – and am trying to download every piece of Amiga documentation possible.
If I told you, I’d have to kill you. 🙂
I’ve seen this in more than one place, however. Maybe “Amiga Disk Drives” book that I have?
I actually bought a couple of the RKRM books back in the day when they were popular. It was a US $50.00 purchase back then, and I was a poor kid working on minimum wage. The funny thing is that they are more use to me now than 17 years ago when I bought them.
Oh yeah, by the way, two points that you might find interesting.
1> Commodore Amiga’s were produced a mere 300 miles from me or so. On the other side of my state, Pennsylvania.
2> I’ve been talking with Laurent Clevy (apologies if this spelling is wrong) of ADF FAQ fame and he verified that the odd/even bits were indeed switched around and changed it in the new FAQ.
In fact, the RKRM Libs and Devices is full of includes, I’ll browse through them more thoroughly.
I’ve traveled to the US last summer to see my sister in Connecticut. While we’ve been to Washington and went to see Niagara (from Boston to Buffalo and then back to New York), we seem to have completely miss Pennsylvania 🙂
Buffalo isn’t too far from me! Buffalo is only about 50 miles(80km) from Pennsylvania. I’m still another 150 miles(240km) + from the border.
[…] I thought it was a data-size problem cropping up again, but I was […]
Hi
I am reading an amiga disk with an atmega8 and I see between 700 and 750 bytes of gap (only one disk tested). The rest is written over with the last track so that all space is erased. If that would not be the case you could find old sync markers. And since the RPM of a diskdrive is not perfect you have these 830 bytes “lead in” and can safely write over it with the last track.
still waiting for my sram (why did you use fram?) so I can read the whole track. to find the sync I look for 200-300 repeating 0xaa first and then I look for 0x4489. that way I can spare the saving of up to 830 bytes of 0xaa.
Denis
PS: just started some days ago. but your blog is a really cool source of information!
Greetings Denis!
I ended up using the FRAM because it was easy to use, easy to request samples, decent capacity (32K bytes), and was driven serially. The serial nature is very nice because it saves pins over normal parallel memory, AND because the data comes in serially. It’s also nice because the device is pretty much static — I can stop the clock at any time, and then just restart the clock when I want to continue reading/writing data. It’s also an SOIC-8 form factor which fit my prototype board perfectly.
I didn’t really “select” the FRAM, but it really worked out quite nicely.
Since the data comes in one bit at a time, I pretty much write out a few bits at a time. I don’t have to worry about packing bytes, fifos, or all that other crap.
My overall (current method) is to measure the time between falling edges, and if the time falls in the range for a ’10’ (say 3.24us-4.24us), then write a ’10’ to the fram. If it falls between 5.24-6.24us write a 100. If it falls 7.24-8.24us, then write a 1000.
I collect 112440 bits, or 14055 bytes. When transmitting them to the PC, I search for a 0x4489 for each sector. So the PC only gets exactly 11 full sectors. This search routine effectively skips over the gap.
What’s funny is that I was just about go edit this exact post you responded to, yesterday.
I’ll let you in on a secret as well. I have my floppy now attached to my FPGA, and I’m working on a gen-3 floppy project. Using verilog, built-in block rams, picoblaze, etc. It is admittedly slightly overkill, but this will help me learn FPGA stuff — and be fun in the process.
(oh and thanks for the compliment on the blog. There was(is?) a lot of struggle (sometimes pretty ugly) while I was working on this project. It was mainly due to my lack of knowledge, and lack of following a methodical process for doing extensive testing on each part. I also obtained logic analyzers, etc, afterwards which REALLY helped debug some critical parts of the code. I want to eventually put together some white papers on doing this type of thing because I think my experience can be valuable to others.)