fx-9860G Edit 1.60 Crashes

[toml_12953 Profile]

I can't start the fx-9860G editor. I get a system error with the choice to reboot or initialize. Is it supposed to be able to in on an fx-9860G II SD?

[SimonLothar]

I checked it with a fx-9750GII SH-4 (OS 2.02.0201): successful.
And with a fx-9860GII SD SH-3 (OS 2.00.0200): successful.
And with a fx-9860GII SD SH-4 (OS 2.09.0201): System ERROR.

Since OS version 2.00 they ceased to support certain syscalls. http://casiopeia.net/forum/viewtopic.php?f=11&t=1742&start=10#p14448).
Seems to be an OS version problem. Which OS do you use? What processor (SH-3 or SH-4)?

[toml_12953 Profile]

I checked it with a fx-9750GII SH-4 (OS 2.02.0201): successful.
And with a fx-9860GII SD SH-3 (OS 2.00.0200): successful.
And with a fx-9860GII SD SH-4 (OS 2.09.0201): System ERROR.

Since OS version 2.00 they ceased to support certain syscalls. http://casiopeia.net/forum/viewtopic.php?f=11&t=1742&start=10#p14448).
Seems to be an OS version problem. Which OS do you use? What processor (SH-3 or SH-4)?

Thanks for the quick reply!

I use the USB Power Graphic 2 fx-9860GII SD SH-4 (OS 2.09.0201)
Is there any alternative that does work on the newer calc? I tried to pm the author of Edit 1.6 but my pm gets flagged as SPAM for some reason.

Tom L

[SimonLothar]

I will try to follow the EDIT 1.6 error. It is interesting.

---

But first, I noticed another intriguing thing, while searching for the EDIT 1.6 problem.

On fx-9860 calculators, there exists a 32 KiB RAM range (physically 8801C000-88024000), which is used for stack and addin static RAM. The stack starts at 88024000 and grows down.
The addin static RAM starts at 8801C000 and is virtualized in contiguous blocks growing towards the stack. On SH-3 systems 8 KiB of this RAM is virtualized by every OS (8801C000 -> 08100000), before an addin is started.
The initialization code of an addin virtualizes additional 4 KiB (8801E000 -> 08102000).
We know the startup code, which does this job

Old startup code: Show

Code: Select all

   mov.l   #_Hmem_SetMM, r2
   mov.l   #h'08102000, r4
   mov.l   #h'8801E000, r5
   jsr      @r2
   mov.b   #h'6C, r6


Contrary to what I thought and posted every now and then, this gives 12 KiB of static RAM for an addin.
On the fx-9860 SH-4 systems the complete 32 KiB RAM range is virtualized by the OSes and could be used as static RAM by addins, as long as it does not grow into the stack, which grows down from 88024000 and as well mustn't grow into the static RAM. The programmer has to accept the responsibility for such a thing not to happen.
I first saw the complete virtualization in fx-CG-OSes, but did not recognize the consequences for fx-9860 SH-3 systems.
Of course this makes syscall 0x03FA obsolete on SH-4 systems. As it is indifferent on SH-4 systems, it can be called without harm in common sources.

It looks as if we could virtualize the complete 32 KiB RAM range on fx-9860 SH-3 sytems as well.

F. i. a first try with a modified startup code (similar to syscall 0x0012)

New startup code: Show

Code: Select all

   mov     #6, r14
   mov.l     #h'1000, r13
   mov     #0, r12
   
virtualization_loop:   
   mov.l   #_Hmem_SetMM, r2
   mov.l   #h'08102000, r4
   add      r12, r4
   mov.l   #h'8801E000, r5
   add      r12, r5
   jsr      @r2
   mov.b   #h'6C, r6
   
   dt      r14
   bf/s   virtualization_loop
   add      r13, r12



This works even on the good old fx9860G slim.

