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
1
« on: February 19, 2015, 12:36:46 pm »
Yes, I'm glad, Helder mended the problem.
I do not see any problem, if admins drop the documentation on their sites.
Though, it would be reasonable to keep track of updates.
2
« on: February 04, 2015, 12:15:12 pm »
This "hidden SD card reader"-thing seems to be interesting indeed.
The CP400 knows some answers like: "[SD DETECT TEST]", "[SD FORMAT TEST]", " No Card !! ", "[SD WRITE TEST]", " Card Write OK!!" a. s. o..
Seems to be able to distiguish between "PANASONIC"-, "TOSHIBA"- or "SAN DISK"-cards.
Where is my soldering iron?
3
« on: February 01, 2015, 04:12:00 am »
I used the very last door, they left open. Even on the CP400 the good old protocol 7.00 function 0x56 (Upload'n'Run) still works.
(BTW: Perhaps some moderator could move this topic to the CASIO-calculators section)
4
« on: January 31, 2015, 10:14:09 am »
The LCD-controller of the CP400 seems to be some R61526- or R61581-clone. It identifies itself as R61523, when queried with command 0xBF.
5
« on: January 23, 2015, 09:29:05 am »
6
« on: January 23, 2015, 09:24:53 am »
Obviously CASIOPEIA is permanently down. Now Noteview needs a new home.
The attachment contains both G3A and G1A
7
« on: January 23, 2015, 08:55:04 am »
Obviously CASIOPEIA is permanently down. Now my documentation fx_calculators_SuperH_based.chm needs a new home.
Post-attachments are limited to 1024 KB. Even the zipped fx_calculators_SuperH_based.chm (20) exceeds this value.
Does anybody know, where I can put the doc?
9
« on: September 19, 2012, 01:57:57 am »
Thanks a lot for your hints. Note: In the Protocol 7 page in the chm, I can confirm that you can indeed send commands over USB to and from the Prizm. It says currently that only IO was used.
Actually, I did only use the serial interface because I have not yet managed to access the Prizm via USB from out of my programs. :'( I use windows. On the fx-9860-types I run a device-enumeration based on vendor-id "VID_07CF&PID_6101". I use the match as serial device and everything works well. With the Prizm I didn't find a way to communicate via USB from out of my programs, yet. To be honest: I abandoned this project. It would be splendid, if you could help. Also, info on the OS update: According to the emergency OS updater, it reports a low OS version (0.02.0200). It may instead use this as the base OS version and could be confirmed by sending an OS with a lower version number. Also, the OS code version for the Get Device-Info doesn't report the OS version. For a 1.04.3200 OS it reports 1.02.0200.
In fact, Get Device-Info returns different results, depending on from where it is called. The emergency OS updater resides in the bootcode. It does not care for any data in the OS range. I will add some hints to my documentation. Also, there is a change for the EditMBString* and DisplayMBString* commands. The unknown variable is int start, representing the first character drawn. This number will be used as the start of the string drawn, but the OS also does bounds adjustment. Passing 0 and the cursor set past the edge of the screen with cause start to be ignored.
I will update my documentation. THX again.
10
« on: September 16, 2012, 01:29:04 pm »
Might it be possible that instead of a hook routine executed within a loop, there could be a function call to start a transfer, then execute some amount of code (which runs under the same constraints as a hook routine but is not called repeatedly), and then a function call to end transfer (if DMA is not finished by that point, loop until it is). I'd imagine this would work very well for double-buffered rendering, where the previous buffer is being DMA'd and the next buffer is being drawn simultaneously.
I expected this question. The assembler routine is divided into three segments. Initializaition, wait-loop and finalization. Possibly these three functional segments could be implemented as three separate functions. Though, I feel a bit uneasy about the SYNCO-instruction.
11
« on: September 16, 2012, 01:11:57 pm »
The LCD doesn't have its own DMA on the Prizm though, I think it's set up with the processor's DMA.
Yes, that's right. The processor's DMA-controller manages the transfer from the Prizms RAM to the LCD's GRAM.
12
« on: September 16, 2012, 01:09:12 pm »
When you make the code public, would you like me to add it to http://prizm.cemetech.net/? Link to a post here?
Feel yourself free.
13
« on: September 16, 2012, 01:04:34 pm »
I love the work that Simon does, but I prefer when I understand what happen! :p I understand that. But I need your help, too. I am no teacher. It is difficult for me to develop a proper feeling for what is necessary to document. I try to do my best, but I think I need your questions. So, will the future routine be speedier than the syscall? The loop that disp_Vram creates will be avoided? The loop cannot be avoided. But one of the advantages of DMA is, that you can do other things simultaneously during the DMA-transfer takes place. I attached fx_calculators_SuperH_based_13.chm. It contains an example. Look for "History" or "LCD-DMA-hook". Attachment removed. Updated: http://ourl.ca/8207/318834
14
« on: August 26, 2012, 12:48:37 pm »
hmm... I will see about using the background VRAM as a second buffer. I don't know of anywhere that documents the required writes and such to copy the VRAM to the LCD. Do I need to play with the LCD at all before using the DMAC?
I am about to write some little assembler function, which will transfer any rectangular range from RAM to the LCD's GRAM via DMA. When it works well I will post the source.
15
« on: August 26, 2012, 08:31:15 am »
What would disturb it? writing to the memory it is copying (or would it not mind this)? Using a syscall that tries to use the DMA?
I think any access to the LCD-controller and any syscall which accesses the LCD-controller will disturb. DMAC0 mustn't be touched, of course (except for polling the TE- and AE-flag). I do not know if the source memory can be written to during the DMA-transfer. But I do not see why not.
|
Show Posts