grosged wrote:
I succeeded in changing lcdbuffer to $ff0000 area , and resolution 4bpp...
But it seems I can't write anthing : all I can see is a "sparking" purple screen (and no freeze, no reset)

What? The CE only has RAM addresses up to D657FF. Everything else is pretty much unmapped or just mmio, and probably shouldn't be touched. Here's some code that executes double buffering; you basically just call it multiple times and it handles everything for you: (Note that you have to set currentDrawingBuffer to $D40000) first, before you try anything Wink


Code:
;-------------------------------------------------------------------------------
lcdSize                 equ lcdWidth*lcdHeight
currentDrawingBuffer    equ mpLcdCursorImg+1024-3
;-------------------------------------------------------------------------------
_SwapDraw:
; Safely swap the vRam buffer pointers for double buffered output
; Arguments:
;  None
; Returns:
;  None
   ld   hl,mpLcdBase&$ff<<8|mpLcdRis
   ld   a,(hl)
   and   a,4
   jr   z,-_
   ld   l,mpLcdIcr&$ff
   ld   (hl),a
   ld   l,h
   ld   bc,(hl)
   and   b
   ld   de,vRam
   jr   nz,_
   ld   de,vRam+lcdSize
_:
   ld   (hl),de
   ld   l,currentDrawingBuffer&$ff
   ld   (hl),bc
   ret
I just was hoping to find usable , fastest access (read/write) areas Rolling Eyes

