Author Topic: Compiling stuff for Prizm  (Read 61241 times)

0 Members and 1 Guest are viewing this topic.

Offline Lionel Debroux

  • LV11 Super Veteran (Next: 3000)
  • ***********
  • Posts: 2135
  • Rating: +290/-45
    • View Profile
    • TI-Chess Team
Re: Compiling stuff for Prizm
« Reply #15 on: March 21, 2011, 04:53:48 pm »
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...
« Last Edit: March 21, 2011, 04:54:00 pm by Lionel Debroux »
Member of the TI-Chess Team.
Co-maintainer of GCC4TI (GCC4TI online documentation), TILP and TIEmu.
Co-admin of TI-Planet.

Offline SimonLothar

  • LV4 Regular (Next: 200)
  • ****
  • Posts: 129
  • Rating: +35/-1
    • View Profile
Re: Compiling stuff for Prizm
« Reply #16 on: March 21, 2011, 05:07:42 pm »
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.
I'll be back.

Offline DJ Omnimaga

  • Former TI programmer
  • CoT Emeritus
  • LV15 Omnimagician (Next: --)
  • *
  • Posts: 55927
  • Rating: +3152/-232
  • CodeWalrus founder & retired Omnimaga founder
    • View Profile
    • DJ Omnimaga Music
Re: Compiling stuff for Prizm
« Reply #17 on: March 22, 2011, 03:23:54 pm »
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.


Offline m1ac4

  • LV4 Regular (Next: 200)
  • ****
  • Posts: 106
  • Rating: +8/-0
    • View Profile
Re: Compiling stuff for Prizm
« Reply #18 on: March 22, 2011, 06:31:36 pm »
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. ;D

Offline DJ Omnimaga

  • Former TI programmer
  • CoT Emeritus
  • LV15 Omnimagician (Next: --)
  • *
  • Posts: 55927
  • Rating: +3152/-232
  • CodeWalrus founder & retired Omnimaga founder
    • View Profile
    • DJ Omnimaga Music
Re: Compiling stuff for Prizm
« Reply #19 on: March 22, 2011, 08:50:09 pm »
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

  • Guest
Re: Compiling stuff for Prizm
« Reply #20 on: March 28, 2011, 04:40:04 pm »
ah... CASIO I haven't used mine for a while I use ti-84 plus SE

Ashbad

  • Guest
Re: Compiling stuff for Prizm
« Reply #21 on: March 28, 2011, 04:43:19 pm »
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? :)

Offline SimonLothar

  • LV4 Regular (Next: 200)
  • ****
  • Posts: 129
  • Rating: +35/-1
    • View Profile
Re: Compiling stuff for Prizm
« Reply #22 on: April 03, 2011, 11:03:17 am »
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://ourl.ca/9205/201161
« Last Edit: April 21, 2011, 04:25:17 am by SimonLothar »
I'll be back.

Offline z80man

  • Casio Traitor
  • LV8 Addict (Next: 1000)
  • ********
  • Posts: 977
  • Rating: +85/-3
    • View Profile
Re: Compiling stuff for Prizm
« Reply #23 on: April 03, 2011, 04:52:08 pm »
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.

List of stuff I need to do before September:
1. Finish the Emulator of the Casio Prizm (in active development)
2. Finish the the SH3 asm IDE/assembler/linker program (in active development)
3. Create a partial Java virtual machine  for the Prizm (not started)
4. Create Axe for the Prizm with an Axe legacy mode (in planning phase)
5. Develop a large set of C and asm libraries for the Prizm (some progress)
6. Create an emulator of the 83+ for the Prizm (not started)
7. Create a well polished game that showcases the ability of the Casio Prizm (not started)

Offline SimonLothar

  • LV4 Regular (Next: 200)
  • ****
  • Posts: 129
  • Rating: +35/-1
    • View Profile
Re: Compiling stuff for Prizm
« Reply #24 on: April 04, 2011, 11:44:09 am »
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://ourl.ca/8207/178619

...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.


I'll be back.

Offline DJ Omnimaga

  • Former TI programmer
  • CoT Emeritus
  • LV15 Omnimagician (Next: --)
  • *
  • Posts: 55927
  • Rating: +3152/-232
  • CodeWalrus founder & retired Omnimaga founder
    • View Profile
    • DJ Omnimaga Music
Re: Compiling stuff for Prizm
« Reply #25 on: April 04, 2011, 02:26:52 pm »
Wow I tried this last night and I was amazed. O.O Somebody should try making a scrolling tilemap demo to show what could be done.


Offline z80man

  • Casio Traitor
  • LV8 Addict (Next: 1000)
  • ********
  • Posts: 977
  • Rating: +85/-3
    • View Profile
Re: Compiling stuff for Prizm
« Reply #26 on: April 06, 2011, 12:15:29 am »
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.

List of stuff I need to do before September:
1. Finish the Emulator of the Casio Prizm (in active development)
2. Finish the the SH3 asm IDE/assembler/linker program (in active development)
3. Create a partial Java virtual machine  for the Prizm (not started)
4. Create Axe for the Prizm with an Axe legacy mode (in planning phase)
5. Develop a large set of C and asm libraries for the Prizm (some progress)
6. Create an emulator of the 83+ for the Prizm (not started)
7. Create a well polished game that showcases the ability of the Casio Prizm (not started)

Offline DJ Omnimaga

  • Former TI programmer
  • CoT Emeritus
  • LV15 Omnimagician (Next: --)
  • *
  • Posts: 55927
  • Rating: +3152/-232
  • CodeWalrus founder & retired Omnimaga founder
    • View Profile
    • DJ Omnimaga Music
Re: Compiling stuff for Prizm
« Reply #27 on: April 06, 2011, 07:31:24 pm »
Glad to see new updates and attempts at simplifying Prizm dev. :D


Offline z80man

  • Casio Traitor
  • LV8 Addict (Next: 1000)
  • ********
  • Posts: 977
  • Rating: +85/-3
    • View Profile
Re: Compiling stuff for Prizm
« Reply #28 on: April 08, 2011, 01:34:52 am »
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.

List of stuff I need to do before September:
1. Finish the Emulator of the Casio Prizm (in active development)
2. Finish the the SH3 asm IDE/assembler/linker program (in active development)
3. Create a partial Java virtual machine  for the Prizm (not started)
4. Create Axe for the Prizm with an Axe legacy mode (in planning phase)
5. Develop a large set of C and asm libraries for the Prizm (some progress)
6. Create an emulator of the 83+ for the Prizm (not started)
7. Create a well polished game that showcases the ability of the Casio Prizm (not started)

Offline SimonLothar

  • LV4 Regular (Next: 200)
  • ****
  • Posts: 129
  • Rating: +35/-1
    • View Profile
Re: Compiling stuff for Prizm
« Reply #29 on: April 09, 2011, 06:47:27 am »
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.
I'll be back.