looking at the code this a.m.

Welp,

I decided to take a look at my code today, although I can’t actually implement anything until after I get home from work. 🙂

Not sure if I mentioned this eariler, but I’m now padding the data sent from the SX back to the PC with a pair of 0xFF’s.  So <0xFF> <0xFF> <13,824 bytes of data> <0xFF><0xFF><8bit-checksum>.

This padding mainly helps me find the start of the data, because I now echo command characters, there is normally a garbage character or so.  It also helps me find the end of the data, and makes the checksum be the very last byte transmitted.

I’m still using SX/B’s built-in UART commands instead of my own, because I found a small issue with my UART bit-banging code, where the bit period varies with the actual data sent due to how MOVB actually operates.

I’ve tacked on a simple 8-bit (% 255, mod 255)  checksum so that I’m sure that data sent = data received.  I’ve got enough problems than to worry if there was a transfer error.

My checksum routine on the PC was kinda screwed up, and I found the problem this morning.  I was including the final FF’s and checksum into the actual checksum, so that’s why it was consistently off.

I’ll put those changes into effect within the next couple days, although between Christmas, New Years, putting a new Bamboo floor in, etc things have been hectic.

The progress has been particularly slow, which is mainly reflective of the fact that I haven’t spent much time on it.  I’m beginning to worry that my project may be undermined by the delay, in that the floppies continue to deteriorate while I’m screwing around.  I do, however, expect to be able to fine tune my SX code to deal with the actual media problems — as long as the data is SOMEWHAT recognizable.  Perhaps I should find a paper that talks about things like “bit rot” etc with floppies, and see how the actual media changes, etc.