Yes , that's weird : concerning the area between $e4000 and $efffff or between $ff0000 and $ffffff, for any value I write there I always read value 0 in return. But when I choose an address from there as lcdbuffer, on screen I can see 0... and other values ! Surprised
Those are memory-mapped port areas, a la the memory map on WikiTI (and elsewhere):
http://wikiti.brandonw.net/index.php?title=84PCE:Wait_States
If you're not careful, you could end up changing ports that you don't mean to.
Yes, I was careful : I did not make attempts in memory-mapped port areas, only the "Unmapped port range" from $e4000 to $efffff and from $ff0000 to $ffffff Wink
I was documenting a few system calls today, and I came across a rather neat one that has no real value. (Well, maybe). Anyways, it appears that the OS has a way to save the entire ram state into flash, and then restore it on a call to _BootOS. This means, as one notable CVSoft puts it, "all of ram is saferam". Using a system call at 0002E0 (Haven't come up with a name for it), allows you to copy ram into the temp buffer. It is also extremly useful if you want to copy something to flash, such as a hook. Anyways, this allows us to write pretty much anything, as now we can use all of ram and easily restore it. However, the OS uses RAM too, so this pretty much means you can't use OS calls. Razz Anywho, here's some example code that saves and restores ram: (Which allows for about 415744 bytes of whatever you want to do). Smile


Code:
#include "ti84pce.inc"

.assume ADL=1
.db $EF,$7B
.org usermem

#macro relocate(new_location)
 #define old_location eval($)
 .org new_location
 #define g_location eval(new_location)
#endmacro

#macro endrelocate()
 #ifdef g_location
 .org $-g_location + old_location
 #undefine g_location
 #undefine old_location
 #endif
#endmacro

   ld   hl,_OSreturn-$D00000+$3C0000
   ld   (__restoreloc),hl
   ld   (__saveSP),sp
   ld   hl,$D00000
   ld   de,$3C0000
   ld   bc,$040000
   call   $0002E0
   di
   ld   hl,reloc
   ld   bc,relocend-reloc
   ld   de,$D00000
   ldir
   jp   _pgrmbegin

_OSreturn:
   di
   ld   hl,$3C0000
   ld   de,$D00000
   ld   bc,$040000
   ldir
__saveSP =$+1
   ld   sp,0
   ret

reloc:
__restoreloc:
   .dl 0
relocate($D00003)
_pgrmbegin:
   ld   sp,$D40000
   
; Super awesome program goes here
   
   ld   hl,(__restoreloc)
   jp   (hl)
endrelocate()
relocend:
MateoConLechuga wrote:
It is also extremly useful if you want to copy something to flash, such as a hook.

Does that Kerm and co. will have a safe reliable way to do hooks now? I remember him talking about how his current implementation wasn't very safe.
Ivoah wrote:
MateoConLechuga wrote:
It is also extremly useful if you want to copy something to flash, such as a hook.

Does that Kerm and co. will have a safe reliable way to do hooks now? I remember him talking about how his current implementation wasn't very safe.

Of course it is safe. Just as long as a garbage collect doesn't happen to make the hook address start with 0x83, but there is a higher probability of the earth falling out of orbit than that happening. I mean, TI technically has the same bug when executing non existent assembly programs, but you don't see them worrying about it Very Happy Also, no, this call erases entire sectors, so it is really only useful for safely saving things temporarily, such as a hook for testing.
grosged wrote:
I just was hoping to find usable , fastest access (read/write) areas Rolling Eyes

Yes , that's weird : concerning the area between $e4000 and $efffff or between $ff0000 and $ffffff, for any value I write there I always read value 0 in return. But when I choose an address from there as lcdbuffer, on screen I can see 0... and other values ! Surprised


Hold on... are you saying you can set the LCD to read from nonexistent memory, and then you have ALL of vBuf1/2 to play with and use as normal memory? This sounds extremely intriguing...
Hactar wrote:
Hold on... are you saying you can set the LCD to read from nonexistent memory, and then you have ALL of vBuf1/2 to play with and use as normal memory? This sounds extremely intriguing...

I believe this is exactly the case that grosged is making Smile In addition, you can use ram saving to pretty much have all of ram + all of vram to do whatever you want with Very Happy
MateoConLechuga wrote:
[I]t appears that the OS has a way to save the entire ram state into flash, and then restore it on a call to _BootOS.
That sounds like deep sleep mode; I think BrandonW described it as being exactly that. I think part of the power savings from deep sleep mode is turning off RAM.

Also, if you want ALL of RAM + VRAM, why bother pointing the LCD to garbage addresses? Why not just show garbage on the screen? Or why not just turn the LCD (or at least the backlight) off? Also, you can set 1 bpp mode. Then you can at least show a 9600-byte message that describes what you're doing.
A little bit ago I was sniffing through the hardware ports on the TI84+CE, and discovered a simple unlocking sequence used probably by developers for TI. Ports 0x38-0x40 control the mapping of RAM memory, while ports 0x41-0x43 control the "dev" mode. It appears that TI actually installed a 1MB ram chip, yet only decided to map 256KB of that for whatever reason. There may be more information available in this mode; but as of right now I am still exploring. The program below basically maps the externally available RAM in order to increase the storage amount. Adriweb was kind enough to test on the TI83PCE as well, and it is confirmed to work:

Download: Dev Mode

[Also added this support to CEmu]:


Haha, nice work. I'm glad we have a magical extra 768KB of RAM to work with on the TI-84 Plus CE calculators. Wink
haha! Very Happy
More seriously, I ventured into the $e00000 memory area (wait-states R/W = 1/1), and I finally found a few places where It is actually possible to write :

    $e0xx08 : value=0 ! DANGEROUS, AVOID value=1 ! (or it'll get your TI soooo sloooow) (Thx, Epharius;) )

    $e0xx09 : we can put here an 8bit value
    $e0xx0a : value from 0 to 15 (half-byte)
    $e0xx0b to $e0xx0f : 5 bytes we can modify

    $e0xx10 : value=0 ! AVOID value=1 (for security) !

    $e0xx11 : also here an 8bit
    $e0xx12 : again a half-byte
    $e0xx13 to $e0xx17 : 5 bytes we can modify

Interesting, isn't it ? Smile
I updated ti84pce.inc with a bunch of things. Enjoy Smile There's a whole lot more on the way too.
Yay, I've figured out a new call Wink
It is located at 021910h and I would call it like this:
_InsertBCBytesAfterCursor Very Happy
Hehe, it first shifts editTail BC bytes to left, and then copy BC bytes from the input HL to the new location of (editTail).

Inputs:
- BC = amount of bytes to insert
- HL points to data to insert

Outputs:
- Added BC bytes after the cursor in the editor
- The data pointed by HL to HL+BC is filled with 1's

Destroyed:
- HL=HL+BC
- BC=0
- DE=(editTail)



And a new more useful call located at 0218D4h:

Code:
ld a, $46
That's all.
I would call it _Load70InA
Great work PT_! Those are some nice finds, especially that second one :p Keep up the great work!

Also, there's actually a range of ports that cause a crash when you write to that location in memory. It could be very useful as a hardware breakpoint in z80 mode, if you are so inclined. The doc is over on Wikiti in the ports section Smile
MateoConLechuga wrote:
I was documenting a few system calls today, and I came across a rather neat one that has no real value. (Well, maybe). Anyways, it appears that the OS has a way to save the entire ram state into flash, and then restore it on a call to _BootOS. This means, as one notable CVSoft puts it, "all of ram is saferam". Using a system call at 0002E0 (Haven't come up with a name for it), allows you to copy ram into the temp buffer. It is also extremly useful if you want to copy something to flash, such as a hook. Anyways, this allows us to write pretty much anything, as now we can use all of ram and easily restore it. However, the OS uses RAM too, so this pretty much means you can't use OS calls. Razz Anywho, here's some example code that saves and restores ram: (Which allows for about 415744 bytes of whatever you want to do). Smile


Code:
#include "ti84pce.inc"

.assume ADL=1
.db $EF,$7B
.org usermem

#macro relocate(new_location)
 #define old_location eval($)
 .org new_location
 #define g_location eval(new_location)
#endmacro

#macro endrelocate()
 #ifdef g_location
 .org $-g_location + old_location
 #undefine g_location
 #undefine old_location
 #endif
#endmacro

   ld   hl,_OSreturn-$D00000+$3C0000
   ld   (__restoreloc),hl
   ld   (__saveSP),sp
   ld   hl,$D00000
   ld   de,$3C0000
   ld   bc,$040000
   call   $0002E0
   di
   ld   hl,reloc
   ld   bc,relocend-reloc
   ld   de,$D00000
   ldir
   jp   _pgrmbegin

_OSreturn:
   di
   ld   hl,$3C0000
   ld   de,$D00000
   ld   bc,$040000
   ldir
__saveSP =$+1
   ld   sp,0
   ret

reloc:
__restoreloc:
   .dl 0
relocate($D00003)
_pgrmbegin:
   ld   sp,$D40000
   
; Super awesome program goes here
   
   ld   hl,(__restoreloc)
   jp   (hl)
endrelocate()
relocend:

Does this mean we can have something akin to a hibernation function on the CE? As you said "and then restore it on a call to _BootOS", and i presume _BootOS is called on boot Razz
c4ooo wrote:
Does this mean we can have something akin to a hibernation function on the CE? As you said "and then restore it on a call to _BootOS", and i presume _BootOS is called on boot
Yes! Actually, it's one of the calculator's touted features from TI themselves: they promoted the fact that it puts itself into a "deep sleep" mode if not turned on for a week or so, useful for students' calculators that go unused (say) all summer. This way, they'll still have battery power to be used after the summer, if students forget to charge them before the first day of school.
KermMartian wrote:
c4ooo wrote:
Does this mean we can have something akin to a hibernation function on the CE? As you said "and then restore it on a call to _BootOS", and i presume _BootOS is called on boot
Yes! Actually, it's one of the calculator's touted features from TI themselves: they promoted the fact that it puts itself into a "deep sleep" mode if not turned on for a week or so, useful for students' calculators that go unused (say) all summer. This way, they'll still have battery power to be used after the summer, if students forget to charge them before the first day of school.

Thats cool! Is this copy of the whole RAM deleted when bootOS is called? Is there some flag to tell the OS weather to restore from the RAM save? I see some awesome potential if something akin to zStart's run on ram clears feature can be implemented without modifying the OS (?)
So while I was trying to understand a part of the OS, it seems to work with the (menuCurrent) values. When I went to the ti84pce.inc, I can't find the one I needed, so I started to check all these values. It seems that someone (@Mateo? Razz) was either drunk or copied it from the 83plus.inc, but all these values above 0Bh or so, are wrong. Here are the current, right values, almost complete:

Code:
; 01h
mApps                     equ 02h
mPrograms                  equ 03h
   mPrograms_Exec               equ 00h
   mPrograms_Edit               equ 01h
   mPrograms_New               equ 02h
mZoom                     equ 04h
   mZoom_Zoom                  equ 00h
   mZoom_Memory               equ 01h
mDraw                     equ 05h
   mDraw_Draw                  equ 00h
   mDraw_Pts                  equ 01h
   mDraw_Sto                  equ 02h
   mDraw_Bckgrnd               equ 03h
mStatPlots                  equ 06h
mStat                     equ 07h
   mStat_Edit                  equ 00h
   mStat_Calc                  equ 01h
   mStat_Tests                  equ 02h
mMath                     equ 08h
   mMath_Math                  equ 00h
   mMath_Num                  equ 01h
   mMath_Complex               equ 02h
   mMath_Prob                  equ 03h
   mMath_Frac                  equ 04h
mTest                     equ 09h
   mTest_Test                  equ 00h
   mTest_Logic                  equ 01h
; 0Ah
mVars                     equ 0Bh
   mVars_Vars                  equ 00h
   mVars_YVars                  equ 01h
   mVars_Color                  equ 02h
mMemory                     equ 0Ch
mMatrix                     equ 0Dh
   mMatrix_Names               equ 00h
   mMatrix_Math               equ 01h
   mMatrix_Edit               equ 02h
mDistr                     equ 0Eh
   mDistr_Distr               equ 00h
   mDistr_Draw                  equ 01h
mAngle                     equ 0Fh
mList                     equ 10h
   mList_Names                  equ 00h
   mList_Ops                  equ 01h
   mList_Math                  equ 02h
mCalculate                  equ 11h
mVarsWin                  equ 15h
   mVarsWin_XY                  equ 00h
   mVarsWin_TTh               equ 01h
   mVarsWin_UVW               equ 02h
mVarsZoom                  equ 16h
   mVarsZoom_ZXZY               equ 00h
   mVarsZoom_ZTZTh               equ 01h
   mVarsZoom_ZU               equ 02h
mVarsGDB                  equ 17h
mVarsPics                  equ 18h
   mVarsPicsPic               equ 00h
   mVarsPicsBckgrnd            equ 01h
mVarsStrings               equ 19h
mVarsStat                  equ 1Ah
   mVarsStat_XY               equ 00h
   mVarsStat_Sigma               equ 01h
   mVarsStat_EQ               equ 02h
   mVarsStat_Test               equ 03h
   mVarsStat_Pts               equ 04h
mVarsTable                  equ 1Bh
mVarsFunc                  equ 1Ch
mVarsParam                  equ 1Dh
mVarsPolar                  equ 1Eh
mVarsFnOnOff               equ 1Fh
mReset                     equ 20h
   mResetRAM                  equ 00h
   mResetArchive               equ 01h
   mResetAll                  equ 02h
mMemoryManagement            equ 21h
mResetDefaults               equ 22h
mFinance                  equ 23h
   mFinance_Calc               equ 00h
   mFinance_Vars               equ 01h
mResetRAMAll               equ 24h
mResetArchiveVars            equ 25h
mResetArchiveApps            equ 26h
mResetArchiveBoth            equ 27h
mResetMemoryAll               equ 28h
mGroup                     equ 29h
   mGroup_Group               equ 00h
   mGroup_Ungroup               equ 01h
mGroupEdit                  equ 2Ah
mProgramEdit               equ 2Bh
   mPrgmEdit_Ctrl               equ 00h
   mPrgmEdit_IO               equ 01h
   mPrgmEdit_Color               equ 02h
   mPrgmEdit_Exec               equ 03h
mProgramZoom               equ 2Ch
   mPrgmZoom_Zoom               equ 00h
   mPrgmZoom_Memory            equ 01h
mProgramDraw               equ 2Dh
   mPrgmDraw_Draw               equ 00h
   mPrgmDraw_Pts               equ 00h
   mPrgmDraw_Sto               equ 00h
   mPrgmDraw_Bck               equ 00h
mProgramStatPlots            equ 2Eh
   mPrgmSP_Plots               equ 00h
   mPrgmSP_Type               equ 01h
   mPrgmSP_Mark               equ 02h
mProgramStat               equ 2Fh
   mPrgmStat_Edit               equ 00h
   mPrgmStat_Calc               equ 01h
   mPrgmStat_Tests               equ 02h
mProgramMath               equ 30h
   mPrgmMath_Math               equ 00h
   mPrgmMath_Num               equ 01h
   mPrgmMath_Complex            equ 02h
   mPrgmMath_Prob               equ 03h
   mPrgmMath_Frac               equ 04h
mLink                     equ 31h
   mLink_Send                  equ 00h
   mLink_Receive               equ 01h
mTransmit                  equ 32h
mErrorXmit                  equ 37h
mErrorQuit                  equ 3Eh
mErrorQuitGoto               equ 3Fh
mCatalog                  equ 46h
  
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

» Go to Registration page
» Goto page Previous  1, 2, 3, 4, 5, 6, 7  Next
» View previous topic :: View next topic  
Page 6 of 7
» All times are UTC - 5 Hours
 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

 

Advertisement