« previous next »
Pages: [1]   Go Down

Author Topic: Multi Picture Storage  (Read 3403 times)

0 Members and 1 Guest are viewing this topic.

Offline systwo

  • LV2 Member (Next: 40)
  • **
  • Posts: 25
  • Rating: +7/-0
    • View Profile
Multi Picture Storage
« on: January 15, 2012, 02:10:36 pm »
Hello again everyone!

Going through Hot Dog's asm tutorial I have hit an obstacle. Storing or displaying pictures is freezing the calculator. This happens when I store 2 picture variables (it doesn't happen with 1). When you hit a key I expect the second picture to show, but it just freezes. The first one shows fine though. Here is the code:

Code: [Select]
#include "ti83plus.inc"
.org $9d93
.db t2ByteTok, tAsmCmp

B_CALL _ClrLCDFull
ld de, plotsscreen
ld hl, Picture
ld bc, 768
ldir

B_CALL _GrBufCpy
B_CALL _getKey
B_CALL _ClrLCDFull
ld hl, Happy
ldir
B_CALL _GrBufCpy
B_CALL _getKey
ret

.option BM_SHD = 2
.option bm_min_w = 96
Picture:
#include "img.bmp"

.option BM_SHD = 2
.option bm_min_w = 96
Happy:
#include "img2.bmp"
The pictures are correctly formatted. Both images are valid and can be displayed if only one picture is displayed or it is the first in the code. Unfortunately I cannot find the attachment button so I can't show you the pictures.

Thanks!


Logged

Offline chickendude

  • LV8 Addict (Next: 1000)
  • ********
  • Posts: 817
  • Rating: +90/-1
  • Pro-Riot Squad
    • View Profile
Re: Multi Picture Storage
« Reply #1 on: January 15, 2012, 02:17:58 pm »
ldir increments both hl AND de, so you'd need to reset de (ld de,plotsscreen or push de then pop de). :)

EDIT: ldir also decrements bc, so you'll need to reset bc as well.
« Last Edit: January 15, 2012, 02:42:06 pm by chickendude »
Logged

Offline Hot_Dog

  • CoT Emeritus
  • LV12 Extreme Poster (Next: 5000)
  • *
  • Posts: 3006
  • Rating: +445/-10
    • View Profile
Re: Multi Picture Storage
« Reply #2 on: January 15, 2012, 03:00:37 pm »
Yeah, I forgot to mention that in the lessons.

By the way, if BC = 0, 65536 bytes of data will be copied.  BC always equals zero after you copy a picture, because the calculator will copy a byte and decrease BC until BC = 0, meaning there are no more bytes that need to be copied.

The second time, since BC was 0, essentially what happened is you corrupted all your calculator's RAM  ;D
Logged

Offline chickendude

  • LV8 Addict (Next: 1000)
  • ********
  • Posts: 817
  • Rating: +90/-1
  • Pro-Riot Squad
    • View Profile
Re: Multi Picture Storage
« Reply #3 on: January 15, 2012, 07:16:37 pm »
Well, assuming that none of the B_CALLs affected their values ;) And to expand a little on what Hot_Dog said, decrementing a register when it equals 0 will "reset" the register to $FF (1-byte reg) or $FFFF (2-byte reg) (in two's complement, -1). So when you do ldir when bc = 0, it first decrements bc by 1, converting it to $FFFF (-1), and checks for 0. As it doesn't equal 0, it repeats that operation $FFFF times until bc=0 again.
Logged

Offline systwo

  • LV2 Member (Next: 40)
  • **
  • Posts: 25
  • Rating: +7/-0
    • View Profile
Re: Multi Picture Storage
« Reply #4 on: January 15, 2012, 08:22:12 pm »
Excellent! I had assumed that the registers would be unaffected.

Here is a copy of the working program for all future people who want it:
Code: [Select]
#include "ti83plus.inc"
.org $9d93
.db t2ByteTok, tAsmCmp

B_CALL _ClrLCDFull
ld de, plotsscreen
ld hl, Picture
ld bc, 768
ldir

B_CALL _GrBufCpy
B_CALL _getKey
B_CALL _ClrLCDFull
ld de, plotsscreen
ld hl, Happy
ld bc, 768
ldir
B_CALL _GrBufCpy
B_CALL _getKey

B_CALL _ClrLCDFull
ld de, plotsscreen
ld hl, splat
ld bc, 768
ldir
B_CALL _GrBufCpy
B_CALL _getKey
ret

.option BM_SHD = 2
.option bm_min_w = 96
Picture:
#include "img.bmp"

.option BM_SHD = 2
.option bm_min_w = 96
Happy:
#include "img2.bmp"

.option BM_SHD = 2
.option bm_min_w = 96
splat:
#include "img3.bmp"

Logged

Offline systwo

  • LV2 Member (Next: 40)
  • **
  • Posts: 25
  • Rating: +7/-0
    • View Profile
Re: Multi Picture Storage
« Reply #5 on: January 27, 2012, 02:55:15 am »
Sorry for double posting, but I have a question relating to this topic. If the RAM did get corrupted (like my first version of the program) on a real calc, what would happen, and is it recoverable? I would assume that things there are not critical (apart from personal unarchived programs...)
Logged

Offline chickendude

  • LV8 Addict (Next: 1000)
  • ********
  • Posts: 817
  • Rating: +90/-1
  • Pro-Riot Squad
    • View Profile
Re: Multi Picture Storage
« Reply #6 on: January 27, 2012, 03:27:09 pm »
Most likely you would just have a RAM clear and everything would be set back to normal. Depending on what parts of the RAM you overwrote, however, you may just have changed some variables. Have you ever played any games that left junk on the homescreen? They used TextShadow to store information during their program without resetting it to what it was before. Things like this are harmless, you'll have to be careful about overwriting more important parts of RAM, though. (Unless you WANT to clear that person's RAM ;))
Logged
Pages: [1]   Go Up
« previous next »