This is an archived, read-only copy of the United-TI subforum , including posts and topic from May 2003 to April 2012. If you would like to discuss any of the topics in this forum, you can visit Cemetech's Technology & Calculator Open Topic subforum. Some of these topics may also be directly-linked to active Cemetech topics. If you are a Cemetech member with a linked United-TI account, you can link United-TI topics here with your current Cemetech topics.

This forum is locked: you cannot post, reply to, or edit topics. Community News & Discuss Nspire => Technology & Calculator Open Topic
Author Message
Lionel Debroux


Member


Joined: 01 Aug 2009
Posts: 170

Posted: 29 May 2010 02:56:46 pm    Post subject:

Hello everybody :)

Intro:
Several weeks ago, I floated the idea of a Nspire "demo" (in the demoscene - http://www.scene.org/ - sense and tradition)
:
Quote:
These days, I was thinking: "why not make a community project of a good Nspire demo and present it at one of the main demo parties at the end of the year or next year ?".
Featuring an intermittent scrolling text that explains the power of the calculator, the way it was locked down, etc.
Multiple TI-8x demos have been presented at various demo parties over the years, that's why I was thinking about the Nspire.
Of course, we'd have to make it clear that watching the demo on a real calculator won't be as pleasurable as it's on the emulator, because the screen really sucks.
[...]
I was just throwing out ideas for federating some coders around a common project, and, as a byproduct, getting more people working on the program loader and improving the Nspire-specific header files and libraries Smile

(complete log: http://netham45.org/irc/EfNet/view.php?log=ti.20100508 )

Aim: as stated above, advancing the state of the art of Ndless and the development toolchain, libraries, through a (presumably) fun cooperative community project.
That is, a number of programmers of the community could make a program that uses the Nspire's hardware potential (like that of TI-Z80 and TI-68k is used by some of the demos listed at http://pouet.net/prodlist.php?platform[]=TI-8x - but with more advanced effects, of course, since the Nspire's ARM9 is clocked at a much higher frequency).
Head to http://pouet.net/sceneorg.php for a selection of the best (most visually appealing / technically impressive / etc.) demos released over the years, for PC, C64, Amiga, and various other platforms, including "Wild" (other hardware) where TI calculators belong.


Important prerequisites:
I've never made a demo myself, I'm not pretending to grasp every aspect of such a project. But I know that we won't get anywhere without at least two major prerequisites (which should probably be discussed in their own topics):
* first and foremost, a program loader. This will solve relocation woes and enable full usage of global variables.
A first step would be making a simple loader (maybe using BFLT, since loading BFLT is much simpler than loading ELF), but in the mid-term, we will need to enhance it with OS & hardware abstraction capability, much like TI-68k so-called "kernels" provide an OS and hardware abstraction capability to properly-written programs. Indeed, TI really does not want ASM programming on the Nspire (as proved by the attack on TI-Bank) and will do everything possible to break hacks: we need something to shield, as much as possible, users programs from TI's badness.
This enhancement requires modifications to the base toolchain (some other ARM GCC+binutils flavor) to handle the enhanced relocation format. Maybe BFLT will prove too limited for the task.

* fast graphical functions - obviously, since demos are aiming at pushing platforms to their limits.
I noticed that HPGCC contains a number of interesting functions ("hpg", "ggl"), under GPL + an exception. See the following descriptions excerpted from the HPGCC headers:
Quote:
* HPG implements basic graphics functionality on the calculator display. Its
* features include:
*
* \li Monochrome, 4-color grayscale, and 16-color grayscale modes
* \li Double buffering with vsync and hardware page flipping
* \li Drawing to and blitting to and from off-screen images
* \li Loading the Xpm (X-Windows pixmap) file format
* \li Drawing of pixels, lines, circles, rectangles, and polygons
* \li Filling of circles, rectangles, and polygons with arbitrary patterns
* \li Text drawing in multiple selectable fonts, or in user-defined fonts
* \li Rectangular clipping regions for each surface
* \li Control of LCD indicators on the calculator screen

Quote:
* GGL (the Gray Graphics Library) provides extended functions for 16-color
* grayscale graphics on the HP49G+ (and possible HP39G+ and HP48gII)
* calculators. It complements the abilities of HPG by providing faster and
* more specialized routines for the 16-color grayscale mode. GGL may be used
* independently of HPG, or seamlessly alongside it.
*
* The main features of the GGL library are:
*
* - Optimizations for 16-color grayscale drawing
* - Fast bitblt routine
* - Masked sprites
* - Antialiased lines


The HPGCC routines are rather generic, so they are neither optimized for size nor optimized for speed. For example, there's a fair number of callbacks. But they're written in C, which makes the adaptation to a different screen size (prior to further optimization) easy. We may want to make the API even more generic, thanks to more macros and inline functions.
Compared to the surviving TI-68k libraries (ExtGraph and Genlib), one of the areas lacking in hpg/ggl is fast sprite functions. Blitting rectangles with patterns is much less efficient.

Looking around on the Internet may reveal more building blocks for 16-grayscale functions, under permissive licenses.



Notes:
* I've watched a fair number of demos, and a number of animations such as rotozoomers, 3D cubes, starfields, etc. are pervasive. It seems that any wild demo should have them. Watch the TI-Z80 & TI-68k demos, and other wild demos such as "Craft": http://pouet.net/prod.php?which=50141 (winner in the Wild category at Breakpoint 2008, the largest demo party). But with a more powerful hardware, we need to do better than this Wink
* wild demos with sound and other creative abuses of the platform's normal usage receive double bonus points. I thought of making sound by making a Nspire and a 89T or 84+(SE) collaborate through the USB link port (sound output through the legacy I/O of the 89T / 84+).
* the GBC ( http://pouet.net/prodlist.php?platform[]=Gameboy+Color ), GBA ( http://pouet.net/prodlist.php?platform[]=Gameboy+Advance ), GP32 ( http://pouet.net/prodlist.php?platform[]=GamePark+GP32 ) and maybe even GP2X ( http://pouet.net/prodlist.php?platform[]=GamePark+GP2X ) demos could be a source of inspiration for concepts - but we don't have either a color screen or hardware dedicated to accelerating graphics, so we definitely can't make a number of things that were showcased on those platforms.



Enough text for now - it's your turn to write now Wink
(sorry for the pouet links not correctly transformed into URLs, I couldn't find a way to do that due to the embedded "[]")
Back to top
bwang


Member


Joined: 15 Mar 2009
Posts: 128

Posted: 29 May 2010 11:51:41 pm    Post subject:

Sounds fun.
I think we should do the following:
1) Program loader.
2) Find the Standard Library functions in the newer OSes.
3) Document more aspects of the Nspire's hardware (e.g. how to access the clock in milliseconds, linking, etc).
4) The graphics library. Out of HPG's features, we definitely need the following:
Quote:

