Omnimaga
Calculator Community => Casio Calculators => Topic started by: yunhua98 on December 31, 2010, 05:34:54 pm
-
Wow this subforum is growing fast
Anyway, does anyone know if Casio is planning to release an emulator? Also, would it be possible to easily port games from TIs to the PRIZM? There are just too many good games on ti just to let them go away.
And if ccasio isn't making an emu, how hard would it be to make a third party one?
-
Wow this subforum is growing fast
Anyway, does anyone know if Casio is planning to release an emulator? Also, would it be possible to easily port games from TIs to the PRIZM? There are just too many good games on ti just to let them go away.
And if ccasio isn't making an emu, how hard would it be to make a third party one?
We'd need something like ti83plus.inc to make one, do we have?
-
Wait what? Why do we need ti83.Inc o make a prizm emu?
-
Wait what? Why do we need ti83.Inc o make a prizm emu?
I *think* we need, sorry. I believe we need to know ALL Tokens to make an emulator.
-
Wait what? Why do we need ti83.Inc o make a prizm emu?
I *think* we need, sorry. I believe we need to know ALL Tokens to make an emulator.
You don't need tokens. The emulator emulates the hardware, the hardware runs the OS, and the OS handles everything else. However, making an emulator would still be very hard, since we need to know a lot about the hardware.
-
Wait what? Why do we need ti83.Inc o make a prizm emu?
I *think* we need, sorry. I believe we need to know ALL Tokens to make an emulator.
You don't need tokens. The emulator emulates the hardware, the hardware runs the OS, and the OS handles everything else. However, making an emulator would still be very hard, since we need to know a lot about the hardware.
Can we remove the OS from the calculator? Is it a single file (example: .tno files)
-
I still don't understand why we need ti83plus.inc to make PRIZM emu...
-
I think he wants to convert to PRIZM asm the Ti 83+ routines to port games / base the emu programming on it
-
I still don't undertake why we need ti83plus.inc to make PRIZM emu...
/FACEPALM
Wow this subforum is growing fast
Anyway, does anyone know if Casio is planning to release an emulator? Also, would it be possible to easily port games from TIs to the PRIZM? There are just too many good games on ti just to let them go away.
And if ccasio isn't making an emu, how hard would it be to make a third party one?
We'd need something like ti83plus.inc to make one, do we have?
And then people say I'M THE ONE who doesnt read what people say...
-
I think he wants to convert to PRIZM asm the Ti 83+ routines to port games
You mean a TI-83+ emulator for the Prizm?
-
Wow this discussion become very strange...
-
No, my first post meant how to make an emu and how similar the languages are, not make an emu that changes the languages
-
The processor used by the Prizm seems to be very different from Z80.
-
something like ti83plus.inc
-
You mean like a cprizm.Inc?
I thougt you meant we needed the ti one. :P
That would be essential for asm coding of course, I don't know about emu though...
-
I still don't undertake why we need ti83plus.inc to make PRIZM emu...
/FACEPALM
Wow this subforum is growing fast
Anyway, does anyone know if Casio is planning to release an emulator? Also, would it be possible to easily port games from TIs to the PRIZM? There are just too many good games on ti just to let them go away.
And if ccasio isn't making an emu, how hard would it be to make a third party one?
We'd need something like ti83plus.inc to make one, do we have?
And then people say I'M THE ONE who doesnt read what people say...
The people who did that were warned for doing it rudely. It doesn't mean you have to do the same as them. Plus this is a very technical subject, which means less tech-savy people (like me) will most likely miss important information in posts, not to mention your post was not very clear (It appeared to ask if we may need the actual TI-83+ file).
As for an emulator, I do not know if we need the inc file necessarly. I know Casio is releasing a free trial software for early 2011. This might include an emu. However, given that the FX-9860G emu apparently doesn't support add-ins, I have doubts that Casio's proprietary emu will be that good.
It would be nice to see a community one, as long as it doesn't contain any copyrighted code.
-
Okay, we don't really need to know the hardware, per SE.
For a TI emulator, you don't need ti83plus.inc. It's very abstract in it's implementation. An emulator for TI calcs in essence emulates things like ports and such, not memory and bcalls. The OS handles all bcalls and such on it's own with it's own code. The code is gotten from a ti-calc based on a ROM.
For a prizm emulator, we need to know screen size, and low-level how it talks to it. That means we need some sort of disassembly of the OS so we can analyze that stuff.
-
What graph said: You almost never need an include file for emulating anything, since all the .inc file is is basically ASM source code that's imported into assembly programs (usually for equates). By the time you're emulating hardware, everything's already in pure data form anyway (you could call it hex), so you wouldn't need the text file for it. Basically, it's just ASM source used in assembling so coders don't have to type all the equates by hand, kinda like #include in C/C++ and prgm in Axe. Maybe you're thinking of ti83plus.rom (instead of .inc)?
That's for the kind of emulator we have to TI calcs, though, which only emulates the hardware and lets it read the OS like a real calc, like graph said. That's why you can have an emu with no OS. It's just like a calculator with no OS: hardware's there, but you can't do anything with it.
So if we were to make a Prizm emu, we'd have to know how its hardware works (ports, LCD, how it reads the OS and other stuff, keys, and everything else). Then to run it we'd need a ROM (or maybe just the OS, depending on how picky Casio is ;)), which you know.
-
I'm pretty sure we could run it with just the OS. I don't know how picky Casio is with roms, but I'm sure it will be alright for personal use or something like this. Now, we need to be careful to see any signs of no-hacking policies. I don't like messing with stuff where it could be legally bad, and wouldn't write an emulator at all in that case. Does anyone know of a disassembler for the SH3? Or at least an instruction set somewhere.
-
author=graphmastur link=topic=5966.msg105395#msg105395 date=1293858085]
I'm pretty sure we could run it with just the OS. I don't know how picky Casio is with roms, but I'm sure it will be alright for personal use or something like this. Now, we need to be careful to see any signs of no-hacking policies. I don't like messing with stuff where it could be legally bad, and wouldn't write an emulator at all in that case. Does anyone know of a disassembler for the SH3? Or at least an instruction set somewhere.
I couldn't find any disassemblers that worked for the SH3, but there is a full documentation at http://documentation.renesas.com/eng/products/mpumcu/rej09b0317_sh_3sm.pdf (http://documentation.renesas.com/eng/products/mpumcu/rej09b0317_sh_3sm.pdf) using that I'm someone will write a disassembler tool allowing us to document ports, memory, and system calls. As for the rom it should be legal as long as you use one from your own calc.
-
Necro, 'cause I never saw this...
Since the last posts, the situation has changed somewhat. Yes, there are multiple disassemblers available and the OS can be probably run without a ROM image. The hardware documentation is available in the previous post.
-
This is good :)
-
I have a feeling that pretty soon we will be capable of building a full Prizm emulator. Even though we haven't fully disassembled the OS yet and the ports are still unknown, an emulator can at least be started. The first thing that can be done is the SH3 emulation core. With this being already fully documented, emulating the instructions is possible and I was actually going to start writing the insructions soon too. This will be in Java for several reasons that I will explain later. Next thing to be emulated will have to be the memory. Now for Ti-83+ emulators you could just make a 64 kb array and call that memory (ignoring flash and ram pages at the moment). Now with a 32 bit proc this is a lot harder. So if anyone is good with writing memory management routines in java I could use some help. Then there is also the flash to be emulated which I believe could just be stored in a file and then accsessed from there. I'm not yet sure if the flash is set up in pages or if it just addresed similar to the ram.
In other hardware the keyboard shouldn't be that hard and the screen will be easy once we find where it is mapped to. usb could be hard to work with, but that shouldn't be nessecary in the initial version of the software. There is also the serial port, but it acts diffrently than the 83+ one because it has input and output buffers. The last hardware I can think of is the clock and that should not be hard to emulate either.
Now I want to go over some project details. Even though I'm mainly a C++ programmer, I wanted to do this in java, one because of portability. Two because my idea was to make each of the hardware devices its own thread so they can operate simultaneously. (this feature being very easy to implement in java) I also wanted to add full debugging software just like in wabbit. This project is also quite ambitious so I will need lots of help from everyone. Once I get started on this I will post updates and also send out help requests. For the past few weeks I have been very busy (especially because I have a job now), but I will have more free time in the near future. Lastly my current priority is to get that app signer out, to make Prizm programming much easier. It's just been I've just been very busy as I previously stated.
-
I can help if you need conceptual level help with any of the hardware processes or opcodes. I'm still working on all of the I/O, excluding keyboard (which I'm not even going to touch until I can at least use the screen), so that might be a bit too ambitious to emulate. But the CPU core is definitely possible. Just be careful with the arithmetic instructions and read the instruction descriptions. Some of them have very important but slightly subtle effects.
On a side note, the Renesas documentation has C code for all of the instructions, so that might be easier in C rather than Java.
-
I can help if you need conceptual level help with any of the hardware processes or opcodes. I'm still working on all of the I/O, excluding keyboard (which I'm not even going to touch until I can at least use the screen), so that might be a bit too ambitious to emulate. But the CPU core is definitely possible. Just be careful with the arithmetic instructions and read the instruction descriptions. Some of them have very important but slightly subtle effects.
On a side note, the Renesas documentation has C code for all of the instructions, so that might be easier in C rather than Java.
Or I could just port the C codes to java
-
Or that ;)
-
Well I already figured out a memory model which a will give a brief description of. How it will work is when an instruction is passed for a memory location, the emulator then converts the physical adress into a virtual one which can be stored into a dynamic array. So in order of execution, a program on the Prizm passes a virtual address to the OS, which then converts that into a physical address, then the emulator converts that into a virtual adress, then the jre converts that into a different virtual address, and then converts that into a physical address. Wow this makes my head hurt. :w00t:
-
lol, Aren't abstraction layers fun?
-
I'm glad to hear an emu might be eventually doable. Good luck to whoever starts working on this.
-
Hey guys >B)
I already thought to a fx9860 emulator some years ago (I never realized it, but I have some ideas).
Briefly, the SH3 isn't a Z80 : it's a recent RISC processor, with MMU, privileged mode, etc...
So the better idea to simulate the processor is, I think, to write a C program that work exactly as the hardware processor (abstract implementation of the hardware). It seems pretty complicated and outsized for this task, but I think it's the better idea to get a reliable base for a complete emulator, and the recent computer processor are enough powerful to run this without any problem.
If this base is chosen, the rest of task to get a worked emulator is to write the software description of the rests of hardware components (RAM, ROM, Screen, keypad, and probably some stuff).
I know a open-source video games emulator, MAME, use this kind of implementation and work well, so it isn't *ONLY* a stupid idea from a Casio programmer :love:
-
The only problem with that is that the SH3 has a ton of little components, registers, and various internal things that all would have to be replicated for a complete emulator. A functionality level emulation might be faster and easier to create.
-
You're true, but I don't know if you really bypass a lot of SH3 functionalities (for example, the Casio OS use the MMU, the interrupts (through the interrupt vector), a lot of system registers, and probably more than 90% of the opcodes, the only think not really used on it is the protected mode, but normally when an interrupt is triggered the CPU switch in privileged mode).
So, except for advanced built-in functionalities (as the UART or the USB internal driver), I don't see a lot of things you can avoid to do :(
Have you a general idea of your implementation that I could see? :P
-
I think z80man might have a better idea than I do about how to emulate the SH3 core. As for Privileged mode, it's actually used quite often on the Prizm. Add-ins appear to operate in it and the OS certainly does.
-
Two because my idea was to make each of the hardware devices its own thread so they can operate simultaneously.
What hardware does the Prizm have that does a lot of computation, other than the CPU?
It's probably OK to use a separate thread for graphics/GUI, but I would advise against using threads for anything that can affect the operation of the CPU (either by interrupting it or by writing to memory). That opens up a veritable Pandora's box of potentially extremely hard to find bugs, because you can no longer rely on two runs of the emulator giving the same result - you are likely to have bugs that only show up one out of 1000 times, or bugs that disappear whenever you add debugging statements (printing debug messages affects timing!), and so on.
-
I saw Java mentioned in this thread, and wanted to mention that it is a bad idea. Emulation with an interpreted language is not going to be fast enough.
-
Well then SirCmpwn you're going to have to help these guys to make the emulator multi-platform-compatible, since their main reason for making it in Java is portability. For some reasons I was sure C++ was Linux-compatible, though.
-
The importance with threads is that many parts of the Prizm run in parrellel(mainly the lcd, but also stuff like the serial port and clock) Otherwise the emulator is set up exactly like the SH3 core. First I already have a memory model set up that takes 32 bit physical adresses. Other core functionnalities are the registers are set up as global variables allowing them to be acseesed at all times. Also porting SH3 commnads will be easier to do because Reneas provided the C code equivalent for every command. They even suggested some good ideas that would make emulator coding much easier. One is that the registers are actually initialized as an array int R[16]. This makes it easier to then emulate instructions the code passed.
There are many other complicated features that can not be explained in just one post. Once I get farther on this project I will create its own thread and make a pdf documentation of the emulator.
I could code this is C++, but I will need to learn how C++ threads work first. Also I will need to learn to use a graphics library that works on all systems because currently all I know is Directx. Last is that non Windows users will have to compile the code themselves.
-
The importance with threads is that many parts of the Prizm run in parrellel(mainly the lcd, but also stuff like the serial port and clock)
That's no reason to sacrifice determinism. You have no control over how Java schedules threads, so there is no way to have a separate thread do something every 10000 clock cycles or whatever. Thus, you cannot make the hardware's emulated timing even close to accurate.
The usual way to write an emulator is to basically do your own scheduling, based on emulated time. Maintain a data structure that keeps track of what event is going to happen at what time - and dispatch an event when sufficiently many CPU cycles have been emulated. Here's a sketch of one possible way (not necessarily the best, just a way) to implement that:
void mainloop() {
while (true) {
// Handle any hardware events that need to be done now
for (HWEvent ev : allHWEvents)
if (ev.time < curTime)
ev.doIt();
normalizeSchedule();
// Handle CPU
while (curTime < 0) {
int instruction = readWord(pc);
pc += 2;
// ...execute instruction and increase curTime appropriately...
}
}
}
// Adjust times so that the next the next event that will happen is at time 0
void normalizeSchedule() {
int next = Integer.MAX_VALUE;
for (HWEvent ev : allHWEvents)
if (ev.time < next)
next = ev.time;
for (HWEvent ev : allHWEvents)
ev.time -= next;
curTime -= next;
}
-
For the record, the entire prizm suite (What this will most likely eventually go in) will be cross platform with C++. I have computers that I can test it on. I should probably get working on that.
-
I have now started work on the Prizm emulator. This project is in C++ and will be compatible with Windows, Linux, and Macintosh. For now all I have are the variables set up and the instruction decode. If you check the SH3 documentation from Reneas, they provide the C code for each instruction. The issue though is that their instructions are in little endian format while the Prizm uses Big endian. Because someone might patch the OS or make their own, I set up a model that will allow instructions to be executed in both formats. lastly I will try to have a sample of the emulator out by tomorrow that will have only the most used commands and a simple debugging interface.
Update: Graphics library will be SDL. Windows binary and C++ source will be available. Compiled using Digital Mars. Example SH3 program will be included
-
Cool to hear :D, good luck with it!
On a side note it migth be nice if someone eventually made a Casio FX-9860G and FX 1.0/AFX emu, because the current existing ones have questionable grayscale/LCD emulation.
First of all, it might be best to have a Prizm one, though, so it's easier to debug the stuff you guys are working on.
-
Cool to hear :D, good luck with it!
On a side note it migth be nice if someone eventually made a Casio FX-9860G and FX 1.0/AFX emu, because the current existing ones have questionable grayscale/LCD emulation.
First of all, it might be best to have a Prizm one, though, so it's easier to debug the stuff you guys are working on.
With the similarity between the FX 9860G and the Prizm I could probably keep 75% of the code intact from either emulator. In addition to having the same proc most of the hardware is similar too.
-
Ya that's what I thought. The only issue would be the screen I guess.
-
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!!!!!!!!!!!!! :w00t: :w00t: :hyper: :hyper: :evillaugh: :evillaugh:
Edit: Super Member, I like that title :)
-
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?
-
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.
-
Or if Casio lets you you could reconstruct a ROM from just an OS.
Glad to know someone's taking this on! :D
-
Here is a prizm emulator modelling program.
It simply brings up a prizm graphic and responds to key presses - nothing more.
Modeling , is a means of coming up with better ideas or using features of the model
for the first working prototype.
This program written in Python could easily be converted to a C program using Windows GUI API.
-
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!!!!!!!!!!!!! :w00t: :w00t: :hyper: :hyper: :evillaugh: :evillaugh:
Edit: Super Member, I like that title :)
Something I hope, though, is that the LCD driver isn't like 10 times slower than the 83+. On the 83+ problems arise when the LCD delay is too low and grayscale needs to be interlaced to look good.
-
Alright the Prizm emulator is coming along quite well. So far it has support for 18 commonly used instructions with all of them in longword format. These instructions are most of the MOV instructions, Add and subtract, comparisons, and branching statements. Tomorrow I will code a simple user interface in to display the contents of each register. I hope to have the first pre-alpha version out either Saturday or Sunday. The code should compile on all systems.
Lastly I was having some trouble trying to emulate the NOP instruction. Help would be much appreciated because it is way to complex for my puny brain.
[j/k] ;)
-
NOP == Nu-Omnimaga-Pron? O.O
j/k I'm glad to hear it's progressing well. Did you have any difficulty getting around the whole virtual memory thing?
-
NOP == Nu-Omnimaga-Pron? O.O
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.
-
Has anyone figured out how to transfer calc files to this emu? I tried dragging them on the screen but it said invalid file type when I tried dragging add-ins and program files, and when I tried setting the emu in receive mode through the linking menu it said not supported in the emu. ???
Is it even possible at all? I liked how most TI emulators allowed such thing. It would be nice to make animated screenshots of games ???
-
Has anyone figured out how to transfer calc files to this emu? I tried dragging them on the screen but it said invalid file type when I tried dragging add-ins and program files, and when I tried setting the emu in receive mode through the linking menu it said not supported in the emu. ???
Is it even possible at all? I liked how most TI emulators allowed such thing. It would be nice to make animated screenshots of games ???
Yeah you won't be able to do that with Casio's free trial. :P Their emulator is not a real emulator in that it only emulates the software not the hardware. Meaning you can not add your own files.
-
I see... I guess then a new emu is in order. <_<
-
Update:
To convince everyone that i'm not slacking off on this project. I am posting the entire project source as of right now. You will notice first off that you cannot compile the code yet because there is no main function. You can however review the code, which I am trying to keep well commented. The most interesting part is "instruction set.h" as it contains the emulated source for each machine instruction. Right now in the code, 9 of the instructions are fully written. 18 instructions (viewable in the source) will be included with the first release (hopefully this weekend). You will also notice that a file called spectrum.cpp is missing. Spectrum will be the official name of the project when I release it. With the first version a user will be able to upload a pre-compiled program (no header) and run that. There will also be a gui (I will be working on that later), that will display the current contents of the 16 registers and the cpu speed. Lastly there really isn't a whole lot left to code before the first release. Enjoy the source for now. :D
-
I'm glad this is progressing. Is it me or is the code really small, though? O.O Or is it just because it's in very early stages?
-
Update:
Well the pre-alpha of the Prizm emu is finished. The only problem is that I have a pretty bad history with compilers and keep on getting errors that should not occur. Basically the main problem is that my complier, digital mars, does not recognize global variables properly. If someone else wants to help me compile this please PM me.
-
Ouch, sorry to hear. I hope you can get it resolved soon. What error do you get? You could post logs, maybe, so people can help.
-
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 :P I would love to hear from you.
-
I'm glad to see this is still progressing. Unfortunately I can't do much, though, since I don't know SH3 assembly and am command prompt-illiterate (besides cd command x.x).
-
One way to improve memory access times when emulating big-endian on a little-endian machine is to have each set of 4 bytes stored backwards. Example memory read functions:
s32 read32(u32 address)
{
return *(s32*)(mem_array+address);
}
s16 read16(u32 address)
{
return *(s16*)(mem_array+(address^2));
}
s8 read8(u32 address)
{
return *(s8*)(mem_array+(address^3));
}Same sort of thing for memory write functions. To put it simply: when accessing 16-bit values, XOR the address with 2; when accessing 8-bit values, XOR the address with 3.
-
I'm not sure if this will work, but this is what I have now. The idea was to just everything as blocks of chars that way I could store data in big endian
int readmemory_long(int pointer)
{
unsigned int r_pointer = pointer - 0x80000000;
if (r_pointer > 0x00FFFFFF) return 0;
int result = 0;
char * p_result = &result;
for (int index = 0; index <4; index++)
{
*p_result = memory[result + index];
p_result++;
}
return result;
}
void writememory_long(int pointer, int data)
{
unsigned int r_pointer = pointer - 0x80000000;
if (r_pointer > 0x00FFFFFF) return;
int * p_data = &data;
for (int index = 0; index <4; index++)
{
memory[r_pointer + index] = *p_data;
p_data++;
}
}
-
That doesn't look like it would work, because you're basically doing a memcpy of size 4, which doesn't change endianness at all.
Edit:
Also, if you're willing to use a couple lines of x86 inline assembly, you can use the BSWAP instruction to convert a 32-bit value between big endian and little endian, and the XCHG instruction to convert a 16-bit value.
Edit2:
Or, for better portability, use the ntohl() and ntohs() functions, which should work on big-endian machines too (in theory)
Edit3:
Almost forgot, use ntohl() and ntohs() for reading memory, htonl() and htons() for writing memory
-
Thanks calc84 for those functions. The header netinet/in.h was not contained by default in my compiler libraries so I will include it with the release to ease the process of compiling for others that may not have it by default.
-
Update:
Here is just a sample executable of what will soon come later. I have 20 instructions emulated now, but they are untested. The emulator accepts the file "spectrum.data" as the compiled source code to be ran with addresses starting at 0xA4000000. So far with my test program, the instructions do not seem to work properly. The PC does increment by 2 with every instruction though. Displayed is the current speed and the contents of R0-R15. Right now the text just scrolls once per second, but I will soon write my function for non scrolling text. If you need any additional debugging tools or a section of the source, feel free to ask because I could quickly supply that. btw, The speed seems really slow for me. My computer is slow to begin with, but I'm averaging 550 Khz at the moment :P
Instructions: //sorry, I was too lazy to rewrite them here so I just ripped them from the source
#define ADD_v 0x300C
#define MOVi_v 0xE000
#define ADDi_v 0x7000
#define MOVLi_v 0xD000
#define MOVr_v 0x6003
#define MOVLin_v 0x2002
#define MOVLim_v 0x6002
#define MOVLpush_v 0x2006
#define MOVLpop_v 0x6006
#define CMPEQr_v 0x3000
#define DT_v 0x4010
#define SUB_v 0x3008
#define ANDr_v 0x2009
#define NOT_v 0x6007
#define ORr_v 0x200B
#define TSTr_v 0x2008
#define XORr_v 0x200A
#define BF_v 0x8B00
#define BT_v 0x8D00
#define NOP_v 0x0009
#define END_v 0xFFFF
#define PAUSE_v 0xFFFE
-
Once again sorry for the triple post, but I have found the part that is heavily slowing the code down.
bool end = true; //if false then end execution
int speed; //speed in Hz
int tempspeed = time(0); //second counter
while (end) //main loop
{
cout << " \b"; //space then backspace for every command. Program fails without it ?
end = decode(); //execution. returns if false if code ends
speed++; //increments speed in Hz for every instruction
if (tempspeed != time(0); //checks if timer has changed
{
display_reg(speed); // shows content of registers and speed
speed = 0; //resets variables
tempspeed = time(0);
}
}This is a section of the main function. The slowdown comes from the lone cout statement that has to run with every loop. For some reason if I remove it, the program then has a fatal error as soon as it boots up.
-
Here it is. The first official release. Included is a sample program "spectrum.data" that repeatedly increments R0 and R1 until you quit the application. For now no fancy graphics, just the standard console screen. Also only 20 instructions are supported with no documentation!! I guarantee you that better versions will soon follow. Also for now the speed is quite slow, but it will get faster later. I have also included the code so you can compile it for other systems. In later releases I will include the linux and mac executable, but for now only windows. So feel free to dissect the code and find any bugs. I'm almost certain there are plenty. :P
-
Cool to see new progress. I assume we can do nothing like on the calc yet, right? (Noticing the lack of an interface or something)
-
Cool to see new progress. I assume we can do nothing like on the calc yet, right? (Noticing the lack of an interface or something)
It doesn't support the OS and most add-ins, since it only emulates a few instructions, and none of the screen/keys/flash AFAIK.
-
Ok thanks for the info.
/me can't wait til we know everything about the calc so we have a full emu like WabbitEmu. :love:
-
I decided to make a timeline on how progress for the emulator will go.
1. incorporate about 20 instructions along with a memory model. include a simple debugging interface (testing phase)
2. incorporate somewhere between 50-80 instructions with an advanced debugging interface. include a simple screen mapped to the vram. include multi threading
3. incorporate all of the SH3 instructions. begin attaching important peripherals such as MMU, FRQCR, and ports. add support for rom memory
4. attach all standard peripherals used by the Prizm. Begin support for Prizm unique peripherals ie LCD driver, add support for the Prizm specific opcodes, incorporate full keyboard emulation
5. Include all peripherals used by the Prizm, begin support for serial port (including sound), usb port. Allow FAT32 communication between the emulator and the host computer. Advanced gui support now incorporated with a full suite of advanced debugging tools. Include real time disassembler and hex editor. First version of plug in scripting language to allow users to create and distribute their own apps that make use of the emulators resources to allow extended functionalities.
6. First stable release
And of course each release number includes sub-releases that patch bugs, add minor updates, and include optimizations. The next scheduled release is for this weekend and will include a new test program that uses all of the available instructions, linux executable, major optimizations, and documentation on how to create your own programs. Currently on the version that I'm using (not the release a few posts up) I'm getting speeds of twice the current release.
-
Will it work through command line or will we just double-click a file and immediately launch the emu after selecting an OS/ROM?
-
*Super Necro Post*
Too bad this never got finished. :/ :(
It would have been nice to have a Prizm emulator other than the Manager. :P