This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Messages - quasi_Phthalo
Pages: 1 2 3 [4] 5 6 ... 8
46
« on: June 27, 2010, 01:16:44 pm »
hmmm, try putting it in the same directory as the program
47
« on: June 27, 2010, 12:10:23 am »
here it is
it probably has something to do with me being on 64-bit windows 7 and using visual studio 2010
if all else fails, you could build the source yourself
48
« on: June 26, 2010, 11:20:25 pm »
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
49
« on: June 26, 2010, 08:38:58 pm »
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
50
« on: June 26, 2010, 08:12:39 pm »
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
51
« on: June 26, 2010, 08:08:06 pm »
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!)
52
« on: June 26, 2010, 07:26:13 pm »
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?
53
« on: June 26, 2010, 03:28:28 pm »
hooray for bruteforcing probability problems hahahaha! i did that once. on homework, not a test, but still. nothing like a true statistical sample 310. you replaced the built-in pseudo-random number generator with an ACTUALLY random number generator 311. you killed someone when they found out what your algorithm was
54
« on: June 26, 2010, 03:16:33 pm »
well, if anyone still wants a command line program to convert decimal floating points to hex floating points, here you go. hand written by yours truly. max precision is 8 bytes after the decimal point. let me know if there's any bugs.
edit: it will crash if the input number is too long
it does not support negative numbers!:
it's up to the implementer of the floating point routines whether negatives should be one's complement of the positives, or should the msb just be flipped?
i.e.: since 32.25d = 20.40h, should -32.25d = A0.40h or DF.C0h ?
55
« on: June 26, 2010, 02:28:20 pm »
that's true. you would need to know how to convert if you writing a game, so that you can put it in the source code. There are two options: have someone write routines to convert all necessary numbers first thing during the game's initialization so that they can still be in decimal in the source code, or someone could whip up a quick command line program to do it for you when your writing the game
56
« on: June 26, 2010, 02:02:15 pm »
think of binary fractional numbers this way:
0.10000000b = half
0.01000000b = fourth
0.11000000b = three fourths
0.00100000b = eight
etc.
then you can translate it into hex, taking them in 8-bit chunks:
00.01h = 1/256
00.10h = 16/256 = 1/16
00.FFh = 255/256
C9.A9EB07h = 201 + 169/256 + 235/65536 + 7/16777216 = 201.663742482662200927734375
Edit:
it's interesting how numbers like one third are:
0.333333333... in base 10
0.555555555... in base 16
Edit2: fixed something misleading
57
« on: June 26, 2010, 01:43:40 pm »
I think a binary floating-point method would be more efficient than decimal. agreed. It's actually kind of silly that TI stores it's floats as decimal. It wastes a lot of memory having lots of bytes that will never use A-F. The only reason for it was to may the number displaying routines faster and easier to code. Who needs that?
58
« on: June 26, 2010, 01:35:16 pm »
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
59
« 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
60
« on: June 25, 2010, 06:38:32 pm »
very large numbers? if you have a complex number c = a + bi, as soon as sqrt(a^2 + b^2) > 2, you know its unbounded. it's a very nice property about the mandelbrot set that makes computing a lot faster. if the magnitude of the complex number has not exceeded 2 after your max_iters, then you assume it's a part of the set.
Edit: as for decimals, the author of Axe would just have to add support to tap into TI-OS's built in FP b_calls and store 9-byte vars
Pages: 1 2 3 [4] 5 6 ... 8
|
Show Posts
