TI 99/4A interfacing

[+Vorticon]

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

[Stuart]

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

[+Vorticon]

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.

[Stuart]

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.

[apersson850]

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.

[+Vorticon]

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

[+Vorticon]

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/

[+TheBF]

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 :-)

[+Vorticon]

 

 

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.

[+Lee Stewart]

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

[+Vorticon]

 

 

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?

[+Lee Stewart]

 

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

[+TheBF]

 

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?

[+Lee Stewart]

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

[+Vorticon]

 

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.

[+Vorticon]

Summary video of the plotter project.

 

https://youtu.be/C4LmvPvJ2Ww

[+Vorticon]

Albert love... Using The Missing Link for the image loading and processing.

 

 

[+TheBF]

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?

[+Vorticon]

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.

[+TheBF]

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.

[+Vorticon]

Very sorry to hear about your mom...

[HOME AUTOMATION]

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.

[+Vorticon]

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.

[+TheBF]

 

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

[+TheBF]

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