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 - SimonLothar
16
« on: August 26, 2012, 07:20:12 am »
But is it possible to have the DMA run while the program continues? The program may have to use double-buffering in that case, but it sounds possible.
In fact syscall 0x0260 runs a simple wait-for-DMA-ready-loop while the DMA takes place, only checking DMA0_CHCR_0.TE (Transfer End Flag) and DMA0_DMAOR.AE (Address Error Flag). During this wait-loop, you could possibly do anything, which does not disturb the running DMA-job. But that would mean to replace Bdisp_PutDisp_DD by some assembler function. Bdisp_PutDisp_DD itself does not offer any hook.
17
« on: August 25, 2012, 12:53:14 pm »
Simon,, here's a question for you that I don't understand. Why is it that there is no noticeable GPS change when you use Bdisp_PutDisp_DD vs Bdisp_PutStrip_DD(1,2)? That makes me think that the delay is not in the actual copying of data. Any thoughts?
I measured the following times when using syscall 0x0260 args time in microseconds 0,0 179 0,43 5734 0,86 11281 0,129 16835 0,172 22390 0,215 28593 syscall 0x025F() is identical to syscall 0x0260(0,215). t. i. calling 0x025F() consumes about 100 times more time compared to calling 0x0260(1,2). Most of the time syscall 0x0260 waits for the DMA-hardware, t. i. the speed-controlling part is the DMA-hardware.
18
« on: August 18, 2012, 11:12:20 am »
Sorry, that I did not answer earlier. (Some reasons: holiday, fair weather a. s. o..)
It seems to be not too simple to write to the Prizm's LCD-driver-interface 0xB4000000.
First the LCD-driver-register has to be selected.
If the OS issues a LCD-driver-register-select (syscall 0x01a2), it first clears bit 4 of MPU-port 0xA405013C (it looks as if this bit controls the LCD-driver's RS-bit; refer to the R61509-manual).
Then the SH-4A instruction SYNCO is performed.
Then the register number is written to 0xB4000000
Then the SH-4A instruction SYNCO is performed.
Then bit 4 of port 0xA405013C is set again.
Then the SH-4A instruction SYNCO is performed.
After a LCD-driver-register has been selected, it can be written to (by writing to 0xB4000000 again)
Every time register 0xB4000000 as well as port 0xA405013C are written to, the SH-4A-specific instruction SYNCO is performed immediately.
It is doubtful that directly writing to the LCD-driver enhances display-performance.
I observed, that writing to VRAM and moving the RAM to the LCD by DMA (syscall 0x025F/syscall 0x0260) is significantly faster than direct LCD-driver access.
19
« on: July 31, 2012, 01:44:06 am »
Helder7 asked me to update NOTEVIEW.G3A
Helder7 provided new, far nicer icons (thx) and asked for support of country-specific-characters.
As for the country-specific-characters, I added a little converting tool (HexDump.exe), which can be used to individually adapt textfiles to country-specific needs before transferring them to the fx-CG.
Version 1.01 removed (it had a bug)
Version 1.02 can be found here
http://www.casio-scene.com/downloads.php?do=file&id=103 (broken)
Due to the broken link in the post above I added version 1.03 here. It includes the fx-9860-version (NOTEVIEW.G1A), too.
21
« on: May 09, 2012, 09:46:20 am »
Could you post your computer's environment-variables?
22
« on: May 08, 2012, 10:00:30 am »
Does the install path of the sdk contain the "(x86)" string?
23
« on: May 01, 2012, 05:03:16 am »
...I'm confused as to why a cg20 image viewer for the cg10 would be any more risky than a PNG/BMP viewer... You are right, of course. Based on careful calculations, the probability of abusing some unlimited standard-imagetype-viewer for the Prizm is even higher compared to an unlimited G3P-viewer. Hence, if someone is troubled over an unlimited G3P-viewer, it immediately follows, that he should be troubled over any unlimited image-viewer for the Prizm at least as much.
24
« on: April 30, 2012, 11:18:25 am »
Like the FXes Model detection syscall, the emulator yields 0x00...
Could be this a good start?
If someone could get me a confirmation, I'll expad my model detection routine
Detecting the model and detecting the emulator are two totally different approaches. It is the job of the emulator to pretend being a certain model, t. i. obviously a fxCG20, hence you cannot detect the emulator by querying the model (provided the emulator is designed by a pro). On a fxCG20 0x1196 returns 0 (A0000305 not being 5A) and on a fxCG10 it returns 1 (A0000305 being 5A). There seem to exist (or will exist someday) two other CG-models (A5 and 55; according to A0000305). At least the OS and rumors point to this. I recommend to try the eight bytes at A001FFD0 to detect the Prizm emulator. Please report, which calculator ID the Prizm emulator happens to has.
25
« on: April 29, 2012, 10:26:40 am »
@Simon : on the emulator, syscall 0x1196 returns 0x00, but if I read directly the byte at 0xA0000305 I get 0xAA.
I do not own an emulator for the Prizm. On the legacy systems the emulator could be detected by query of the calculator id (at 0xA000FFD0) which has been eight zeros with the emulator. Maybe it is similar on the Prizm (with 0xA001FFD0 of course). BTW, it's off-topic but do you know a Sleep syscall ? I think we need it, until now all games use 100% of CPU so they drain batteries. I know this function use TMU2 on fx-9860, maybe we can write an equivalent routine for Prizm.
What do you mean? A sleep function (like the one of the legacy SDK) based on a timer does not save power. The MPU's sleep instruction does, but this is a different concept. The MPU's power saving sleep mode is entered when calling PowerOff (0x1839).
26
« on: April 27, 2012, 11:47:22 am »
Anyone can find a syscall who detects the model?
I think it is 0x1196. int (void). This call checks, if the byte at A0000305 is 5A. You could query the byte at A0000305 as well. 5A: cg10 AA: cg20 55: cg?? A5: cg??
27
« on: April 15, 2012, 12:43:01 am »
I just tried my old account. It still works. Marvelous job you've done there! THX. 
29
« on: April 09, 2012, 02:48:23 am »
I have to apply a correction to the last version of fx_calculators_SuperH_based.chm ( http://ourl.ca/8207/238670): syscall 0x1DA6: int Bfile_GetFileSize_OS( int HANDLE ); Returns the filesize. syscall 0x1DA9: int Bfile_SeekFile_OS( int HANDLE, int pos ); Moves the current filepos to pos. syscall 0x1DAB: int Bfile_Filepos( int HANDLE ); Returns the current filepos.
30
« on: April 07, 2012, 02:07:26 pm »
I am one of the Prizm hackers who had been expressing concerns on #cemetech. I've been in various contact with Casio marketing and engineering personnel over the past year or so, and they have made it clear that they're currently turning a blind eye to mature, responsible third-party hacking. Officially, they're supposed to both not support it and potentially disallow it, but that hinges on how we behave. A Prizm coder started discussing creating a fake reset Add-In over at Cemetech, and a large number of us Prizm hackers quickly expressed our opinions on why that would be bad for everyone in terms of getting Casio to look more closely at what we were doing with Add-Ins and think seriously about Add-In security. Bottom line:
We do not want to drive Casio into the same cat-and-mouse game the Nspire developers have to work around.
One of the great advantages of Prizm programming in my view is that our programs and add-ins work on Prizms without jailbreaking, without Ndlessing, without any sort of unlocking tools. If we want to maintain that, we have to code like ethical, mature, grown-up programmers. Undermining the whole reason that there's a different between the CG10 and the CG20, at least with a public tool release, would not be responsible. I can appreciate the ego value of successfully figuring out the format, and even telling people of your technical successes, but just as it wouldn't be ethical to release a tool to the general public that could exploit a glitch in computer systems to steal identities on the assumption that some would use it for good, it's not ethical to release this tool. There's a very good reason that SourceCoder doesn't do such image format conversions, and trust me, it's not technical reasons.
Is it really ethical or necessary to link a discussion about the g3p-fileformat with "fake reset-addin programming" or -jeeeeeesh!- "stealing identities"? These have never been ideas of this thread. But nevertheless, interesting rhetorical impact. Congrats.  Though. What a pity. I found interesting syscalls during analyzing the g3p-system (f. i. SaveFileDialog or OpenFileDialog; man'o'man, these would save a lot of G3A-space). :'(
|
Show Posts