This is an archived, read-only copy of the United-TI subforum , including posts and topic from May 2003 to April 2012. If you would like to discuss any of the topics in this forum, you can visit Cemetech's
z80 & ez80 Assembly subforum. Some of these topics may also be directly-linked to active Cemetech topics. If you are a Cemetech member with a linked United-TI account, you can link United-TI topics here with your current Cemetech topics.
Z80 & 68k Assembly =>
z80 & ez80 Assembly
| Author |
Message |
|
Iambian
Advanced Member
Joined: 13 Mar 2004
Posts: 423
|
 Posted: 31 Dec 2008 10:48:39 pm Post subject: |
|
|
Before I resort to attempting to email the author, I'm having trouble using the decompressing routine found in this ticalc entry : http://www.ticalc.org/archives/files/fileinfo/178/17865.html
I used this pic>>z80 application to create images using the "Spiffy" compression but I have not been able to restore the image to its original form. I've tested whether or not the program was culpable and found that the compressed images packaged with the ticalc entry did not work either. I have also tested as to whether or not the program needed SMC to run so I pasted it to $8000 and ran it there (since I'm trying to run this in an app). No luck, either (the code lacks jp, so I assumed it was safe). The demo is meant to run on a TI-82 with CrASH, so I haven't had the chance to test it out.
I am positive that I'm using the code according to the documentation, and now I'm wondering if the code I got off of ticalc is faulty, or if it's something I'm doing wrong. The code I'm using is as follows:
Code:
ld hl,TitleSplash
ld de,(scratchpad)
ld b,96
call decomp
ld hl,(scratchpad)
ld de,sgraybuf
ld bc,768
ldir
"TitleSplash" is the address to the compressed image. "scratchpad" is the external data file being used, since I'm out of saferam. "sgraybuf" is the screen-sized buffer that is to be used during the grayscale interrupt (which has already been verified to work correctly). "decomp" is the address to the decompression routine found in the package.
Can anyone eyeball this and see where I'm going wrong? Should a question like this be better off being asked to the author himself?
(Personally, I dislike email, so I *had* to post it before ever considering going that route)
EDIT(2): Shoot. Though the internet connection died on me, and instead, it did a double post. May someone please delete the other topic?
Last edited by Guest on 31 Dec 2008 10:53:36 pm; edited 1 time in total |
|
| Back to top |
|
|
DigiTan
Unregistered HyperCam 2
Super Elite (Last Title)
Joined: 10 Nov 2003
Posts: 4468
|
| Posted: 31 Dec 2008 11:50:08 pm Post subject: |
|
|
| Maybe this has already been checked, but are you 100% certain (scratchpad) is correctly pointing to your file. TI-82 VAT routines can be extremely dysfunctional. And I trust common_array has a good pointer too? |
|
| Back to top |
|
|
Iambian
Advanced Member
Joined: 13 Mar 2004
Posts: 423
|
| Posted: 31 Dec 2008 11:57:04 pm Post subject: |
|
|
| I have verified that (scratchpad) points correctly to the file in question, since the routine has also failed to work when I try to write out directly to the buffer as well. common_array also has a good pointer, but I'm unsure as to whether or not I actually need it to be initialized to some sort of values. I'm pretty sure that the readme would've stated something like that if the memory area needed initialization. |
|
| Back to top |
|
|
FloppusMaximus
Advanced Member
Joined: 22 Aug 2008
Posts: 472
|
| Posted: 03 Jan 2009 02:16:53 pm Post subject: |
|
|
That code doesn't modify itself, but it does modify the compressed data. So it won't work if you're using it to decompress data stored in your app (unless you copy the compressed data to RAM first, I guess.)
To use it in an app, you could change the IsBit subroutine to the following (untested):
Code:
IsBit:
SLA C
RET NZ
INC HL
LD C,(HL)
RL C
RET
Also, remove this part:
Code:
dc_finish:
RLC C
RET C
RLC (HL)
JR dc_finish
and replace it with a simple 'RET'. |
|
| Back to top |
|
|
Iambian
Advanced Member
Joined: 13 Mar 2004
Posts: 423
|
| Posted: 03 Jan 2009 11:43:30 pm Post subject: |
|
|
Thanks for the information.
Actually, I found out that bit about the routine modifying the data not less than ten minutes ago, and I supplied for myself a halfway decent workaround that does involve copying the compressed data to RAM.
I also tried out your edit just now, but the image only decompresses correctly about halfway before junk starts being output and the buffer overflows. I'll see if I can tweak the routine a bit more to make it work correctly. If not... I can always use the workaround I wrote above.
Oh, and I *do* understand the documentation not stating anything about where the image was, since the code was written for an 82, which does not contain any Flash to worry about...
Last edited by Guest on 03 Jan 2009 11:44:44 pm; edited 1 time in total |
|
| Back to top |
|
|
FloppusMaximus
Advanced Member
Joined: 22 Aug 2008
Posts: 472
|
| Posted: 04 Jan 2009 02:12:11 pm Post subject: |
|
|
Oops. You also have to change the 'POP BC' to a 'POP AF / LD B, A'.
My modified version above uses C to store the next few bits of the input, rather than using it as a simple counter as the original code does. |
|
| Back to top |
|
|
|
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.
»
Go to Registration page
