68k Flash Apps?

[TC01]

Is there any way to write flash apps for the 68k calcs anymore, without using TI's Flash Studio? Because Microsoft's JVM is no longer available on their site, which is required for it to run.

TIGCC/GCC4TI doesn't support flash apps- are there no third-party programs that let you do this?

I'd have put this in either the ASM or C forums, but I'm not sure what language apps on 68k calcs are written in.

[apcalc]

Microsoft JVM is not available directly from Microsoft, but I found it on a third party website and I got TI Flash Studio working .  I have never really tried to make a flash app for a 68k calc, but I have always wondered if this was possible.  TI Flash Studio does not use the same syntax as TIGCC/GCC4TI so I can not copy and paste code to it, but I think I did make a small app once when I first got TI Flash Studio working that cleared the screen or something.  If I am not mistaken, TI Flash Studio allows you to write flash apps in C.

EDIT: You should be able to download Microsoft JVM from one of the links on this website: http://java-virtual-machine.net/download.html.  I think it is the site I used.

[Lionel Debroux]

Is there any way to write flash apps for the 68k calcs anymore, without using TI's Flash Studio?

Well, no. The only decent use case for TIFS is indeed FlashApps. But then you have to withstand the crappy C compiler which understands only an old dialect of C and generates bad code.

For what purpose would you like to write a FlashApp ? Better system integration ?

I'd have put this in either the ASM or C forums, but I'm not sure what language apps on 68k calcs are written in.

As apcalc wrote, usually C. I'm not aware of full-ASM FlashApps. Some bits, such as the declaration of frames and string frames, may need to be in C.

[TC01]

Microsoft JVM is not available directly from Microsoft, but I found it on a third party website and I got TI Flash Studio working .  I have never really tried to make a flash app for a 68k calc, but I have always wondered if this was possible.  TI Flash Studio does not use the same syntax as TIGCC/GCC4TI so I can not copy and paste code to it, but I think I did make a small app once when I first got TI Flash Studio working that cleared the screen or something.  If I am not mistaken, TI Flash Studio allows you to write flash apps in C.

EDIT: You should be able to download Microsoft JVM from one of the links on this website: http://java-virtual-machine.net/download.html.  I think it is the site I used.

Okay, which brings me to question 2: would it work on Windows 7? The site doesn't list 7, but it does list Vista, and I assume it could be out of date.

Is there any way to write flash apps for the 68k calcs anymore, without using TI's Flash Studio?

Well, no. The only decent use case for TIFS is indeed FlashApps. But then you have to withstand the crappy C compiler which understands only an old dialect of C and generates bad code.

For what purpose would you like to write a FlashApp ? Better system integration ?

To be honest, I'm not sure, which brings me to question 3: are there any advantages to writing 68k programs in flash apps, rather than normal programs?

I do have an idea for a 68k program, and having not done much 68k programming (I haven't done too much Z80 programming either, but I've done more of it than 68k programming), I'm just looking at different ways to do it. I know the differences between apps and programs on Z80 calcs (for the most part, anyway), but not on the 68ks.

I'd have put this in either the ASM or C forums, but I'm not sure what language apps on 68k calcs are written in.

As apcalc wrote, usually C. I'm not aware of full-ASM FlashApps. Some bits, such as the declaration of frames and string frames, may need to be in C.

Ah, okay.

[apcalc]

Okay, which brings me to question 2: would it work on Windows 7? The site doesn't list 7, but it does list Vista, and I assume it could be out of date.

I am running Windows 7 and it works fine.

To be honest, I'm not sure, which brings me to question 3: are there any advantages to writing 68k programs in flash apps, rather than normal programs?

None that I know of.  Actually, as stated earlier, since TI Flash Studio uses an older version of C, you might have some disadvantages by using that.

[Lionel Debroux]

To be honest, I'm not sure, which brings me to question 3: are there any advantages to writing 68k programs in flash apps, rather than normal programs?

There are some advantages, indeed, but mostly for uncommon use cases, e.g.:
* deeper system integration, such as Greg Dietsche's SuperStart program decompressor & launcher. ASM programs would have to resort to event hooks;
* programs > 64 KB large. That said, those are pretty easy as well for ASM programs if relying on HW3Patch on all models (it's almost necessary for daily use of 89T calculators anyway; the production of the 89 and 92+ stopped long ago);
* FlashApps execute from Flash, so they don't need to take RAM for their own code, unlike ASM programs. That said, it's pretty hard to make a program that uses the entire RAM, the only example that comes to my mind is the Chrono Fantasy masterpiece.

Downsides of TIFS / FlashApps, including but not limited to:
* the crappy compiler, and the less efficient instructions used to read RAM from Flash memory;
* the smaller set of programmer-accessible functions, focused on higher-level things;
* no way to use the large set of external libraries designed for TIGCC/GCC4TI ASM programs, you're limited to what the OS proposes (and performance suffers because AMS's graphical functions are slow) or you have to make the new code yourself...
* TIGCC's documentation is much more complete (especially about low-level aspects) than that of TIFS, and GCC4TI's documentation is a superset of TIGCC's;
* FlashApps consume RAM permanently, for their own data (.data and .bss sections, where they store writable stuff). Many apps use several dozens of bytes, but several apps take up more than 1 KB (granted, the PreOS "kernel" consumes much more than 1 KB, but it yields more advanced functionality that ASM programs can build on, though almost nobody does nowadays);
(* compatibility with AMS 2.05 and later only, while many ASM programs happily run on AMS 1.01 92+ / AMS 1.00 89 - but nowadays, this is a weak argument, as  AMS 2.05 was released in 2000)


