KermMartian wrote:
Qwerty.55 wrote:
There's a huge differences between "possible" and "runs fast enough to be useful." Sure, Ashbad could likely port some SNES EMU C code, but it'd probably be slow as heck on-calc. It'd be a PITA to write an emulator for the entire instruction set of the chip from scratch as well as the peripherals, though.
Ah, that's a good point. And calc84, another good point; do either of you happen to know offhand how big the SNES's RAM is?


actually, it wouldn't have to be that slow Wink Apparently the SNES runs at different speed for different operations -- normal things are ~22 MHZ, other things significantly slower. This would take more than just porting something -- a rewrite would yeild us more speed than porting an existing emulator, so we can keep it Prizm-Specific. However, while most could (and should) be done in something like C, inline assembly for small optimizations could be very useful.

though don't look at me to do an actual emulator Razz
Ashbad, but the memory thing is still prohibitive; the overhead of doing some kind of trick with ROM to compensate for the insufficient RAM would reduce speed by a huge amount, possibly a full order of magnitude, easily making it far slower than the real device.
oh sorry, I read it as '128KB', not '128MB' Razz in that case, yes.
Ashbad wrote:
oh sorry, I read it as '128KB', not '128MB' Razz in that case, yes.
It is indeed 128KB, but unless I'm mistaken the Prizm has a maximum 64KB scratch space allocatable to C programs (?).
Probably more if you allocate it at runtime, since malloc is a proper syscall (0x1F44) and not something we've implemented ourselves. You effectively get a 64k stack, but potentially more available RAM depending on what the malloc implementation does.

For all I know, it may just scribble all over the same chunk of memory we allocate to .bss and .data, but I'd hope that's not the case. The SRAM in the thing seems to be 16 megabit, so the system certainly has more than 64k available.
Oooh. I wasn't aware that we potentially had up to 2MB (assuming we trash everything that the calculator's OS is using; I suppose that would be relevant if we succeed in porting Linux or some other OS). I vote that someone write a small add-in that mallocs and displays until it can't malloc anymore.
  
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

» Go to Registration page
Page 2 of 2
» All times are UTC - 5 Hours
 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

 

Advertisement