the setting:
I have braved the caverns of attempting to write an asm program that uses usb8x's msd driver to interface with a flash drive. I've managed to retrieve file handle to the file i want and read many correct bytes from it. 
the issue:
BUT, after a certain amount of time (the same every time), the data i am reading comes out as garbage. first the 'organized' kind of garbage that has patterns so it's obvious that it is actually data, just not the data i intended to read. then, comes some entirely random garbage. eventually, it runs across the correct data again after a while, but then it relapses again. 

what is going on? is the file handle being corrupted? is the driver not reading from the correct place?
i'm checking for the carry flag after each read and i'm checking that bc (# bytes read) = # bytes i told it to read

help! i'm drowing! thanks

This is a bit off-topic but what is the difference between USB8x and MSD8x anyway?

i realize that, per forum rules, i still need to wait 8 more minutes to make the 6 hour threshold so i can double post, but this is an important update:

there apparently is some corruption of the seek pointer! I altered the program to keep track of its own seek offset an reset the pointer between each read and it works almost* flawlessly! (the file is very large, so the seek pointer update time gets longer a n d  l o n  g  e   r  .  .    ., so its impractical) I really shouldn't have to do that though. the file read U_CALL should take care of that, right? Here's the new code:#define numFrames 6360
#define fileName "/bwmov.bin",0
b_call(_RunIndicOff)
ld hl,sName
ld de,fileHandle
u_call(uDOS_openFile)
jp c,NoFile
NextFrame:
ld bc,fileHandle
ld hl,(SeekPointer)
ld de,(SeekPointer+2)
push hl
push de
u_call(uDOS_fileSeek)
pop de
pop hl
ld bc,768
add hl,bc
jr nc,_noCarry
inc de
_noCarry:
ld (SeekPointer),hl
ld (SeekPointer+2),de
ld hl,fileHandle
ld de,plotSScreen
ld bc,768
u_call(uDOS_fileRead)
jp c,FileReadError
ld hl,768
sbc hl,bc
ld a,l
cp 0
jp nz,FileReadError
ld a,h
cp 0
jp nz,FileReadError
b_call(_GrBufCpy)
b_call(_GetCSC)
cp skClear
jp z,Exit
ld de,(FramesLeft)
dec de
ld (FramesLeft),de
ld a,e
cp 0
jr nz,NextFrame
ld a,d
cp 0
jr nz,NextFrame
jr Exit

SeekPointer: ;not static
.dw 0,0

FramesLeft: ;not static
.dw numFrames

sName:
.db fileName
*even with the seek pointer corrected, the data is randomly garbage on some scattered reads. i have a hunch that these are the places where the seek pointer gets corrupted in the first place, perhaps?

msd8x is just an interface to the MSD driver in usb8x. The MSD driver is only in usb8x. There was a time when the driver was in msd8x itself, but it has since been shifted and integrated into usb8x itself.

So msd8x is just the interface (and it uses the extra RAM pages, which is why it doesn't work on newer 84+/SEs -- the MSD driver itself still works on those models).

As far as what you're seeing, I would check and make sure you're not using the same area of memory more than once (using more of statVars than you should be, for example -- 531 bytes). I've driven myself insane more times than I can count because of strange memory corruption issues because of things like that.

It's sheer luck that it works on your newer 84+.

When I find the time, I'll rework it to not use the extra RAM pages.

usb8x itself is also long overdue for an update.

It's sheer luck that it works on your newer 84+.

When I find the time, I'll rework it to not use the extra RAM pages.

usb8x itself is also long overdue for an update.

Update == FAT32?

SirCmpwn: did 8 minutes kill you? well, let's get back on topic, shall we?

Excuse you?

Also, FAT32 would be a nice feature, although I would just reformat it as FAT.

SirCmpwn: did 8 minutes kill you? well, let's get back on topic, shall we?

Brandon, I've relocated the file handle (and the USBDriverCall and the USBDriverBuf each) to some (isolated) memory inside the program where it couldn't possibly be corrupted accidentally, nor could they corrupt each other, but the same thing happened. Exact same garbage and everything, so I know it's not that.
Am I missing some error checking?
Is there a safe limit on the maximum number of bytes read at once?

(oh, yes, side note, FAT32 would be helpful because WINDOWS DOESN'T LET YOU PARTITION REMOVABLE MEDIA!)

I think Windows actually will let you, it's just that all but the first partition will be inaccessible. I'm really not at all sure what happens with usb8x if you place a FAT16 primary partition at the very end of the drive.

I attempted to hack in FAT32 support long ago but failed. It would require a from-scratch rewrite of all the code, which probably needs to happen anyway.

Yep, so we can mess around with Blue8x, like I've asked for several times

I don't remember you asking for that, but yeah, that's the main priority for getting an update out.