Quote from: quasi_Phthalo on June 26, 2010, 08:08:06 pm

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.

FAT and FAT32 are the same thing. However, msd8x supports only FAT16 at the moment, which means most modern flash drives won't work with it.

"FAT" in Windows is actually FAT16 (or it could be FAT12, Microsoft doesn't distinguish). FAT32 is FAT32.

Oh whoops, I got a little mixed up there

ok, i've tried breaking the read up into 3 256-bytes chunks with error checks in between, still to no avail.
can anyone else see anything i might have overlooked? if not, i'll have to assume the issue is outside my program, and either in USB8x or the flash drive itself. Seeing as the drive works fine with my computer, all fingers are pointing to USB8x

what does MSD_cacheOn do? I might be overlooking the page, but there seems to be a lack of documentation on that U_CALL. MSD8x uses it, but i see it was only recently added to usb8x.

anyway, here's the code with init. i'm pretty sure i modeled it after msd8x pretty well:#define numFrames 6360
#define fileName  "/bwmov.bin",0

.org $9D95

Initialize:
xor a
out (28h),a
inc a
out (20h),a
call U_CALL_INIT
jp c,NotInstalled
ld hl,USBDriverBuf
u_call(uDriverInit)
ld hl,appBackUpScreen
ld de,appBackUpScreen+256
u_call(uMSD_Initialize)
jr nc,_success

u_call(uHostKill)
u_call(uDriverKill)
b_call(_ClrLCDFull)
b_call(_HomeUp)
ld hl,sReconnect
call IPutS
call IGetKey
cp kClear
jp z,Exit
jr Initialize

fileHandle: .block 27

_success:
u_call(uUFI_Initialize)
jp c,USBError
u_call(uFAT_Initialize)
jp c,USBError
b_call(_RunIndicOff)
ld hl,sName
ld de,fileHandle
u_call(uDOS_openFile)
jp c,NoFile
NextFrame:
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
jp nz,NextFrame
jp Exit

USBDriverCall: .block 32

FramesLeft: ;not static
.dw numFrames

sName:
.db fileName

Exit:
u_call(uHostKill)
u_call(uDriverKill)
b_call(_GrBufClr)
b_call(_ClrScrnFull)
b_call(_HomeUp)
CallBack:
ret

USBDriverBuf: .block 128

U_CALL_INIT:
ld hl,uuAppName
.db rMOV9TOOP1
b_call(_FindApp)
jr c,uuDone
ld de,USBDriverCall
ld hl,uuDriverCode
ld bc,uuDriverSize-uuDriverCode
ldir
ld (USBDriverCall+uuMod1-uuDriverCode+1),a
in a,(6)
ld (USBDriverCall+uuMod3-uuDriverCode+1),a
or a
jr uuDone
uuAppName:
.db $14,"USBDRV8X",0
uuDriverCode:
push af
in a,(6)
ld (USBDriverCall+uuMod2-uuDriverCode+1),a
call USBDriverCall+uuCall1-uuDriverCode
pop af
call USBDriverEntryPoint
push af
uuMod2:
ld a,0
out (6),a
pop af
ret
uuCallBack:
uuMod3:
ld a,0
out (6),a
call CallBack
uuCall1:
uuMod1:
ld a,0
out (6),a
ret
uuDriverSize:
uuDone:
ret



Not rewriting usb8x, just the mass storage driver (the part I wrote).

Why doesn't your code have $BB, $6D at the start? Nothing else jumps out at me at first glance.

EDIT: MSD_CacheOn attempts to enable sector read caching so that if you try to read the same sector more than once, it won't go to the drive first. If I remember correctly, this uses the extra RAM pages, so it should probably be revisited because of the newer 84+/SEs.

A working demo of Blue8x is mostly dependent on the usb8x update.

You might want to try reading 512 bytes at a time instead just to see if you get the right data. There could be some issue with reading 768 bytes at a time, but it's sounding more like there's memory corruption going on. You might also want to display the contents of the file handle memory both before and after each call, pausing for a keypress each time, and see if it goes wonky while in the call to DOS_fileRead.

so, i took your advice, and watched the file handle. I HIGHLY doubt that it's coincidence that the garbage data comes in on the very frame at which the seek pointer carries to the second byte. Also, the 'type' of garbage changes at every carry.

I didn't catch that you said this was happening. That certainly sounds like a usb8x bug...I'll look into it.
Perhaps as a temporary workaround, you could change the seek pointer yourself (I can't remember how simple or complex DOS_fileSeek actually is).

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).

Thanks for reminding me, seems I was wrong