59 replies to this topic

[Marco]

I was very curious about the execution speed of programs running on the flash and tested it five minutes ago. The result was great, much better than I expected: it was 88% that of programs running in the RAM. So we can use RXE for games needing high performance, too (RXE slows down about 13% only).

Maybe different calc models use different flash types with different access times and RXE execution speed would differ then - does anyone know sth. about it?

Btw. there's a way how to boost up RXE game's speed: most CPU ressources fall apart for graphical routines, esp. block filling/moving. What about copying these critical routines into RAM during runtime and call them via procedural variables then?

[dscoshpe]

My knowledge of the lower languages falls apart here, but if you know a way of writing it so that the routines are simply compiled in to the data block then they will automatically reside in RAM when the RXE is loaded.

- dscoshpe -

[Marco]

I think in Assembler this should be possible, but in (Turbo) Pascal at least there's no way to compile directly into the data block (for C probably not, too, but don't know it exactly). Unfortunately, sizeof() doesn't work for procs (in TP; C?), but no problem.

Code would look this like:

{procedure pointers}
var hline: procedure(x,y,w: integer);
     vline: procedure(x,y,h: integer);
     ...

{block with critical procedures}
procedure hlinecritical(x,y,w: integer); far;
begin
  ...
end;

procedure vlinecritical(x,y,w: integer); far;
begin
  ...
end;

... {maybe some other critical routines}

procedure dummy; {we need it as sizeof doesn't work here}
begin
end;

var criticalprocs: pointer;
     criticalprocssize: word;

begin

  {copy to RAM}
  criticalprocssize := ofs(dummy)-ofs(hlinecritical);
  getmem(criticalprocs,criticalprocssize);
  move(ptr(cseg,ofs(hlinecritical))^,criticalprocs^,criticalprocssize);

  {initialize vars}
  hline := criticalprocs;
  vline := ptr(dseg,word(criticalprocs)+ofs(vlinecritical)-ofs(hlinecritical));
  copysprites := ptr(dseg,word(criticalprocs)+ofs(copyspritescritical)-ofs(hlinecritical));
  ...
end.

Should work, but not tested

[Marco]

Tested: works



Only two things you have to watch out for: Of course the compiler assumes these procs copied to RAM later would be in original CS.

1. Thus, calling non RAM procs from a RAM proc defined in the same CS will not work, unless you also call them by procedural variables. No matter for procs defined in another unit (also system unit), as these have another CS anyways. For C this should be similar as in Pascal.

2. Data constants such as arrays or strings usual are putted to the code segment causing trouble too (you can't access them from procs copied to RAM). Solution: make them predefined variables instead of constants, that'll force the compiler to put them into data segment (DS of course stays untouched when calling a RAM proc).

Example (assume test to be called from RAM):

procedure test;
  writeln('Hello world from seg ',cseg,'!');
end;

will not work, but

const s: string = 'Hello world from seg ';

procedure test;
  writeln(s,cseg,'!');
end;

works fine.

[Marco]

Addendum to rxe execution speed issue:

You know the testings I made some month ago (you even can read it in the postings above), resulting that RXE slows down execution about 13%. Well, this tests were OK and also not surprising as the flash has longer access times than the RAM. But here's now something really surprising :

I made the tests above coming to that result with 13% with pure flash access only and all variables held in CPU regsiters to prevent getting results falsified by RAM accesses. But obviously, when NOT accessing the Flash alone only but making frequently mixed RAM/Flash acces (for example, CS in flash, DS in RAM), the program runs significant faster, even faster than when using RAM access only!

Hence, using RXE format wouldn't mean only to save memory, but also that your program will run much faster despite the longer flash access times, cause also RXE programs have no pure flash access as data segment always is held in RAM.

(Btw I discovered this by accidend when I made performance tests for the MLCafx VM's ALU; as RXE the VM ran about 21% faster than as EXE!!! And I made this test several times)

Maybe a reason for this could be that there's one controller for the RAM and one for the flash inside the calc and the CPU can send requests to both but needn't to wait until one is ready. So you have a kind of parallel working adress selection or something. I just can't imagine another explaination for it...

[dscoshpe]

I put v1.60 on the file sharing.

Plenty of new features, all are listed in the file sharing and discussed in the ReadMe.txt that comes in the package.

Also includes the fix for Marco's DFA stuff!

- dscoshpe -

[Orwell]

I tried to use dRXE to make some tests and i couldn't make any successful RXE conversions

I have tried the following tests:
* Digital Mars:
Conversion ok, works on the emulator, but crash on AFX.
* TurboC 3:
- without hack: Conversion ok, but crash on the emulator and on AFX.
- with hack: crash from dRXE during examination (Message: "Runtime Error 424; Object required")

The original prog is a simple loop waiting for the EXE key. For the dRXE crash i suppose i need some runtimes, but I don't know which ones...

I use the following options for the compilers:
DM: -2 -Aa -Ab -cpp -gg -w7 -msd -o+space
TCC: -2 -r -G -mt -O -d

My AFX's rom is 1.02.
I'd like to try the RXE system for the next version of Sonic, I think it could give some nice results

[dscoshpe]

Send both versions of the program to my email and I will take a look.

dscoshpe hotmail com

- dscoshpe -

[Orwell]

Done

[dscoshpe]

OK I tried the DM version and it seems to run fine on the calc. Launching from touche it waits for EXE' /> to be pressed and then exits. So it seems to be ok.

The TCC version does need the hack to be applied, and the error you encountered was a bug that is my fault in dRXE. When I added the feature to directly write header values I changed some things around and did not update an object that the hack routine looks at. I have fixed this. After converting and running the TCC version it does not run properly which is not surprising for Borland compiled programs. Since this program is the simplest Borland compile I have to test I'll see if I can use it to make the hack more reliable.

I'm curious as to why the DM version you made did not work, it should. Is it the first file in the drive image? If it isn't you have to relocate it to run from a position within the drive image since dRXE places it at the begining by default.

- dscoshpe -

[Orwell]

I'm curious as to why the DM version you made did not work, it should. Is it the first file in the drive image? If it isn't you have to relocate it to run from a position within the drive image since dRXE places it at the begining by default.

<{POST_SNAPBACK}>

I didn't know it had to be the first file in the drive image
My programs generally use some external files for data, so I can't easily know where the executable will be placed in the drive... Anyway, what must I change in dRXE to set the correct position?

[dscoshpe]

Yeah, because part of the program is executed directly from where it is stored the RXE has to know where it is sitting. I have dRXE automatically set this to be as the first file on the romdisk drive image.

The value labelled "Base" is what determines where the RXE believes it resides which is a segment value. By default it is 4040h. 4000h is the actual start of the drive, but because of the file system overhead the first file will not appear until 4060h. The reason it is set to 4040h in dRXE is because to accomadate drives larger than 128k for which another 20h must be added for overhead every 128k. I calculate as: (20h * (filesize / 128k)) + 4040h. I noted in dRXE that the 4040h value is misleading, this is why.

To change the location, there are some options:
1) Convert the program to reside in a different location that you have already determined.
2) If you have already converted to the default base address, you can use the "RXE Relocation Tool" under the options tab in dRXE and specify a new segment.
3) Use Add-In Packager 2.30 or greater to package your drive images since I gave it the ability to automatically figure out and update RXE files as they are relocated in an image. I would like to say I didn't test it extensibly so it may have some bugs which I can fix if they are found.
4) Change nothing and just make sure it is the first file on the drive.

