[TI Z80] bcall() - what exactly happens?

Got questions? Got answers? Go here for both.

Moderator: MaxCoderz Staff

Post Reply
chickendude
Extreme Poster
Posts: 340
Joined: Fri 07 Jul, 2006 2:39 pm

[TI Z80] bcall() - what exactly happens?

Post by chickendude »

Code: Select all

rst $28
.db $0A,$45	;$450A aka _puts

$28:
jp 2810

;hl = pointer to text label

$2810:
 push hl	;sp -2
 push hl	;-4
 push hl	;-6
 push af	;-8	save af
 push bc 	;-10	save bc
 push de	;-12	save de
 push hl	;-14	save hl
 ld hl,000f	;15
 add hl,sp
;stack starts at $FFFF and counts down, so this is like:
;sub sp,15

 ld d,(hl)	;hl points to the upper byte of (pc) address that was pushed onto the stack with our reset call
 dec hl		;move to lower byte
 ld e,(hl)	;
 inc de		;skip over the address of the bcall
 inc de		;de now points to the code just after bcall(_puts)
 ld (hl),e	;essentially change our return address to just after the bcall
 inc hl
 ld (hl),d

 in a,($06)
 ld c,a

 dec hl
 dec hl
 dec hl		;points LSB of first push hl
 ld (hl),a	;replace with value of in a,($06)
 dec hl
 ld (hl),$28
 dec hl
 ld (hl),$e7	;change 2nd push hl to 28e7 location

 dec de
 ld a,(de)
 ld h,a		;MSB of our bcall ($45)
 dec de
 ld a,(de)
 ld l,a		;LSB of our bcall ($0A)
;hl = pointer to bcall

 ld b,0		;bc = whatever in a,($06) means

 bit 7,h	;bit 7 is not on
 jr nz,$2846	;if it is on, reset it

 bit 6,h	;bit 7 is off, check if bit 6 is on/off
 jr z,$284c	:if it is off, do something. else reset it

$2840:
 res 6,h
 ld a,$1b	;27
 jr $2857

$2846:
 res 7,h
 ld a,$1f	;31
 jr $2857

$284c:
 in a,($06)
 and $1f	;make sure not >31 cause below has 32  bytes
 ld de,$8230	;ti83p.inc defines this as "baseAppBrTab"
 add a,e	;add the offset
 ld e,a
 ld a,(de)	;store value at offset to a
 ld b,a		;store into b
$2857:		;bit 7 or 6 was reset, or both are already reset
 out ($06),a	;output whatever those values mean
 ld de,$4000
 add hl,de	;why do we do this? we reset bit 6 then effectively add it right back
 ld e,l
 ld d,h		;load bcall location into de
 ld hl,$0008
 add hl,sp	;point to the stack position of 3rd push hl
 ld a,(de)	;load LSB from the location pointed to at bcall
 ld (hl),a	;store it in stack
 inc de
 inc hl
 ld a,(de)
 ld (hl),a	;load from the LUT and store where it points to into stack

 inc de		;again not sure what the purpose of this is
 ld a,b
 or a
 jr z,$2874
 ld a,(de)
 neg
 add a,b
 jr $2879
$2874:
 or a
 jr nz,$2879
 ld a,c
$2879:
 out ($06),a	;this seems to do something to the bcall lookup table?
 pop hl		;recall all our values (these should be unchanged by all the stack manipulation)
 pop de
 pop bc
 pop af
 ret		;jump to bcall
Sorry for posting the whole thing (i think!), i sorta commented the parts i understood. It just seems like there is a lot of redundant code and it was made unnecessarily complicated.

I was initially trying to find where the TI stores the sprites for the large font, but it turned out not to be as simple as i thought. But anyway, that is another subject altogether (that led me to many more questions!) and i think it would be clearer if i just made another topic on that.

But anyway, if it isn't too much trouble, could someone explain what exactly is going on here?
User avatar
Dwedit
Maxcoderz Staff
Posts: 579
Joined: Wed 15 Dec, 2004 6:06 am
Location: Chicago!
Contact:

Post by Dwedit »

If you want to find the font, use a graphics editor like Tile Layer Pro or YY-CHR.
Easy enough to find...
Image
(note: YY-CHR is almost always a false positive for antivirus software. Add it to an exclusion list.)

But yeah, Bcall has to check the type of call to see whether it is a relative page call or absolute call, and everything else. It also has to prevent relative bcalls from being called from RAM.
You know your hexadecimal output routine is broken when it displays the character 'G'.
Spencer
Extreme Poster
Posts: 346
Joined: Mon 17 Jan, 2005 8:56 am
Location: Indiana

Post by Spencer »

chickendude wrote:where the TI stores the sprites for the large font
It's different in every ROM version. There may be a way to locate it with a bcall.
User avatar
benryves
Maxcoderz Staff
Posts: 3087
Joined: Thu 16 Dec, 2004 10:06 pm
Location: Croydon, England
Contact:

Post by benryves »

Spencer wrote:
chickendude wrote:where the TI stores the sprites for the large font
It's different in every ROM version. There may be a way to locate it with a bcall.
The best I can think of is LoadPattern: "Loads the font pattern for a character to RAM. Also includes the characters width in pixels. This will work for both variable width and 5x7 fonts".
chickendude
Extreme Poster
Posts: 340
Joined: Fri 07 Jul, 2006 2:39 pm

Post by chickendude »

benryves wrote:
Spencer wrote:
chickendude wrote:where the TI stores the sprites for the large font
It's different in every ROM version. There may be a way to locate it with a bcall.
The best I can think of is LoadPattern: "Loads the font pattern for a character to RAM. Also includes the characters width in pixels. This will work for both variable width and 5x7 fonts".
I guess that kinda nulls my other topic. But thanks, i'll play around with it and see what i can come up with :)

And what is the difference between a relative/absolute call? Are bits 6/7 in some way related to/identifiers to check that?

Thanks for all the replies!
User avatar
Dwedit
Maxcoderz Staff
Posts: 579
Joined: Wed 15 Dec, 2004 6:06 am
Location: Chicago!
Contact:

Post by Dwedit »

When inside an app, you specify a BCALL like this:

mybcall = $ -$4000
.dw address_on_other_page
.db page_number_within_app

The address thrown into bcall will be between 0000 and 3FFF. Then it looks at the destination address and page number, switches banks, and jumps.
I'm calling it a "relative bcall" for some reason.
You know your hexadecimal output routine is broken when it displays the character 'G'.
Post Reply