; Main loop on the drive mloop jsr readbyte cmp #'h' bne mloop lda #hmsge-hellomsg ; number of bytes that we'll be sending jsr sendbyte ldx #hmsge-hellomsg stx $06 sendhello ldx $06 lda hellomsg-1,x ; send message to IECHost using the fast protocol jsr sendbyte dec $06 bne sendhello beq mloop hellomsg .text "!DLROW OLLEH" ; hello world! hmsge
I had an idea for synchronizing just based on bit changes on the lines, ie. use the pin change interrupt on the server side to synchronize the bit timing. Once you have any two pin changes, you know the relative clock speed and can keep it updated. You should be able to send the raw data in real time in one pass, no need for sector seek etc., just start sending out whatever passes under the head and interpret that as track data later. I believe there's just enough time to do this at the highest track density.
edit: Come to think of it the floppy bit-stream doesn't afford clock-recovery on the receive end when transmitted with 2-bits in parallel, and even if it did BVC jitter would cause trouble.
Quoting doynaxedit: Come to think of it the floppy bit-stream doesn't afford clock-recovery on the receive end when transmitted with 2-bits in parallel, and even if it did BVC jitter would cause trouble. We are talking cross-platform here so assuming the raw bits could be sent out, shouldn't there always be something toggling due to the encoding? (well, maybe not during sync) Synchronization could then easily be done by correlation on a sampled buffer load. Perhaps the bvc jitter could be solved in the same way assuming enough bits are transferred for each bvc? The main question is though, can enough bits be sent out per byte in average?
We are talking cross-platform here so assuming the raw bits could be sent out, shouldn't there always be something toggling due to the encoding? (well, maybe not during sync)
lax $1c00 sta $1800 asl sta $1800 lda swizzle,x sta $1800 asl sta $1800
Synchronization could then easily be done by correlation on a sampled buffer load. Perhaps the bvc jitter could be solved in the same way assuming enough bits are transferred for each bvc?
The main question is though, can enough bits be sent out per byte in average?
Isn't possible to transfer raw GCR data to IECHost rebuilding bytes here?