Well right now I don't even have a prizm, my main goal was to make it so that a GCC based tool chain would be available for cross platform development and so that we would not be dependent on Casio's fx-9860 sdk since it requires you to have a serial to obtain.
Qwerty do we have C syntax for that as well? And a name, official or otherwise?
Jonimus, I the official name is PrintMiniGlyph(), which doesn't appear to be listed in your SDK toolchain.
No it is not, I seem to be missing quite a few of them, really if I could get an up to date listing to generate my lib from that would be the best, but right now I don't really have any good way to do that. I am trying to find where SimonLothar has the listing in his SDK but I can't seem to find it all I know is that for him the libs are generated on the first build and I'd like to get a similar setup for the GCC SDK if possible.
It looks like for the standard C library routines Simon just rips them out of the fx9860 library but I can't really do that but I might look into newlib or similar to cover those through GCC. Also I still cannot tell where the list of syscalls is that you use to make the headers and the lib, I really would like to be able to verify I am not missing any in the GCC setup so those users are not left out.
TheStorm wrote:
,,,I still cannot tell where the list of syscalls is that you use to make the headers and the lib, I really would like to be able to verify I am not missing any in the GCC setup so those users are not left out.
The verified syscalls are listed (including the interfaces) in BaseOptions.ini Section [vleSysCalls]in directory BaseOptions.
Thanks, I'll see if i can whip up a sed script or similar to allow me to take that and turn it into something I can use with GCC.
About the serial port, port Q doesn't seem to control the line status as I've seen so far, but as a note the serial controller has built in sound functions which means that the cpu doesn't have to devote all of its power to turning the lines on and off. For data it includes two protocols which I'll have to check on, but I know one of them could be ported to the 83+ without to much difficulty.
And onto the CPG which controls the frequency of the cpu and other devices. The CPG matches the 7730 version which means that clock speeds of 220 Mhz are possible in software. And if peripherals cannot manage those high speeds, they each have dividers available to use. Basically a base frequency is produced by the internal resonator at 29 Mhz, then it passes through the PLL which can multiply it by x1, x2, x4, x8, or x16. There is also a slow mode for under 150 Mhz which divides that frequency by 2. Then after that the signal is split into clocks for the SuperHWayBus which controls all the perpherals, the BSC which controls memory, and one for the cpu frequency. Each of those signals goes to its own divider where it can be divided by /1, /2, /4, /8, or /16. This allows high speeds in some areas while slower in other areas. Now at boot the OS writes $C1000000 to the FRQCR which corresponds to slow mode, x2 multiplier, and no division. This means a speed of 29 Mhz, it is increased though when an app is ran.
I'm still mostly interested in making the Prizm conform to the CALCnet protocol, since it has more CPU power to work around the weaker calculators' limitations, but that's some great information. And I am extremely interested in this sound functionality you're mentioning. And frequency control! That's awesome!
z80man wrote:
About the serial port, port Q doesn't seem to control the line status...
You are right. The registers responsible are not at all documented. The port configuration of the 7305 is very strange, does not conform to any SH processor, which documentation I read up to now, but in spite of that, accessing the serial i/o-pins directly is possible.
http://ourl.ca/9205/218794
z80man wrote:
Now at boot the OS writes $C1000000 to the FRQCR...
Where did you find that? I searched the whole OS (and BIOS) and found only the values 0x8F101103 or 0x8F102203, which are written to FRQCR several times. But these values do not conform to the 7730-documentation. Perhaps they mixed up the bits a bit to prevent attemps of overclocking.
SimonLothar wrote:
z80man wrote:
About the serial port, port Q doesn't seem to control the line status...
You are right. The registers responsible are not at all documented. The port configuration of the 7305 is very strange, does not conform to any SH processor, which documentation I read up to now, but in spite of that, accessing the serial i/o-pins directly is possible.
http://ourl.ca/9205/218794
z80man wrote:
Now at boot the OS writes $C1000000 to the FRQCR...
Where did you find that? I searched the whole OS (and BIOS) and found only the values 0x8F101103 or 0x8F102203, which are written to FRQCR several times. But these values do not conform to the 7730-documentation. Perhaps they mixed up the bits a bit to prevent attemps of overclocking.
Simon, based on that posts' contents:
Quote:
At first the outer gate has to be opened:
Set bit 3 of port 0xA4050162 to output mode, t. i. set control register 0xA4050142 accordingly.
Set bit 3 and bit 2 of port 0xA4050162. Do not ask why bit 2 has to be set, too. I do not know.
How to control the output of the serial transmit pin:
Set bit 2 of port 0xA4050130 to output mode, t. i. set control register 0xA4050110 accordingly.
Set or clear bit 2 of port 0xA4050130 to control the serial transmit pin state.
How to read the state of the serial receive pin:
Set bit 3 of port 0xA4050130 to input mode, t. i. set control register 0xA4050110 accordingly.
Read port 0xA4050130 and isolate bit 3 to obtain the serial receive pin state.
Does that mean that one pin is only able to send, and the other is only able to receive, as in standard RS232? It's not two bidirectional pins like the TIs? If so, then that puts a big cramp in both communication and sound programs.
It's not all bad with the serial. Yes we can't communicate is the same way as we could as on the 83+, but the sound functionality is still possible. I'm currently reading the 54 page manual on controlling the sound CODEC on the 7730. I'll post the results of what I learned tomorrow.
z80man wrote:
It's not all bad with the serial. Yes we can't communicate is the same way as we could as on the 83+, but the sound functionality is still possible. I'm currently reading the 54 page manual on controlling the sound CODEC on the 7730. I'll post the results of what I learned tomorrow.
Yeah, but if we can only transmit on one wire, that means we're limited to at best monophonic sound, although we could probably do a few channels.
I'm still working to document the SIOF and I don't want to post any details until I've tested it. The basic idea of the SIOF is that its primary purpose is for playing audio in a .wav format. The data to be played can be loaded manually or can be done by DMAC functions. What I found most interesting was that interrupts can be toggled for the DMAC to send new data to the SIOF once it's played its cache. These interrupts do not interrupt your code but toggle an external function. It appears to be possible in the future to create a function that will play an audio file and will continue to play while your code still runs as normal. The only slowdown this function would have is if the DMAC and the cpu access the ram at the same time, but that is rare as most cpu operations are done in the cache.
Also to note is that the SIOF can work is the reverse and can take audio input too. SO instead of reading data from a file it saves data to one. It also appears that the SIOF "might" be able to allow low-level 2 line input output.
KermMartian wrote:
z80man wrote:
It's not all bad with the serial. Yes we can't communicate is the same way as we could as on the 83+, but the sound functionality is still possible. I'm currently reading the 54 page manual on controlling the sound CODEC on the 7730. I'll post the results of what I learned tomorrow.
Yeah, but if we can only transmit on one wire, that means we're limited to at best monophonic sound, although we could probably do a few channels.
And presumably impair a CN2.2 implementation?
Very severely impair a CN2.2 implementation, I should say.
might as well share some things I found out about the prizm the past few days working with Raptor:
OS_InnerWait_ms takes a milliseconds parameter for how long to pause program execution, and is fairly accurate -- except it can't take values over 1000 (one second). Anything over 1000 milliseconds will pause for about 5 millisconds instead. The solution to pausing over 1 second is to call it many times in increments of 1000 or so, or use something like this:
Code: inline void pausems(int ms) {
for(ms; ms>0; ms-=1000) {
OS_InnerWait_ms((ms>=1000?1000:ms%1000)-2);
}
}
Another thing, are the modes for the Bdisp_Fill_VRAM(int color, int mode) syscall (from what I saw, this is currently undocumented for the modes). Color, of course, is any 16bit color in rgb:5-6-5 format, and mode can be 1, 2 or 3 (there might be more modes, but I doubt it and even if there are I probably won't find them). Mode 0 does nothing to clear the screen. Mode 1 clears everything with the give color, except the top row where the usual PrintXY Y coordinate is 1 (so, when the small menu thing with the battery level on the left and the "hourglass" thing on the right are present, they are not cleared by the syscall). Mode 2 clears in a "widescreen" type of view (like mode 1, doesn't clear the top printXY row, but also doesn't clear the bottom one either; useful for keeping a small menu at the bottom free from clearing) -- if you only need the middle 6 printXY rows of VRAM, then use this, it is a *lot* faster than other modes, for obvious reasons. Finally, mode 3 clears the entire screen with that color. Some defines for the modes I made, for use with this syscall:
Code: #define CLEAR_MODE_BOTTOM 1
#define CLEAR_MODE_WIDESCREEN 2
#define CLEAR_MODE_FULLSCREEN 3
#define CLEAR_MODE_NONE 0
And the Bdisp_Fill_VRAM_2(int color) syscall that is its brother seems to just do the same as Bdisp_Fill_VRAM, but automatically in mode 2 (widescreen).
EDIT: Bdisp_Fill_VRAM in mode CLEAR_MODE_FULLSCREEN is pretty much as fast as this, except takes a color instead of making everything just black (just for speed comparison):
Code: for(int i = 0; i < LCD_WIDTH_PX*LCD_HEIGHT_PX/2; i++) {
*(int*)((int*)0xA8000000+i) = 0;
}
I would like try the overclocking code, but I not found the "iodefine.h" file. Where can i find it?
PierrotLL wrote:
I would like try the overclocking code, but I not found the "iodefine.h" file. Where can i find it?
I just managed to find the 7705 SH3's iodefine.h file online after a very long time searching, though I'm pretty sure I'm legally unable to distribute it, so I'm at this very moment trying to make a standalone routine that allows you to change the processor speed. Will post results soon 
EDIT: I don't have enough time tonight (plus I'm too lazy to try to do something more than once) so I'm going to post my (failed) attempt at making an overclocking routine that overclocks to 162MHz, I'll post it here:
Code: void overclock162mhz(void) {
*((unsigned short*)(0xFFFFFF84)) = 0x5a00;
*((unsigned short*)(0xFFFFFF86)) = 0x5a02;
*((unsigned short*)(0xFFFFFF80)) = 0x8210;
}
Seeming from the iodefine file, it should be correct -- though I did notice one thing wrong with it, which was that the CPG struct didn't have a WCNTC member, but rather it was the WDT struct that held it instead. Anyways, until proven guilty, I'm assuming it's okay to post the iodefine file for the 7705, so here it is, best of luck succeeding where I failed and quit
http://dl.dropbox.com/u/48618220/7705iodefine.h
Just to make sure, are we positive the Prizm uses the SH3 7705?
Thanks for the file.
About CPU, I don't know, SH7705 is used by fx-9860G. I read that Prizm CPU is in SH4-A family.
