Calculator Community > TI 68K

accel68k - a 68k Basic IDE for your 68k calculator

(1/5) > >>

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

Lionel Debroux:

--- Quote ---This IDE will use custom editing routines to ensure that key delays don't vex you anymore!
--- End quote ---
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.


--- Quote ---- It will be full screen and (hopefully) use the small font as well.
--- End quote ---
You'll probably want to use fast character / string drawing routines, like the TICT eBook reader (ebook) and several others are doing.


--- Quote ---- It will be a hybrid of TI-Basic and C.
--- End quote ---
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.

blue_bear_94:
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!

Lionel Debroux:

--- Quote ---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.
--- End quote ---
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.


--- Quote ---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?)
--- End quote ---
It happens because of the need of creating twins from archived variables, etc.


--- Quote ---By the way, where are the fast drawing routines?
--- End quote ---
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.


--- Quote ---P. S. I've never heard of the OSInit functions. Thank you for telling me that!
--- End quote ---
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.

blue_bear_94:
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?

Navigation

[0] Message Index

[#] Next page