+Vorticon Posted September 9, 2017 Author Share Posted September 9, 2017 Hi. I'm looking at triggering interrupts upon the status of certain pins on the parallel port, something similar to pin interrupts on the Arduino or the Raspberry Pi. Is the TI capable of doing this? The E/A manual is very sketchy on the use of interrupts, but it does mention INT1 as an external interrupt for the 9901. Not sure how to use that info or whether it would even help me in the current situation... Quote Link to comment Share on other sites More sharing options...
Stuart Posted September 9, 2017 Share Posted September 9, 2017 (edited) Hi. I'm looking at triggering interrupts upon the status of certain pins on the parallel port, something similar to pin interrupts on the Arduino or the Raspberry Pi. Is the TI capable of doing this? The E/A manual is very sketchy on the use of interrupts, but it does mention INT1 as an external interrupt for the 9901. Not sure how to use that info or whether it would even help me in the current situation... You can't trigger anything direct from a pin on the parallel port because there is no connection from the parallel port to the interrupt circuitry. You can *poll* the parallel port for pin status but that's not what you're asking. /INT1 is an interrupt generated by one of the PEB cards, and I don't think there is any way you can usefully use that for what you're thinking of (unless you design your own PEB card). You've got access to some of the interrupt pins on the TMS 9901 (/INT3 - /INT7) through the joystick interface, and you could use one of these to trigger an interrupt. You have the problem though of the processor interrupt code being hard-wired and so the processor only calls the interrupt service routine in the console ROM. It might be possible to hook into the user-defined interrupt service routine called from the VDP interrupt routine and use that to interrogate the interrupt pins on the TMS 9901, but then you might as well just directly interrogate the pins on the parallel port. Trying to use these pins on the joystick port in this way will also preclude use of the keyboard while you have anything connected to the joystick port. If you're interested in experimenting, I've got some more of my TMS 9900 system PCBs on order and that gives you easy access to all the interrupt pins on the TMS 9901 and all the interrupt vectors. You can program the TMS 9901 either from Cortex BASIC or assembler. A little example program below. In this case the interrupt vector for /INT2 (the interrupt vectors are stored in the low area of ROM) is >8004 (which is in RAM in this system). The code places at >8004 a jump to the code at address MESSG. Each time an /INT2 interrupt occurs (just use a bit of wire to short the /INT2 pin on a header connector to ground) the code at address MESSG is run to print a message over the serial port. *The following block of code has to be run by the user to initialise the interrupt routine. AORG >80C0 Load code after the interrupt /INT2 entry point and workspace. LWPI MYWS Load workspace. *Store a branch instruction at the /INT2 code entry point to branch to the code to print a message. LI R1,>0460 Op-code for Branch instruction. MOV R1,@>8004 LI R1,MESSG MOV R1,@>8006 *Enable /INT2 interrupts on the TMS 9901 and TMS 9900. LI R12,>0040 CRU base address for the TMS 9901. SBZ 0 Set Control bit to 0 to select interrupt mode. SBO 2 Enable (unmask) /INT2 interrupt. LIMI 2 Enable processor interrupt levels 0, 1 and 2. *Return to TIBUG. B @>0080 Quit back to TIBUG. *The following block of code is called each time an /INT2 interrupt occurs. *Code to print message. MESSG EQU $ MOV R11,@SAVR11 Save R11. CLR R12 CRU base address for the TMS 9902. LI R1,MSGTXT Set pointer to text message. BL @PMESSG Print message. *** XOP @MSGTXT,14 Print message text. *** CAN'T USE AN XOP IN THE INTERRUPT ROUTINE. MOV @SAVR11,R11 Restore R11. LI R0,>8000 Timing loop to debounce the switch contact. DBLOOP DEC R0 JNE DBLOOP RTWP Return to calling routine. *Print message subroutine. PMESSG MOVB *R1+,R2 Copy character from text message and increment pointer. JEQ EXIT If character is >00 then exit. SBO 16 Set /RTS on. WENTRY1 TB 22 Transmit buffer register empty? JNE WENTRY1 No, loop until it is. LDCR R2,8 Send character. WLOOP1 TB 22 Transmit buffer register empty? JNE WLOOP1 No, loop until it is. JMP PMESSG Process next character in message. EXIT B *R11 Return. *Workspace and data. MYWS BSS 32 Workspace. SAVR11 DATA 0 MSGTXT BYTE >0D,>0A TEXT 'An /INT2 interrupt has occurred.' BYTE >0D,>0A BYTE >00 END Edited September 9, 2017 by Stuart Quote Link to comment Share on other sites More sharing options...
+Vorticon Posted September 9, 2017 Author Share Posted September 9, 2017 Great example, even though I really want to keep things on the actual TI. I did find on Thierry Nouspikel's site a mouse interface design that uses the LOAD interrupt line on the side expansion port to trigger a user interrupt when the mouse is moved, and then reading the joystick port which is connected to the mouse as well to read movement direction and button presses. Unfortunately, that requires having an interface board attached to the expansion port in order to gain access to the LOAD line... It's an option I suppose... I'll have to think about this a bit more and see if I can get creative without having to use interrupts. I do have one of Jim Fetzner's PEB proto boards on hand which I could also use. Quote Link to comment Share on other sites More sharing options...
Stuart Posted September 9, 2017 Share Posted September 9, 2017 Have you got a Horizon Ramdisk? That apparently has a hook for a user interrupt service routine, so you could possibly trigger interrupts through the joystick port and TMS 9901, and that will trigger the console ISR to run each PEB card ISR in turn to find the source. A hook into the Ramdisk ISR could check the TMS 9901 interrupt pins to see if one of your interrupts occurred. I don't fully understand how the Ramdisk card ISR works (the Ramdisk code is on Thiery's site) but it would be simple to modify the Ramdisk code to point directly to your ISR (at a known location in memory) and reload the Ramdisk code. Quote Link to comment Share on other sites More sharing options...
apersson850 Posted September 9, 2017 Share Posted September 9, 2017 On an original TI, this is difficult. I can do it on mine, since I have either the capability to run it from one of my own PEB cards, either the /O card or the clock card, but they are my own designs. I also have more freedom in doing what I want with an interrupt, since I've modified my console to allow modification of the operating system ROM chips, which otherwise have full control over all interrupts except the LOAD one. Quote Link to comment Share on other sites More sharing options...
+Vorticon Posted September 9, 2017 Author Share Posted September 9, 2017 Have you got a Horizon Ramdisk? That apparently has a hook for a user interrupt service routine, so you could possibly trigger interrupts through the joystick port and TMS 9901, and that will trigger the console ISR to run each PEB card ISR in turn to find the source. A hook into the Ramdisk ISR could check the TMS 9901 interrupt pins to see if one of your interrupts occurred. I don't fully understand how the Ramdisk card ISR works (the Ramdisk code is on Thiery's site) but it would be simple to modify the Ramdisk code to point directly to your ISR (at a known location in memory) and reload the Ramdisk code. Yes, I saw that on Thierry's site. It's another option to look into... Quote Link to comment Share on other sites More sharing options...
+Vorticon Posted October 20, 2018 Author Share Posted October 20, 2018 Here's a look at my latest project: a 2D plotter driven entirely by the TI with no micro-controller support. Definitely one of the harder projects I have undertaken to date... http://atariage.com/forums/blog/659/entry-14733-x-y-plotter-table-for-the-ti-994a-computer-final/ 3 Quote Link to comment Share on other sites More sharing options...
+TheBF Posted October 20, 2018 Share Posted October 20, 2018 Here's a look at my latest project: a 2D plotter driven entirely by the TI with no micro-controller support. Definitely one of the harder projects I have undertaken to date... http://atariage.com/forums/blog/659/entry-14733-x-y-plotter-table-for-the-ti-994a-computer-final/ Very cool! Sounds like a perfect Forth candidate too. Having a console to test your sub-routines interactively makes projects like this a lot of fun in Forth. I can envision a simplified form of Postscript that becomes a text based device driver. Whispering: don't get distracted by the shiny project, don't get distracted by the shiny project, don't get distracted by the shiny project, don't get distracted by the shiny project :-) 3 Quote Link to comment Share on other sites More sharing options...
+Vorticon Posted October 20, 2018 Author Share Posted October 20, 2018 Very cool! Sounds like a perfect Forth candidate too. Having a console to test your sub-routines interactively makes projects like this a lot of fun in Forth. I can envision a simplified form of Postscript that becomes a text based device driver. Whispering: don't get distracted by the shiny project, don't get distracted by the shiny project, don't get distracted by the shiny project, don't get distracted by the shiny project :-) Yeah, the story of my life! I'm going to be using this book to create the drawings in software then test them in The Missing Link to make sure they display and scale properly before sending them to the plotter. Forth would actually be a prime candidate for this. Once the primitives are laid down, it would be super easy to create logo-like turtle graphics. 2 Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted October 20, 2018 Share Posted October 20, 2018 Here's a look at my latest project: a 2D plotter driven entirely by the TI with no micro-controller support. Definitely one of the harder projects I have undertaken to date... http://atariage.com/forums/blog/659/entry-14733-x-y-plotter-table-for-the-ti-994a-computer-final/ Very cool! Sounds like a perfect Forth candidate too. Having a console to test your sub-routines interactively makes projects like this a lot of fun in Forth. I can envision a simplified form of Postscript that becomes a text based device driver. Whispering: don't get distracted by the shiny project, don't get distracted by the shiny project, don't get distracted by the shiny project, don't get distracted by the shiny project :-) Not only would Forth be an excellent choice for speed and ease of implementation over XB, but fbForth 2.0 has built-in access to Floating Point (FP) math; TurboForth and TI Forth have block-loadable FP support; and CAMEL99 has integer-based trigonometry to 4 decimal places! ...lee Quote Link to comment Share on other sites More sharing options...
+Vorticon Posted October 20, 2018 Author Share Posted October 20, 2018 Not only would Forth be an excellent choice for speed and ease of implementation over XB, but fbForth 2.0 has built-in access to Floating Point (FP) math; TurboForth and TI Forth have block-loadable FP support; and CAMEL99 has integer-based trigonometry to 4 decimal places! ...lee Lee, if you or TheBF are attending the pre-Faire jam session in Chicago this year, perhaps we can put together a basic Forth framework during that session to run the plotter and make a joint demo at the Faire the following day. I can bring everything needed from a hardware standpoint. What say you? 1 Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted October 20, 2018 Share Posted October 20, 2018 Lee, if you or TheBF are attending the pre-Faire jam session in Chicago this year, perhaps we can put together a basic Forth framework during that session to run the plotter and make a joint demo at the Faire the following day. I can bring everything needed from a hardware standpoint. What say you? You’re on! ...lee 1 Quote Link to comment Share on other sites More sharing options...
+TheBF Posted October 20, 2018 Share Posted October 20, 2018 Lee, if you or TheBF are attending the pre-Faire jam session in Chicago this year, perhaps we can put together a basic Forth framework during that session to run the plotter and make a joint demo at the Faire the following day. I can bring everything needed from a hardware standpoint. What say you? Sounds interesting. Do you have a doc on the hardware interface to your plotter? When is Chicago again? Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted October 20, 2018 Share Posted October 20, 2018 Sounds interesting. ... When is Chicago again? CHI Friday is all day November 9 at the Hilton Garden Inn and the Chicago Faire is the next day (November 10, 9:00 AM – 5-ish) at the Evanston Public Library. ...lee Quote Link to comment Share on other sites More sharing options...
+Vorticon Posted October 20, 2018 Author Share Posted October 20, 2018 Sounds interesting. Do you have a doc on the hardware interface to your plotter? When is Chicago again? Check the blog link in my first post on this. Quote Link to comment Share on other sites More sharing options...
+Vorticon Posted October 23, 2018 Author Share Posted October 23, 2018 Summary video of the plotter project. https://youtu.be/C4LmvPvJ2Ww 4 Quote Link to comment Share on other sites More sharing options...
+Vorticon Posted October 24, 2018 Author Share Posted October 24, 2018 Albert love... Using The Missing Link for the image loading and processing. 2 Quote Link to comment Share on other sites More sharing options...
+TheBF Posted October 24, 2018 Share Posted October 24, 2018 Hey Doc, I started unravelling your ASM code to convert it to a Forth Lexicon. How many [pixels per row] and [pixels per column] does your plotter have? I have my system in a weird state right now where I broke my ANS file support, but I have a version that can still load source code files. So in theory if I can make this work you could write the image as a text description like postscript, "include" the file into forth, and Forth would interpret it and plot it. That's the dream. The motor driver is a bit tricky, but I think I can do it with a little more time. I also notice that I didn't see line drawing in the video. Is it possible to put the pen down and draw a continuous line with the hardware as is? 1 Quote Link to comment Share on other sites More sharing options...
+Vorticon Posted October 25, 2018 Author Share Posted October 25, 2018 Hey Doc, I started unravelling your ASM code to convert it to a Forth Lexicon. How many [pixels per row] and [pixels per column] does your plotter have? I have my system in a weird state right now where I broke my ANS file support, but I have a version that can still load source code files. So in theory if I can make this work you could write the image as a text description like postscript, "include" the file into forth, and Forth would interpret it and plot it. That's the dream. The motor driver is a bit tricky, but I think I can do it with a little more time. I also notice that I didn't see line drawing in the video. Is it possible to put the pen down and draw a continuous line with the hardware as is? The plotter matches the bitmap screen on the TI, and thus has a drawing area of 256x200 pixels. That said, this is an artificial limitation I imposed when writing the driver code and is reflected in the scaling factor I used which is 12 steps of stepper motor movement per pixel as that produced the best pixel spacing. You could arguably go for much higher resolution, but I doubt the mechanical platform would be up to it because it's not exactly a precisely machined device and has a lot of play in the axes... You certainly could just put the pen down and just run the motors for continuous drawing. I simply did not program any software to do so, but it is something I'd like to implement in Forth for a turtle graphics-like application. Which is where you and Lee come in! I'm super interested in what you can come up with. Quote Link to comment Share on other sites More sharing options...
+TheBF Posted October 25, 2018 Share Posted October 25, 2018 OK. That's all I needed to know. We will keep it safe and stick to the 256x200 and go from there. I have found a simple version of Turtle graphics in Forth. I am going to have to learn a bit about TI bit map mode to have a way to test it. (I am sure I can borrow stuff from Lee's system to get me jumpstarted) P.S. I won't be going to Chicago. My mom is a late stage COPD patient and she is making more frequent visits to hospital to clear her CO2. Not a good sign. Quote Link to comment Share on other sites More sharing options...
+Vorticon Posted October 25, 2018 Author Share Posted October 25, 2018 Very sorry to hear about your mom... 2 Quote Link to comment Share on other sites More sharing options...
HOME AUTOMATION Posted October 27, 2018 Share Posted October 27, 2018 I only today read the part about triggering interrupts upon the status of certain pins on the parallel port... I felt a similar need upon the status of certain pins on 74165 parallel to serial shift registers in my controllers input subsystem.I am curious how you made out with the interrupts. I have a working test design. The point of which is to detect when any input has changed states, without priority, while allowing for any or all input states to remain high or low on all inputs. I wish I could tout it's utility (which is real) however the method is a little too power hungry... could be a little bit more responsive... and would have a complete failure mode should a single interrupt relay fail in the open mode. I would like to bump the relays out of the design while maintaining the simplicity. But for now I've moved on. Quote Link to comment Share on other sites More sharing options...
+Vorticon Posted October 27, 2018 Author Share Posted October 27, 2018 I only today read the part about triggering interrupts upon the status of certain pins on the parallel port... I felt a similar need upon the status of certain pins on 74165 parallel to serial shift registers in my controllers input subsystem. I am curious how you made out with the interrupts. I have a working test design. The point of which is to detect when any input has changed states, without priority, while allowing for any or all input states to remain high or low on all inputs. I wish I could tout it's utility (which is real) however the method is a little too power hungry... could be a little bit more responsive... and would have a complete failure mode should a single interrupt relay fail in the open mode. I would like to bump the relays out of the design while maintaining the simplicity. But for now I've moved on. I gave up on that one because I did not want to use external circuitry. I did however install a load interrupt wire for future use Could you post a schematic by any chance? As for the relay, your solution to the fear of failure is solid state relays. I used one in my slot car controller board. Quote Link to comment Share on other sites More sharing options...
+TheBF Posted October 28, 2018 Share Posted October 28, 2018 I gave up on that one because I did not want to use external circuitry. I did however install a load interrupt wire for future use Could you post a schematic by any chance? As for the relay, your solution to the fear of failure is solid state relays. I used one in my slot car controller board. Another cool device for protection is the opto-isolator. Connects your circuits with nothing more than light! https://www.electronics-tutorials.ws/blog/optocoupler.html Quote Link to comment Share on other sites More sharing options...
+TheBF Posted November 1, 2018 Share Posted November 1, 2018 (edited) As I work on creating a plotting engine for the Vorticon plotter, I realized it might be handy to have a line drawing routine. Years ago a guy in Hong Kong, Dr. C. H. Ting created a recursive algorithm in Forth that is damned hard to understand but amazingly tiny. I got it working today using a Sprite as the "pen". Then I used some compiler tricks and that doubled the speed. I need to create a bit mapped screen with a dot plot routine to test out the turtle graphics. For people with time on their hands here is the line drawing routine in normal Forth. : PLOT ( y x ) FUSE PEN @ SP.Y V! ; \ write x,y as int, to VDP sprite record : 2OVER 2>R 2DUP 2R> 2SWAP ; : 2ROT 2>R 2SWAP 2R> 2SWAP ; \ orignal code : DRAW ( X1 Y1 X2 Y2 -- ) 2OVER 2OVER ( does 4dup ) ROT - ABS >R - ABS R> MAX 2 < IF 2DROP PLOT EXIT THEN 2OVER 2OVER ROT + 1+ 2/ >R ( Y3) + 1+ 2/ ( X3) R> 2DUP 2ROT RECURSE RECURSE ; And here is what it took to double the speed. No assembly required. Correction, I did code the word 4TH, which copies the 4th stack item onto the top of the stack but that's in a library file. \ optimizers compile code words together end to end CODE 4DUP INLINE[ 4TH 4TH 4TH 4TH ] NEXT, ENDCODE CODE 2ROT INLINE[ 2>R 2SWAP 2R> 2SWAP ] NEXT, ENDCODE CODE DIFF(X,Y) INLINE[ ROT - ABS >R - ABS R> ] NEXT, ENDCODE CODE MIDPOINT INLINE[ ROT + 1+ 2/ >R + 1+ 2/ R> ] NEXT, ENDCODE \ optimized version : DRAW2 ( X1 Y1 X2 Y2 -- ) \ 2.1 times faster 4DUP DIFF(X,Y) MAX 2 < IF 2DROP PLOT EXIT THEN 4DUP MIDPOINT 2DUP 2ROT RECURSE RECURSE ; I suspect it could be almost doubled again in hand coded Assembler. I need to compare it to the Bresenham algorithm. Although recursion is pretty cheap in Forth it ain't free. But for small code footprint this one can't be beat. TINGLINE.mp4 Edited November 1, 2018 by TheBF 1 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.