Jump to content
IGNORED

Communicate without RS-232


cbmeeks

Recommended Posts

I'm thinking of working on a small project that requires the TI-99/4A and a Commodore PET to "talk" to each other.

 

Normally, this would be a job for serial and while the PET has a serial port, the stock TI does not.

 

I have the PEB but I have not obtained a serial card yet. What I do have is the 32K sidecar expansion that has some header pins.

 

So, I was wondering, how difficult would it be to use some of those pins as crude I/O?

 

All I would need is a simple triggering system. I don't need to transfer data. Just something like:

 

 

10 TI sends signal to PET
20 PET detects signal, runs script
30 PET finishes script, sends signal to TI
40 TI detects signal, runs script
50 GOTO 10

 

Thanks for any suggestions.

Link to comment
Share on other sites

Is the joystick one direction, or bidirectional? I think bidirectional since I recall Peter Hoddie running his "Dueling Banjo's" demo back in the day at Trinity College for the Chicago Fair and I thought he linked those systems through the joystick port. If it is bidirectional, might be simpler just to use the joystick port with maybe an assembly routine for the toggle.

 

Beery

Link to comment
Share on other sites

Everything you'll ever want to know (and a whole bunch of stuff you'd never need to know) about the joystick port:

 

 

http://www.unige.ch/medecine/nouspikel/ti99/joystick.htm

 

Nothing is obvious in that link the port is bidirectional other than the name of the pins are given as I/O.

 

All you can do is attempt to write to the address instead of read, and see what you get..........

Beery

Link to comment
Share on other sites

You can use the joystick port for both input and output - http://www.stuartconner.me.uk/ti/ti.htm#i2c_interfacemight give you some useful information.

 

Although if you're interfacing with a Commodore PET, you really ought to find an IEEE card for your PEB and interface over the IEEE ports - that would be a great project. ;-)

  • Like 2
Link to comment
Share on other sites

You can use the joystick port for both input and output - http://www.stuartconner.me.uk/ti/ti.htm#i2c_interfacemight give you some useful information.

 

Although if you're interfacing with a Commodore PET, you really ought to find an IEEE card for your PEB and interface over the IEEE ports - that would be a great project. ;-)

 

I looked online and the cheapest I could find was $39 + S/H. Is that a reasonable price? There doesn't seem to be many of them around.

Link to comment
Share on other sites

 

for the ieee card for the TI?where?

 

 

Well.....I saw a few of them on eBay and they were $100 or so. Except the one that was $39.95. So my gut told me to just buy it. Which I did.

 

Looks to be in pretty good shape and it's from a seller I've bought from before.

  • Like 1
Link to comment
Share on other sites

IEEE is not a card. It is a standards organization that standardized several interfaces, not just the one implied above, which is, I believe, the IEEE 488 or GPIB (also HPIB).

 

...lee

 

Right. I knew IEEE was an organization. I just assumed when Stuart mentioned IEEE he meant the RS-232 card.

 

So there was an IEEE-488 card too?

Link to comment
Share on other sites

That's a great question. I was thinking the joystick too but wasn't sure if any of the pins were bi-directional.

 

I could just make the PET trigger the "fire" button of the TI and the TI could pulse a pin on the user port of the PET.

Cassette port. It is bidirectional and designed to transmit data or receive data.

 