Pretty much anybody in the community will tell you that you should make ASM programs, hands down. Except maybe if you have a specific use case that is better fulfilled with a FlashApp.
In all fairness, I should mention that the damage of TI's crappy compiler can be mitigated by compiling chunks with TIGCC/GCC4TI and somehow integrating them in the FlashApp. The only FlashApp doing this (that I know) is the GTC on-calc C compiler / ASM assembler FlashApp (which is a FlashApp because it contains > 64 KB of code and because the process of compiling with decent optimization requires significant amounts of RAM, so it had better run from Flash). But obviously, it's more complicated...

[TC01]

To be honest, I'm not sure, which brings me to question 3: are there any advantages to writing 68k programs in flash apps, rather than normal programs?

There are some advantages, indeed, but mostly for uncommon use cases, e.g.:
* deeper system integration, such as Greg Dietsche's SuperStart program decompressor & launcher. ASM programs would have to resort to event hooks;
* programs > 64 KB large. That said, those are pretty easy as well for ASM programs if relying on HW3Patch on all models (it's almost necessary for daily use of 89T calculators anyway; the production of the 89 and 92+ stopped long ago);
* FlashApps execute from Flash, so they don't need to take RAM for their own code, unlike ASM programs. That said, it's pretty hard to make a program that uses the entire RAM, the only example that comes to my mind is the Chrono Fantasy masterpiece.

Downsides of TIFS / FlashApps, including but not limited to:
* the crappy compiler, and the less efficient instructions used to read RAM from Flash memory;
* the smaller set of programmer-accessible functions, focused on higher-level things;
* no way to use the large set of external libraries designed for TIGCC/GCC4TI ASM programs, you're limited to what the OS proposes (and performance suffers because AMS's graphical functions are slow) or you have to make the new code yourself...
* TIGCC's documentation is much more complete (especially about low-level aspects) than that of TIFS, and GCC4TI's documentation is a superset of TIGCC's;
* FlashApps consume RAM permanently, for their own data (.data and .bss sections, where they store writable stuff). Many apps use several dozens of bytes, but several apps take up more than 1 KB (granted, the PreOS "kernel" consumes much more than 1 KB, but it yields more advanced functionality that ASM programs can build on, though almost nobody does nowadays);
(* compatibility with AMS 2.05 and later only, while many ASM programs happily run on AMS 1.01 92+ / AMS 1.00 89 - but nowadays, this is a weak argument, as  AMS 2.05 was released in 2000)


Pretty much anybody in the community will tell you that you should make ASM programs, hands down. Except maybe if you have a specific use case that is better fulfilled with a FlashApp.
In all fairness, I should mention that the damage of TI's crappy compiler can be mitigated by compiling chunks with TIGCC/GCC4TI and somehow integrating them in the FlashApp. The only FlashApp doing this (that I know) is the GTC on-calc C compiler / ASM assembler FlashApp (which is a FlashApp because it contains > 64 KB of code and because the process of compiling with decent optimization requires significant amounts of RAM, so it had better run from Flash). But obviously, it's more complicated...

Ah, okay. So really, the only reason to use a flash app would be for very large programs and/or programs that would otherwise need to use event hooks.

So, is there some reason why TIGCC/GCC4TI can't compile to flash apps? What I mean is, is there a reason why the feature was never added? Is this just not a feature that it's worthwhile working on (because there are only a few reasons why apps would be an advantage), or is it impossible to do for some reason? Because it looks like a lot of the downsides are simply related to TI's Flash Studio, not the app format itself.

[Lionel Debroux]