Though, one thing is a bit confusing. With SH-3 systems, the third parameter of syscall 03FA (Hmem_SetMMU) is 0x6C. This would mean - according to the SH7705-manual -, that PTEL.SZ (bit 4) is programmed to 0, giving a blocksize of 1 KiB. But actually it virtualizes 4 KiB blocks. The only explanation is, that here we have some incompatibility between SH7705 and SH7337/SH7355.

On SH-4 systems they use 0x7C, which complies to the SH7724-manual, setting PTEL.SZ0 to 1 and PTEL.SZ1 to 0, which gives 4 KiB block virtualization.

I hope, I did not overlook some problem.

[toml_12953 Profile]

I will try to follow the EDIT 1.6 error. It is interesting.

The reason I'd like a text editor is to use the on-calc C compiler, WSC. That compiler only works for text output as far as I can tell. The bouncing ball demo seems to lock up with a blank display and requites a poke in the reset hole to recover. I'd like to contact the author of that as well to see about getting an update for the newer calculators.

Tom L

[SimonLothar]

I'm still on it.
(I needed some UBC-tools to do that. I had them already coded for fx-9860G/GII SH-3 and fx-CG. Now I had to develop an UBC-tool for fx-9860GII SH-4, which took a bit more time than I expected.)

[SimonLothar]

The reason seems to be syscall 0x042E, which is not compatible on fx-9860 SH-4 calculators.
Remove the SD-card and try again, please.

[toml_12953 Profile]

The reason seems to be syscall 0x042E, which is not compatible on fx-9860 SH-4 calculators.
Remove the SD-card and try again, please.

It works when the SD card is out but shows 0 bytes free in storage memory.

Tom L

[SimonLothar]

I added a new upload (version 1.62; only the fixed G1A; http://casiopeia.net/forum/downloads.php?view=detail&df_id=154).
Refer to the original entry http://casiopeia.net/forum/downloads.php?view=detail&df_id=68 for the documentation and other information.

Changes made to EDIT.C:
I first inserted the function

Bfile_GetMediaFree2: Show

Code: Select all

/*
/*
Replacement for Bfile_GetMediaFree because of the incompatibility of syscall 0x42e on fx-9860 SH-4 OSes.
The function returns a max. freebytes of 0x7FFFFFFF.
SimonLothar. 30.09.2016
*/
int Bfile_GetMediaFree2( enum DEVICE_TYPE devicetype, int*freebytes ){
int freebytes2[2];   
int checkvalue;   
int result;
   switch( devicetype ){
      case DEVICE_MAIN_MEMORY :
      // the main memory syscall is OK
         result = Bfile_GetMediaFree( devicetype, freebytes );
         break;
      default :
      // first check, which syscall 0x42E-version is running
         freebytes2[1] = 0;
         result = Bfile_GetMediaFree( devicetype, freebytes2 );
         if ( result != 0 ) break;
         checkvalue = freebytes2[1];
         freebytes2[1] = 1;
         result = Bfile_GetMediaFree( devicetype, freebytes2 );
         if ( result != 0 ) break;
         if ( checkvalue == freebytes2[1] ){
         // here the value of freebytes2[1] has been overwritten => SH-4 OS
            if ( freebytes2[0] == 0 ) *freebytes = freebytes2[1];
            else *freebytes = 0x7FFFFFFF;
         }else{
         // here the value of freebytes2[1] has not been touched => SH-3 OS
            *freebytes = freebytes2[0];
         };
   }
   return result;
}


Then I replaced every call of Bfile_GetMediaFree by a call of Bfile_GetMediaFree2.

This version has been tested on SH-3 and SH-4 calculators.

[toml_12953 Profile]

I added a new upload (version 1.62; only the fixed G1A; [url]http://casiopeia.net/forum/downloads.php?
This version has been tested on SH-3 and SH-4 calculators.

So exactly what does this version fix? 1.60 showed 0 bytes free in storage memory and so does this one. 1.60 crashed when I had my 32GB SD card in and so does this one. Please forgive me for being so dense but I don't see any difference in execution.

For now, I've set the SDC Option to No and Edit runs since it ignores the SD card but it would be nice to be able to edit files on the SD card without having to copy them to either main or storage memory.

Tom L