Show Posts

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 - the_mad_joob

Pages: [1] 2 3 ... 23
1
TI Z80 / Re: Caboose: Automatically Append "Ans" to Applicable Entries
« on: January 15, 2021, 03:40:46 am »
Glad i could be of help.
And about flag 3,(iy+$49), it's luckily retro-compatible, so the code works on older systems aswell =]
Except of course if some user code modifies it, but i highly doubt anybody ever takes the risk to use the system flags area for storage.

EDIT :

In case you need it for another project, there is also 4,(iy+$49), that tells what is highlighted (0=entry | 1=answer).
Of course, you have to check 3,(iy+$49) first to see if something is actually highlighted, cause its state seems unstable if that's not the case.
Bits 6 seems to have a function aswell, but i didn't manage to accurately discover which.

2
TI Z80 / Re: Caboose: Automatically Append "Ans" to Applicable Entries
« on: January 14, 2021, 06:55:06 pm »
I believe i found how to solve everything, and i even discovered an undocumented mathprint flag on my way =]
This code simulates ans+enter in a very clean way.
By clean i mean exactly as if you did it manually, which means you don't have to deal with adding the entry internally at all.
In short, the homescreen hook replaces enter by ans, and right after that, a getcsc hook automatically simulates enter.
That also means you don't have to check if there is enough memory for ans, in which case only enter is processed.
Also, it appears you don't need to check if a menu is open at all.
Note that though the homescreen hook is permanent, the getcsc hook is temporary, and properly restores any older one if there was one.
Enjoy :
Code: [Select]
hook_home

.db $83

di
ld c,a
in a,($02)

rla
jr nc,hook_home_max_speed

ld a,$01
out ($20),a

hook_home_max_speed

dec c
jr nz,hook_home_exit

ld a,b

cp kenter
jr z,hook_home_enter

hook_home_exit

cp a

ret

hook_home_enter

bit 3,(iy+$49)
jr nz,hook_home_exit

;Here is where you check if you want to add Ans or not.
;If yes, jump to hook_home_ans_enter, otherwise return.

hook_home_ans_enter

ld de,appbackupscreen
ld hl,flags+hookflags2
ld a,(hl)
ld (de),a
or %00000001
ld (hl),a
ld bc,3
inc de
ld hl,getkeyhookptr
ldir
ld hl,hook_keyboard
ld (getkeyhookptr),hl
in a,($06)
ld (getkeyhookptr+2),a
ld b,kans
cp a

ret

hook_keyboard

.db $83

di
in a,($02)

rla
jr nc,hook_keyboard_max_speed

ld a,$01
out ($20),a

hook_keyboard_max_speed

ld de,flags+hookflags2
ld hl,appbackupscreen
ldi
ld bc,3
ld de,getkeyhookptr
ldir
ld a,kenter
cp a

ret

3
TI Z80 / Re: Caboose: Automatically Append "Ans" to Applicable Entries
« on: January 14, 2021, 03:29:54 am »
Is there any kind of "update homescreen" bcall that I can use to make sure it does get displayed?
I might have the code you need, but it's not just a bcall.
It was originally designed to fully restore home after returning from an asm prgm (no matter the split and mathprint settings).
I tested it as an updater from a homescreen hook just to see, and it seems a few adjustments are needed.
Will post the code later today as an edit of this post, so stay tuned.

EDIT :

Great news, i managed to adapt my code.
Note that it's designed to work for a homescreen hook with a=2, i haven't fully tested it with the other contexts.
Also, though it works as expected (everything properly displayed after a _clrlcdfull), it might not solve your problem, cause i believe it's not a display issue, more like the fact that the Ans you add should also be added to the list of mp home entries on RAM page 3.
Anyway, that will be a good way to tell if i'm right about that.
Code: [Select]
.db $83

di
ld c,a
in a,($02)

rla
jr nc,hook_max_speed

ld a,$01
out ($20),a

hook_max_speed

dec c

dec c
jr z,hook_evaluate

cp a

ret

hook_evaluate

bit 5,(iy+$44)
jr z,hook_core