Of course you would need RXB to pull this off:

          IO                                                   PAGE I12
          -------------------------------------------------------------
 
          CASSETTE INPUT/OUTPUT/VERIFY INSTRUCTION
 
          Format         CALL IO(type,length,vdp-address[,...])
 
           The three different cassette I/O instructions use the same
          format. The write and read instructions physically perform
          Input/Output to the cassette. The verify instruction will
          read a tape and compare it, byte by byte, against what is in
          the specified VDP area. All will report an  I/O error if one
          is detected. No prompts are present with these three formats.   
          These three types control the cassette directly so no prompt 
          will tell the user to turn on or off the cassette record/play 
          buttons. The programmer must inform the user with own prompt.
 
          Programs
          (Presently I have no cassette to write programs with.)
 
          AUDIO GATE
          ----------
          CRU bit 24 is the audio gate which allows data being read to
          be heard. If the bit is set to 1, the data being read is
          heard, and if the bit is set to 0, the data is not heard.
          Setting the bit to a 0 or 1 is done with an IO instruction, or
          a Assembly instruction.
 
          MOTOR CONTROL
          -------------
          There are two CRU bits (22 and 23) used to control cassettes
          1 and 2, respectively. When there is no Cassette IO being
          done, both motors remain on. When Cassette IO is specified,
          the DSR (Device Service Routine) will control the data being
          read. If there are two motor units connected, the data will be
          read simultaneously, or you may have the option of reading
          data from one motor unit and playing the recorded voice from
          another motor unit through the TV (Monitor) speaker. 
          
          *NOTE:
          Compatibility with or without 32K or other devices is not a
          concern as IO needs no RAM to work with. Therefore from just
          a console all IO commands will work fine. If you only have a
          Cassette and RXB you can quickly load/save/verify without
          menus, or just make up your own.

Ports are OUTPUT, INPUT and VERIFY, plus you have MOTOR CONTROL.

I would suggest you use 8 or 16 bits on a two way send receive if you are going for Device controls like robotics.

There are a couple of YOUTUBE video on using RXB CALL IO command for CRU but none on CASSETTE yet.

Link to comment
Share on other sites

 

You can do a CALL IO for INPUT and end with a comma and CALL IO for OUTPUT on other port in a single command!

 

So you are talking SERIAL vs I am talking PARALLEL, which one is faster?

 

There is no issue with INPUT and OUTPUT being the same memory address and you could even use VERIFY each time in that same command.

Link to comment
Share on other sites

seems to me... one issue with CRU bit I/O is that once a port is configured for output it's difficult to reset.

requiring the use of separate CRU ports for Rx and Tx.

 

