Alright I am now able to get the pre-alpha compiled to machine code. I just need to debug it before I can release it. The primary issue now is that I'm trying to emulate the SH3 proc which is in big endian mode, but my compiler works in little endian. This has the effect of causing many annoying bugs that can be hard to locate and remove. This isn't preventing me form releasing the first version, but it does slow me down a little.

I'm also now releasing a few details on how the emulator will work. The first version is not meant to emulate the Prizm, but instead only focus on the SH3 for now. This version also runs from the command prompt which displays several stats. Right now it tells you how many instructions are executed per second and the contents of the 16 general purpose registers. As of now the emulator only supports 18 simple instructions. Most of which involve longwords. The reason for doing this was that I wanted to release the emulator in only small steps. That way we could check that everything works perfectly before I move onto the next segment. Release 2 will feature mostly the same instructions, but with support added for bytes, words, and immediate data. For now though I only want to focus on the current 18 instructions which I will list with the release. When the emulator starts it will load the contents of "spectrum.data" into 0x80000000 on the memory. There are 2 bonus instructions to be used as well. One is (end 0xFFFF) which tells the emulator to stop and quit and (pause 0xFFFE) which pauses execution. For now they are included as standard instructions, but will later be implemented outside of the code.

Future releases will include a full gui that will help with hacking and development. In addition to a fully click able Prizm model there will be real time disassembly, display of memory contents, and stack along with numerous other tools. I am also planning on creating an easy to learn scripting language that will allow users to create their own tools to be run alongside the emulator. The scripting language will allow you to create ui objects, access the Prizm memory, access keyboard inputs, and even allow you to create your own variables with control loops and arithmetic.

If you have any questions, suggestions, criticism, or you want to  tell me I'm an idiot  I would love to hear from you.

Entire width of the screen? Could you explain a little more on how this is supposed to work. My best idea because rotating is heavily proc intensive is to just use several sprites for each stage of the rotation.

Could you mark line 291 please?

Or is it just this typo?

Quote

unsigned int n = half_byteone(;

Yeah that was just a typo. It is not actually in the code. And I marked 291 as a comment

I was wondering if anyone here participates in any sports at their schools. This thread is for discussing any sports that you do and some of your memories from there. It is not for starting a war on which sport is better. And as a note to Americans, remember that this is an international site so for the sake of simplicity please refer to soccer as football and football as American football.

For me I do distance running. In the fall I do cross country and in the spring I do track. In fact today I had my first track meet of the season and set 2 PR's (personal record) In the 1600 meter race (about a mile) I ran a 5:20 and in the 4x800 meter relay I ran a 2:28 for my leg of the race. In cross country our races are 3 miles (just under 5km) and are on various terrain including hills, mud, and sand. My PR for that is 18:40 which I am just about to set in the picture below. I'm hoping that next year my team wins the league championship.

Alright I was compiling my Prizm emulator when I came upon an error. As a global variable I had defined a bit field of 1 byte that is split into two 4 bit variables. I then used a #define to rewrite the bit field so that I would not have to label the the struct name. Here is an eample of  the error I got.
unsigned int n = half_byteone;
spectrum.cpp(291: Error: '(' expected following simple type name
struct middle_byte                       //creates a bit feld for reading the middle byte of an instruction
{
unsigned char half_byteone:4;
unsigned char half_bytetwo:4;
};
unsigned char low_byte;   //creates low byte of instruction

 #define half_byteone middle_byte.half_byteone
 #define half_bytetwo middle_byte.half_bytetwo
blah...
void ADD() //ADD Rm,Rn
{
unsigned int n = half_byteone;   //291
unsigned int m = half_bytetwo;
R[n] += R[m];
PC += 2;
return;
}
blah...
half_byteone = (instruction & 0x0F00) / 0x100;     // inside the function that calls ADD()
half_bytetwo = (instruction & 0x00F0) / 0x10;This error appears every time I reference the bit field not just this one example. When I googled this error I found that fixing it involved some sort of weird work with templates (which I have never used before ) Some help on getting this to work would be greatly appreciated.

Hooray for Casio programmers!   You are in luck, we have already hacked the Prizm to the point in which you can now code in asm, C, or C++. (or just straight hex for me) Join us now in the Przim discussion forums. and here are your peanuts


btw: your english is pretty good!  
Edit: just wondering, why is the name of this topic the SH3 command of CMP/EQ R1,R1

Someone rate down one of DJ's posts so that it reads 666 again. 
Or we could just uprate his posts until it is 1337

I had visited here a few times before to learn how do stuff in axe, asm, and basic, but I didn't join till Christmas Day when I got my beloved Casio Prizm. I came here to learn how to start asm coding, but instead ended up working on how to hack the Prizm. Within two months I had joined the anti-riot squad.