In order to relocate RXE files they must be converted with dRXE 1.53 or greater since they add a "dRXE Tag" which has information about what was done in the conversion and this information is needed for relocation. I included a text file titled "Relocation.txt" in the dRXE distribution that has information about the dRXE Tag incase anyone wants to add this functionality to their own programs.

- dscoshpe -

[Orwell]

After a few days i decided to make some new tests (with correct relocation this time )... I was a bit afraid that the conversion could slow down the program a bit, since the instructions are executed in flash and not in ram, which I thought was faster...
Thus I used an old prog I had made to test the speed of my graphic libraries, and tried it again after the RXE conversion with a 24*17 sprite (with mask and clipping)
I was really amazed by the results:
EXE: 529 fps
RXE: 602 fps
Marco's observations about the speed increase were thus correct

This is really great, because a huge part of the operations in a real time game consist also of drawing every items on screen... So this means that we could certainly expect a nice speed increase in most games

[dscoshpe]

Yeah Marco's discovery about the speed increase the programs recieve has been a pleasant surprise. I myself was also expecting them to slow down based on the speed that Casio's official programs seem to run.

- dscoshpe -

[Marco]

Maybe the official Add Ins slow down the CPU (that was possible with a port but I don't remebmer which it was) in order to save battery? For menus and typing in you don't need full speed anyways but it wouldn't hurt either for the basic interpreter.

Also the internal Add Ins are executed from ROM that has slower access times than Flash (see Oliver's Guide) which has slower access times than RAM. Or they're just bad implemented...

---Edit:---

No I guess internal Add Ins are running the CPU on full speed, too. When I some time ago slowed down the CPU just one step by writing directly to this port using Hack's Edit and getting back to main menu the menu was much slower then. So probably ROM and/or bad implementation is the reason.

[dscoshpe]

I would guess bad implementation because the add-ins that get written to flash are also slower than what I would think they should be. If they are able to port all of these programs to the 9860, and if casiokaki is correct the risc cpu, then perhaps the poor performance is due to not optimizing their routines very much to save portability.

- dscoshpe -

[huhn_m]

maybe someone with a decent C decompiler should try to get the handes on the sourcecode and optimize it? I already thought about using the interrupt routines and optimizing them but I'm too lazy to check what the interrupts for the various functions are (and no, they MAINLY do not use the BIOS interrupts. I already tested that).

We could release sth. like a "SPEED OS" for the calcs. Now that would be nice

[Orwell]

During my hollydays I tried again to use the RXE system, with the new version of dRXE...
I tried to convert an executable (which was compiled with DM), but the software now crashes during the "Examine" step
When it says "Getting fix-up targets..." there is an error "Runtime Error '6': Overflow"

I tried with some other DM executables and there were no problem. I will send you the prog I tried to convert...

[dscoshpe]

Oops, yeah I think that is a bug that I caught during the last programs you sent me and I forgot to make an update.

Basically what happened was that I changed the layout of the program a little bit and didnt update everything properly. I'll put an update up as soon as possible.

- dscoshpe -