Omnimaga
Calculator Community => Other Calc-Related Projects and Ideas => TI 68K => Topic started by: blue_bear_94 on May 04, 2013, 09:24:09 pm
-
Announcing accel68k - Your Future IDE for TI-89 Basic
The development will not be in full force until AP tests are over, but I'd like to give you a preview of what is happening:
- This IDE will use custom editing routines to ensure that key delays don't vex you anymore! In fact, the whole editing is overhauled in order to give a streamlined editing experience!
- It will also give a range of refactoring features, including Local consolidation.
- It will be full screen and (hopefully) use the small font as well.
- It will be a hybrid of TI-Basic and C. To be precise, the editor itself will be in C, and the frontend (file selection, switching) will be in TI-BASIC.
- It will require lots of knowledge about the EStack and the VAT, so help is appreciated!
This will be my most ambitious 68k project of all, and I will furnish you with screenshots when I get the visual interface functional.
Edit Got the skelly code for the backend attached!
Edit II New skelly code and key layout pic!
Edit III Holy shoot! That scan was huge! Now it's only 40% size.
-
This IDE will use custom editing routines to ensure that key delays don't vex you anymore!
FWIW, OS key delays can be easily manipulated through OSInit* functions declared in kbd.h ( http://debrouxl.github.io/gcc4ti/kbd.html ). The KerNO crash protection does it. Also, OSdequeue() + kbd_queue() are fast enough for most purposes, most TICT programs use them. TI-Chess has its own keyboard reading code, but does de-bouncing (effectively limiting the input rate to 4 or 5 keypresses per second anyway) and most of all, maybe AMS' AUTO_INT_1 handler is not called at all, making OSdequeue() + kbd_queue() inoperative.
- It will be full screen and (hopefully) use the small font as well.
You'll probably want to use fast character / string drawing routines, like the TICT eBook reader (ebook) and several others are doing.
- It will be a hybrid of TI-Basic and C.
Mixed BASIC / C execution is a world of slowness (for calling C from BASIC, as shown by the overhead of calling flib/flib2, vertel and suchlike libraries) and hurt (for calling BASIC from C, due to all the errors it can throw if something goes wrong). Some file explorers, such as TICT-Explorer, do not even attempt to provide this functionality, given how hard doing it correctly is: they just paste the invocation to the Home Screen Line and bail out.
-
Well, I have decided that I will use my own keyboard layout for editing and make the user hold down modifier keys, so I'll have to kill interrupts and use direct keyboard access. And since I will only call C from BASIC (not the other way around), I'll try doing so, and if it's too slow, then I'll make the frontend C as well. (By the way, why would this happen?)
By the way, where are the fast drawing routines?
P. S. I've never heard of the OSInit functions. Thank you for telling me that!
-
Well, I have decided that I will use my own keyboard layout for editing and make the user hold down modifier keys, so I'll have to kill interrupts and use direct keyboard access.
Using your own keyboard layout definitely wouldn't require using direct keyboard access, but changing the way modifier keys are handled looks harder to do without using direct keyboard access, indeed.
And since I will only call C from BASIC (not the other way around), I'll try doing so, and if it's too slow, then I'll make the frontend C as well. (By the way, why would this happen?)
It happens because of the need of creating twins from archived variables, etc.
By the way, where are the fast drawing routines?
In the source code of the programs I mentioned, which is why I mentioned them ? ;)
The latest version should be in ebook. The setup routine reads the font data directly from the OS area, accounting for AMS 1.xx, AMS 2.xx/3.xx, and PedroM, which require different methods to retrieve this information.
P. S. I've never heard of the OSInit functions. Thank you for telling me that!
You should spend some more time browsing the GCC4TI documentation, which I've linked above and is in my signature anyway ;)
I've learnt lots of things that way. By now, the number of documented ROM_CALLs has probably reached a thousand (out of 15xx on the most recent versions), the remainder of undocumented things being mostly made of useless / hard to use functions (although some of my '2002-2003 contributions are probably still missing, I added them myself years later to GCC4TI). Beyond that, there are other routines in the library.
-
Does the slowness from calling C from BASIC happen even if the C program run isn't archived, or is the slowness from creating twins of other archived variables?
-
Some overhead for launching a native code program occurs even when the target program is unarchived (which opens the door to data losses in the event of a crash / power loss, of course). It is very likely that launching an unarchived ASM program is faster than launching an archived ASM program, due to the overhead of creating a twin, though I don't remember benchmarking that aspect.
TI tried to make it hard to launch a native code program from another native code program. The net result was the development of such radical approaches as patching the OS to completely disable the silly RAM execution protection (HW2Patch, HW3Patch and tiosmod+amspatch; modern versions of PreOS do it as well, but it's not as easy to detect as an OS patch). Being the maintainer of / a contributor to some of the program launchers led me to explicitly advocate, for at least half a decade, to just rely on OS patches for disabling the RAM execution protection.
It just makes programmers' lives easier, and has marginal impact on users: not only users have to patch the OS just once (each time they transfer a new OS version, but that's a pretty infrequent operation), but as far as 89T users are concerned, there is simply no other sane way to achieve multi-chunk programs with two-way control transfers between chunks. Everybody is happier (programs are easier to make and smaller) when the silly RAM execution protection is disabled, as shown by the http://tict.ticalc.org/downloads/launchmultiple.tar.bz2 PoC.
-
Some overhead for launching a native code program occurs even when the target program is unarchived (which opens the door to data losses in the event of a crash / power loss, of course). It is very likely that launching an unarchived ASM program is faster than launching an archived ASM program, due to the overhead of creating a twin, though I don't remember benchmarking that aspect.
Well, speed is critical only in the editor, so as long as the editor's speed remains unaffected, I'll probably be fine with some degree of slowness.
-
Sounds like an interesting project, good luck with it! :D
-
Also, maybe the fast font drawing routines Lionel mentioned in his post should be added to the GCC4TI libraries?
Meanwhile, I'm figuring out how to use these font routines :banghead:.
-
Due to e-mail notifications being broken for weeks, I missed quite a number of posts on Omnimaga, starting with this topic...
Have you found out how to use the "faststr" routines, by examining e.g. ebook ? There needs to be a setup phase before you can use the drawing routines.
Also, maybe the fast font drawing routines Lionel mentioned in his post should be added to the GCC4TI libraries?
Indeed, the "faststr" family of routines could and should have been added to TIGCC a decade ago...
However, since he became the only active member of the team, the TIGCC maintainer was a major roadblock to advancing the library and documentation. He explicitly refused my "faststr" series, my "fastitoa" series, someone else's fast fread / fwrite, and various other (potential) contributions which would have been useful to users; even among the contributions that he accepted in principle, he let lots of work languish, for instance a contribution making sprite routines faster and smaller while supporting an additional drawing mode.
GCC4TI broke the community free from his counter-productive stranglehold, but let's be realistic, GCC4TI occurred too late to have any meaningful impact on the activity in the TI-68k native code programming community. I did integrate a subset of my work to GCC4TI, but not the faststr and fastitoa series.
-
Yep, it's true that few people program in C for the 68k series.
-
Yup, it's been that way since 2006-2007, and GCC4TI in 2009+ didn't change much the outcome, though nearly all active developers use GCC4TI instead of the unmaintained TIGCC, for obvious reasons.
Did you make the faststr routines from ebook work in your program ? :)
-
Yes; however, I also need one that word-wraps.
-
Is the slowdown from calling C/ASM from BASIC due to having to search through the VAT like on Z80 calcs? I remember that calling ASM programs from Z80 BASIC was very slow because of that and it would get worse and worse as your RAM got lower, so people relied on Flash APPS that installed ASM libs via parser hooks instead, which was much faster.
-
Is the slowdown from calling C/ASM from BASIC due to having to search through the VAT like on Z80 calcs? I remember that calling ASM programs from Z80 BASIC was very slow because of that and it would get worse and worse as your RAM got lower, so people relied on Flash APPS that installed ASM libs via parser hooks instead, which was much faster.
Even if it were so, we still wouldn't be able to sign flashapps that would work on TI-89s without patches.
-
Not sure what you mean: we can sign TI-68k FlashApps with TI's private key, and they're accepted by pristine OS versions.
-
Not sure what you mean: we can sign TI-68k FlashApps with TI's private key, and they're accepted by pristine OS versions.
I meant that we don't have the private key. Or do we now?
-
We've deduced the private keys from the factorization of the corresponding public keys in August or September 2009 ;)
But FlashApps have never been popular on the TI-68k series due to the horrible toolchain used by TI (poor optimization, it only speaks a pre-C89 dialect, etc.), and nobody spent time adding FlashApp support to the GCC4TI linker following the public keys' factorization: the number of (potential) users is pretty low.
-
I think another issue is how it's possible to run programs that are archived on 68K calcs, which is impossible on Z80 calcs, making it even more pointless to make Flash APPs on 68K (since one of the main reason why they're used in the first place is to save RAM)
-
Well, one thing is true now: I could release the IDE in app form to bypass the size limits (too bad, because support wasn't added to GCC4TI due to lack of interest).
-
As I wrote in the other topic, the size limit has been meaningless for practical purposes nearly since its inception, in the 20th century :)
There are several multi-chunk ASM programs which use 100+ KB of code in RAM.
GTC is a FlashApp because having the code execute in RAM would have severely reduced the amount of RAM available for storing compilation data and/or the speed. For functionality and optimization reasons, it's mostly compiled with TIGCC/GCC4TI to COFF object files, the toolchain in TIFS is used mainly for the final FlashApp production.
-
As I wrote in the other topic, the size limit has been meaningless for practical purposes nearly since its inception, in the 20th century :)
There are several multi-chunk ASM programs which use 100+ KB of code in RAM.
GTC is a FlashApp because having the code execute in RAM would have severely reduced the amount of RAM available for storing compilation data and/or the speed. For functionality and optimization reasons, it's mostly compiled with TIGCC/GCC4TI to COFF object files, the toolchain in TIFS is used mainly for the final FlashApp production.
OK, I'll try to get the IDE to be a flash app, then, since I don't know much about using multi-chunk ASM programs; besides, the RAM needs to be used for the TI-Basic programs to edit.
-
OK, I'll try to get the IDE to be a flash app, then
Ouch, it's a bad idea to add a TIFS dependency to your program...
While FlashApp signing is now trivial, and GTC shows that it's possible to reduce the pain of using TIFS, it doesn't mean that FlashApps are a good thing to do, especially in this day and age...
since I don't know much about using multi-chunk ASM programs
To begin with, it's easier than making a mixed GCC4TI / TIFS compilation, especially if you use anything newer than Windows XP. The TIFS IDE works only on XP and earlier, due to a dependency on Microsoft's proprietary, non-standard, "Microsoft Java" (and it's horribly buggy anyway); the toolchain may work on newer Windows versions, but then you'll have to invoke it from the command line.
the RAM needs to be used for the TI-Basic programs to edit.
That's a fact, but there's room before your editor becomes so big that it can't fit in RAM alongside the BASIC program...