Compiling stuff for Prizm

[Lionel Debroux]

Looks pretty nice, congratulations

I wonder when someone will be able tor replicate this bouncing boxes demo on the Nspire (CAS) CX, which is extremely likely to be even more locked down than the earlier Nspire models...

[SimonLothar]

I totally like the display routine!

So? Then if you like it crowded, try this...

@DJ_O: it is C, not assembler!

If something has been wrong with this post, I'd like to apologize.
English is not my mother tongue, so perhaps the post sounded rude or impolite.
Never meant to be.

[DJ Omnimaga]

It's ok I understand. I think the part people could have found rude is only the "!" part, but from a language to another people have different ways to say some things. An example is how in French posting all-caps words is considered as yelling, while in USA it's considered as emphasis.

I am curious how far we'll be able to push the Prizm when display routines like IonFastCopy are written.

[m1ac4]

I am curious how far we'll be able to push the Prizm when display routines like IonFastCopy are written.

Imagine actually being able to use real color textures in a 3D engine.  Its kinda hard to distinguish texture in 4-color greyscale but imagine being able to use real color texture in a game.  If you can get a routine to work fast enough then you can produce some amazing games with just that alone.
Personally, I can entertain myself for a long time just by staring at the bouncing rectangles.  Imagine what games developed later on would do.

[DJ Omnimaga]

Personally, what I'm thinking of at first is some games similar to what GBA ones look like. It would be nice to see someone attempt a color raycaster, though. Also the great thing with the Prizm screen is that there's no blur. When I tried the version of Insight with fewer squares but higher framerate, it looked like on a real LCD screen.

[Mario]

ah... CASIO I haven't used mine for a while I use ti-84 plus SE

[Ashbad]

ah... CASIO I haven't used mine for a while I use ti-84 plus SE

same, I never even tried out a casio calc before but maybe soon I'll stop touching TI calcs in favor of the more free-to-program Casio calcs

also, Mario, first time I've seen you here -- you enjoying your stay here on the forums?

[SimonLothar]

miniSDK (version 1.04).
New with version 1.04: SDK equipped with a GUI, to configure the projects more conveniently. The documentation of which resides in the included HTMLHELP-file (fx_calculators_SuperH_based.chm; search for "SDK, getting started"); two new functions in INSIGHT to demonstrate the speed difference between direct draw and VRAM-DMAC.

EDIT:
Attachment removed.
New version: http://www.omnimaga.org/index.php?topic=6608.msg147037#msg147037

[z80man]

Whoa how are you doing all of this? That's pretty cool, but how do we replicate this in our programs? Last time I checked the VRAM-DMAC was still undocumented. What I think we need is a long explanation of how insight exactly works and how you created all of those routines. I don't mean to put any pressure on you Simon, but me and I assume many others are starting to fall behind on all of these new finds. I have several projects that I wish to start, but I cannot not start them yet as I don't understand all of the inner workings. For me as an asm coder it is important to know this because I can't rely on C routines. Also a few of us have no prior experience with other Casio calcs, like me, and are unfamiliar with the previous SDK and syscalls. An explanation from the ground up would be very helpful.

[SimonLothar]

For me as an asm coder it is important to know this because I can't rely on C routines.

ASM and C/C++ are both important tools, if you want to program the Prizm (as well as the fx-9860 series). I daresay it is not possible to avoid either of them. Of course you have to decide carefully, which of both is the appropriate tool in a certain situation. Though, mostly it will be C. Anyhow the next version of the miniSDK will accept assembler-source-modules as well.

What I think we need is a long explanation of how insight exactly works

INSIGHT is a C-program. Therefore a pre-condition to understand INSIGHT is the knowledge of C. I am sorry not to have a better message. But myhap it is not this bad, if you should decide to learn C.

and syscalls. An explanation from the ground up would be very helpful

I tried to explain the use of syscalls from out of assembler here:
http://www.omnimaga.org/index.php?topic=5610.msg124495#msg124495

...Last time I checked the VRAM-DMAC was still undocumented.

I documented the VRAM-DMAC-syscalls 0x025F and 0x0260 the first time in the HTMLHELP-file of miniSDK version 1.03.

[DJ Omnimaga]

Wow I tried this last night and I was amazed. Somebody should try making a scrolling tilemap demo to show what could be done.

[z80man]

Thanks for pointing out the help file Simon. I had trouble opening it at first due to Windows 7 incompatibilities, but soon fixed that using 7zip. I do have a small problem now that involves the fx 9860g SDK. Apparently to download that form Casio's site you must own an fx 9860g which I do not have. Hopefully this shouldn't be too much of a problem once I finish my assembler.

In other things. What I meant to say by the Insight explanation is if you could add comments to the code. I do already know C, but it can be hard to read without comments.

Lastly with the assembler/IDE I'm working on. I'm designing it to be much more advanced than the standard gcc assembler.  New features that it will include are a special type of macro (too difficult to explain here), namespaces, structs, thread support, self-modifying code support, interrupts/exception handling,  auto opts, and classes/objects. The IDE will be like any standard coding IDE with syntax highlighting and all that sort, but will add certain features such as helping the coder establish code and data blocks with proper displacements along with 16 bit color tools. At the moment this project is in development and early versions will be available soon.

[DJ Omnimaga]

Glad to see new updates and attempts at simplifying Prizm dev.

[z80man]

Okay I'm working on getting a shell up and running now, but I can't find a syscall that meets one of my needs. What I need to do is to create a list of the files contained in a directory. None of the MCS or Bfile syscalls seem to accomplish this so I'm wondering if such call dos exist, is it undocumented or do I need to write a routine to find this information.

The other thing I was wondering about was if it is better to do a syscall using the 80020070 address or to just call directly to the the syscall. My only concern with calling directly was that some OS's could use different locations for the calls making some older programs unusable.

[SimonLothar]

Okay I'm working on getting a shell up and running now, but I can't find a syscall that meets one of my needs. What I need to do is to create a list of the files contained in a directory. None of the MCS or Bfile syscalls seem to accomplish this so I'm wondering if such call dos exist, is it undocumented or do I need to write a routine to find this information.

These are the syscalls for enumerating the storage memory:

syscall 0x1DB6: int Bfile_FindFirst( const unsigned short *filename, int*FindHandle, FONTCHARACTER *foundfile, FILE_INFO *fileinfo );

FONTCHARACTER is unsigned short in the current implementation (as in the legacy systems).
typedef struct tag_FILE_INFO
{
    unsigned short id;
    unsigned short type;
    unsigned long fsize;
    unsigned long dsize;
    unsigned int property;
    unsigned long address;
} FILE_INFO;
The members of the FILE_INFO-struct are not filled as documented in the legacy SDK!
The function checks the length of the filename first. In case it should be greater than 0x10A the function returns errorcode -3.
Every FindHandle has to be closed with Bfile_FindClose, if is is not needed any more!
syscall 0x1DB8: int Bfile_FindNext( int FindHandle, FONTCHARACTER *foundfile, FILE_INFO *fileinfo );
syscall 0x1DBA: int Bfile_FindClose( int FindHandle );

Concerning enumeration of the MCS: I have still to check, if it can be done in the same fashion like with the legacy systems. But the interesting thing is, that Bfile_FindFirst returns "@MainMem" as found file with a search pattern "\\fls0\".

The other thing I was wondering about was if it is better to do a syscall using the 80020070 address or to just call directly to the the syscall. My only concern with calling directly was that some OS's could use different locations for the calls making some older programs unusable.

At any rate the use of absolute addresses should be avoided.