5

Every time I assemble an application for the TI-83+ calculator (Z80 processor), it stops running at CALL. Here is an example ("Hello") — it starts running just fine, but the calculator freezes at the CALL instruction. Anything I put before CALL works just fine, and anything I put after doesn't run. This is a disassembly of the code, to show addresses rather than labels. I have "touched it up" to show DB lines where those fall in, to make it easier to read.

I have never had this problem writing assembly "programs" (which are loaded into RAM). The only problems that I know of with running "applications" (which are kept in Flash ROM) are that they cannot be self-modifying, and that because paging is necessary, accessing data on a separate page is not possible. This is not self-modifying and only has one page... What have I done wrong?

0080 218900        LD   HL, 0089h
0083 cd9900        CALL 0099h        ;                      --- App stops here
0086 c38f00        JP   008fh
0089 48656c6c6f00  DB   "Hello", 0
008f fd360500      LD   (IY+05h), 0
0093 ef            RST  28h          ; B_CALL (
0094 364c          DB   4C36h        ;   _ReloadAppEntryVecs)
0096 ef            RST  28h          ; B_CALL (
0097 2740          DB   4027h        ;   _JForceCmdNoChar)  --- App should end here
0099 7e            LD   A, (HL)      ;                      --- Call goes to here
009a ef            RST  28h          ; B_CALL (
009b 0445          DB   4504h        ;   _PutC)
009d fe00          CP   0
009f c8            RET  Z
00a0 23            INC  HL
00a1 18f6          JR   0099h
hippietrail
  • 15,848
  • 18
  • 99
  • 158
c4757p
  • 1,728
  • 4
  • 18
  • 25
  • Does the putc call guarantee that it will preserve the contents of register A? Big trouble if not. To find out if that's the problem, surround the putc call with a push and a pop to preserve A. – Wayne Conrad Jan 27 '10 at 21:36
  • Pretty sure applications start at 4080h. – Nietzche-jou Jan 27 '10 at 21:39
  • Yes, putc preserves the accumulator. – c4757p Jan 27 '10 at 21:42
  • I don't think applications start at 4080h — like I said, anything I put before CALL works (and not everything before 0083h, everything before wherever I put CALL). If applications started at 4080h, it would skip right over it. 0080h is right after the header, which is where all the obscure documentation hints that it should start. – c4757p Jan 27 '10 at 21:44
  • Yes. Anyway, the code never gets to the PutC call. – c4757p Jan 27 '10 at 21:45
  • I assume the stack pointer is set to something reasonable? – Richard Pennington Jan 27 '10 at 21:47
  • Interesting question. Excuse me for asking some obvious questions, although I know Z80 asm, I don't know anything about your calculator. So, 1) How do you know the app stops at the call? 2) Assuming the answer to [1] is single stepping with a debugger of some kind, are you sure single stepping works in "applications"?. I say this because single stepping usually works by inserting a RST after the instruction, not possible in flash rom. 3) Are you sure you've set the stack pointer to the end of some valid RAM? (the call pushes ret address 0x0086, onto this stack). Later I may ask about RST 28h. – Bill Forster Jan 27 '10 at 21:47
  • I will however try pushing and popping both AF and HL just in case. Just about every other system call they have destroys a crapton of registers, so I find it hard to believe the "Registers destroyed: None" in the documentation. – c4757p Jan 27 '10 at 21:48
  • Applications definitely live in the 4000-7FFF range. Anything you put before CALL works likely because none of it is sensitive to addresses. – Nietzche-jou Jan 27 '10 at 21:48
  • @Bill: 1/2) Yes, single stepping with a debugger. I have tested, and yes, single stepping does work with applications. My guess is that it is integrated into the processor emulator, which runs just one instruction at a time. 3) I know this is messy (I should definitely set the stack pointer in 'real' code), but the stack pointer always starts out in a good place. I've tested this, and it's always where it belongs in the beginning. 3+(4)) RST 28h | DB xxxxh is the official way, according to TI, to do a system call. – c4757p Jan 27 '10 at 21:51
  • @sgm: OK, I'll try that. Maybe I'm just being dumb. I haven't been able to find any good documentation though. – c4757p Jan 27 '10 at 21:52
  • 2
    I find it extremely scary that I remember some of the opcodes (cd, c3, 23 to name a few). – Richard Pennington Jan 27 '10 at 21:53
  • I'm going to move my thoughts into an answer. It also contains a link to a tutorial! – Nietzche-jou Jan 27 '10 at 21:54
  • @Richard, the z80 was my first foray into "real" coding as a teenager, I have fond memories of the mnemonics, especially the incredibly powerful DJNZ one, but CD and 00 are the only opcodes I remember so I'm scared of you too :-) – paxdiablo Jan 27 '10 at 22:00
  • @paxdiablo: Ah! The famous 00. Of course! I think I remember them because I first learned to program by reading the blue 8080 data book and coded by typing programs in in hex. – Richard Pennington Jan 27 '10 at 22:02
  • @Richard Pennington. Me too! My first project involved hand assembling a few hundred lines of 8080 code, then entering the hex codes onto an Intel dev board with a 20 key pad and a single line of 7 segment LED digits. At the time I couldn't conceive of programming any other way. – Bill Forster Jan 27 '10 at 22:18
  • @Richard Pennington: Just stumbled across this thread and I can't resist to make a necro comment. Yes, I remember the opcodes too. Exactly my thoughts. You are not alone. Yes, CD and 23. And its about 25 years since I hacked those into my ZX Spectrum, because it didn't have an assembler. Really scary ^^ – Gunther Piez Apr 22 '11 at 23:14

2 Answers2

9

Apparently, you are assembling to address 0080h. This can't be correct because the address range 0000h--3FFFh is locked to ROM page 0. Indeed, according to this example, you assemble to 4000h. So your problem is that your CALL is jumping into the firmware, not a part of your application.

Nietzche-jou
  • 14,415
  • 4
  • 34
  • 45
  • 2
    Yeah, that was a dumb moment. I threw in 'ORG 4000h' and now it works. I've got another problem now though... Nothing I 'PutC' is going to the screen — probably a moronic mistake. Jeez — the first freaking language I ever programmed in was 8080 assembler, and now it's been so long my assembly code looks like it was written by a chimpanzee. – c4757p Jan 27 '10 at 22:02
  • Ok. Problem solved. Yep, the PutC problem as a moronic mistake as well. Thank you. – c4757p Jan 27 '10 at 22:07
2

Here's a memory map I found for the Ti-83+. You can't be loading this program at address $0080, that's where ROM lives. It gets loaded elsewhere. That works for a while until you make a JP or CALL. The CALL $0099 doesn't jump to your expected jump address, it jumps into ROM. That's a quick end.

You need to choose a proper ORG directive in your .asm so it gets loaded into RAM at the expected address. Wherever that might be.

Hans Passant
  • 922,412
  • 146
  • 1,693
  • 2,536