ld a,$03
ld b,64
ld hl,$DA7E
out ($05),a

bcall(_savedisp)

di
xor a
out ($05),a

hook_core

;here goes the code that alters the homescreen entry

bit 5,(iy+$44)
jr nz,hook_update_mp

ld a,(currow)
push af

bcall(_rstrshadow)

di
pop af
ld (currow),a

ret

hook_update_mp

ld a,$03
ld b,64
ld hl,$DA7E
out ($05),a

bcall(_restoredisp)

di
xor a
out ($05),a

ret

4
TI Z80 / Re: Caboose: Automatically Append "Ans" to Applicable Entries
« on: January 08, 2021, 12:00:13 am »
You're welcome.

Switching to max CPU speed could be significant, at the very beginning of the app & hook codes.
Don't forget to backup af before that if needed, of course :
in a,(2)
rlca
and 1
out (32),a

Disabling interrupts is also a thing, and i would even recommend it after each bcall aswell.

Cheers.

5
TI Z80 / Re: Caboose: Automatically Append "Ans" to Applicable Entries
« on: January 04, 2021, 08:48:32 pm »
Useful indeed =]
I might have a fix for you, tVarStrng ($AA) appears to be missing from the list of word tokens.
Cheers.

6
News / Re: Happy Holidays Omnimaga
« on: December 28, 2020, 09:57:31 pm »
Good luck for 2021, folks.
Kisses from the milky way.

7
ASM / Re: [8X+] universal snacks
« on: December 27, 2020, 04:53:09 pm »
CHANGED

LCD :
Inversion routines were removed (obsolete).
All others were updated to support most recent hardware (bit 7 of port $10 no longer polled).

