Jump to content

theincrediblepeep

New Members
  • Posts

    8
  • Joined

  • Last visited

Recent Profile Visitors

405 profile views

theincrediblepeep's Achievements

Combat Commando

Combat Commando (1/9)

22

Reputation

  1. Happy 2023, all! Wishes for an exciting new orbit around the sun. I have been playing with the RS-232 serial interface in TI BASIC, and it has lots of fun potential. However, what I don't understand is how to read from RS232 in a non-blocking way. Considering this simple example: 10 OPEN #1:"RS232.BA=9600.DA=8.PA=N.CR.LF",INPUT 20 INPUT #1:D$ 30 PRINT D$ 40 GOTO 20 Above, the computer waits on line 20 until there is a sufficient parcel of incoming data, and then proceeds; no other code can be run during that time. Is there a way to "peek" the serial queue in a non-blocking way for if an I/O READ would return data? I have tried using the EOF function, to see if that could be used to detect incoming serial data, but it returns an error on the serial device when in BASIC. I did not venture coding something like this in assembly until I could get past the issue in BASIC, but perhaps BASIC has no way to do it? In assembly, I've considered that it might be accomplished by hooking into an interrupt to fire when data is available, which I've never done before. Any insight?
  2. Great information, everyone! It sounds like there are a few approaches, but the floating-point VDP usage is largely unavoidable. Worst case, I can snapshot the bytes in that area before the operation and then restore previous values after the operation. It just seemed kind of silly to have to resort to that if there were alternatives. Thanks for all your help!
  3. Hi all! In a TI-99 assembly, I am using both floating-point math functions and bitmap mode together, and the problem is that the math functions of XMLLNK/GPLLNK like to use low VDP memory for some of its work, a region I am using to store the screen bitmap. In the screenshot attached, you will notice a block of stray pixels on the right side of the screen, 28 bytes starting at VDP >03C0. Floating-point math was also stacking a couple of numbers at VDP >0008, which I was able to move elsewhere by changing the address in VSPTR (>836E), but I have not discovered a way to move the operations that use VDP >03C0. I first initialize the bitmap, color map, and pattern descriptor table, so at the beginning, that region is all zeroes. When stepping through the first pass of the main loop, a step-over of the first floating-point branch is precisely when the data appears in that location. It happens in emulation as well. Editor/Assembler code LISS1 is also attached. Any ideas? LISS1
  4. Oh, believe me, I understand! My version of Premiere is like 10 years old, before Adobe started doing all that awful subscription junk. Adobe subscription products are painfully bad.
  5. Hi, Omega! Thanks, I use Adobe Premiere on Windows. Do you create TI videos? Vorticon, I'm flattered; thanks!
  6. Hello, contest participants! All of your entries were very inspiring. I hope you don't mind, but I made a little video featuring the contest entries and winners.
  7. tibasic and kl99, congratulations! Vorticon, thanks to you for conducting this fun and exciting contest, fueling many very creative works. To all participants, great work! It has been a delight seeing everyone's strategies around the 10-line limit.
  8. Submission: Alpha10 Platform: TI BASIC Written by: Geoff Haddad Instructions: Three at a time, letters come falling down from the top of the screen, and you must press and hold each letter shown to vanquish them! Make sure Alpha Lock is on. If a letter makes it all the way to the bottom, you lose, and the program freezes. alpha10.dsk
×
×
  • Create New...