* Drawing to and blitting to and from off-screen images
* Drawing of pixels, lines, circles, rectangles, and polygons
* Filling of circles, rectangles, and polygons with arbitrary patterns
* Text drawing in multiple selectable fonts, or in user-defined fonts
* Rectangular clipping regions for each surface

XPM images would be nice, but I don't think they are essential. How hard are they? Double buffering on the Nspire
is best done by just drawing to a separately allocated backbuffer and then drawing it to the screen, as I don't believe
we can do hardware swapping of the LCD buffer.
(1) is definitely the highest priority, followed by (2). (3) and (4) can be done concurrently.
Also, I think Hackspire needs updating. I might go do that soon...
Back to top
Lionel Debroux


Member


Joined: 01 Aug 2009
Posts: 170

Posted: 30 May 2010 06:01:34 am    Post subject:

Thanks for replying ;)

Significant work finding the standard library functions in newer OS versions (well, mostly 1.7.2741) has been done months ago by ExtendeD, geogeo and hwti. Therefore, I'd rank graphical functions higher than finding the standard library functions Smile
Back to top
ExtendeD


Advanced Newbie


Joined: 30 Aug 2009
Posts: 91

Posted: 30 May 2010 08:00:10 am    Post subject:

We actually have in the private part of Ndless's SVN repo a tool for automating the discovery of the symbols of the OS, based on the symbols found in another version of the OS. So most of the standard library functions in newer OS versions are probably already available (I can't recall the sucess hit).
I may ask squalyl anonymous access on the SVN repo to the tool if anyone is interested.
Back to top
bsl


Advanced Newbie


Joined: 09 Jan 2010
Posts: 94

Posted: 30 May 2010 01:58:08 pm    Post subject:

ExtendeD wrote:

We actually have in the private part of Ndless's SVN repo a tool for automating the discovery of the symbols of the OS, based on the symbols found in another version of the OS. So most of the standard library functions in newer OS versions are probably already available (I can't recall the sucess hit).
I may ask squalyl anonymous access on the SVN repo to the tool if anyone is interested.


Yes !!!, I was wondering about this obvious idea for some time. I have already mapped ndless entry points OS1.1 to OS1.7 with my memory editor.
I have also discovered that the OS1.7 entry points listed where correct provided you add a small offset[Don't know why that is ???]
The problem is: what is the prototyping for those[proprietery ???] calls.
The standard C prototyping is known of course.
EDIT: By finding the OS 1.7 entry signatures for the standard C stuff , you then use it to find it in OS1.1 and either build the ndless header
files or create a new one called stdio.h .


Last edited by Guest on 30 May 2010 05:10:46 pm; edited 1 time in total
Back to top
fb39ca4


Newbie


Joined: 24 Jan 2010
Posts: 8

Posted: 10 Jul 2010 04:55:51 pm    Post subject:

[quote=Lionel Debroux]wild demos with sound and other creative abuses of the platform's normal usage receive double bonus points. I thought of making sound by making a Nspire and a 89T or 84+(SE) collaborate through the USB link port (sound output through the legacy I/O of the 89T / 84+).[/quote]

Rather than that, we can just use usb speakers.
Back to top
Lionel Debroux


Member


Joined: 01 Aug 2009
Posts: 170

Posted: 11 Jul 2010 12:28:10 am    Post subject:

Indeed, we can... but that makes for a less impressive demo Wink
Back to top
Display posts from previous:   
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

» Go to Registration page
    »
» View previous topic :: View next topic  
Page 1 of 1 » All times are UTC - 5 Hours

 

Advertisement