Omnimaga
Calculator Community => TI Calculators => ASM => Topic started by: quasi_Phthalo on June 25, 2010, 11:40:56 pm
-
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
-
I think the msd driver from usb8x is outdated. The MSD8x driver should do better.
Also, could you post code please? It might just be some stupid register corruption, you never know. (and Linus' Law: 'given enough eyeballs, all bugs are shallow')
-
This is a bit off-topic but what is the difference between USB8x and MSD8x anyway?
-
wait, I always thought that MSD8x was just a GUI for the msd driver in USB8x. I don't think it has a driver of its own because because it won't run without USB8x.
well here's the section of code after a proper initialization:#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 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
FramesLeft: ;not static
.dw numFrames
sName:
.db fileName
fileHandle is located 128 bytes into the statVars (how big is statVars anyway?)
NoFile and FileReadError just clean up and exit the program
-
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?
-
We are a bit more lax for regular posters and Omnimaga veterans, but you have 35 posts and have been here less than a month. Would 8 minutes have killed you? There is also a button called "modify" up there just begging to be pressed.
Either way, try not to do it again.
-
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.
-
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).
I have a newer 84+ without the extra pages and msd8x works fine for me, with the exception of the occasional garbled text.
-
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.
-
Yep, so we can mess around with Blue8x, like I've asked for several times :)
-
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?
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!)
-
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.
-
I would just reformat it as FAT
can't if its over 4gb because windows won't let you partition it
Quote from: quasi_Phthalo on Today at 08:08:06 PM
SirCmpwn: did 8 minutes kill you? well, let's get back on topic, shall we?
Excuse you?
i meant no disrespect. voice inflection is lost in typing: i was taking the matter lightly
-
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.
-
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.
-
"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 :P
-
Yep, so we can mess around with Blue8x, like I've asked for several times :)
Yeah, did a working demo of blue8x ever come out? It was intriguing.
-
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
-
I point to you, because msd8x can read and write large variables for myself and many others.
Programs have also been written (not publicly released) that stream video from a flash drive, which it seems like that's what you're doing. They read 512 bytes at a time, which is the size of one sector, and it means the driver doesn't have to span sectors to read a chunk of data.
You might want to post a little more of your code, specifically setting up usb8x itself and where all the equates are.
usb8x can be quirky from an assembly program (versus a Flash application)...perhaps there's some assumption the driver(s) are making that doesn't work in your situation.
-
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
-
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.
I'd love a rewrite to usb8x. I just got my adapter and am about to try it out on a newer 84+se. I'll let you know how it turns out. ;D
Quasi, good luck getting this to work! Oh, and don't worry about those 8 minutes. :)
-
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.
-
Why doesn't your code have $BB, $6D at the start? Nothing else jumps out at me at first glance.
i'm a purist: i don't want to mar my program with a TI token. i let my 8xp packer to do that for me.
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 third byte (editted). Also, the 'type' of garbage changes at every carry.
and i took you other advice to only read 512 at a time: same issue in the same place
editted
-
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).
-
you could change the seek pointer yourself
i've tried that (See one of my earlier code postings) and it works for the most part (sometimes a single frame will be half garbage)
except, since the file i'm using is large, the seek time gets longer and longer the farther you go, until it's eventually impractical to try to play a movie.
i've editted an earlier post. the garbage was actually happening when the seek pointer carried to the THIRD byte, not second
-
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 :)
-
ok, so i've made it so that it re-seeks on the reads that would carry the seek pointer to the third byte as a temporary work around. i hope this can be fixed eventually, because the seek delay every 33ish frames starts to get really annoying towards the end when it's the longest