Search the Community
Showing results for tags 'TIMXT'.
Found 4 results
During the past few weeks I've been mulling over how to proceed with TIMXT and its development. The code base needs some TLC and many of the routines could be more efficient if I just bit the bullet to rework or rewrite them. I figured a development thread might help me collect my thoughts and share the periodic update. On that note... A few AA members (i.e., Paradroyd, duhproject) have twitter feeds where they post pictures of various BBS systems they connect to. I noticed a few cool C64 BBSs and was curious how the color and graphics were being interpreted. The C64 palette and character sets are different from the TI, and PETSCII has its own way of moving the cursor and controlling which graphics set to use. With the F18A, we can adjust the palette and use the text mode attributes to display colors, just like TIMXT handles ANSI colors today. So I thought a good approach to redoing the core interpreter would be to try my hand at emulating PETSCII. This week I incorporated the C64 extra graphics (thanks to Sometimes99'ers font collection) and finished all but two control routines for displaying the graphics and colors. The terminal window is hard-coded for 80 columns, though I might try to allow for a 40-column color mode to get closer to the C64 experience. Note: Particles BBS allows for PETSCII in 40 and 80 columns; of course, I chose 80 for my call Also, a few pictures show "@" and "]" in place of horizontal and vertical lines; I did not realize until later that there is some uniqueness to the PETSCII character sets that required me to redefine a few more characters. Scorps portal has been down so I couldn't retake the photos. Don't mind the terminal status bar - I haven't updated it. What you are seeing is PETSCII at 38.4K. 1. PLACEHOLDER - Current Release Files Shift838 pulled the EA5 and FR99 images together. This version is from early 2017 and should work with the standard RS232 and the nanoPEB. Macros cannot be saved/loaded in this version; that will be corrected in the future. TIMXT_NANO.zip EA option 5 files TIMXT_NANO.bin FR99 bin file TIMXT-v02c-2017-01-NANO-EA5.dsk disk image (thx Schmitzi) ** The PETSCII version has not yet been released ** 2. PLACEHOLDER - hardware configurations TI terminal emulators generally do not support hardware handshaking. a. TI/CorComp/Myarc RS232 The following cable is NOT configured for any RTS/CTS hardware handshaking, so be sure to turn it off if your modem is configured. AT&K0 is one common command to shut down handshaking. RS232 - modem device 1 - 1 2 - 3 3 - 2 6 - 20 7 - 7 20 - 6 b. NanoPEB Serial - a standard DB9 to DB25 serial cable works well with the nano. The nano's rs232 port is configured similar to that of a PC for easy connectivity. This also means if you roll your own cable, be aware that the pins will be different. c. uberGROM cart UART Connecting the UART to a modem device requires either a TTL-to-RS232 converter or a device that can operated at TTL levels. There are only three required connections: Ground, Receive, and Transmit. 3. Links to other relevant threads: RS232 Interrupts: http://atariage.com/forums/topic/250049-interrupt-service-routine-and-the-rs232/?do=findComment&comment=3462424 NanoPEB Serial thread: http://atariage.com/forums/topic/259886-timxt-with-nanopeb-version-1/ **Edit: added placeholders for files and configurations
BETA RELEASE 9640 Menu System (80 Column Menu Loader) F18A & 9938 Compatible Best when used with Extended BASIC 2.7 Suite Cartridge TIMXT (80 Column Color ANSI Communications Program) F18A Compatible Okay here are the programs and unfinished documentation. I wanted to gussy up the manual more, but I've been slammed at work and will not even be home on Saturday which is the day this was originally going to be released. Enjoy the heck out of these programs, they are going to change the way you use your TI! Please post all questions, comments, ideas or bug reports to this message thread. Ω 9640 Menu System & TIMXT.zip
It seemed appropriate to start a new thread. Heatwave BBS has been back online since Mad Hatter provided the files to me. The "testing" seems to have gone well, so I will plan to keep the BBS online going forward. I have not yet moved the BBS to its final hardware home, which means it is still running on my well-traveled Geneve programming system. You can get to it via telnet at heatwave.ddns.net port 9640 For those of you using the F18A, I recommend trying TIMXT at 38.4K. I have been making some tweaks and updates to the program but I don't yet have an ETA for its next release. Geneve users can use PORT, also at 38.4k.
For quite some time I have been mulling over ways to improve character reception in a TI terminal emulator. Most terminal emulators combine the TI interrupt service routine and the RS232's circular interrupt buffer to receive characters. During character reception, the TI ROM ISR first determines if an external interrupt has occurred. If so, it must scan the peripheral cards one at a time to find the interrupt. Once the proper RS232 port is located, it must execute the card's interrupt service routine. The RS232's interrupt routine populates the 254 byte circular buffer that resides in VDP memory. Unfortunately, this whole process requires a lot of overhead and starts to fail miserably at speeds above 4800bps. Not only is the buffer size too small, all of the processing required to scan the card, handle the interrupt, and stuff it into VDP, require too much time. TIMXT could not exceed 4800bps successfully - at 9600, the TI spent 100% of its time servicing the interrupts, dropping characters along the way. Implementing hardware flow control was an option but it meant building a special cable that many people wouldn't care to make. I went through the same scenario with my Geneve terminal emulator: PORT can sustain 38.4kKbps without a special cable; it only requires handshaking when displaying color text mode (using the V9938 graphics mode and its slow character plotting) or when transferring files with Ymodem-G. But I digress. Months later I was looking at some information on Thierry's site when I came across an interesting article. It described an ingenious method to manage external interrupts using (abusing) the ROM interrupt service routine: http://www.unige.ch/medecine/nouspikel/ti99/jeff.txt This idea resonated with me. In PORT, I hijacked the system's interrupt vectors so that I could process external interrupts, video, and keyboard with no system overhead. This was "easy" to do with an OS in RAM. But the TI ROM is..well..ROM! I was skeptical at first; will there be much of an improvement? It took me a day or so to modify the emulator. I reserved a 4K buffer to stash incoming data. Two routines are required: an interrupt-driven RS232 capture routine and a buffer emptying routine. Think of the buffer like a bucket: one routine fills the bucket with characters; the other routine draws them out for display and other purposes. Only the active RS232 is checked and it is given immediate priority in the user ISR. Once complete I did some base testing with my Geneve. I then asked Omega to test the program at 9600bps. He reported success. He then told me he used 19.2 with success! So, I added an option for 38.4K and surprisingly, it worked! With no hardware handshaking or cable magic! There are a few considerations: 1. Some peripherals rely upon GPLWS R15. Jeff's method changes this value, so disk and other peripherals may fail. My solution was to modify DSRLNK to turn off RS232 interrupts and restore R15 prior to calling the ROM routine. The environment is restored afterwards. 2. All VDP-based automatic processing is inhibited. No sound, no quit key, no 50/60hz timers. You can enable the VDP interrupts and service them if you restore things to 'normal', and then re-enable the interrupt handler when complete. You cannot have both operating at the same time. I suppose a 9901-based 60hz timer may work, I'll have to try that some day. 3. Keyboard scanning takes a long time. For time-sensitive RS232 input, I use a modified direct keyboard scanning routine that can be interrupted in between steps. My next challenges are to improve the keyscan routine and optimize the display interpreter. Later a uni-directional flow control may be needed especially when there is so much data being displayed so quickly.