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
16
« 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. .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
17
« 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.
18
« 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.
19
« on: December 28, 2020, 09:57:31 pm »
Good luck for 2021, folks.
Kisses from the milky way.
20
« 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
21
« 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 :
.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
;###############################################################################
.endThis 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.
22
« 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.
23
« 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.
$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  . 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.
24
« 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 :
.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
retThat 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 :
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
25
« on: December 09, 2020, 06:14:37 pm »
Well I made some of those fixes from above. You should get yourself an account  . 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.
26
« 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.
27
« 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.
28
« 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).
29
« on: October 29, 2020, 11:32:44 pm »
Pretty cool, good job !
30
« on: October 04, 2020, 07:23:02 am »
Holy moly...
Looks like i figured out most of the inconsistencies.
It appears some of the opcodes i used in my test programs take longer to process than i thought.
More specifically, EX (SP),HL actually lasts 20 cycles instead of 19, and PUSH AF lasts 12 instead of 11.
The culprit is port $2E, which by default adds 1 cycle to every write in memory.
With that in mind, i'm gonna write a new delay tester, hoping not to find more surprises.
EDIT :
Post#1 updated with the new delay values, which are way more consistent.
I also added a few more details on the inconsistencies i discovered, code examples soon to come.
|
Show Posts