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 - z80man
Pages: 1 ... 17 18 [19] 20 21 ... 62
271
« on: May 13, 2011, 02:45:11 am »
272
« on: May 13, 2011, 02:43:53 am »
Would that be interrupt based to prevent slowdowns or is it simple enough to within standard code.
273
« on: May 13, 2011, 02:39:51 am »
Would Khavi have a break button by any chance. That could be useful to break from buggy programs using the ON button.
274
« on: May 13, 2011, 02:26:49 am »
And I'd like to implement my 84+ emulator on Khavi too as that is technically a bytecode VM as well. I do have a question though. Is Khavi a standalone program or is it more like a framework to be used to make VM's? Sort of like libraries that you attach to a program except this library controls the program flow.
275
« on: May 13, 2011, 02:19:22 am »
Make extra money from the 84+ keypad. Someone who buys the calc will have to buy the keypad separately.
I'd probably spend more money on the 84+ keypad as that's all I'm interested in. 
276
« on: May 13, 2011, 02:18:08 am »
Actually I recently found out a little more about how the screen receiver works. It appears to use the dmac to do quick transfers of the vram to the usb. The problem is that the vram to DD (screen draw) also uses the dmac so screen reciever must wait till it is free. What I've seen is if you do a for loop to 100,000 with no drawing with screen receiver running there is little slowdown to your code, but if it is graphic intensive there still is little slowdown, but screen receiver won't do an transfers. Also if screen receiver is already using the dmac then directdraw must wait till it is done. The full dmac transfer takes about 1/22 of a second, but you can have your own code running during this time.
277
« on: May 13, 2011, 02:11:21 am »
I found that my current code for the core emulation is faster because I now have inline asm than that emulator, but it does provide extremely valuable code for the hardware and memory which is 80% of the emulator.
278
« on: May 13, 2011, 02:08:10 am »
Simon's Mini-SDK uses the Renesas compiler which is less optimized than the gcc compiler. The Casio SDK is also more difficult to use and requires that you already own a fx9860g unless you got the SDK already from fishbot. 
279
« on: May 13, 2011, 02:05:25 am »
I just sent this email to Renesas based off some new found evidence Hello I have an inquiry about a device that uses a Super H processor. This device is the Casio fx-cg10 graphing calculator which is believed to use a modified SH3. Based off a reading from the rom chip the identifier "RENESAS SH7305" and "RENESAS SH7355" are found. Now Renesas does not appear to be selling either a 7305 or 7355 brand Super H so I have reason to believe that this is a custom order. If it is at all possible would a full hardware documentation be available for this version of the Super H or at least could I know which processor it is most closely related to?
Thank you for your time,
[my name was here]
I found this identifier at the end of file produced from the spreadsheet app. In my case SHEET.g3m. There appears to be more written at this location too if anyone can decipher it.
280
« on: May 12, 2011, 03:21:38 am »
Yeah that topic went big pretty fast. One day I checked and I was like "Wtf? 230 posts!". I guess that's what happens with TI-Boy SE and such projects, though.
Yeah I remember it was about 1.5 years ago when I first sent TI-Boy to my calc and was greeted with the bad hardware message After all this time I finally get to enjoy its greatness.
281
« on: May 12, 2011, 03:19:15 am »
Ah ok. Maybe it's a program for more fortunate and private schools.
No not really. Yes my school does travel much more than others because we are private, but almost every public school in around my area has an MUN program. In fact I know that one public school in Los Angeles is going on a trip in Turkey this year. Part of the reason why there is either lots of schools with MUN in an area or none is because the majority of conferences are local so that if few other nearby schools don't have MUN then there are no conferences.
282
« on: May 12, 2011, 03:14:12 am »
But isn't there a different image format available on the Prizm?  Anyone could write a converter to make custom images. Not that it's widely available, though, since most students won't browse calc websites to download such stuff.
Yes it is possible to make an image converter or just an image opener that doesn't use g3p. And there is also g3b which is like an animated gif. It would probably be for the best if TI did the same because for education purposes pre-included images can be used to prevent pr0n. And then with people like us who get around these restraints, we're not the kind of people to start a pr0n issue. In fact I'd be very careful with any image converter software we make because we don't want it to get into the wrong hands and then cause Casio to release a new OS.
283
« on: May 12, 2011, 03:08:51 am »
MUN is found internationally not just in the US, but many schools don't have it. It is quite popular in schools around where I live, but perhaps not as much in other areas.
284
« on: May 12, 2011, 03:06:46 am »
And once again another good reason to go Prizm route. I can see teachers having to deal with excesive amount of pr0n on the CX if TI doesn't do anything about it. But because teachers always get their ways TI will probably cancel that.
285
« on: May 12, 2011, 02:55:49 am »
I just saw this on TI's website for the standard Nspire CX. TI-Nspire supports the following image types: jpg, jpeg, bmp and png. Now with the Prizm there are two models: the cg10 and the cg20. The difference being that the cg20 can load bmp images while the cg10 (for US testing requirements) cannot. Now if TI allows the CX to do so wouldn't they be voiding usage of their calcs on tests. If not, then what the hell Casio 
Pages: 1 ... 17 18 [19] 20 21 ... 62
|
Show Posts
