keithGood news, good news.
After banging my head on the same problem for the last three hours, I’ve finally made some more progress.
Using option #2 from the previous post, I’ve written two non-isr based software UARTs for communicating to the USB FTDI chip, and I’ve tested pretty much the full range of values in each direction.
So what’s this mean? I’m one MORE step closer to total integration of all my code. There is now ONE SX program for everything and ONE pc program for everything. My receive code only receives single bytes, as I’m not messing with strings etc etc on the SX — but this is OK. This gives me minimum 256 commands…… and even if I want to set it up to receive an individual track number, I have plenty of command room.
The first two commands will be:
1> “read track” where (for right now only) it will sit there and wait for a track, stopping the buffer at, say 16k. It will use the ISR code to write the data into the FRAM, and then report OK status back to the PC
2> “send track” where the SX will transfer the contents of memory to the PC via USB
The baud rate between the SX and the PC right now is 2mbps. This is very respectable, and testing the SX with a terminal program, I wasn’t dropping anything! Now I DID need a pause between bytes of about 200us, but that’s not too much. Even then the data was FLYING by….. I hope *MY* software receive works fast enough to capture the data at that rate……..
Regarding track readout, you may wish to wire INDEX signal to the SX, too, and wait for INDEX pulse to sync your data aquisition code with that.
Check an excerpt from RKRM on INDEX pulse in my blog:
https://tnt23.livejournal.com/524302.html?mode=reply
I’m lucky enough to have some original RKM’s from back in the day. It’s funny because when I bought them originally, I was perhaps 14, they were expensive (USD $50 — I have two) and for the most part didn’t know what the heck to do with them. I was programming on the amiga when I was young, including some 3D graphics stuff, but you might argue they are more useful to me now.
I have read this passage before.
Once I start working on the hardware side again, which isn’t too far out, I’ll look at this again.
My PC software(well, modified Marco’s), though, doesn’t care much about extraneous data. I have seen this data at the beginning of a dumped track, usually works out to a few bytes. The entire decoding process doesn’t start until a valid SYNC is read, so a half dozen bytes received before the SYNC are simply passed over when I’m looking for a SYNC.