| Author |
Message |
|
fougere
Advanced Newbie
Joined: 07 Aug 2009
Posts: 56
|
 Posted: 08 Aug 2009 05:35:42 pm Post subject: |
|
|
Given the information WikiTI provides on page $1F for TI-83's, I assume that the code capable of waiting for a new OS is located here. (the code that is executed if you replace a battery while holding the 'delete' key) Does anyone know exactly what adress that particular section of code starts at so I can make a jump to it (instead of re-inserting a battery)?
Thanks |
|
| Back to top |
|
|
Graphmastur
Advanced Member
Joined: 25 Mar 2009
Posts: 360
|
| Posted: 08 Aug 2009 06:10:24 pm Post subject: |
|
|
| I don't think so. I believe, that it is not located on a page. I could be wrong, but when I asked brandon if I messed up the os, how could send the original, and he said that as long as the physical calculator works, then that should work. If you want to send an os this way, you should put in the readme what to do. |
|
| Back to top |
|
|
fougere
Advanced Newbie
Joined: 07 Aug 2009
Posts: 56
|
| Posted: 08 Aug 2009 06:20:53 pm Post subject: |
|
|
page $1F is the Boot Code page, and i thought that it could not be overwritten and that's where all the stuff similiar to a computer's bios goes. Correct me if I'm wrong, but whatever's on $1F when it comes from the TI factory is what will stay on it forever. If it's true that it cannot be overwritten, then Brandon is still right: As long as the physical calc works, you can still install an OS.
Last edited by Guest on 08 Aug 2009 06:22:23 pm; edited 1 time in total |
|
| Back to top |
|
|
FloppusMaximus
Advanced Member
Joined: 22 Aug 2008
Posts: 472
|
| Posted: 08 Aug 2009 08:02:57 pm Post subject: |
|
|
Page 1F/3F/7F cannot be changed. The calculator will reset if you try to write to it.
The routine that does the work of receiving and installing an OS is the BCALL 8072. That routine expects that the first packet has already been received (since, otherwise, why would you be calling it?) Refer to page 7F, as well as pages 7C and 76, if you want to know the correct way of using that routine; some memory areas need to be initialized beforehand. |
|
| Back to top |
|
|
fougere
Advanced Newbie
Joined: 07 Aug 2009
Posts: 56
|
| Posted: 09 Aug 2009 08:07:30 am Post subject: |
|
|
Quote: That routine expects that the first packet has already been received
But, when you press 'delete' while re-inserting a battery, the 'Waiting... Please install operating system now' screen pops up without the first packet having been received. |
|
| Back to top |
|
|
calc84maniac
Elite
Joined: 22 Jan 2007
Posts: 770
|
| Posted: 09 Aug 2009 01:07:17 pm Post subject: |
|
|
| Maybe that's when it's "waiting" for the packet - then it calls the routine. |
|
| Back to top |
|
|
fullmetalcoder
Member
Joined: 01 Aug 2009
Posts: 139
|
| Posted: 09 Aug 2009 02:51:49 pm Post subject: |
|
|
| Anyone knows where that routine RETURNS ? Now that we can sign 3rd party OSes and send them without any battery trick or similar black magic we (or at least I, with my recent experimentations on modifying CSX) are faced with another problem : first run of the OS once installed. It looks like it does boot but in a rather weird way : while data can be written to LCD, attempt to change the contrast fail. And this is not the only puzzling thing : key press are caught multiple times at that point. Removing a battery to force a reboot solves everything but it's not very user-friendly... |
|
| Back to top |
|
|
fougere
Advanced Newbie
Joined: 07 Aug 2009
Posts: 56
|
| Posted: 09 Aug 2009 07:58:05 pm Post subject: |
|
|
| in addtion to fullmetalcoder's comment, disconnecting the link cable from the USB port (on 84's) causes the calc to freeze unless the batteries have been removed at least once since installation. |
|
| Back to top |
|
|
brandonw
Advanced Member
Joined: 12 Jan 2007
Posts: 455
|
| Posted: 10 Aug 2009 01:45:05 am Post subject: |
|
|
I should also mention that the USB version of the ReceiveOS BCALL is 80F6h (84+/SE only, of course).
EDIT: There's another one I decided to call _AttemptUSBOSReceive for some reason:
Code:
_AttemptUSBOSReceive:
80E4h:
Inputs: NZ set if this is being called in response to a USB event (A needs to be contents of port 56h)
If Z set, it will wait for an event to occur.
Unplugging a mini-B cable here will throw a boot code error.
Example:
in a,(56h)
or a;if nothing's going on, Z will be set and it'll wait, otherwise it'll take action immediately
B_CALL AttemptUSBOSReceive
A little cryptic, I know, and untested, but that ought to work.
The boot code displays the "Waiting...Please install operating system now." text, waits for the first link packet, and then (more or less) jumps to _ReceiveOS. If you want to duplicate that, you have to do it yourself and then BCALL that routine (it does NOT return).
When the boot code successfully receives and validates an OS, it marks it as valid by writing 5Ah to 0056h, then clears memory and some other hardware, outputs zero to port 7, and jumps to 0053h (this is the entry point for an OS).
Disassemble the TI-OS to see what it does at this point, which is basically set up some more stuff and wait for an interrupt to be generated (meaning you press ON or the sending device tries to talk to it over I/O or USB), at which point it's "turned on", set up the system monitor, homescreen context, display the "RAM cleared" text, and jump to _Mon.
EDIT: and, of course, if you aren't handling the USB interrupts, it will freeze on cable insertion/removal/whatever.
EDIT2: and, don't call code directly on page 7Fh. That's not smart. Use BCALLs or do it yourself, unless you have no choice.
Last edited by Guest on 10 Aug 2009 01:52:00 am; edited 1 time in total |
|
| Back to top |
|
|
fullmetalcoder
Member
Joined: 01 Aug 2009
Posts: 139
|
| Posted: 10 Aug 2009 03:30:42 am Post subject: |
|
|
brandonw wrote: EDIT2: and, don't call code directly on page 7Fh. That's not smart. Use BCALLs or do it yourself, unless you have no choice.
But will the bcalls work when a 3rd-party OS is installed? I know the boot-code is still here and it is possible to rewrite the off-page call routine but if I remember well the page/address of the bcall are placed on an OS page and the addresses in ti83plus.inc (or similar) are just pointers to a field holding the page/address data in one of those pages... Do they survive OS installation? |
|
| Back to top |
|
|
fougere
Advanced Newbie
Joined: 07 Aug 2009
Posts: 56
|
| Posted: 10 Aug 2009 09:53:10 am Post subject: |
|
|
brandonw: am I correct in assuming that the 3 bytes at $80E4 on page $7F are the address and page of the actual AttempOSReceive routine? if so, then it points to $4145 on page $6F, so I should do this: (using mem map mode 0)
Code:
ld a,$6F
out (6),a
in a,($56)
or a
call $4145
right?
well, it doesn't work for some reason. the interrupts still work fine, but it never starts to wait for an OS, nor does it return (which it's not supposed to) |
|
| Back to top |
|
|
brandonw
Advanced Member
Joined: 12 Jan 2007
Posts: 455
|
| Posted: 10 Aug 2009 01:05:16 pm Post subject: |
|
|
fullmetalcoder wrote: brandonw wrote: EDIT2: and, don't call code directly on page 7Fh. That's not smart. Use BCALLs or do it yourself, unless you have no choice.
But will the bcalls work when a 3rd-party OS is installed? I know the boot-code is still here and it is possible to rewrite the off-page call routine but if I remember well the page/address of the bcall are placed on an OS page and the addresses in ti83plus.inc (or similar) are just pointers to a field holding the page/address data in one of those pages... Do they survive OS installation?
The boot code BCALLs are of course still there, but no, the actual BCALL routine which swaps in that page is gone, since it resides on page 0. So yes, you have to manually duplicate what the BCALL routine does, which is back up the current page, swap in the boot code page, get the page:address for the routine, call it, and swap the original page back.
FougereRapide wrote: brandonw: am I correct in assuming that the 3 bytes at $80E4 on page $7F are the address and page of the actual AttempOSReceive routine? if so, then it points to $4145 on page $6F, so I should do this: (using mem map mode 0) Code: ld a,$6F
out (6),a
in a,($56)
or a
call $4145
right?
well, it doesn't work for some reason. the interrupts still work fine, but it never starts to wait for an OS, nor does it return (which it's not supposed to)
Yes. I probably didn't document it correctly, but once you've executed that, insert a mini-B cable and see if your PC recognizes your calculator. If so, then it would be working. If not, I don't know, like I said, I probably didn't document it correctly. Disassemble it and see what it does.
Last edited by Guest on 10 Aug 2009 01:06:29 pm; edited 1 time in total |
|
| Back to top |
|
|
|
Z80 & 68k Assembly => z80 & ez80 Assembly
