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 - uberspire
46
« on: December 27, 2010, 04:17:30 am »
After changing some of the data you can see a change in the icon, but then the app becomes unrunnable. Any ideas why would be helpful. The first 2 bytes in the headers are 0xAA and 0xAC, right? On the fx-9860, to disable the checksum you would change the first byte (0xAA) to 0xAC. Try and see if that works.
47
« on: December 26, 2010, 03:55:22 am »
IIRC, the header for fx-9860G addins had a couple of spots that were just blank filler just to mess with us.
48
« on: December 26, 2010, 03:43:26 am »
@Qwerty.55: You can download a complete SuperH 3 GNU toolchain (which contains GCC, binutils -> assembler, objdump, linker, etc.) from KPIT for free: http://kpitgnutools.com/. You have to register though. In Casio's SDK, they use some proprietary software from Hitachi.
49
« on: December 26, 2010, 03:38:51 am »
Are you sure it runs at 29 MHz? Some sources says 59 and others 100. The 9860G was slowed down to 29, I think, but it was possible with a program by Kucalc to set the speed at 59 or something, from what I remember.
Well the fx-9860G ran at 29.5MHz at default to maximize battery life. I have no idea what speed the oscillator in the Prizm is running at. The SuperH 3 processor in the fx-9860G had a register for the internal clock generator which you can modify to quadruple (x4) the clock speed to 118MHz (SuperH processors are capable of running at these frequencies).
50
« on: December 26, 2010, 03:25:34 am »
A random additional question for Kucalc: Where did you get the add-ins?
You can download the addins for free as a Guest off Casio's website: https://edu.casio.com/download_service/download/category.php. Scroll down to fx-CG Series, check Add-in software, then click Next and you can download them. They have 3 add-ins up right now. I also forgot that Casio is japaneese, so I guess it might be a good idea to ask them for more info. I hope they speak english, though. 
They seem to speak English. Actually, I was searching my email, I still have the email address for Casio HQ. I don't know if the email address still works, it's been about 4 years since I used it to ask them something. I wrote up an email asking about a SDK and if maybe if they would let the community (us) help them out by letting us beta test the SDK (like in the ClassPad days). IIRC, Casio (the French branch) said they would let us beta test the fx-9860G SDK, but they (Japanese branch) just released the SDK a year later skipping beta testing.
51
« on: December 26, 2010, 02:16:00 am »
I guess someone will have to explore the Prizm and make some kind of SDK until the Casio one comes :S
Finding a way to run unsigned code might be tricky... Maybe as tricky as the Nspire.
Since it seems some of you are very interested in programming the Prizm, I'll tell you guys this (I apologize if it's very lengthy): From disassembling the addins given by Casio, the Prizm uses a SuperH 3 processor, which is what Casio has been using in their products for the last decade (fx-9860, fx-9750GII, Classpad 300, Pocket Viewer, etc.) The addins contain a header 0x7000 bytes long which contains info specific to the addin (appname, icon bitmap, date, version, copy protection, size of addin in bytes, etc.) before the actual binary starts. Addins are loaded into memory offset 0x00300000 (execution starts at 0x00307000). You can confirm this yourself if want using objdump that has been cross compiled for SuperH support (such as GCC targeted for sh-elf). SuperH 3 software manual: http://documentation.renesas.com/eng/products/mpumcu/rej09b0317_sh_3sm.pdfIf someone has the time, it should be easy to crack the header format. The header is about ~28KB, large enough to contain the icon bitmap for the addin. Once someone knows what's the icon dimensions are in pixels, you could probably find it in header by using some hex to RGB viewer. Hardware wise, it seems pretty similar to the fx-9860G (it seems to be just a fx-9860G with an upgraded color screen and a larger flash chip). From this, I'm guessing the operating system is stored in memory offset 0xA0000000 (Area P2). You can try asking Casio Japan (not the USA branch, they won't be able to help much since they don't design the calcs) for technical info and questions about an SDK. Someone in the community asked Casio Japan for the USB communication specs and their R&D department nicely gave it us. You can keep bugging Casio Japan to release an SDK, but you have to understand it takes them time to make an SDK since they have to polish up their emulator which the R&D guys use in development, package up a compiler/linker, write manuals, etc. Casio doesn't make any money off SDKs, so I don't think it's their top priority. I think when the fx-9860G came out, Casio didn't release an SDK until a year later IIRC, but hopefully we don't have to wait too long this time for the Prizm. According to Casio's website, they plan to release some trial software at the beginning of next year, so you guys should keep a watch out for that since it might include an emulator. I'd try to find out more, but I'm too busy right now in college. Hopefully you guys will find everything you need to know in the near future. Happy hackings and Merry Christmas!
52
« on: October 11, 2010, 10:58:01 pm »
I figure that this information is only valid for your good ol' Ti-73's, TI-83+/84+(SE)s and perhaps a select few other calculators. You'd have to ask around for how the Ti-89 calcs work, though I think they work in a similar way. The Nspire is completely different and ... well. I'm not the person to ask.
I agree. The Nspire seems completely different and more akin to what the fx-9860G and Prizm do. Reading around the Hackspire wiki, it seems that with the 32-bit ARM processor in the TI-nSpire you have a 4GB memory map, so you don't really need to do fancy page or memory swapping, since it can access a wider range of memory. The only reason I know that the old TI-83's used an actual Z80 is because I took apart some person's Ti-83 in my college's math lab and found that sucker. A honest-to-God real Z80. I'll never forget that day. I wasn't able to tell which one was the ROM, which one was the RAM, and which one was the memory mapping hardware. There was some other chip there, too. Couldn't figure out what it could possibly be doing.
Yeah, I remember going through some schematics for a Z80 computer and noting the extra hardware it would take to break the 64KB barrier. Now these days, you've got 32 bit processors with large buses and integrated memory controllers, the extra chips aren't necessary. 
53
« on: October 11, 2010, 10:23:19 pm »
These models don't actually use a physical Z80, but rather a SoC that has additional hardware that does things beyond what a normal Z80 would be doing. Example: Memory-mapping "pages" of FlashROM in 16KB chunks to sit evenly with the Z80's 64KB physical address space.
Ah, ok a System-on-Chip. Yeah, because there would be no way a regular Z80 would be able to do that unless you did some fancy stuff with the address and data buses. Hmmm, that actually wouldn't seem very smart in a first glance, but it might make a little sense actually. It's a cheap solution. Z80 is kind of slow (compared to today's ARM and SuperH) so the CPU wouldn't be outrunning the Flash and the programs aren't extremely large (like 100KB or bigger) so not much reading would have to be done.
To address another concern, the calculator *is* slow enough (even at 15MHz) to run programs directly from FlashROM without needing to insert "wait cycles". Or rather, the Flash is fast enough to keep up with the Z80.
Heh, yeah, that's what I was saying. Thanks for clearing this up Iambian. I guess I was just embarrassing myself trying to guess how TI apps get executed, thought it would be same way as Casio.  I guess we now know for sure that Casio and TI (at least the TI-8x ones) load their apps differently.
54
« on: October 11, 2010, 09:51:53 pm »
I'm just guessing and I could be totally wrong, because I'm not a TI guy, but the portion of RAM used by the OS is temporarily replaced by your flash app. When you close or exit out of your flash app, a system call to some portion of RAM (your SafeRAM probably?) that still contains a tiny piece of the OS that will load back the OS from the ROM to the RAM. That would explain your case of why APPS still run fine when you're almost out of RAM. Also I thought only rewriting the flash chip sectors weared it out, not reading?
I believe that is true for most flash chips. But it would be slower to run off a program that was on Flash, than on RAM since Flash typically have longer reading cycles than RAM. I am 100% sure that the TI-83+ to TI-84+SE run Apps directly from Archive.
Hmmm, that actually wouldn't seem very smart in a first glance, but it might make a little sense actually. It's a cheap solution. Z80 is kind of slow (compared to today's ARM and SuperH) so the CPU wouldn't be outrunning the Flash and the programs aren't extremely large (like 100KB or bigger) so not much reading would have to be done. EDIT: Wait a sec, I don't see how this is actually possible. A Z80 has a 16-bit parallel address bus with an 8-bit parallel bus to load in 1 byte for each cycle. With 16-bit's for addressing, the Z80 would only be able to access the lowest 64KB of Flash max. Well, unless the Flash is split into 64KB memory banks and you access each one separately. Or the Z80 has been modified to have it's address bus extended beyond? And since it's running off Flash, is the data bus on the Z80 swapped or disconnected by a multiplexer and connected to the Flash's data output? But then the RAM would be disconnected and there would be no memory for stacks and variables. Or is it 32KB for program instructions and 32KB for program data (variables and stacks)? Or a 48KB/16KB memory map? I need someone here to explain what's happening.  Interesting...
So it's like the TI-Nspire.
Yes, I'm pretty sure the TI-nSpire would follow the same scheme as the Prizm or fx-9860G since it uses a modern ARM processor. The TI-nSpire, needs to "boot up" by copying the OS to the RAM. If power is lost to the RAM (bad batteries, or something), it's need to be loaded back in again. That's why the TI-nSpire goes into some sort of sleep mode (instead of having power cut off to everything) so the OS stays within the RAM. EDIT: Yep, I've been reading your guy's wiki: http://hackspire.unsads.com/wiki/index.php/Memory_layout Quote: "Since 32MB of RAM is available, which is quite a lot, the whole OS code is decrypted from the OS image and copied to RAM at boot time, when the message "Loading Operating System..." is displayed during ~8 seconds. The RAM is also used as temporary storage transparently for the user as described above." The fx-9860G and most likely the Prizm do the same thing, except Casio's don't have that 8 second boot time. Most of today's CPU's are built using Harvard architecture where the program data and instruction memory are separate. Typically, the program data are stored on a hard drive (or some device for storage such as Flash) and the instruction memory is the RAM. All PCs are built this way and almost all computers are like this.
55
« on: October 11, 2010, 09:10:53 pm »
It seems there's been some confusion bewteen RAM and ROM in some posts above.
TI's applications are stored in ROM (Flash-ROM).
Casio's add-ins are equivalent, and are stored in ROM too.
So the geometry add-in has nothing to do with the RAM of the Prizm.
Yes, Casio addins are stored in ROM (Flash). But to be executed, it has to be loaded into the RAM. Well, at least, it's how it's done on Casio calcs. I believe this is true actually for TI and Casio calcs. Flash is good for storage, but not good for running programs off of and is very slow (compared to RAM). Read and write cycles will shorten down the life of the flash chip and kill it. TI's I think do this too: copies program from Flash and places them into a space of RAM reserved by the OS to be executed. I'm pretty sure the TI-89 does that for sure. On Z80 based TI-8X's, portions of a program are copied into RAM when necessary by code banking (or as some of you call code swapping) due to the 16-bit addressing limit on the Z80. I think a lot of confusion comes from the way TI uses it's RAM (to store user data), whereas Casio uses it's RAM in a more modern computer-ish way. (The 61KB of BASIC program memory is actually a tiny chunk of Flash. On the fx-9860G, a hack was done to expand the available BASIC programming storage from 64KB to I think 300KB since it's just Flash memory, not RAM. The RAM is completely separate from the 61KB) A better way to explain this is to use your computer as an example. All your programs are stored on your hard drive, not in your RAM. When you want to run a program, the program is loaded from the hard drive to your RAM and hence RAM get's used up (this also explains why if you have a slow hard drive, booting up will take longer). Running the program from hard drive will kill your hard drive and is extremely slow. On our calcs, we use Flash instead of a hard drive, but it's basically the same idea. Someone with enough knowledge about TI hardware is gonna have to confirm if TI calcs do this too.
56
« on: October 11, 2010, 07:56:17 pm »
61 KB RAM seems fairly low and may be a problem for highly advaced games, but that's assuming the unit really has that amount as an absolute maximum. It's possible that there may be additional “hidden” or system RAM that can be used, at least by ASM or apps (assuming they are supported).
Low RAM isn't an insurmountable problem if ASM is supported. Code swapping would allow some incredibly impressive games, particularly if the Archives are utilized.
I think there is some misunderstanding. The 61KB of memory is for storing BASIC programs and other user data (your graphs, math input history, calculator settings, etc.) 61KB of RAM wouldn't be enough to run the OS the Prizm or the fx-9860G use. Looking around the Casio's site, I can see no mention of the 61KB as being RAM. Instead, they call the 61KB as program memory, which is what it really is since it's for storing BASIC programs. The previous generation, fx-9860G has 64KB of BASIC program memory, with 512KB of RAM available for C/ASM apps. In the Casio world, we call our flash apps or asm app: addins. We don't really use assembly since Casio provides us with a C SDK (complete with compiler and emulator) and C is more convenient for programming. I guess you could program in assembly, but the processors are probably too complex (compared to Z80 or 68K) to be coded by hand in assembly. The RAM in the Casio Prizm has gotta be at least more than 739KB, since the Geometry addin for the Prizm is ~739KB. The addins have to be loaded into RAM before execution. Considering that some of the RAM is also used by the operating system, best bets are that the Prizm contains maybe an 8MB RAM chip with 1MB or 2MB usable RAM for C/ASM apps. That would make sense, because the previous generation, the fx-9860G has 4MB RAM chip with 512KB of usable RAM.
57
« on: October 09, 2010, 05:38:22 pm »
Clam-shell version? 
The Casio fx-9860G Slim:  It fits in your pocket.
58
« on: October 09, 2010, 05:35:23 pm »
The Prizm is an awesome looking calculator. Finally a calc with a backlit color screen. 61Kb of RAM really? It is going to need 162Kb if video RAM just to display a full screen picture.
The 61KB of RAM is used for storing BASIC programs. You have 10MB of usable flash memory to store flash apps (C and Assembly) and whatever you want (text, pictures, etc.) On the fx-9860, you had 64KB RAM for storing BASIC progs, but if you wanted to write an app you had access to, I believe, 512KB of hardware RAM and you would just use malloc() to allocate memory for the video RAM or use the video RAM provided by the Casio OS. I speculate in the future, CASIO might release a SD card version and a clam-shell version, just like they did for the fx-9860G. Casio is most likely going to release a SDK where you can program in C or assembly. They've done so for all the previous calculators that officially supported add-ins (ClassPad and fx-9860G) and Casio has already released a couple of add-ins on their download site (IIRC, a units converter and a geometry app) so this calculator is surely capable of C and assembly programming. Casio even has an official SDK forum on their site, so they're aware that there are nerds out there who want to program and make apps. A final note, the North American Prizm (fx-CG10) seems to be a bit crippled than the other Prizm (fx-CG20). From what it sounds like, images and movies (in CASIO's g3p format) created on a fx-CG20 cannot be opened on a fx-CG10, unless it was provided by Casio (On Casio's site you can download images/movies from their gallery: http://edu.casio.com/products/cg_series/materials.html) The fx-CG20 can open images and movies from both the fx-CG20 and fx-CG10. This was probably done so it would conform to testing standards in the US.
59
« on: October 08, 2010, 01:26:03 pm »
I haven't posted here in a long time, but I thought you guys might be interested:  Coming out in January 2011, it has a 216x384 65,536 color display and 16 MB of flash for apps. There's a video of it here: You could see in the old classroom a TI-Nspire. Then while the old classroom is being transformed into a modern one, the TI-Nspire changes to a CASIO Prizm.
60
« on: September 12, 2008, 10:36:21 pm »
Falcon is a calculator that I'm designing (original design) and building. I have a thread about it at here: Falcon 8. I kind of got the idea from some guy at United-TI who wanted to build his own TI-86. I thought to myself, why not build my own with decent specs. It uses MLC as one of it's native languages. Lua might be added later.
|
Show Posts