specific :
battchecka : a bit closer to TI's original code
cleanexit : removed (obsolete)
cpirnc : now interrupt-friendly (af' no longer used)
cpirznc : now interrupt-friendly (af' no longer used)
keybscan : faster detection, also now foolproof and key repeat friendly
poweroff : not IM2-exclusive anymore

A few files|routines were renamed.
Continued to improve documentation here & there.

NEW

keybcheck
keybdebounce
prgmedita
prgmeditb

HAPPY 2021 IN ADVANCE =]

#####

CHANGED

No more subfolders.
font_large_custom.png (font.png before) : a few sprites improved
font_large_custom.txt (font.txt before) : a few sprites improved
lcddispchr : slightly faster at 6MHz
lcddispstr : slightly faster at 6MHz
prgmedita : now mathprint-compatible and with additional securities
prgmeditb : now mathprint-compatible and with additional securities

NEW

ti83plus.inc : ultimate TI-83+|TI-83+SE|TI-84+|TI-84+SE include file
font_large_system.png : large character system font preview
1_character_tokens.txt : token>character reference table for all valid 1 character long tokens
font_large_system.txt : information about large character system font

#####

CHANGED

ti83plus.inc : new information about 3 undocumented system flags (iy+49h)
prgmedita : slightly faster
prgmeditb : slightly faster

NEW

system_ram_structure.txt : system ram structure summary

8
ASM / Re: investigating port $2F
« on: December 22, 2020, 08:18:08 am »
Alright, it seems what i believed to be LCD crashes actually aren't.
In short, it appears that in some specific contexts, writing to port $2F can cause bit 1 of port $02 to become permanently reset.
The nasty consequence is that all codes that poll that bit before interacting with the LCD (basically all OS display routines) enter an endless loop.

Here is a program that shows what i'm talking about.
It supposedly displays the state of port $02 bit 1, and waits for any keypress before exiting :
Code: [Select]
.nolist
.org $9D93
#include "ti83plus.inc"
.list

;#################################### DATA #####################################

.db t2bytetok,tasmcmp

;#####

di
in a,($02)

rla
ret nc ; TI-83+

in a,($21)

and %00000010
ret nz ; TI-84+CSE

in a,($2A)
or %00000011

cp $27
ret nz ; port $2A unusual

in a,($2E)
or %00000001

cp $45
ret nz ; port $2E unusual

ld a,(currow)
ld (textshadcur),a
res apptextsave,(iy+appflags)

call keybclear

bcall(_clrlcdfull)

di
ld hl,$0000
ld (currow),hl

;Everything before this isn't exactly relevant.

in a,($2F)

ld c,a
and %11111100

out ($2F),a

ld a,$01
ld b,0
djnz $

out ($20),a

;16+ CC required here to avoid _putmap to enter endless loop

in a,($02)

rra
and %00000001
add a,'0'
ld b,a
ld a,c

out ($2F),a

ld a,b

bcall(_putmap)

;Everything after this isn't exactly relevant.

di
xor a
ld b,%00001000
out ($01),a

wait_key_pressed

in a,($01)

inc a
jr nz,key_pressed

in a,($04)

and b
jp nz,wait_key_pressed

key_pressed

xor a
ld (kbdscancode),a
res oninterrupt,(iy+onflags)
set apptextsave,(iy+appflags)

call keybclear_wait_keys_released

bit 5,(iy+$44)
jr nz,restore_mathprint

ld a,(flags+sgrflags)

rra
jp nc,restore_textshadow

bcall(_grbufcpy)

di

restore_textshadow

bcall(_rstrshadow)

di

ret

restore_mathprint

ld a,$03
ld b,64
ld hl,$DA7E
out ($05),a

bcall(_restoredisp)

di
xor a
out ($05),a

ret

;keybclear

;DESCRIPTION
;Waits until the keyboard is clear from any press.
;Includes a debouncing delay.

;IN
;interrupts : disabled

;OUT
;keyboard : all groups monitored
;a = ?
;f = %???????0
;bc = $0000
;stack : 2 bytes (call included)

keybclear

xor a
ld b,%00001000
out ($01),a

keybclear_wait_keys_released

in a,($01)

inc a
jp nz,keybclear_wait_keys_released

keybclear_wait_on_released

in a,($04)

and b
jp z,keybclear_wait_on_released

in a,($02)
ld bc,96

rla
jr nc,keybclear_wait_bouncing

in a,($20)

or a
jr z,keybclear_wait_bouncing

ld c,240

keybclear_wait_bouncing

djnz keybclear_wait_bouncing

dec c
jp nz,keybclear_wait_bouncing

ret

;###############################################################################

.end
This code causes _putmap to enter an endless loop, but as soon as you add at least 16 CC (don't ask me why) between OUT ($20),A & IN A,($02), it works fine.
I believe what specifically causes the bit to become static is the too close proximity between OUT ($20),A & OUT ($2F),A, but i'm not entirely sure yet.

EDIT :

After having inspected multiple code contexts, i believe i finally managed to isolate most of it.
See my first post for details.

9
ASM / Re: looking for a code exorcist
« on: December 19, 2020, 09:39:32 am »
My .org directive was wrong, because i commented the prgm header, so that i could hexedit on PC and type on calc.
So, basically, the JP instruction was leaping on the second byte of the LD instruction, which explains everything.
So my calc isn't broken after all, and my assumption that TI-83+ hardware requires a few cycles between OUT & IN was wrong.
Error 40, case closed.

10
ASM / Re: looking for a code exorcist
« on: December 19, 2020, 08:16:01 am »
Sweet baby carrots :0
Maybe the actual circuits bare degraded causing bits to linger on the bus or something? Other idea: it looks like the code might be missing the 01 in the "ld bc,**" instruction (01xxxx) because he LSB comes first.
Code: [Select]
$0000  1 nop \ nop
$0001  0 ld bc,xx00h (DB00 in your case)
$0002  1 ld a,(bc) \ nop
$0010  1 djnz $+0
$0011  0 ld de,xx00h
$0012  1 ld (de),a \ nop
$00F0  1 ret p \ nop
$00F1  WTF pop af \ nope (oof!)
$00F2  0 jp p,xx00
$00FF  0 rst 38h \ nop
Once the program is on your calc, if you could hex-dump it, then we could check if maybe it is missing the 01.
Thanks for your time.
I already hex-checked the program data using calcsys, since i couldn't believe what i witnessed, so it's not that.
I was actually suspecting the LD BC,X instruction was processed as multiple ones myself, and i was just finding that POP AF thing right before your post XD.
About the degraded circuits theory, that could be a lead, though i believe i would have noticed some significant bugs|crashes elsewhere.
However, now that i think of it, it could be that the problem is specific to the RAM area where the LD BC,X is located.

EDIT : It's a TI-83+VS from 1999, the only noticeable thing being a slightly damaged LCD.

11
ASM / looking for a code exorcist
« on: December 18, 2020, 10:26:02 pm »
Welcome.

While i was randomly testing stuff on a TI-83+ (real hardware), i came across a pretty unexpected behaviour.
I isolated what's relevant in a tiny program :
Code: [Select]
.db $BB,$6D
di
xor a
out (1),a
ld bc,0
wait_key_released
in a,(1)
inc a
jp nz,wait_key_released
ret
That code does what it's supposed to do successfully.
When you press ENTER to start the program, it freezes until you release the key.
Then, when the key is released, you're back to the homescreen.

Now let's say you decide to use LD BC,1 instead.
In that case, you should expect the exact same behaviour, right ?
Well, in reality, the program exits right away, despite the key is still being pressed.
That basically means the loop is exited at some point (i suspect it's exited right away).
The very big problem i have with that, is that the LD BC,X instruction isn't supposed to have any influence on the condition check at all.
Any idea what's happening ?

EDIT 1 :

I suspected it had something to do with the proximity of the OUT & IN instructions, and i believe i was right.
Indeed, if the LD instruction is removed, the keypress is ignored aswell, probably because the TI-83+ keyboard is so slow that opening groups takes some time.
With a single NOP instruction, keypress ignored aswell.
However, 2 NOP instructions are enough.
But that doesn't solve the mystery yet, because that would mean that somehow, 2 NOPs (8 CC) take more time to process than 1 LD BC,X (10 CC).
And that still doesn't explain why the processing time of LD BC,X can vary depending on X.
Is my z80 drunk ?

EDIT 2 :

I officially entered the twilight zone.
I started to test the LD BC,X arguments, in hope of finding a pattern.
I didn't, but instead, i found out that it's even worse than i thought :
Code: [Select]
0 = keypress not detected
1 = keypress detected
WTF = RAM clear when key released

LD BC,X RESULT
$0000 1
$0001 0
$0002 1
$0010 1
$0011 0
$0012 1
$00F0 1
$00F1 WTF
$00F2 0
$00FF 0

12
ASM / Re: WikiTI
« on: December 09, 2020, 06:14:37 pm »
Well I made some of those fixes from above. You should get yourself an account :D .
Thanks for your time, and for the community.
My name wasn't necessary in the credits at all, but i understand, i would have done the same.
I have some more discoveries in my backpack, so yeah, i'll try to make an account next time.

13
ASM / Re: WikiTI
« on: December 08, 2020, 08:21:22 pm »
Oh, thanks for confirming that. I know the code to set 15MHz mode does take some advantage of that, because it essentially writes a 0 to port 20h (mirror of the link port) on those calcs which is generally safe, but writes a non-zero value on the other calcs.
I actually just re-tested that method aswell.
While it's safe on the 83+BE if there's no link activity, i wouldn't recommend using it on other models, see my note on port $20 on my synthesis post.

14
ASM / Re: WikiTI
« on: December 08, 2020, 07:36:38 pm »
As for the mirrored port writing being ignored, that's actually really handy to know.
I found back my old 83+ from 1999, so i was finally able to test that.
So, i can confirm that writes to mirrored ports are definitely NOT ignored, updated my previous post.
At least, writing to port $20 had the exact same effect as actually writing to port $00.
Cheers.

15
TI Z80 / Re: E37 made another small font editor
« on: November 02, 2020, 01:55:27 pm »
Hello there.
If you don't intend to use extra RAM pages, i guess the easiest way is to use _editprog first, so that the program data automatically take all the available free RAM, and then _closeprog once you're done.
Those 2 ROM calls aren't on the wiki though, but you can find them in the official documentation (83psysroutines.pdf).

Pages: [1] 2 3 ... 23