keithThe more and more I play with this I find that I’m limited with visibility. Its tough to debug when you constantly have to deal with this overhanging problem :
The data arrives at my hardware, and to the PC bitshifted. The data is not evenly byte-aligned, and so before you can do anything with the data, even look at it, you have do a couple things:
1. Find how much the particular sector is shifted by finding the sync.
2. Anytime you need to read a byte, shift all future reads by the same amount
You can’t simply access an array, because you need to massage the data for read.
This I find to be a royal pain in the butt, and a lot of extra bitshifting code on the PC.
I was reading some 68000 assembly on the amiga yesterday, and most of the code is so simple because the hardware sync’s on the sync string, and the data arrives to the higher software layers properly shifted.
Which made me think next, why can’t my hardware just deliver properly aligned data?
So at least for the next couple days, I’m going to look into ways of doing this.
This isn’t particularly easy, because right now, I’m handling everything at the bit level since everything done is serially. One bit received, one bit stored into the FRAM. The segment of code that handles the USB transfers is mostly one bit at a time as well.
I suppose I could setup a 4-byte shift register, checked after each bit to see if the contents of the four bytes are 0x44 0x89 0x44 0x89. Hrrmm.. I wonder if just 0x44 0x89 would suffice. But then I guess I’d have to determine if that’s the first one or the second…. but I guess either way, aligning the next data on a new byte would work. BUT, that’s assuming I keep track of the which bit position I’m currently in, and then “hurry up” and shift a bunch of 0’s or something into memory. I say hurry up because if I’m doing this when I’m storing, time is of the essence.
The other alternative, I guess, is to handle this at transfer time, but time is crucial there too because I’m dealing with an ASYNC uart on the USB side, where time between bits is very important. However, I can control the exact time between bits by changing the baud rate. Which is currently at 9600. If memory serves me 9600 gives me something like 104 microseconds between bits. I guess that’s tons of 20ns clock cycles.
I’m just thinking out loud………
Would it make any sense to try to implement some sort of “auto tuning” towards the bit stream that’s been delivered from floppy? Sort of judging long “1”s still as valid “1”s, and long “0”s as valid “0”s?
BTW, I seem to beat the hell out of my project:
https://milliways.chance.ru/~tnt23/pics/amiga/workbench1.jpg
https://milliways.chance.ru/~tnt23/pics/amiga/workbench2.jpg
One more thing.
Fiddling with MFM Editor from DiskMonTools suite, I couldn’t help but notice the following thing.
Using Track Info gadget, one is shown the list of sectors found within current track. The left column in the list is byte offset at which given sector resides. And it is immediately followed by a dot and a single digit which I believe can be additional bit shift.
These digits aren’t the same all along the track. Can this make a point?
Yeah, that is the bitshift that’s after the period. And the software currently handles the situation when the bitshifts are different. What it roughly does is this :
for bitshift = 0 to 7
lookforsyncsat(bitshift)
next bitshift
and if lookforsyncat() finds a SYNC, then it reads the track in shifted that particular amount.
All of the routines in AFR somehow rely(directly or indirectly through another function) on the current bitshift to be set, and all reads get shifted by a global bitshift variable.
I was thinking about doing the bitshifting in hardware, but it looks like its going to be pretty tough. There are too many dependencies. Right now I process just a stream of BITS in hardware —- I don’t even understand or deal in bytes.
My next thought, once I can get this semester of school out of the way, is to have a pre-process routine that goes through the raw data, trying to remove one sector at a time, and get all the data properly bitshifted BEFORE mfm decoding. The fact that this is currently done “on the fly”, you can’t see/debug the intermediate steps because the data is either 100% MFM with multiple bitshifts or 100% decoded. I don’t like that.
I want to post some output from my software –it’s sort of raw debug output, but you’ll understand it.
Slightly off topic, could you recommend companies and/or links for obtaining components? I need some quite odd chips, like 2Mbytes DRAM (or better yet 8Mbytes), but these seem to be obsolete (most manufacturers went for SDRAM nowadays) and are practically unavailable here in Russia.
These are who I generally deal with:
https://www.digi-key.com/
https://www.mouser.com/
https://www.newark.com/
Yeah I need some super old ram to upgrade my A500 accelerator from 2mb to 8mb. Old chips, like 20 pin DIPs IIRC. I forget the configuration of the ram, but it takes 16 or 20 of the 20-pin jobbies to be properly configured.
HTH
Thanks, will investigate those.
I have upgraded my A500 to whole 1M of RAM. Got 8 chips from a friend, the most tricky part was to clear holes for them on the motherboard from solder, and tweaked some soldered jumpers (mine is Rev8.A).
Any updates lately?
Unfortunately not. I’ve been pretty busy lately. Usually over the Christmas break between semesters I have a decent amount of time. It seems the holiday festivities ate up what time I had, and school seemed to start early this year. I’m a Computer Science major at University of Pittsburgh (https://www.cs.pitt.edu) in the long stretch towards the finish line of my Bachelor’s degree. I will probably finish this year, provided that my work schedule and my school schedule somehow mesh. I’m taking a heavier load this semester than normal, three classes instead of two, which I do at night after work. My schedule has been particularly rough lately….. last night I worked until midnight, I’m back in work as of 7am, and I have school directly after work, including a decent one way commute.
This is not to say that I haven’t put thought into the project, as I have. Unfortunately, I have a habit of over-thinking the project, and not putting enough real effort into it. Was it someone who was working on the shuttle project who said, “One real test is worth 1,000 expert opinions.” ? My debugging book tells me to, “quit thinking and look.”
I’ve also been playing with a new toy. I recently bought a 9mp Point and Shoot digital camera, upgrading from my earlier 3.2mp.
Where are you at with your project?
“Quit thinking and look”, I like that!
I can understand working and studying at the same time is not easy. Hope you’ll do well.
Must be a nice camera of yours. Mine is Canon EOS300D since 2003, I hardly find time to use it other than for shooting my DIY stuff 🙂
Being mostly good last year, I’ve got an old Atari 65XL from Santa. Will look at it later, at least after I’ve done most of my Amiga floppy project.
Speaking of the latter, I’m pretty done I think. Stuff gets browsed, loaded and emulated well. I have posted some shots as well as some comments at http://www.amiga.org. Only problem is speed issue, the floppy image loads in 24 seconds and gets MFM encoded in another 35 seconds. Oh well, still usable I guess.