Omnimaga
Calculator Community => TI Calculators => General Calculator Help => Topic started by: SolusIpse on June 30, 2010, 10:52:24 pm
-
So how much progress has been made in terms of getting games onto Nspire? Is there anything like TIGCC yet? Or is it still far from it? Does the Nspire still emulate z80 properly with the exception of unofficial instructions? What does one need to do to make sure that z80 ASM programs are compatible with Nspire?
Also, how's the 68k front? Is it still just TIGCC or did the split happen and there's another C compiler for 68k calcs? Any good games out? And is it true that 68k may be phased out in favor of Nspire CAS? At least Ti-84's going to stay for awhile right?
-
Hi SolusIpse, nice to see you still around sometimes.
Sadly, Nspire dev has slowed down recently, because Ndless 1.0 is only compatible with OS 1.1, which has issues on newer Nspires and the even newer ones cannot be downgraded below OS 2.0. Ndless 2.0 is progressing incredibly slowly at the moment. It currently runs on OS 1.7, but it doesn't work too well on OS 2.0 yet. The developpers are busy so it hinders developpement a lot. There would probably also be legal issues due to the hack allowing a CAS OS to be sent on a non-CAS calc, so they are waiting for that and trying to figure out a way to get around that.
Right now, though, on OS 1.1, you can do ARM9 assembly and C. I am not experienced in the domain, though, so you would need to ask in this section what tools are required to make games on it.
As for 68K it seems to be slowly fading away, both due to TI phasing out 68K calcs it seems (and Nspires picking up in popularity) and Kevin Kofler trolling scared several veterans away (such as the person maintaining TiLP).
Nspire dev should pick up again once Ndless 2.0 comes out, but there are no date for this yet. I am sure they welcome any contributions, though. You would need to PM ExtendeD or geogeo on yAronet forums or United-TI.
That said, the z80 community is doing some sort of come back, especially with the new language Axe Parser.
-
did anyone ever figure out why Ti-Boy SE and lots of other programs no longer worked on new calcs? Was it really a hardware change on Ti's part?
-
It was, sadly. The 84+ calcs made after May 2007 only have 48 KB of RAM instead of 128. This means while older 15 MHz calcs got 96 KB of extra RAM, the newer ones got 16. Calc84 was working on an alternative but progress has been slow lately. I hope he won't quit calcs. You can check the TI-Boy SE section. You may find a topic regarding newer calcs.
-
The Nspire does not yet have an equivalent of TIGCC. However, any standard arm-elf-gcc + GNU development tools will work nicely.
Once you get your arm-elf-gcc set up, starting development is as simple as grabbing the skeleton-[windows|linux]-1.0.zip file from the first post here (http://ourl.ca/4852) and placing your code in the appropriate places. I think the skeleton files are bug-free now.
Nspire development should speed up as more of the standard library is found. Eventually, we should be able to port existing programs without too much trouble.
-
Any well-behaved standard arm-elf-gcc toolchain will work for the Nspire indeed, but there are significant restrictions on what the programs can do because there's no program loader (=> no relocation support => a number of uses of global variables, or functions, is impossible).
Writing a BFLT program loader would be fairly easy (because the BFLT format is trivial), and files in BFLT format are easy to produce from the ELF output of arm-elf-gcc toolchains.
Is it still just TIGCC or did the split happen and there's another C compiler for 68k calcs?
There are two other C compilers for TI-68k calcs: GTC and GCC4TI.
GTC has a brand-new compiler that works both on the computer and on the calculators; GCC4TI is based on TIGCC, it's a superset of it and it contains multiple fixes and optimizations (some of which are thoroughly tested, and were contributed to TIGCC as early as 2002). A lot of work is necessary to raise from the arguably low quality of TIGCC (no sane build system, portability issues in the build scripts, thin test suite, etc.)
There's no sort of come back on the TI-68k community, which has been largely dead since 2007 (though several great programs, like lachprog's, have been released since then).
and Kevin Kofler trolling scared several veterans away (such as the person maintaining TiLP).
Romain Liévin left mainly because he is working on getting a higher degree in teaching physics, wanted to spend more time with his wife and children, and didn't learn much anymore (from a development perspective) from maintaining such large projects.
But it's a fact that Kevin Kofler's misbehaviour with so many people over ten years has something to do with Romain's decision, and the decision of many people over the years.
-
Kudos to Quigibo! From the screens Axe is really impressive. Looks much better than a lot of the C->z80 converters in from awhile ago.
Was never really good at C to be able to set up a dev environment on my own. Hopefully Nspire programming will reach the same level as 68k but it's sad to hear the news concerning TiLP and TIGCC/GCC4TI. If there's one thing I like about Nspire, it has a nice big screen unlike z80 calcs >.< so few pixels! so hard to make decent looking 16x16 bw people sprites!
As for TI cutting RAM, I almost can't blame them after spending so much time processing silicon wafers by hand.
-
One issue with C is that it was apparently not suitable for z80 platforms. Writing a good C compiler was apparently very hard . Same for Java. It was much easier for someone to make a brand new language, or something that looks similar to BASIC but is rather simple in syntax so it can be compiled easier. Btw did you see the Axe Tribute video? Altough more have been shown since then, the video already shows a lot of Axe stuff. I myself have been working on a game called Supersonic Ball in the projects/ideas section which has parralax scrolling.
If you check ticalc.org featured programs for the last 7 months, you'll notice there are more so far than the first 7 months of 2008 and 2009 combined and I think more than 2006 and 2007 if I remember. Cemetech and Omni activity picked up, TI-BASIC Developper is slowly doing the same since the past month or so and TI-BANK has been picking up for at least 2 years. The only downside is that ticalc.org traffic did not rise that much and a lot of other forums were nearly left abandonned by their admins (altough some were hit by situations similar to KK but to a lower extent, causing some ppl to migrate elsewhere) and it caused them to spiral downwards while other sites spirals upwards.
In other words, the TI community in general is picking up again, but it would be much better if we had Ndless 2.0, even if it only supported OS 1.7, which is installable on the clickpad Nspires which are still for sale atm
-
There is apparently a C compiler for the Z80 that supports Z80 calculators, z88dk (I found it when I was reading through the newsletter archives on ticalc.org- it was in the second-to-last one). Here is a link to their forums (http://www.z88dk.org/forum/index.php)... I presume some people already know about this, but others might not. I didn't.
Apparently it's not too efficient or easy to use- and most of the posts in the "TI Calculators forum" are bug reports- and they don't have anyone working on the project at the moment who actually owns the calculators. But it appears to still be in active development- last release was in 2009.
-
I heard it produced inneficient code, as did SDCC. I never used them, though, so I cannot judge myself.
-
Indeed, unlike the 68k ISA (which was designed for C programming), the Z80 ISA is not well adapted to C programming. All C compilers targetting the Z80 ISA make a rather laughable job compared to what ASM programmers can do.
-
What does ISA means? I checked Google and all I got was stuff about old graphic cards and international societies/studies/etc
-
In this context, I meant Instruction Set Architecture. But ISA also means, between other things, "Industry Standard Architecture", an old bus used in old PCs, before PCI, and later AGP and PCI-Express :)
-
Aaaah ok, thanks for the info :)
I assume the fact C compilers are hard on z80 is because it's a 8 bit processor, right?
-
It's not only because of that, AFAICT. But someone more knowledgeable with the Z80 ISA would have a more useful POV than mine here.
-
I do not exactly remember when, but I had a small discussion about this with TD-Linux in #omnimaga recently, and it seems to be effectively due to the z80 processor being too limited for a language like C. Something to do with not having enough registers.
-
Yeah, it's a register issue. IIRC the z80 proccessor has 14 general purpose registers while the ARM one in the nspire has 37(?) registers, if the documentation I was reading is correct.
-
Didn't some of the z80 registers also required the combination of two registers?
-
By 'combining' registers it allows for storage of 16-bit data, but alone they can only hold 8-bits of data. So AF, BC, DE, HL, IX, IY, and SP can hold up to 16-bits of data(I believe). But IX, IY, and SP are reserved for the OS or something and shouldn't be modified.
I may not totally sure about IX, IY, and SP, I know that SP is the stack pointer, but I am not entirely sure what IX and IY are for. Maybe someone with more knowledge could enlighten us since I only know some basic stuff :D
-
The x86 ISA doesn't have much more register than the Z80 ISA has.
ARM processors have 16 registers usable for general-purpose code, plus some more control registers.
-
Only IY is used by the OS, and SP is used pretty much everywhere (you need to preserve SP to use call, ret, push, and pop)
IY is actually the start of the OS flags, so you can use it by disabling interrupts then restoring it when done.
IX can be used by programs, and along with IY is an index register. They're called that because when using them indirectly, you can add a constant index (8-bit signed) to them, like "res 3,(ix+9)", which resets the third bit of the byte nine after IX.
The disadvantage to using them is that they are larger and slower. The instruction above is 4 bytes, while "res 3,(hl)", the equivalent version with hl instead of ix+9, is only 2.