I forked QEmu today and have been working on getting Prizm emulation added. Right now, I have cloned the existing SH7750 code into a SH7305, added the prizm as a new machine, mapped the flash chip in the prizm emulated (built-in common flash), and have attached a sh4a-specific gdb to qemu and have been stepping through the boot sequence.

More could have been done, except I am still orienting myself with qemu as well as working around some quirks (debug messages to stderr not printing, thinking none of the code was running).

I have set up a page on wikiprizm as a call to get a centralized location for peripheral documentation needed for basic emulation. I know that there's information scattered around, but there isn't one stop that has a list of all known and unknown peripherals in the prizm. I encourage anyone with documentation or with a working prizm that can experiment and document their findings to look at this wiki article.

Not much to show, other than me failing to get the flash chip mapped to the right stop (mapped an alias to 0xA4000000, which is for peripherals. On the plus side, I saw writes to some of the SH7724 peripherals as well as unknowns, documented).

Things will start to kick off once the core of the SH7305 is implemented, should let things like the LCD, keyboard, etc. get added smoothly.

I will update this post once I push my changes to github.

<edit>

Once the source is put up, I encourage anyone able to contribute to do so, either with code, documentation, comments, notes, etc..

<edit>

Current changes have been pushed to https://github.com/AHelper/qemu

By peripherals, do you also mean things such as the serial port, USB, display, etc. that are connected to the core but not physically close to it? I am only asking because important addresses for some of these are known (for example, geekboy just asked me about the ones for the serial port on the Prizm, in order to get direct serial address from a future payload), and it would make sense to list all the addresses in one page, or alternatively (and I think this makes more sense), list the addresses for each thing on their page using a template or something, then with some wiki magic show them all in the Peripherals page along with links to the detailed pages for each thing.

At this point, both. Having documentation about physical hardware would be nice (If there was a nice breakdown on how to use the LCD and differences from the r61509 manual that is available) to get code added for emulation.

Wiki magic is always welcome, I'll try my hand at it later on.

I suppose you already know about the "fx-MPUs" page of Simon's documentation, where many addresses are listed? Hopefully I'll get to adding that information to the wiki one of these days.

RE: wiki magic. The last time I tried some "magic" (which was actually something simple, formatting-related if I remember correctly), I was stopped/slowed down by the fact that the Mediawiki version of the wiki is very old and the only documentation I could find appears to be for much more powerful and recent Mediawiki versions. Perhaps we should bother the people responsible to update it... but last I heard, I remember there were some technical problems (related to plugins?) that were making the upgrade hard.

WikiPrizm is on a very up-to-date LTS version of Mediawiki (version info).

@gbl08ma: Yup, I do know about that section. I have yet to go through and pick out some of the parts that don't quite fit the SH7724 documentation.

I just added a small change to the emulator that will log all unknown memory accesses. That will at least help log unknown peripherals and such.

@KermM, would you be open to adding on to mediawiki?

Using that log, I have been documenting more unknown peripheral accesses.

I have the foundation for getting RTC and CPG emulation, with the R64CNT register in the RTC correctly emulated so far. Looking at getting more peripherals in order to get the bootloader to move further along as it keeps hitting loops checking the values of registers that I don't have implemented yet.

FWIW, that's also how nspire_emu was implemented (beyond some initial minimum, I guess), one unknown peripheral access at the time.
TI's OS exercises less of the MMU than Linux does, so IIRC, running the Nspire port of Linux properly required some improvements to nspire_emu.

