Quote from: Kristaba on February 19, 2011, 08:06:49 am

Firstly, what do you know about the G3A header checksum...it's the last information I need for my G3A wrapper

It's the last information I do not know either. But I experienced, that it is not essential. I assembled a little memory-viewer-G3A and did not care about this field. The G3A works without any problems. But anyhow, I like to know how this value is computed, too.

Good thing you are speaking to the right person on cracking the g3a header. The 16 bit crc checksum (well I believe its a crc) only calculates the 32 bit modular checksum at address 0x0020. Now I have not yet cracked the crc yet, but I did crack the modular checksum. How that works is that every byte is added to a tally except for the four bytes at 0x20 and the last four bytes which are a copy of the checksum. But to get by the crc you can use one of the checksums previously written by Casio in one of the three apps. I would first like to apologize on slacking off on my app signer program, but I have been busy lately. How it works though is it compares the modular checksum between your app and a prewritten one. If your app has a lower checksum, then the app signer first divides the checksum of the prewritten app minus the checksum of your app by $FF. It then adds X number of $FF to safe areas in the header that were previously $00. The signer then finds the modulus between the prewritten app minus your app by $FF. It then adds the result to one byte that was $00 originally. If your app has a greater checksum, then the signer divides as usual, but then turns X number of $FF bytes to $00 and the modulus is is subtracted from a $FF byte. There is also full documentation for this on the Prizm wiki http://wiki.prizmwiki.co.cc/wiki/Main_Page

NOP == Nu-Omnimaga-Pron?

j/k I'm glad to hear it's progressing well. Did you have any difficulty getting around the whole virtual memory thing?

I haven't tested it for speed yet, but how it works is when the program is started two dynamic arrays are initialized. The first one is an index of pointers. Every pointer in there represents a 64kb section of ram. The second array is the data in ram. An example of this would be for a write to memory. First the part of the emulator that needs to write to memory would call the memory write function with the syntax writememory(int data = 42, int address = 0x00000005);. Then the memory function would take the address 0x00000003 and see that it corresponds to the 0x00000000 page (pages are all 64kb long). The next step would be to then parse the the first array for 0x00000000. If it exists then the memory function writes 42 to the second array with the syntax memorydata [index][offset] =42. Where index is the index in the first array where 0x00000000 was found and offset is the lower word in data. and if 0x00000000 doesn't exist then it is added to the first array and another 64 kb are added to the second array. This might be kind of hard to understand, but I will have better examples later along with the source for review.

I usually stick to only the C++ STL, but sometimes a function might be easier to use in the C library, and for sections that require absolute speed I will write that in asm. It does make your code a little unclear when you have both iostream and stdio, but it will not cause errors when you compile.

Sounds nice. =) Question though, will this emulator require you to dump your own Prizm's ROM, or will it be able to function just with an OS?

To be a true emulator a rom dump will be required, but it looks like some software will need to be written to do that.

Even the screen shouldn't be too bad once I get the general framework up. In fact I could convert this for a whole bunch of different SH3 calcs. Technically it's even possible to expand this for SH4 proc devices because the SH4 executes all of the SH3 commands in addition to a few new ones of its own. I could even go as far to make my own virtual dream calculators using the Super H architecture.


And what's this. 300 posts!!!!!!!!!!!!! 

Edit: Super Member, I like that title

My goal with this is to allow people to make quick rpg's with little or no coding experience. Because you will be separated from the code this could use Basic, axe or asm. Axe would be easy for someone to compile, but I'm not much of an axe programmer while with asm some people may not be able to compile their code.

I wonder... could the explosion effect from Leafiness's Graviter game be implemented in one of these two games? That would really rule, although I bet it would be a bit slow with other type of particles around.

I don't know about Powder Game, but it looks like Dust Toy might be able to handle velocity. Every particle has 1 byte in L1, but only uses 3 bits I believe. The rest of the bits could be used for direction and velocity. Also I think the method Dust Toy uses to render particles could be optimized. Currently it seems to render every particle, every frame which causes slowdowns with large numbers of particles even when they are not moving. If a particle was rendered every time a pixel next to it was changed, then a speed increase might be possible.