If you're talking about the 9901, then you can do a software reset of the 9901 to reset the I/O ports you've used for output back to inputs again. A bit clunky but it does work (depending on what *exactly* you're trying to do) - I used the technique to implement an IDE interface on a 9901 on one of my boards.

  • Like 1
Link to comment
Share on other sites

@RXB... looking pretty good! So far...

@Stuart... yes, not exactly sure of the procedure but Don't all the ports reset simultaneously... can the ones needed for the keyboard be simply set again by the program to regain keyboard functions???

@cbmeeks ...

 

cassette motor controls 1 and 2 are on 9901 ports 6 and 7 are on pins 19 and 23 respectively however these drive bipolar transistors which in turn drive opto-couplers... no input here! Output slow.

Magnetic In(port 11) is capacitively coupled by C-409 then on to dual comparators... might work might work as input... might need some additional compponents to interface...

Magnetic Out(port 9) is also capacitively coupled... also a series 6.8K Ohm resistor is inserted... strange as it may sound... I have port 8 listed as an available input... perhaps it's only switched to output mode if the cassette DSR tries to write.

Audio gate is a collector driven output.

 

Rx might work better from the joystick port.

 

Just off the top of my head... I've never done RS232 directly. :ponder:

  • Like 1
Link to comment
Share on other sites

@Stuart... yes, not exactly sure of the procedure but Don't all the ports reset simultaneously... can the ones needed for the keyboard be simply set again by the program to regain keyboard functions???

 

Yes they could. If you're using the built-in keyboard scanning routine, I suspect that that will set them as outputs when doing a keyboard scan anyway - but never tried that so would need testing.

Link to comment
Share on other sites

RXB CALL IO also has CRU of keyboard rows too.

          IO                                                   PAGE I10
          -------------------------------------------------------------
 
          CRU ACCESS INSTRUCTION
 
          Format         CALL IO(type,bits,cru-base,variable,variable
                         [,...])
 
           The IO types 2 and 3 can be used to control devices.
          IO always must be the CRU address divided by 2 as any 
          value above 8192 will be out of range. The cru-base must be  
          divided by 2 as the 9901 chip ignores the least significant 
          bits of the base register it uses. See Editor Assembler 
          Manual page 61. The CRU data to be written should be right  
          justified in the byte or word. The least significant bit 
          will output to or input from the CRU address specified by 
          the CRU base address. Subsequent bits will come from or go 
          to sequentially higher CRU addresses. If the CRU input reads 
          less than 8 bits, the unused bits in the byte are reset to 
          zero. If the CRU input reads less than 16 bits but more than 
          8 bits, the unused bits in the full two 8 bit bytes will be 
          reset to zero.
 
          Programs
          Line 100 display what it does | >100 DISPLAY AT(1,1)ERASE ALL
          for you.                      |  :"THIS PROGRAM CHECKS FOR
                                        |    UNUSUAL KEYS BEING PRESSED
                                        |  , EVEN IF MORE THEN FOUR KEY
                                        |  ARE BEING PRESSED AT ONCE"
          Line 110 scans CRU at >0006   | >110 CALL IO(2,16,3,A,B):: IF
          and reports keys pressed.     |   A=18 AND B=255 THEN 110 ELS
                                        |  E CALL HPUT(24,3,RPT$(" ",30
                                        |  ),24,24,STR$(A)&" "&STR$(B))
          Line 120 more reports.        | >120 IF A=146 THEN CALL HPUT(
                                        |  24,3,"FUNCTION KEY")ELSE IF
                                        |  B=191 THEN CALL HPUT(24,3,"C
                                        |  ONTROL KEY")ELSE IF B=223 TH
                                        |  EN CALL HPUT(24,3,"SHIFT KEY
                                        |  ")
          Line 130 still more reports.  | >130 IF B=251 THEN CALL HPUT(
                                        |  24,3,"ENTER KEY")ELSE IF B=2
                                        |  53 THEN CALL HPUT(24,3,"SPAC
                                        |  E BAR")ELSE IF B=254 THEN CA
                                        |  LL HPUT(24,3,"PLUS/EQUAL KEY
                                        |  ")
          Line start over scan of keys. | >140 GOTO 110

So you can scan for individual keys or entire row of keys using CRU access.

Link to comment
Share on other sites

I'm thinking of working on a small project that requires the TI-99/4A and a Commodore PET to "talk" to each other.

 

Normally, this would be a job for serial and while the PET has a serial port, the stock TI does not.

 

I have the PEB but I have not obtained a serial card yet. What I do have is the 32K sidecar expansion that has some header pins.

 

So, I was wondering, how difficult would it be to use some of those pins as crude I/O?

 

All I would need is a simple triggering system. I don't need to transfer data. Just something like:

10 TI sends signal to PET
20 PET detects signal, runs script
30 PET finishes script, sends signal to TI
40 TI detects signal, runs script
50 GOTO 10

Thanks for any suggestions.

 

In theory....

 

For that simple requirement

 

10 you could use the Cassette interface motor control and a pull up resistor on the PET (if PET has parallel port) for the TI output signal. (on/off from TI)

20 PET reads that bit change on PIO port and runs some code

30 The PET generates an audio tone by toggling a bit rapidly

40 "tone" is Read by the TI on the Cassette receive input via CRU code and TI runs its "script"

 

The TI would need assembly code to detect the rapid change on the CRU input as a signal to run it's own "script".

PET might need assembly code to make a rapidly changing signal.

 

Custom code and a little wiring required. Strange but possible. :)

  • Like 2
Link to comment
Share on other sites

 

In theory....

 

For that simple requirement

 

10 you could use the Cassette interface motor control and a pull up resistor on the PET (if PET has parallel port) for the TI output signal. (on/off from TI)

20 PET reads that bit change on PIO port and runs some code

30 The PET generates an audio tone by toggling a bit rapidly

40 "tone" is Read by the TI on the Cassette receive input via CRU code and TI runs its "script"

 

The TI would need assembly code to detect the rapid change on the CRU input as a signal to run it's own "script".

PET might need assembly code to make a rapidly changing signal.

 

Custom code and a little wiring required. Strange but possible. :)

 

No, your line 30 is wrong. The PET toggles a bit that switches on an air compressor that blows through a kazoo that is next to a microphone that feed an audio tone into the TI. ;-) ;-)

  • Like 3
Link to comment
Share on other sites

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...