Thankfully qemu already has a SH4a core implemented along with a few peripherals in the SH7750, so I don't need to touch the MMU at all right now. But catching unknown accesses, mapping to known peripherals, then adding a peripheral definition file to the sh4 hardware sources is what's been moving the emulation forward (along with documenting addresses that don't match any known peripherals. Those will be "fun" to deal with).

I have the CMT implemented, testing it right now.

<edit>

Trying to hunt down a peripheral that uses 0xfe3c0000/0xfe3c0210 (I have also seen 0xfe2c0000), causing issues booting :/

Some considerations regarding what happened since I went offline yesterday:

- The giant memory regions at 0xFE200000, 0xFE240000, ... 0xFE380000 you documented on the Peripherals page do not appear to be writable or have any content on the official emulator, and when I tried to read (not write) them (actually I only tried 0xFE380000) on my only working real device with INSIGHT, the calculator halted (but only after the address input message box went away and the screen was redrawn at the new memory location, showing it's empty), giving me some moments of tachycardia which alleviated after I pressed the reboot button and the calculator came back intact (so far, at least). Again, I repeat, the SH7305 contains (besides the usual blue smoke) some *magic*! And looks like, as usual, the emulator is accurate in some things, but not to that point (I believe the difference may be that the emulator is more tolerant to unaligned accesses to some addresses).

- If the first on-chip RAM area gets written and read by the bootloader that might be bad news, since I am using them in at least my image viewer. Let's hope it's just the bootloader doing a memory check or using it for some buffer that has no importance once the OS boots.

- Please note that the bootloader checks the OS for integrity and will automatically enter OS emergency update mode if it doesn't find the proper OS "CASIOWIN" string and OS checksum(s), and in that case it definitely uses the LCD. If you don't have the OS part in the ROM of the emulator, some of the behavior you have been seeing might be relative to the updater path and not to the normal boot process. In the "normal" boot path, the emulator would only use the LCD (if at all) to turn it on and make it white, then eventually display the busy indicator by calling a syscall on the OS after it has checked the OS integrity (I hope), or otherwise it might have a busy indicator copy for its own use.

- The calculator turns on by itself (cold boot, of course) once the batteries are put in.

- When rebooting my real device today, there is definitely enough wait time, before the LCD brightness is set to the level I chose, to allow 4.5 seconds to pass. This wait time might be increased in 001V04 / Macronix calculators for some reason, giving the additional one second of boot time.

I recall from my experience with trying to operate a Prizm low on batteries, that often the screen would light up for four seconds or so along with the busy indicator... only to turn off after that. But I'm not sure that's really due to the bootloader/OS checking the battery level and cutting off power for safety, or because it indeed is too low for the CPU and peripherals to keep running and some lower-level mechanism takes care of halting everything.

- RE: "So, there is a subperipheral of the sound processing peripheral apparently being used by the bootcode", "huh, it sets up port A". If by "sound processing peripheral" you mean the ADC, then that's probably to check the battery voltage, which is something that makes sense in the bootloader. According to Simon's docs, main battery voltage is checked using the channel A of the ADC (at 0xA4610080; in previous models with backup battery, channel C was also used).
If you mean the DAC, then I don't know. What I know for sure is that the SH7305 has a DAC, because as I was told:

...with this, I think the existence of all the audio stuff is explained, and while I don't see why the bootloader could be initializing it, it can be just a matter of not wanting to leave hardware uninitialized. It would be interesting to see the compare the bootloader of these dictionaries, of the Prizm and of the fx-CP400, since all of these appear to use the SH7305.

- I will have to explore these a bit more

- This is right before peripherals get initialized (there are 2 large initialization blocks that I see in the bootloader so far, this is before the second block which sets up most peripherals). I don't know if these regions are actually used

- Indeed, I haven't focused on seeing what the bootloader is doing from a top-level aspect, just from raw accesses (I don't have logging set up for seeing if it reads the OS). And I don't have a complete ROM dump of the calc, mainly because I can always get the OS by other means (I have the first 4MB dumped). Trying to get to emergency OS updating right away is actually a good thing because I'll be able to identify the USB peripheral accesses.

- Thanks, couldn't remember that part

- The 4.5 seconds of waiting was done multiple time for me. I can get you the address of the function that does the waiting as well as the one that calls it multiple times.

- When I said sound processing unit, I meant the actual SPU2. From what I can tell, you only need that if you want to do hardware audio format decompression (or compression?). For raw audio, the FSI peripheral streams audio output (linux kernel has a driver for this, apparently works fine playing audio). This should be explored on a real prizm, not sure if you can access the IO port in the emulator or if the FSI is configured properly there.

=====

I'm switching focus back to school-related things, so progress on this will drop out for a short while. I will get the DMAC and INTC set up eventually. I will still need to find documentation on how the LCD gets set up and configured.

It's been a long time...

Lately there has been some interest in an open-source Prizm emulator, as right now we still only have Casio's proprietary emulator, which has all the known limitations and a big drawback: its price.
See for example https://www.cemetech.net/forum/viewtopic.php?p=250283#250283 . The topic has also been brought up on other forums and private messaging.

Apparently there's general consensus that the creation of a community-made emulator is likely to breathe new life into the Prizm development community; whether that would really happen, no one can tell... if such effort isn't paired with a refresh of development tools (IMO that would involve fixing all pending libfxcg issues and making the installation of the toolchain easier), I doubt an emulator alone will make much difference.

Time for a message from our sponsors... The Prizm is a great platform, featuring a color screen, support for C and (partial) C+, much more RAM than the Z80/eZ80 color calcs, relatively big storage... DEVELOPERS DEVELOPERS DEVELOPERS

One of the things that was going on when this project was paused/abandoned was the identification of all the peripherals in the Prizm CPU and their memory mappings. I have good news: some time ago, I noticed Simon Lothar released the complete list of peripherals and their addresses in the latest version of his docs.

I didn't check it all, but his findings were consistent with what we already had documented in the wiki. I believe that from this it's fairly easy to map the peripherals to those present in other Renesas cores; after that, only Casio's custom modules would be missing, but I'm confident the Prizm doesn't use these much and that, for a start, they wouldn't even be needed.

I'm not very interested in looking further into this if there is little interest; I doubt I will be able to do anything alone and if the public for this sort of thing would be big enough to justify such a big effort. (In other words, I have better things to do with my summer than waste it on Prizm stuff, for less than 10 people to enjoy and subsequently forget). I'm not sure AHelper is interested in coming back to this project, but I doubt it. Waiting for feedback from the community...

The main issues that hindered PRIZM development and deterred people from programming for that calculator IMHO are the following:

-BASIC is way too slow and limited. Granted, there is Lua, but it doesn't come bundled with the calculator by default.
-No Asm(), OpenLib/ExecLib command nor parser hooks for libraries such as CE Textlib, Sprites, Celtic and xLIBCE.
-No community emulator with debugging features. This is what hindered CE dev the most
-The calculator costs twice as much as the TI-83 Premium CE in France, which is where Casio calculator development is the strongest.
-Limited market share, especially outside France and even moreso since the color TI z80/ez80 calculators came out.
-Terrible Linux and 64-bit Windows OS support for years.
-SourceCoder lacks support for opening multiple Casio programs at a time. This can be a problem for elaborate BASIC programs (although I haven't checked if the Goto subroutines trick works)

There would probably be an higher amount of interest if you cross-posted this on multiple sites (especially Planète-Casio), but it is not 100% guaranteed, plus most people there would probably use the emulator mainly to test their BASIC games rather than as a C debugging tool. I myself would definitively like to be able to use SourceCoder, export all First Fantasy programs in a single click like with ez80/z80 BASIC programs and then quickly drag and drop them into the emulator screen without having to send them to my calculator over and over. But of course, the ones who would benefit the most from such emulator are C and ASM programmers.

It is more or less general knowledge that the BASIC on Casio calculators sucks, and most users are aware than any worthy games and programs need the installation of add-ins. There's not much we can do about the BASIC quality, short of overclocking the calculator, but even that only deals with the speed problems. I also don't think it would be of much use if Casio had included a Asm() command on their BASIC, because their calculators use SuperH processors which were definitely not meant to be programmed in hand-crafted assembly, being an architecture way more complex than Z80.

With this said, this doesn't stop people from developing better custom languages. Most people are already used to having to install add-ins, and add-ins can be transferred between calculators just like basic programs, so the problem of these languages not being built-in to the OS is not that high.
For one, I'd like to see a finished and polished Lua port supersede LuaZM. There are also other languages tailored to embedded systems which can be of interest. And of course, I'm sure the Prizm can cope with an emulator for at least one major game handheld.

Your points about the calculator price and market share make sense, but they only explain why we're not seeing new Prizm users. They don't explain why even current users have stopped caring about it, nor why libfxcg (and many other projects) was mostly abandoned, etc. (Yes, I'm aware of the fact that abandoned projects is a problem common across many calculators. Some years ago I even remember discussing how a contest could be made to motivate users to complete unfinished projects).

I'm not sure what you mean by terrible Windows and Linux support. The calculator appears as mass storage when connected to any of my Windows and Linux machines, no further action necessary (in fact, it's better in Linux because on the first connection Windows always looks for drivers even though generic ones would work). The emulators work fine under Wine.

It appears that despite the low activity, Cemetech ends up having more Prizm activity than any other forum, even Casio-focused ones, hence why I only bother to post about Prizm stuff here. In fact, with the exception of those months at the beginning when Omnimaga had more Prizm activity, Cemetech always had more than any other website.

It's a shame there's so little Prizm development... I've been trying to get into it myself lately, but it's been a bit hard to find the time and motivation for it. I'm not sure how it could be possible to make the community more interested, but personally, I would appreciate a proper emulator. Transferring builds to a real calculator is a hassle when doing rapid changes because of the time it takes to connect and transfer files, and I can imagine I would have even more use of an emulator when I get to the stage where I really need to debug something in a program.

One of these days I might try to compile AHelper's fork of QEMU, and see what I can do in terms of adding SH7305 peripherals, now that we know what peripherals it has and what addresses they are mapped to. But it probably requires more dabbling around the Renesas docs than I'm willing to, plus lots of learning about QEMU's internals, and I have way more exciting projects going on. Let's see if I can make this one exciting too...

My view is that if we could get an absolutely functioning compiler online with facility to upload source files for existing add-ins for anyone to be able to play with and compile without having to go through any setup of their own hardware that would advance the whole Prizm development both in number of developers and diversity of add-ins. In turn it would also make so many people advance their C coding etc skills.

I have one and would develop for it, but I simply don't know how. An emulator would be nice, but so would a link to a tutorial

Hi Luxen, there is an outdated material here https://www.cemetech.net/forum/viewtopic.php?t=6133 with links to prizm wiki write ups etc - also search for sdk in the prizm forum for tips for specific platforms which may help you a bit.

I almost succeeded with my windows setup but it's not 100% - more advanced developers for prizm here use linux but i cannot match those setups. That's why i was hoping to have an online compiler capable of such things as gbl08ma can do.

Good luck and post on the sdk etc forums if you have any problems with libs or makefiles - I struggled a lot with those things