That's great! Nice job tracking those down. I think that if you're totally bored, your next syscall project should be to try to track down the small-font routines.

C/ASM files can be a maximum of 1 MB of code and data, excluding the .g3a header.

Is there a way around this?

1) Modify the OS.
2) Use an ASM shell.
3) Use multiple programs.

Hmm, I guess that makes sense. However, I hope z80man's Walnut shell will also be formatted to work with C, otherwise I doubt many people will use it

I believe C support is already implemented

Well what is needed would be a linker script for the toolchain, unless it loads the program to the same place in ram and such then it might not actually needed.

I doubt it loads it into the same RAM, because he's planning on threading last I heard.

Just to mention we are making some progress with MMU. It doesn't appear to be exactly the TBL I've been looking for, but at 0x8804CF0C there is an array of physical addresses for the currently running app which in my case was Insight. The reason why this is not the real TBL is that the virtual page number and the page flags are missing. Also as a note these pages are each 64 kb. This would suggest that the Prizm maps as many 64 kb pages as needed to run an app up to 1 Mb.

Edit: Looking in the UTLB 0xF7000000 which is a cache the physical entry of $0116A17C which corresponds to the physical location of Insight (for my calc, your's will vary). The physical location is 0116A000 and the 17C is the page flags. I still can't find the virtual address.

z80man, on Omnimaga you were reporting that there was some progress with using the 3-pin serial port; can you tell us more about that?

Some of the OS code references addresses that are related to the SIOF and its functions. The SIOF controls serial port operations and is far superior to the primitive port control on the 83+. There are multiple channels which can send data simultaneously. Not only that but, but large buffers, interrupt controls, and automatic DMAC transfers are provided. Now the SIOF did not appear to be identical to the one on the 7730 as a few addresses were off, but it is very similar in function.

Does it allow raw control, though? For something like CALCnet to be totally inter-operable with the TI and Casio calculators, I would need raw control over the two data lines in the serial port. I guess I'll have to read up more on the SIOF and what it offers.

The Prizm-processor's serial module base address is 0xA4410000 (7705) and the register structure is the 7730's.
But I recommend to use the serial syscalls documented in fx_calculators_SuperH_based.chm. The functions are very reliable.

I'm sure they are, but they enforce some kind of standardized serial protocol, perhaps even a two-wire software flow control RS232, no? I need direct access to the lines for my prospective projects, including a sound player and a CALCnet port.

SimonLothar, do we have syscall numbers for those on the fx-CG or will they be the same as on the fx-9860? Either way can you point me to where I might find those so I can add them to the libfxcg used by my GCC based PrizmSDK?

The syscall numbers on the fx-CG are completely different compared to the fx-9860 (luckily the interfaces are not). Have a look at fx_calculators_SuperH_based.chm (contained in the mini-SDK.zip). The fx-CG serial syscalls start at number 0x1BB7. From the start page of the CHM-file go for the topic "fx-CG20" and then "Syscalls, serial".

Do you mind if I include that chm with my GCC based SDK setup, or even better would be to maybe host an editable copy of it so everyone can contribute to it?

On a related note I wanted to thank you for your research into the Prizm and for finding all the syscalls we have found so far. We all owe you a great deal of thanks for what we can do so far.

The syscalls starting at 0x1BB7 are pure serial communication functions without any protocol overhead. The protocol 7.00, which is the native fx-communication protocol, is covered by a different set of syscalls.
The direct pin access should be possible too. I suspect 7730 port Q. But that has to be verified. I'll do some experiments tomorrow.

I don't mind.


If you have any information, it would be no problem for me to add it to the CHM-file. With an appropriate reference to the originator, of course!

No need to. Syscall 0x023C.