Use cases are fairly limited, but also, nobody ever spent time implementing that feature into the TIGCC/GCC4TI linker. And as long as there are very, very few TI-68k C/ASM programmers (the TI-68k communities aren't seeing any kind of uptake similar to that in the TI-Z80 communities), it probably won't be implemented.

[apcalc]

I agree with Lionel Debroux that this feature will not be implemented.  The activity of the 68k community has dropped a lot over the past few years.  I am getting into 68k programming now, but I find myself to be more interested in programming for the TI-Nspire instead of my 89.

[Lionel Debroux]

The TI-68k series is "you can program lots of things right now". IMO, it's a better starting point to embedded programming (with a notion of optimization) than the more powerful TI-Nspire series can be.

[DJ Omnimaga]

I think the reason why Flash APPs are more popular on z80 calcs is because of their even more limited memory and the 8 KB code limit present on the 83+/84+. The disadvantage of flash apps, though, is that they can take a long while to transfer to the calc and they disallows self-modifying code. On 68K calcs, you have a lot of RAM so you don't need to rely on APPs as much.

As for the 68k community, one thing that could maybe be done is attempt at setting up a main hub forum for the 68k programmers and it would have a spiral effect in terms of activity increase, as people would join due to the higher activity. The problem, though, is that TI-Freakware tried to do that a few years ago and despite the absence of troublemakers on their board, it still didn't work. From experience, I also remember that some 68K C programmers were rather narrow-minded about BASIC programmers, so if Omnimaga managed to attract 68K coders again, I am a bit worried that it would clash between z80 BASIC/Axe+68K/Nspire BASIC programmers and 68K ASM/C programmers, like I've seen happen before when I ran into 68k coders. One example would be the reply to the first comment on this page: http://www.ticalc.org/archives/news/articles/13/139/139347.html That said, there are so many BASIC/Axe programmers and open-minded people right now on Omni that if someone came and caused trouble, he would get most of the community against himself.

[TC01]

I think the reason why Flash APPs are more popular on z80 calcs is because of their even more limited memory and the 8 KB code limit present on the 83+/84+. The disadvantage of flash apps, though, is that they can take a long while to transfer to the calc and they disallows self-modifying code. On 68K calcs, you have a lot of RAM so you don't need to rely on APPs as much.

As for the 68k community, one thing that could maybe be done is attempt at setting up a main hub forum for the 68k programmers and it would have a spiral effect in terms of activity increase, as people would join due to the higher activity. The problem, though, is that TI-Freakware tried to do that a few years ago and despite the absence of troublemakers on their board, it still didn't work. From experience, I also remember that some 68K C programmers were rather narrow-minded about BASIC programmers, so if Omnimaga managed to attract 68K coders again, I am a bit worried that it would clash between z80 BASIC/Axe+68K/Nspire BASIC programmers and 68K ASM/C programmers, like I've seen happen before when I ran into 68k coders. One example would be the reply to the first comment on this page: http://www.ticalc.org/archives/news/articles/13/139/139347.html That said, there are so many BASIC/Axe programmers and open-minded people right now on Omni that if someone came and caused trouble, he would get most of the community against himself.

True. Its rather sad that even the release of a new on-calc programming language for the 68k calcs hasn't had much of an effect- the only NewProg program on ticalc.org is a Minesweeper clone made by the NewProg developer.

I'm learning 68k C programming, and am currently working on a 68k project, but I definitely still do a lot of Z80 programming- maybe not as much at the moment with my 83+'s dead link port, but still some.

[DJ Omnimaga]

Having seen how NewProg got its own section like BBC Basic, I assume it is an interpreted language, though. The fact people most likely need the NewProg APP on their calc to run games made with it probably doesn't help. I think the 68k scene kinda died, though, but unlike the z80 scene, in 2009 and 2010, it did not pick up again.

I have doubts at this point that z80 programming will die, considering how much Cemetech and Omnimaga activity increased compared to last year. For Nspire dev, it will depend of how TI behaves, I think (and if Ndless 2 comes out)

[apcalc]

For Nspire dev, it will depend of how TI behaves, I think (and if Ndless 2 comes out)

This is what I fear about the Nspire.  Although a good percentage of us now can use Ndless on our calcs and can make/run ASM/C programs, when new Touchpad nspires rise to dominance and outnumber the clickpads, Ndless may be blocked completly.  This could destroy the TI community if TI ever decides to retire Z80 calcs.

[TC01]

Having seen how NewProg got its own section like BBC Basic, I assume it is an interpreted language, though. The fact people most likely need the NewProg APP on their calc to run games made with it probably doesn't help. I think the 68k scene kinda died, though, but unlike the z80 scene, in 2009 and 2010, it did not pick up again.

I gave NewProg a try recently. Well, actually, I haven't done much with it, just installed it, probably because I've been learning C. Appropriately enough given this topic, it's not actually an app, it's a suite of programs.

The way it works is you write programs in a Basic-like syntax using the Program Editor (in a way similar to Axe, except since this is the 89 the function names are typed out), then "compile" it into an app variable (*.89y, HPP on calc). The difference to Axe is that you do need the newprog() program to run it, it's not a nostub program- which is why it gets its own file section on ticalc.org, I assume.